Internationalization (i18n) Patterns

Many React applications begin life in a single language. UI copy is written directly inside components. Numbers are formatted according to the browser's default behavior. Dates are displayed in one familiar format. Layout assumes left-to-right reading order. Everything feels straightforward. Then the product expands.

We add a second language and introduce a translation function. Hardcoded strings are replaced with t("key"). It works until we notice subtle cracks.

Plural rules differ across languages. “1 item” versus “2 items” becomes more complex in Arabic, which has multiple plural categories. Variable interpolation behaves differently depending on word order. Dates and currency formatting follow regional conventions that cannot be handled with string concatenation. Right-to-left languages reverse the layout direction, but spacing, icon alignment, and navigation flow are designed for left-to-right layouts. A language switch causes the entire application to flicker because translation files load asynchronously. Some components remount, losing local state. Headings change structure, altering accessible names mid-navigation.

The deeper issue is architectural. We treat internationalization as a text-replacement layer rather than a rendering contract. But in React 19, rendering is concurrent, staged, and boundary-based. Changing the language is not a small patch; it is equivalent to re-rendering the entire application under a new locale configuration. If translation data, formatting rules, and direction are not modeled as stable inputs to rendering, concurrency exposes inconsistencies: unstable accessible names, layout shifts, remounts, and formatting mismatches. The problem we are solving in this lesson is therefore not how to translate strings. We are working on how to design internationalization so that language, formatting, pluralization, and layout direction integrate cleanly into React’s rendering model, while remaining stable, predictable, and concurrency-safe.