Non English Localization using translated Message IDs

Hi there,

We have noticed that in creating our po files for languages other then english, that there are entries for both the original msgid and the “translated” msgstr from the po file of the english.

For example, our code contains localization here: LOCTEXT(“SaveButtonText”, “Save Text”);

In the English PO , we wanted it to say “SAVE”

msgctxt "OurGame"
msgid "Save Text"
msgstr "SAVE"  

In for example our Turkish PO we have a field for

msgctxt "OurGame"
msgid "Save Text"
msgstr ""  

AND

msgctxt "OurGame"
msgid "SAVE"
msgstr ""  

If we change the turkish PO “Save Text” msgstr to the desired text (KAYDET), when we run the game it actually shows Save Text instead.

Instead we need to set the “SAVE” msgstr to the text, to get the translation to appear.

This seems a bit counter intuitive, as it using the English translation results as the msgid… And it also means we have double the entries in our po, with half of them being useless.

Is this expected behavior?
Is there something we have done wrong?

,

Is this happening, even if you’re creating a new file within a new project? Or do you feel that the newly saved file included KAYDET is not being updated correctly?

Please provide me a bit more information to go on, that would be greatly appreciated.

This happens even if I remove all the info in our po file in the non english language. So a blank po file in turkish for instance will then contain the original message ids with blank msgstrings (As expected), but also then contain the duplicate msg string from the en file for that message id, as the additional message id. That is it shows both:

#. SaveButtonText
#. Source/OurGame/Private/Game/OGGameSingleton.cpp:394
#: Source/OurGame/Private/Game/OGGameSingleton.cpp:394
     msgctxt "OurGame"
     msgid "Save Text"
     msgstr ""  

#. SaveButtonText
#. Source/OurGame/Private/Game/OGGameSingleton.cpp:394
#: Source/OurGame/Private/Game/OGGameSingleton.cpp:394
     msgctxt "OurGame"
     msgid "SAVE"
     msgstr ""  

Where in our previous game on 4.7 it would just show the first one, which matches the LOCTEXT define of LOCTEXT(“SaveButtonText”, “Save Text”);

This doesnt happen in our en file which is set as our native culture .

Note that the comments generated by the po generation show that both translations are linked to the same LOCTEXT key param and same code line, indicating they are for the exact same LOCTEXT definition.

If we changed our English po to translate Save Text to BOB instead, the second entry would change in all of our non english to have a msgid of BOB.

We also are using the commandline/ini way, not the translation dashboard. I cant attach our ini here or post it apparently cause it is too long. And it won’t let me reply to my own reply… But it was setup like our previously shipped game.

,

I have tested this out the way that’s shown within our [documentation][1]. I did not run into any errors while attempting this. With that being said, you can upload your files to Drive (or something similar) and provide me the shared link. If there are any additional steps that I need to take to fully test this out, please include those. I need to follow your steps directly.

Thanks! :slight_smile:

https://docs.unrealengine.com/latest/INT/Gameplay/Localization/Setup/index.html

Hey ,

We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.

Thank you!

A long term follow up for others, I eventually realised this was intended behaviour and confirmation is here too https://answers.unrealengine.com/questions/437460/spanish-archive-file-uses-english-translation-text.html

To get around this I made the native culture in the localization export from en to a subset of en (I choose the wonderful Pitcairn Island en-PN) and made the loc for that the exact default that the game exported).

Then we could safely edit the en localization po’s and no worry about breaking localization everywhere else.