Why Word-for-Word Translation Fails
When you build an interface, your code silently encodes assumptions about English grammar. Word order, singular/plural logic, and gendered nouns all seem like natural parts of sentence construction until you try to render the same UI in another language. The best i18n libraries handle complex plural rules and date formatting, but they cannot fix strings that were never translatable in the first place.
A basic example: an image subtitle that reads “Added: January 1.” If you split this into a static Added label and an interpolated date, you run into two problems. The colon is a syntactical-descriptive mark that many languages handle differently, and the word order—verb before object—fails in Dutch (which puts the date first) or Korean. The fix is simple: translate the whole sentence, not its parts.
The Cost of Reusable Components
It is standard practice to abstract shared UI into a single component. If your app supports images, videos, and generic files, you might build one <StatusBar> that takes a fileType prop and interpolates it into strings like Select the {fileType}. From an engineering standpoint, that is efficient. From a translation standpoint, it can break completely.
Interpolation is an essential i18n feature that lets you mix dynamic and static text. But it creates problems that only surface when you deal with grammar that English does not have. Keeping one shared component means every language must bend to English sentence structure.
Pluralization Is Not Binary
English treats plural as a simple singular-versus-other distinction, including for zero items. Other languages have more categories. The Unicode CLDR defines six plural forms: zero, one, two, few, many, and other. Hindi uses a singular form for zero; Latvian has dedicated forms for zero, one, and other counts.
Polish demonstrates the complexity. It has distinct endings for “one” (1 pies), “few” (2–4, as in 2 psy), “many” (5+ as in 5 psów), and “other.” The rules are not intuitive: 22 dogs takes the few form (22 psy) because the number ends in 2, but 12–14 use the many form (12 psów). No amount of singular and plural props can capture this.
Gender Affects More Than the Noun
In gendered languages like French, the article and adjective change with the noun. Translating “The file is ready” gives three different French strings:
- “Le fichier est prêt” (masculine)
- “L'image est prête” (feminine, with elision)
- “La vidéo est prête” (feminine)
Interpolating {fileType} into that sentence gives you no way to pick the correct gender form. Any hardcoded article or adjective will be wrong most of the time.
Declensions Change the Whole Sentence
Some languages decline nouns based on their syntactic role. Polish, for example:
- “I like your dog” → “Lubię twojego psa” (object form)
- “Your dog is cute” → “Twój pies jest słodki” (subject form)
The same happens in the plural, with additional changes to adjectives and pronouns based on case and number. A plural “you” plus plural nouns yields yet another form: “Wasze pieski są słodkie.” Quechuan, Indo-European, and Bantu languages all have similar systems. Old English had declensions too, but Modern English lost them, so they are invisible to most developers today.
Do This Instead
The recurring failure mode is treating a sentence as a template where you slot in dynamic values. UI text should live in the translation files as complete sentences. The translator, not your component, decides where the date, the noun, or the gender agreement goes.
- Translate full strings, never fragments. Placeholders that get concatenated with static text create grammatically impossible sentences in most languages.
- Use your i18n library’s built-in pluralization and gender support rather than hand-rolling a
count === 1check in your component. - Do not abstract away grammatical variety. A shared component for status messages will fail if one translation needs “image ready” and another needs “video ready” with completely different word order and agreement.
- Give your translators full sentences with context, not a bag of words and parts.
Your job as a front-end developer is not to know Polish cases or French elision rules. It is to structure your UI text so that translation libraries have the grammatical room to work, and to avoid baking English assumptions into the application logic that selects those strings.
Interpolation Isn’t the Enemy
The safest approach might seem to be avoiding interpolation entirely, but that’s rarely practical. Consider a sentence where part of the text is a link, as in “Learn more about supported images.” The link itself must be supplied from code, so the string has to be split:
This split is fine as long as both fragments are translated together as one sentence. The translator sees that “supported images” belongs inside the larger sentence and can apply the correct case endings and plural morphology. The problems only start when you try to reuse either fragment outside this specific context. Creating a generic “Learn more about {noun}” component, for instance, reintroduces the same failure we saw with the <StatusBar> example. Likewise, lifting “supported images” out to use as a standalone heading would fail, because that context may demand a different grammatical form.
Don’t Build Sentences in Code
The earlier “Added: January 1” example broke because the word order was hardcoded in the codebase. The fix was to translate the entire sentence and interpolate only the date. The general rule: never assemble text in code—whether that means ordering words, inserting punctuation, managing line breaks, or forcing capitalization.
This kind of layout is a translation trap. It has six separately styled elements:
- Get 10 images
- per month for only
- $
- 2
- .99
- /image
Each element must be its own node in the code. Coordinating spacing, line breaks, word order, and currency formatting across six interpolated pieces is not realistically maintainable. Hardcoding the visual order to protect the design will simply produce ungrammatical sentences in other languages. The only reliable solutions are serving the whole layout as an image with per-language versions, or simplifying the design so there are fewer styled breaks.
Let Libraries Do the Grammar Work
Pluralization rules vary so widely between languages that tracking them manually is not feasible. This is precisely the problem i18n libraries are built to solve. The examples in this article follow the i18next JavaScript framework, which has ports for React, Vue, Rails, and others. These libraries encode plural rules so you pass in a quantity and get the correct form back.
With an English translation file containing singular and plural entries, the Polish file would need several more forms that don’t exist in English. But the call site doesn’t change:
The function call passes the count itself, and the library determines the matching plural category for the active language. You don’t need to remember which key maps to which number, or even know that categories beyond singular and plural exist.
What you must not do is reach into the library and use a key like dogCount.many directly. As shown above, the many category maps to different numeric ranges in different languages—and in some it doesn’t exist at all. Hardcoding a category name is guaranteed to be wrong for some users. The library exists to absorb that complexity; let it.
The Takeaway
Multilingual content stays a difficult problem even with the best tooling. The practical path is to keep a few principles in mind: interpolate only within sentence-level translation units, keep sentence construction and text manipulation out of code, and hand pluralization logic over to i18n libraries. Following those guidelines lets you give every user a correct, natural experience in their own language—without becoming a linguist along the way.
