Grammatical gender and case: why your templates break in other languages

A string like You received {itemName} looks perfectly safe. It has one placeholder, one clear meaning, and it reads naturally in English no matter what item name goes in. The moment it is translated into a language with grammatical gender or noun cases, that safety disappears — because the words around the placeholder may need to change depending on the noun that fills it, and the noun is not known until runtime.

This is one of the most common sources of grammatically broken translated text in games, and it is worth understanding at a basic level even if you never write a line of the target languages yourself.

What grammatical gender actually means

In many languages, every noun belongs to a grammatical class — commonly labeled masculine, feminine, or neuter — regardless of whether the thing it names has any real-world gender. A sword and a shield can belong to different grammatical genders in the same language, for no reason connected to their meaning.

The article, and often the adjective, in front of the noun has to agree with that gender. So a phrase meaning 'the new sword' and a phrase meaning 'the new shield' can use different words for 'the' and different endings on 'new', even though the sentence structure is otherwise identical. A template that hardcodes the article or the adjective ending around a variable item name will be correct for some items and wrong for others.

Case adds a second dimension

Separately from gender, some languages inflect nouns by case — changing the noun's ending, or the word itself, depending on its grammatical role in the sentence (subject, direct object, possessor, and so on). 'You received a sword' and 'the sword's power' might use two different forms of the word for sword, not because the meaning changed, but because its role in the sentence changed.

Combine gender and case and you get a genuinely large number of possible forms for a single noun. A translator working from a source file cannot always predict which form is needed just from seeing the noun in isolation — they need the sentence, and often the specific item name, to get it right.

Where this breaks in practice

The failure mode is always the same shape: a template concatenates fixed text around a variable, and the fixed text was written assuming one grammatical form that does not hold for every possible value of the variable.

// Looks safe in English, is not safe once translated
"You received {itemName}."
"New {itemName} unlocked!"
"Equip {itemName}?"

Strategies that actually help

There is no single fix that works for every language, but a few approaches reduce the damage substantially.

• Reword templates to avoid agreement entirely — 'Received: {itemName}' instead of 'You received {itemName}' sidesteps the article-agreement problem because there is no article next to the variable
• Where a neutral phrasing is not possible, provide gendered or case-specific variants of the template and let the translation choose which one applies per item, rather than forcing one template to cover every item
• Ask translators early which specific templates are dangerous for their language — a native speaker will spot an agreement problem in seconds, but only if they see the template with real item names substituted in, not just the isolated source string
• Keep item names and templates in separate reviewable columns so a translator can check every combination, rather than translating templates once and hoping they hold up against every item added later

The takeaway for engineering

This is fundamentally a string-concatenation problem, not a translation-quality problem — no amount of translator skill fixes a template that structurally cannot agree with every value it might receive. The fix has to happen at the template design stage, ideally before any language with gender or case is even in scope, because rewriting a whole item-name-and-template system after launch is far more expensive than designing around the risk from the start.