I’ve gathered all of the text in my game, and created an archive in a different language. However, there are a number of text strings that are the same, but used in different locations. In the Translation Editor I can see what these locations are, and I can set a translation to use, but when I run the game in the specified culture, only one of the relevant text strings is being localised. I assumed that I would be able to set a translation to use for each of the individual localisation keys, or that the same translation would be used for both, but this isn’t the case, and I don’t seem to have any control over this. Am I missing something obvious?
Localization Dashboard - Unable to assign translations for two keys of the same text string
The localization system in UE4 collapses identical strings within the same ‘namespace’ to use the same translation.
So in what I can see from your screenshot, you have a single string STANDARD which is used in quite a few places, but all instances use the same namespace, which is blank in this case. This means all those instances should be using the same translation, which in your case should be GERMAN.
It looks like you may have a non-standard way of managing your data which could be the source of your problem. It seems you have all your text in specific localization assets, this isn’t necessary in UE4, but shouldn’t be a problem. I can’t be sure how you’re referencing this data. Make sure you aren’t going through an FText::ToString() or FText::FromString() transformation. This breaks the link to the translation look up and could cause translations to appear to not work in some scenarios.
Okay, I think I’ve figured out what was going wrong. There are several instances in the game of the same text string in two locations, where one of them is in all caps, and one of them is lower case. This seems to confuse the localisation system; they’re listed as the same source string, and you can see both of the keys, but for some reason the translation isn’t being used for the upper-case string. Perhaps storing the string as lower-case and using a function to capitalise it is the way to go.
The localization system itself is definitely case-sensitive, this would be a major bug otherwise. I’m guessing that there is a bug in the translation editor itself.
We don’t expose a capitalization function on FText which means you’ll be breaking the translation link in order to go through a capitalization process. A process that doesn’t make sense for quite a few languages.
Try opening you *.manifest file in a text editor. This file has all of the source strings and the information about where they were gathered. Make sure that your case-sensitive strings have separate entries in this file. Next look for the matching *.archive file and open that in a text editor. This file contains all the translations for a specific locale. Look for your two source strings again and ensure that there are two entries.
Let me know what you find.
The .manifest file does only seem to have one entry for the case-sensitive strings. Similarly, there’s only one entry in the .archive file. For the record, I’ve used the Localization Dashboard to do all of the gathering and compiling, so it’s very likely it’s a bug in that system.
Just to clarify, is it the strings themselves that differ by case, or is it the keys used to identify those strings?
From the screenshot you posted, your keys appear to be GUIDs, so I’m guessing you mean the strings themselves.
Yes, it’s the Strings that are different. For example, I have a button with the text ‘Options’ on it, and then the heading for the options screen which reads ‘OPTIONS’.
Just to let you know, there was a bug in our gather process for assets where strings that only differed by case could be merged together. This has now been fixed, and will be part of the 4.11 release.