So, as I mentioned earlier, im currently trying to set a Git (Desktop or Fork) versioning, to see if tracking files modifs can help speed up a possibly "safe/manual" TL process
And first problem : all decrypted text files are encoded as SHIFT-JIS, and no git program i managed to run seem to display japanese text correcly, just scrap/garbage symbols, pure joy for the eyes :3333333
For now i havent managed to find any solution to either force git programs to correctly display (or convert before doing diff) shift jis files, or even mass (batch ?) convert all txt files into utf-8 encondig
(tho id prefer not doin the last one to avoid mess with code)
Here goes another row of madness -w-
Update : looks like i finally found a function to force git display shift jis files afterall xD
(*.txt text working-tree-encoding=SHIFT-JIS)
At least i can see / track the modified japanese text now >:3
Update 2 : Now git refuses to apply diff encoding to all txt files when staging/commiting because among them theres some utf-8 files
The nightmare will never end -w-#
Update 2.2 : only solution i found so far is to manually convert every single utf-8 to shift-jis to have git not go ptsd when trying to commit them for versioning
But thats exactly what im trying to avoid if update function makes decrypting Text_Script necessary, thus needing to reconvert every reluctant utf file again...
Why did they (the git team) had to make utf-8 the only encoding for git diff display, holy hell -w-###
Update 2.3 : at least git renormalize helped identify all the utf-8 files in text, but still a pain not to be automatable
Update 2.4 : OOH ! Seems like renormalize skipped / ignored unre-encodable UTFs and applied the SHIFT-JIS encoding to the commit tree O.O
Guess i got my clean base to try some handycraft translatishery now hehehe >:3cc
Update 2.5 : OK, now theres some serious level of witchcraft goin on lol
Inside SubEvents there are some JIS files that worktree-encode doesnt display right or are considered as UTFs for some reason ? oO
Luckily theres only 2 of them, so i can allow myself to deal with these manually, as long as everything can be tracked this way uwu
Update 3 : Apparently I was wrong about the update option, which i believed was to download latest version / files. Instead it just tells the player the last version is aviable on the DL site for download.
However it doesnt change much since the modifications can be tracked now.
The TL process, if running properly, will only have to add / edit the updated files.
Update 4 : As I was expecting / afraid of, there are some japanese text lines that seem neither attached to text script, nor part or image display -w-
Some game visuals, for certain text boxes or choice buttons, seem to contain text i cannot locate or find among the text/image datas.
Some examples in the very begenning : the text boxes from the save/init message, the update / tech assistant message, or the choices buttons at start when asked to skip the prologue.
Which make me suspect these ("floating strings") lying within the files that shouldnt messed with : the map files
It seems like there will have to work with Wolf Editor after all... -w-
As long as the map files can be edited, i dont care about reexporting the game, as long as the modified files do their job
For now all i can do is keeping these (manually typed) lines somewhere for later translation as long as these cant be located
Update 4.1 : Slowly finding the strings within the map events, just need to test if edited maps dont cause problems -w-
Update 4.2 : Due to some strings being hidden within certains commands and not accessible by Wolf Editor search, im currently using Dreamsavior's Translate++ to access common event data and reexport common event file, and so far it works. But holly hell, theres a lot of system text in here lol
You must be registered to see the links