Hi,
The problem is that I have a class named RGSpeakerActor, and in the header I have defined an array of Ftexts:
TArray<FText> Texts
In the .cpp I have a #define LOCTEXT_NAMESPACE “SPEAKERACTOR” at the beginning and a #undef LOCTEXT_NAMESPACE at the end.
This array of FTexts is filled inside all the blueprints I have all over my game, so when I run the gather text commandlet it creates all the files with all the texts but they are ordered alphabetically, not by object.
I can’t lend this unordered file to my translator or he will kill me.
This is a sample of how is my .archive file is:
{
"FormatVersion": 1,
"Namespace": "",
"Children": [
{
"Source":
{
"Text": "...but I know you."
},
"Translation":
{
"Text": ""
}
},
{
"Source":
{
"Text": "...or the H key"
},
"Translation":
{
"Text": ""
}
},
{
"Source":
{
"Text": "Are you lost?"
},
"Translation":
{
"Text": ""
}
},
{
"Source":
{
"Text": "Be careful!!"
},
"Translation":
{
"Text": ""
}
},
{
"Source":
{
"Text": "Come close to the mechanism with the red light"
},
"Translation":
{
"Text": ""
}
},
As you can see I have no Namespace or object separator…
Is there some way to define a namespace inside the blueprints?
Can I do the gather text without the alphabetic order?
There is currently no way to namespace text extracted from content.
A couple things come to mind as possible solutions/stop gaps, but they would all require additional code.
If you were to export to .po format it would at least include all the comments with where the text was gathered from. This format is also directly consumable by most translator software so it’s probably a better way to go overall. As with the archive format all that data is kept separately in the manifest file which makes cross-referencing nearly impossible, but those formats weren’t designed to be edited directly by translators.
But they are pretty easy to setup. Insert these snippets into your loc config ini and you’re set. You’ll want to run the import after you’ve gathered and generated archives/manifest but before you generate localization resources files. Export can happen at the end.
;Import localized PO files
[GatherTextStep4]
CommandletClass=InternationalizationExport
bImportLoc=true
;Export PO files
[GatherTextStep6]
CommandletClass=InternationalizationExport
bExportLoc=true
If you have any additional questions or are interested in the code work around let me know.
Thank You for answer! Actually I know about this arrow :), but it doesn’t help e.g. if you need to change namespace of all elements in array. Maybe there is another way to set namespace in C++ code in UPROPERTY definition or something else?
Namespaces will actually be less of an issue for assets in 4.14 since each unique identity (namespace + key, and all asset FTexts get a unique key) will be exported as a unique entry for translation.
‘Namespaces will actually be less of an issue for assets in 4.14 since each unique identity (namespace + key, and all asset FTexts get a unique key) will be exported as a unique entry for translation.’
Erm, how is that a good thing?
I have ‘Loc_press_a’ in asseta, assetb and assetc for example. The translators will see three copies of the identical text since they’re now ‘unique’. Previously there would be one copy of loc_press_a which the po files would translate into each locale appropriately.
It’s a good thing because translators can now translate text based on the context it’s used in, without having to ask someone to go back and re-author some content to allow them to give an accurate translation for that use-case (which also invalidates translations for locales that may not need a unique translation).
Translators, especially professional ones, will have a translation memory available in their translation tools which can automatically apply a translation to any 100% matches.
‘Loc_press_a’ sounds like a key to me. Are you trying to use the localisation system as if it were a string table, rather than provide the native text as the source?
Yes, loc_press_a is a piece of text informing the user to press a specific key, it’s also something that needs translating and may need to be in multiple assets. So the text would be, in that specific case, ‘press start to continue’ and the context is identical wherever it’s used. A better solution rather than insisting everything, even identical strings, becomes a unique entry in a po file is to allow an asset to choose a namespace.
The implementation as is, if you try to put a namespace and key into the advanced settings, what you get is namespace=‘mynamespace [GuidFromAssetName]’ with a key that appears randomly generated. Just try getting access to a specific string across assets, it’s impossible. In 4.13 the text itself became the namespace+key so ‘press space’ appears only once for the translating team.
A workaround is to pop the ftext values into a widget class that’s used across all the UI. Not ideal.
Having identical text duplicated many times in the po files is just unusable for localisation and prone to errors. I agree context is important which is why we prefer to use a token method with an example English string.
Also, 4.14 implementation with enforced unique namespace results in the same actual string stored multiple times in memory.
You have an entry for asseta and an entry for assetb. Even if the translators have tools to automate ensuring the string is identical in each asset, that identical string will be stored in both arrays.
The GUID you mention in the namespace is actually the package localisation ID. It’s there to allow stable keys while editing text, and also to allow people to use custom keys for their text (since the conflict domain is limited to a single package) - these are both features that people have been requesting for a long time.
With regards to memory consumption, this change hasn’t actually affected that at all, as each identity has always had a unique display string, even when we collapsed things together for translation. The reason for this is that when performing a live-culture switch, we just update the display strings in-place and we don’t know which texts are shared in all cultures.
For our games, text doesn’t actually get duplicated very often due to the way our data tends to be organised. Game data is typically stored in Blueprints, Data Tables, or Data assets, and UI data is typically built up from component UMG assets, which results in the same text instance just being referenced or shared rather than repeated in assets.
I will state once again that the localisation system in UE4 isn’t designed to be used to author a string table as source text, and we don’t build it with such a use-case in mind. It is designed to let people author source text as source, without worrying about how the localisation system gathers and processes that.
I’m not saying we’ll never add dedicated string table asset type and integrate it into FText properties, but we haven’t yet because you can essentially make your own string table using a Data Table, where the row name is the key, and the row struct just holds an FText. Admittedly that doesn’t integrate nicely into FText properties, but you could easily expose a function to look-up a row from a given table, and use it in BP construction scripts, C++ constructors, and any other C++ or BP ‘getter’ code to resolve your ID to your text.
From my perspective, if you put the text “Back” (note - not a token or string table lookup, a piece of translatable text) in asset 1, and “Back” in asset 2, you should not have to send two entries for “Back” to your localisation company. You should be able to use the same text and it should ONLY put the one version in the PO file.
The risk is only one of the assets gets translated and the other asset shows the English (or whatever you have as default).
