Why i18n Is Harder Than Translation
Locale routing, date formats, plurals, RTL — the full scope
Written by the RadarTrek editorial team · June 2026
The translation fallacy
Most developers think internationalisation (i18n) means swapping English strings for translated ones. In reality, translation is only the surface layer. Beneath it lies locale routing, number and date formatting, plural rules that vary wildly between languages, gender-inflected text, bidirectional (RTL) layouts, and cultural conventions around currency symbols, address formats, and even colour meaning.
Analogy: the iceberg
Translation is the tip of the iceberg — visible, easy to point at. Everything below the waterline (locale detection, format APIs, plural categories, RTL CSS, translation pipeline) is what actually sinks ships. Most i18n bugs live underwater.
The four axes of i18n
- Locale routing — URLs must encode the locale (/en, /ar, /fr) so search engines index each language and users can share links that stay in the right language.
- Message translation — Strings, interpolated variables, and rich text (bold, links) inside translations must all be handled without breaking HTML.
- Format localisation — Dates, times, numbers, and currencies look completely different across locales: 1,234.56 in en-US is 1.234,56 in de-DE and ١٬٢٣٤٫٥٦ in ar-EG.
- Layout and script direction — Arabic and Hebrew read right-to-left. Margins, paddings, icons, and flex directions all need to mirror — and a simple CSS `dir` attribute is only the start.
Why gettext alone is not enough
Many older systems use GNU gettext or simple key-value JSON files and call it done. But they collapse under plural rules (Russian has four plural forms; Arabic has six), gendered nouns (French "le formulaire" vs "la page"), and number formatting. The browser's built-in `Intl` API solves formatting; ICU MessageFormat solves plurals and gender. A modern i18n library wires both together.
What is ICU MessageFormat?
ICU (International Components for Unicode) is a widely-adopted open standard for message syntax. It provides `{count, plural, one{# item} other{# items}}` syntax for plurals, `{gender, select, male{He} female{She} other{They}}` for gender, and `{name}` for simple variable interpolation. next-intl uses ICU natively.
Choosing a library: next-intl
For Next.js App Router projects, next-intl is the de-facto standard. It supports server components natively (no Context Provider re-renders on the server), integrates with the App Router's `[locale]` segment pattern, ships ICU MessageFormat, and provides typed message keys when you use its TypeScript integration. We will use next-intl throughout this course.
i18n is an architectural decision
Adding i18n to an existing app is painful. Routes must be restructured, all string literals must be extracted, and the build pipeline needs to be extended. Build locale support from day one — retrofitting it at launch is a 2-week task that feels like a 1-day task until you are in it.
Key ideas from this lesson