we use English as native/default language in our game. Our texts inside the game (i call them loca keys) are in English, but not always represent the final English texts. For example, we changed some of the texts to have an entire different meaning during our localization process. Now it seems the native language is not being localized even though we added an English localization file (inside the localization dashboard).
We cannot change the loca keys, because it will screw the entire localization of all other languages! What can we do to localize our native/default language (English) as well?
We currently don’t have anyone on my immediate team that has much experience using the localization tools in the editor, so I’m going to try to learn more so that I can help you with this issue. In the meantime, have you followed the tutorial posted here for how to use the dashboard?
Also, can you try to expand on what you mean when you say “Our texts inside the game (i call them loca keys) are in English, but not always represent the final English texts”? Do you mean that you’re doing something special, or that the “translated” versions of the English text simply aren’t “translated” and really just appropriated to mean something else entirely?
Thank you for taking the time. The localization itself is working just fine, usage of the Dashboard is no problem at all. We gathered out texts, exported them as .PO files, translated them and re-imported them. The translations also do work in the game.
I’ll elaborate on what my issue is:
Are texts written in the game, for example in our menu are in english. After gathering all the texts and exporting the .PO file with the originial english ‘loca keys’ i do not want to change these originial texts in the game, because then i would have to redo all other language translations for this key.
So when i realised that i wanted to change some of the original english texts, i decided to also create a translation for english, however, my english translation is never translated in the game (i guess due to the fact that english is set as primary language). Therefore my question was why my primary language is not being localized.
UPDATE: After some more testing though i realised the following. The original, primary language should not be a language you want to use in-game. You should never translate the primary language, because it messes up the whole localization.
The way the localization Dashboard works right now, it’s missing a critical feature, which would be to either, except localizaitons for the primary languge or to set some kind of original language, which only contains all the keys and which never changes. We worked around the issue by creating another language ‘en-US’, which now contanis our english translation, and using ‘en’ as a ‘dummy’ for all our original loca keys. It’s hacky, but it works.
Here are two screenshots, which might help to understand what’s gonig on:
Thank you for explaining. I looked into the workflow for the Localization Dashboard and messed with it some myself and I’m wondering something. When you decided you wanted to change some of the original text and then added another English culture, did you add “en”, “en-us”, “en-uk”, or any other of the English-Region combinations? If so, if you wanted to see those translations, you would need to select that specific combination as your active culture to see the translated version.
From at the time that I’m doing this, I’ve set up a simple actor blueprint with a text variable that is printed on the BeginPlay event. My native language is “en” and I’ve set up a translation for “en-us” that modifies that string. If I launch in Standalone directly without any console commands, the en-us translation is used because the editor is in en-us by default. If I use the “-culture=en” console command, I’m given the native (source) text.
I believe the confusion here is coming from the fact that the editor’s default culture when using en-us Windows is “en-us” and not just “en”. Could that explain what you’re seeing?
When people have done this in the past, we’ve recommended that they use en-US-POSIX as their “fake” native language, as it’s not something that will ever be used in practice.
What you’re doing here (using “en” as your “fake” language, and “en-US” as your real language) just isn’t going to work well - for example, my culture is set to en-GB so I’d still see your “fake” language.
4.14 changes the way translations are keyed, so that they’re no longer keyed directly against the source text. This means that you can copy-edit your native text without losing your translations at runtime (caveat: you’d need to enable using “stale” translations as we do still check the translation source matches the active translation text by default to preserve the old behaviour. Also note that the PO export will still export any “stale” translations as an empty string regardless of that setting).
