Internationalization (i18n)
🚧 ExpandingInternationalization — i18n, because there are eighteen letters between the i and the n — is the work of designing your software so it can adapt to other languages and regions, before you’ve actually translated a single string. It’s the structural groundwork; localization (l10n) is the act of filling in a specific language — including localizing video, which has its own set of traps. The reason this is a foundation and not an afterthought is brutal in practice: retrofitting i18n into a codebase that assumed English, left-to-right text, US dates, and dollar signs is one of the most expensive things a team can do. Get the bones right early and adding a language is a content task, not an engineering project.
When this page is filled in, it’ll cover the usual traps: hard-coded strings, concatenated sentences that break under translation, assumptions about text direction (right-to-left languages like Arabic and Hebrew), date/number/currency formatting, character encoding (use UTF-8, always), and why you should never split a person’s name into “first” and “last.” Until then, the Go Deeper links carry it.
📚 Go Deeper
Books
- The Unicode StandardOnce you've been bitten by an encoding bug, you'll want to understand the system underneath every piece of text your software touches.
Tools
- MDN — LocalizationPractical, code-level guidance on locales, language negotiation, and the browser APIs that make i18n work.
- W3C Internationalization (i18n) ActivityThe canonical source for the hard parts — text direction, character encoding, language tags, and why your assumptions about names and dates are wrong.