Lesson 28 of 30
Translating strings is the easy 10% — the hard part is the stuff that isn't just text: plurals, dates, number formats, and layouts that have to survive text getting 3x longer or flowing right-to-left.
12 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 2
Why is `count === 1 ? "item" : "items"` structurally wrong for internationalization, not just English-specific?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
i18n (internationalization) is designing the app to support multiple languages/locales; l10n (localization) is actually producing the content for a specific one. The number in each abbreviation (i18n, l10n) just counts the letters skipped in the middle — a shorthand convention, not a technical distinction.
const count = 3;
// ❌ hardcoded English pluralization logic
`You have ${count} ${count === 1 ? "item" : "items"}`;
// ✅ delegate to the platform's actual pluralization rules
new Intl.PluralRules("en-US").select(count); // "one" | "other" — varies by locale!
English has two plural forms (one/other). Many languages have more — Russian has distinct forms for 1, for 2-4, and for 5+; Arabic has six. Hardcoding count === 1 ? ... : ... isn't just English-centric, it's structurally wrong for most of the world's languages, which is exactly why real i18n libraries route pluralization through locale-aware rules instead of a manual ternary.
<p>Welcome, {name}!</p> hardcoded in English — every other language needs a code change.
"You have " + count + " items" breaks the moment a language's word order differs from English's — always translate the whole templated sentence as one unit ("You have {count} items"), with the translator controlling word order for their language.dir="rtl" on the document plus CSS logical properties (margin-inline-start instead of margin-left) is the modern, maintainable approach."How would you internationalize this app?" is a real question for any product with global ambitions, and naming the actual hard parts (pluralization rules, string concatenation, layout expansion, RTL) — not just "add a translation file" — is what shows you've actually shipped a localized product before.