Setting up format text for localization

Hi,

I wondered if I could get some pointers or best practices for setting up format text nodes for localisation.

There’s just some things I can’t get my head around how to cater for so many language variations in these 2 examples.

  1. I have a building (wall, ceiling, floor) that can be made out of multiple materials (brick, stone, wood).

In my format node I would currently think of displaying like the following, where the same names are used in various ways (as nouns or adjectives etc)

the format I have : and the text I am expecting to display

  • {material} {building piece} : wood floor, stone wall etc
  • This {buildingpiece} is made out of {material} : This wall is made out of stone, This ceiling is made out of wood

The worry is that in some languages a lot could change in these sentences. I’m thinking some languages would want “floor of wood” instead of “wood floor” or even something entirely different like in polish “drewniana podloga” where the the wood (noun) = drewno, and the wood(en) (adjective) = drewniany are completely different, but the engine would make them both use the same namespace.

  1. We have armour pieces in our game: chest, head, leg armour for example. And we have an enum for where a piece of armour should go where the types are chest, head, leg in the enum.

we then will want to display

  • {bodypart} armour
  • this armour goes on your {bodypart}
  • this armour reduces damage taken to the {bodypart}
  • shoot an enemy in the {bodypart}

In Polish, for example, we can not give a translation of the words “head” “chest” “leg” without knowing the rest of the sentence first, because the ending of the word changes based on the circumstance ( to the… , in the…, of the… etc.).

in different languages the localisation system in ue4 will let the translators rearrange the format, but without knowing what the variable will be or what all posibilities for the variable are, they may not always be able to give a good translation.

  1. We are thinking of setting all text namespaces to “MyGame”, and then finding individual bits of text that wouldn’t fit into this in a separate namespace, is this a good practice?

for eg. the word “fire” would be used as a word for flame damage, or “click to fire weapon”, so would need a different namespace. But the word

So in all, what should I be looking at implementing across our codebase and blueprints to handle these?

many thanks

ricky

Hi Ricky,

Points 1 & 2 are both concatenation issues. Concatenating natural language in a generic and perfectly localisable way is very difficult, and is not something we provide out-of-the box as it requires context that we don’t have.

We would advise you avoid this sort of thing where possible (ie, rather than inject an item name into a tooltip, you define a tooltip per-item), otherwise you’ll have to provide your own solution that takes into account your domain specific knowledge and set-up.

FWIW, 4.13 adds support for gender forms in format operations, so you could build more accurate strings if you fed the culture-specific gender of each argument into your list of format arguments so that translators could query it as part of their translation, although this won’t help with any other grammatical differences a language may have.

In addition to gender forms, 4.13 also adds support for plural forms so that you can localise things like “There is 1 cat” and “There are 4 cats” correctly. You can find more information about plural/gender forms in the 4.13 release notes (search for “LOCALIZED TEXT FORMATTING IMPROVEMENTS”).

With regard to point 3, you’re correct that we currently collapse identical strings within the same namespace to have the same translation, however that will change for 4.14 where each identity will be exported as a unique entry, and translators will instead use their translation memory to resolve duplicates (and hopefully provide more accurate translations).

Thanks,
Jamie.