Localization Dashboard doesn't correctly compile all translated text

I am using the localization dashboard to create subtitles in 12 different languages. My native language is set to English. I have copy/pasted the translated subtitles from every language and compiled the results. For the most part, the correct subtitles are displayed in the translated language. However, there are some lines which are displayed in english, despite the language/culture being set to something else.

After much digging around, I found that this is a problem with the tool which compiles the language from the “Game.archive” JSON file into the binary “Game.locres” file. I have verified that the Game.archive file contains the translation, verified that the key is correct, and that I’m doing everything correctly. I then compiled the translated language into the “Game.locres” file. I then opened up the Game.locres file in a hex editor and looked for the translated text which was giving me trouble. Sure enough, the translated text is in English instead of the translated language. I have verified that this same line is causing problems for all of the other languages.
I have no idea why this line isn’t being translated. There’s nothing unusual about it, there are no special characters or malformed characters in the key or native text.

I have attached the “Game.Archive” and “Game.locres” files for the finnish language in a zip file. The key which is giving me trouble is “OceanPlastics_HS02_03” which can be found at line #173 in the game.archive file. If you open up the game.locres file and look at address 0x166B, you’ll see the compiled text is in english instead of finnish. I have tried to delete the game.locres file and regenerating it by compiling the language, but it made no difference.

Can you provide your Game.manifest too? That’s what actually acts as a filter for the LocRes.

Here you go! I’ll take a look at it on my end to see if I can spot anything funky going on as well.

If it helps, I found the key in the game.manifest file as well at address 0x20C6

Another funky problem I found:
I am gathering text from the project to generate the manifest. All of the text lives in a string table. When I import a specific caption in english, and then apply translations to it, then compile the translations, the translated text shows up correctly in the finnish culture, but not in the portoguese culture (it defaults to the native english language), even if there is a portoguese translation.

I have tried to step through the engine source code at the moment it tries to compile the languages, but from what I can tell, it creates a separate thread of execution and uses a slate window to render the progress of that thread. I’d like to step through the worker threads line of execution to see if I can catch the particular translation which is not being translated to see if there’s a logic issue or a data issue, but I’m at a bit of a loss on how to break on a separate thread of execution if I don’t know what code section is being run in a separate thread.

So, your translation is “stale”.

The source text in the manifest is:

By collaborating with other like minded companies, I think we can make a significant difference to this problem.

But the source text the translation was made against is:

By collaborating with other like minded companies, I think we can make a significant differnce to this problem.

It look like a typo was fixed, but doing this will invalidate the translation by default, but until recently the translation editor (which is actually a separate tool to the localization dashboard) didn’t understand the concept of “stale” translations so wouldn’t broadcast this fact (the recommended PO export/import flow does understand “stale” translations).

If you know you don’t care about “stale” translations, then there’s an option under the compile settings in the localization dashboard to skip the source check and force an existing translation to be used by the LocRes files, even if we consider it to not be a 100% match to the current source.

It actually creates a separate process, but if you want to debug the localization pipeline you can run your editor with:

-run=GatherText -config=Config/Localization/Game_X.ini

Where “X” is one of the steps, eg) Game_Gather.ini, or Game_Compile.ini (you can find these files in your projects Config/Localization folder).

First, thanks for looking into this over the weekend. Much appreciated. I’m crunching to meet a deadline and I wasn’t sure I’d get an answer in time, so I started working on another approach where all of my translations are stored in string tables. I’ll try with the “Skip Source Check” enabled before I commit to my drastic alternative.

Also, I’ve tried the export / import of PO files, but it always failed for me. Here is a screenshot of the error window and the error message.

Would the source staleness problem be fixed with more current versions of the engine, such as 4.20?

Single culture export/import was broken for a while, but exporting/importing all cultures worked fine. Both that and the translation editor not reporting stale translations as untranslated were fixed in 4.20.