internationalization-and-localization
Internationalization & Localization
Designing for one language and bolting on translation later is the most expensive shortcut in product. Layouts crack under German, hardcoded MM/DD/YYYY lies to half the planet, "You have " + count + " items" can't pluralize in any language but English, and a left-pinned sidebar lands on the wrong edge in Arabic. Build for many locales from the first commit.
Three distinct disciplines
| Term | What it is | Who owns it | When |
|---|---|---|---|
| Internationalization (i18n) | Engineering the product so it can support any locale: externalized strings, locale-aware formatting, logical layout, RTL support, font fallback | Engineers + designers | Build time, once |
| Localization (l10n) | Adapting the product to a specific locale: translated copy, local formats, culturally-fit imagery, legal compliance | Localizers + translators + designers | Per target locale |
| Translation | Converting text from one language to another | Translators | A subtask of l10n |
i18n = "18 letters between i and n". l10n = "10 between l and n". i18n is the foundation that makes l10n cheap. Translation alone is not localization — translated text in an LTR-only layout with US date formats is still broken.
A locale is more than a language. It's language-REGION (BCP 47): en-US ≠ en-GB (color/colour, MM/DD vs DD/MM), pt-BR ≠ pt-PT, zh-Hans (Simplified) ≠ zh-Hant (Traditional). Region drives formatting; language drives translation. Always carry the full tag.
Text expansion — design for the longest string, not the English one
Translated text changes length. UI built tight around English overflows, truncates, or wraps badly.