UMG / Localization Best Practices for strings & major issue

Hi all,

So when setting up Localization (I’m using the Localization Dashboard, which is not in the scope of this question), here is my desired work flow but it appears it does not work this way.

The basic idea that I’d like to operate on (but doesn’t seem the way UE4 works) is to be able to have knowledge of pre-made localization keys (Read – Namespace + Lookup Key) and be able to enter that on a Text Content block of a widget and have the widget do the loc look-up and display the culture specific translation. However, it appears entering text into the Content blocks automatically tells the localization tool that it should make a new key (and NOT using something that already exists).

Create a loc key and gather text with Loc Dashboard (confirm the translation was found and added into the loc files):

Here is an example
NSLOCTEXT(“Game”, “YesTag”, “Yes Plz!”);

Then follow these steps:


  1. Setup Blueprint Widget with a Text Block
  2. Set the Text Blocks “Content | Text” to be “YesTag”, Also set the Namespace to be “Game” in the dropdown to the right (Note the KEY, lets call it “GenKey”).
  3. Run game and watch it not look-up the NSLOCTEXT you created earlier, instead it acts like what you entered in the Text block’s “Content | Text” to be the Source Text for a new translation with namespace = “Game” and key = “GenKey”.

This feels problematic to me from a technical standpoint. I understand how it is easy to instantly create source texts (which could be a valid english translation and you’re done!) from a designer standpoint, but UMG doesn’t provide any means to use existing translations already due to the auto-generation of new loc key’s when entering text.

More importantly (and dangerously), if I change that text in anyway, the KEY value will be re-generated so if a bunch of translations were created for a specific Widget TextBlock and someone accidentally changes that text (and even if they change it back), they’re now effectively unbound because the KEY on that Text Block’s text content changed. This would create a headache for the loc team which could be inadvertently caused even if someone attempts to watch out for this issue and avoid it by changing back to the original text.

In the following - Ignore the binding function, the same result occurs for the FText values. Attached are images - same text, made an “accidental” edit between steps 1 and 2 but reset to the previous text:

99615-step1.png

99616-step2.png


So With all this in mind – What is the best practice to effectively use existing localization strings in a manner that doesn’t require me to make tons of very simple binding functions to do localization text look-up? The recommendation I’ve gotten thus far is to accept the workflow and modify the entries that are gathered afterwards and move forward like that. It seems reasonable and still a better solution to lots of binding functions in blueprints. What about the case of key regeneration? Seems like it is simply generating a new GUID everytime.

Also is there an easy way to get re-usability out of repeated strings in your UMG elements with the current way UE4 appears to do things in UMG?

Thanks very much!

Hello MrCorzell,

I have provided a link to a similar question. Could you take a look at the last answer given and let me know if this answers your question about having different keys for each change?

Link: [BUG] Unable to localize two words with different meaning - Programming & Scripting - Epic Developer Community Forums

If I misunderstood your question, could you provide a more detailed list of reproduction steps so that I can make sure that we are on the same page?

The provided link helps explain some of the thought processes behind localization in UE4, but it still doesn’t really solve the question of how we can easily reuse existing tags that localization have laid out (in say, another UMG Label or using NSLOOKUP from source). The link makes it sound like the only thing that matters is that the source (pre-translation text) and namspace is the same ( key don’t necessarily seem to be relevent) and it’ll auto-magic resolve everything?

Say I have NSLOOKUP(“Namespace”, “String1”, “Hello”) defined somewhere in our source files for localization.

How would I bind this specific text to a UMG widget without creating a blueprint binding to for the value that does a localization look-up using the namespace and key with the “Find Text in Localization Table” bp function?

The way the UMG bindings work seem to be directly at odds with how developers want to (all the experience I’ve had with other engines / UE3) use localization which would be hand off a namespace / key to the engine, which will return the localized text in the current culture / language.

Thanks, this will help, I’m sure Loc is workable, I am just not seeing it as of yet.

edit: Whoops, fixed incorrect statement about namespace.

Hello MrCorzell,

From the information provided I have written up a request for what I believe you are asking for and I have submitted it to the developers for further consideration. I have also provided a link to the public tracker, please feel free to use this link for future updates.

Link: Unreal Engine Issues and Bug Tracker (UE-34242)

Make it a great day

Thanks very much! This feels like it would be a nice feature to have.

Cheers