Internationalization questions test whether you know that "translate the strings" is only the easy 10% of the job. The hard part is pluralization rules, locale-aware formatting, right-to-left layout, and not shipping every language's translations to every single user.

The main ways to translate an app

Most real apps combine the first and third: a translation library for UI copy, and Intl for locale-aware formatting of dates, numbers, and currency, since Intl already knows every locale's formatting rules, writing your own would be redundant and easy to get wrong.

react-intl (FormatJS)

The {count, plural, =0 {...} one {...} other {...}} syntax is ICU MessageFormat, and it's the actual reason to reach for react-intl over a simpler key-value library. Pluralization isn't "singular versus plural" in most languages, some have separate forms for one, two, few, many, and everything else. ICU's plural categories map onto whichever subset a given locale actually needs, applying the right grammatical rule automatically through Intl.PluralRules underneath.

Remember: a manual count === 1 ? "item" : "items" check only handles English. ICU MessageFormat handles the languages that need more than two plural forms.

Loading translations lazily, per locale

Shipping every locale's bundle to every visitor wastes bytes, an English visitor doesn't need the French, German, and Japanese translation files downloaded alongside their page. Load translations the same way you'd code-split a route.

In a framework like Next.js, the routing layer itself, [locale] dynamic segments, next-intl, resolves the locale from the URL path or the Accept-Language header on the server, and serves only that one locale's bundle, skipping a client-side fetch waterfall on the very first load.

Remember: load one locale's translations on demand, not every locale up front. An English visitor should never download the French bundle.

Formatting with Intl, never by hand

The native Intl API is the right tool for formatting. Never hand-roll date or currency formatting, decimal separators, thousands separators, date field order, and currency symbol placement vary in ways that are easy to get wrong and expensive to keep maintaining yourself.

React components typically wrap these to avoid rebuilding a formatter, which has real construction cost, on every single render.

react-intl's FormattedDate, FormattedNumber, and FormattedRelativeTime components are thin wrappers around exactly these Intl constructors, plus this same memoization, plus reading the active locale from context automatically.

Remember: never build your own date or currency formatting logic. Intl already encodes every locale's actual rules correctly.

RTL: the whole layout flips, not just the text

A handful of widely-used languages, Arabic, Hebrew, Persian, Urdu, are right-to-left, and getting this right means more than mirroring the text, the entire layout direction flips.

Setting dir="rtl" on <html>, or any container, flips text alignment, flexbox and grid item order (with zero JSX changes needed), the visual direction margin/padding/border shorthand apply, and native form control alignment, all automatically, because these are direction-aware properties by the CSS spec itself, not something needing JavaScript to flip.

The CSS mistake to avoid: physical properties, margin-left, padding-right, text-align: left, never flip with dir="rtl". They stay pinned to the physical left or right no matter the reading direction, which breaks the layout in RTL. Logical properties flip automatically, since they're defined relative to text flow, not a fixed screen side.

Icons that show direction, a "back" arrow, a "next" chevron, need to mirror in RTL too, and that's not automatic, it needs explicit handling, usually scoped to [dir="rtl"].

Remember: a physical property like margin-left stays pinned left in RTL and breaks. A logical property like margin-inline-start flips correctly on its own.

What breaks past the obvious date and currency cases

Pluralization is not binary in many languages, Russian and Polish have several plural forms depending on the exact count, and Intl.PluralRules/ICU MessageFormat handle this correctly where a manual check simply doesn't generalize. Name order and formality vary too, some locales expect the family name before the given name, or need formal and informal address forms English doesn't have at all. Text expansion is a layout concern worth naming out loud: German and Finnish UI strings routinely run 30 to 40 percent longer than the English original, and a layout built to fit English exactly visibly breaks once translated, so fixed-width buttons and labels should be designed to tolerate that from the start.

The failures that actually show up in production rarely come from a missing translation key. They come from formatting logic hardcoded for one locale and never revisited: a price built with string concatenation instead of Intl.NumberFormat, a plural check that only handles English, a fixed-width button that clips German text. Treating Intl and ICU pluralization as the default from day one, rather than a retrofit once a second locale ships, is what separates code that scales to new markets from code that needs a rewrite to get there.

Remember: the real internationalization bugs are almost never a missing translation key. They're formatting logic quietly hardcoded for one locale from the start.