Re: 奴隷との生活 -Teaching Feeling-
Nomake Wan said:
Here is the script with the demo lines translated!
Okay, thanks! I'll have the trial patch ready later today. Now we just need an ambassador to contact Ray. Anyone up for the job?
Update: The trial patch is ready to go (mostly). I was able to play all the way through to the end, but I encountered some crashing at times near the endgame when I stopped なでing. Guess Sylvie really didn't like that. Going to try triggering it on an unpatched copy, to rule out the patch as the cause.
Nomake Wan said:
However, notice that line 1121 appears to be the "bought" part of buying clothes. Line 1156 is how they should look, line 1155 is missing 1121. Plus a bunch of those \n lines should be separate (which actually caused the majority of the lines at the end to appear as 'untranslated' when they had been translated previously, such as Line 1706 and Line 1100 to name one example).
Hopefully this helps.
The line 1121 discepancy is due to grammatical differences. If you look a fresh copy of shop.ks in Japanese, you'll notice that for all of the lines that are missing 1121 at the end (e.g. 1155), the game prints the first part of the sentence then jumps and prints を買った. So for line 1155 in the dict, it jumps to label *c_e5 in the scenario to print 白いワンピース then it jumps to label *color and prints を買った. When I first constructed the dictionary, I set up a translation entry from を買った→;を買った so that line 1155 wouldn't print, but would be commented out so that when exporting from the translated scenario files the translated lines would match up 1:1 between Japanese and English.
As for lines 1100 and 1706, that was actually a subtle change to the text, not a newline issue. The demo says 「[name]」ってお呼びしますね while the release says 「[name]」とお呼びしますね. I suspect the other translation misses were due to similar changes (and expect that future revisions by Ray will cause similar issues). It's unfortunate that the part after the newline got caught up in this discrepancy, but the alternative (i.e. not joining newlines) would give you less freedom to change the flow of the text.
If you prefer editing scenario files to editing the dictionary, then I recommend this workflow moving forward:
- Make a copy of the original untranslated scenario files.
- Apply the translation dict to the copy using my script.
- Make nonstructural changes to the files, if needed.
- Test the changes ingame and return step 3 if needed.
- Export lines from the original scenario and changed scenario.
- Join the exported lines to make an updated translation dict.
- Make structural changes to the scenario files last.
This workflow should minimize errors and headaches, but you need to be aware of a few things. First, in step 3 you
must not insert or move around tags that split the text. That means any tag except the following:
Code:
[l], [p], [r], [emb], [lr], [name], [miyage]
Also during step 3, you must not remove any passages of text completely. For example, if you were translating shop.ks and you came across を買った, you should comment it out (by putting a ; in front of it) instead of deleting it.
As a corollary to this, when you export the lines in step 5, both files should have exactly the same number of lines. This ensures that we have a 1:1 mapping between the files, which makes joining them trivial. As long as you follow these rules, you are free to edit the text as you like (even inserting or removing line breaks).
The second thing you should be aware of is duplication. The translation dictionary should only have one entry for each unique passage of Japanese text, so you must remove duplicates in the Japanese column after you join together the exported lines. That means you either have to either be aware of duplicate passages and change each one as you're editing the scenario files, or you have to take a hands-on approach to removing duplicates after joining the exported lines. Both ways are tedious and error prone, which is why it may be a good idea to just edit these directly in the dictionary.
Now, I can handle step 6 for you if you'd like (it's also pretty easy to do it yourself with Excel). But if you don't follow steps 1 through 5 (and verify that the exported line counts match in step 5), it takes a lot of manual work to produce the translation dictionary, which means errors can creep in and we both get headaches.
This workflow might make step 7 more difficult for you (since you'll need to reapply your structural edits every time you want to update the translation). I think we can probably handle this using GNU diff to create a patch of your structural edits, but things could get hairy when the game gets updated or if you decide to insert or delete line breaks when editing the scenarios (since GNU diff cares about line numbers). On the other hand, since the structural edits would all be together in a patch file, you wouldn't have to worry about forgetting any of them when 1.20 rolls around.
One last thing, you can put a '_' in front of any special character at the beginning of the line to escape it. So instead of "...*cough*" you could do "_*cough*".
