Unreal: Letting translators use gender information

If you want to add gender information to strings in Unreal, you can do it with {var}|gender(masculine, feminine, neuter) construction. Then you pass the ETextGender value as {var} to the format node or function and Unreal selects the correct form for you.

Quite often though, you don’t need this in English. And you’d prefer to keep your text clear instead of adding it just in case. You can do it while still letting your translators take advantage of it.

The trick is to pass the string through a format function or node anyway and pass the gender information. Then your translators will be able to add the above construction themselves. You’ll just need to agree on the pattern for the gender variable names and support it in code or blueprints.

Agree on the name or pattern for gender variables

For one of the projects we just agreed that it’s going to be {g} for speaker gender. So translators knew they can add {g}|gender(...) whenever they needed to branch on the speaker’s gender.

A full solution would be to come up with a pattern for all the relevant aspects of a string, e.g.:

1. Speaker gender is always passed as {speaker_g} if it’s a dialogue line and the speaker isn’t fixed.
2. Target gender is always passed as {target_g} if it’s a dialogue line and it’s targeted at someone in particular and this target isn’t fixed.
3. For any names of people (in the broadest sense of “beings with a non-grammatical gender that doesn’t change after translation”) mentioned as variables in text, you also pass their gender with a _g suffix. E.g., for {hero} you also pass their gender as {hero_g}.

Examples: Go get {hero_name}, {player_name}! said by an NPC to the player would also supply the gender of the mentioned hero as {hero_name_g}, the gender of the speaker as {speaker_g}, and the gender of the player as {target_g}.

A popup You've spotted {gendered_unit_name} in the forest nearby. Attack or leave them be? (not a dialogue line, not addressed to anyone in particular) will only provide the unit gender as {gendered_unit_name_g}.

The best way to explain where and which variables are available is to add that information with a bit of a comment to the string context. You can even do it automatically since you have a clear system for these variables.

E.g., if you unify your hero and unit variables and always pass gender with them, you can write a script that’d add this information to every line that has those variables. If your dialogue ids follow a pattern, you can use that to add information about the speaker/target gender variables along with more information about the speaker and target, if any.

Clearly limit the scope where gender constructions can be added

You want to communicate clearly where translators can add gender constructions.

The best way to do it is by adding this information to the string context, as described above.

Structuring your content and ids in a way that makes it obvious what is what also helps. E.g., if your dialogue ids follow a pattern, translators will get used to it and know what tools are available to them when they see a dialogue line.

If it’s limited to a specific file or files, you can just communicate that it only works in particular files. But then again, if it’s limited to a whole file or files, you can just add this information to all strings context in those files.

Always put strings within that scope through a format node with gender info

Don’t forget that you have to always put strings like this through a format node or function and supply all the potential variables.

One way to go about it is to just add all the needed pins to a format node:

Another is to write your own wrapper that would accept speaker, target, and mentions of the relevant type that contains both the name and gender among other information, and then unpack it into the format variables following the agreed pattern. E.g., you’d pass your Hero object to it, it’d unpack it to {hero} and {hero_g}, and pass it to the string in a format node.

Warnings and caveats

This is by far not an ideal grammatical system for gender branching in a game. Depending on what you have, you will encounter fewer or more edge cases.

E.g., if you use it for units and some of your units are non-grammatically gendered (like, Hunter being male, or Enchantress being female) but some are not (like Ballista or something poetic like Hand of God), and both types of units can go in place of the unit variable then it’s going to be a mess anyway. Grammatical gender for the latter category will change with translation so whatever you assign for English won’t work in other languages. And then again, what is the ballista gender in English? :D

A way out of that mess would require translators to be able to specify the grammatical gender of the translated unit name. Which is a whole other layer of complexity.

The same goes for heroes, speakers, and everything else. This works for things that have defined non-grammatical gender that doesn’t change with translation.