Glossary / Internationalization
Internationalization
Internationalization (often i18n) is designing software so it can support different languages, scripts, regions, calendars, numbering systems, time conventions, and cultural expectations without redesigning the application. It is an architectural capability; localization supplies specific language- and region-appropriate content and behavior. Good internationalization externalizes text, uses Unicode safely, delegates formatting to locale-aware APIs, supports text expansion and bidirectional writing, and keeps business data separate from its localized presentation.
Engineering foundations
- Separate translatable messages from code; use message catalogs with stable keys and context, plural/select rules, interpolation, and translator comments.
- Store text as Unicode; avoid assumptions that one character equals one byte, one UTF-16 code unit, or one grapheme cluster. Handle combining marks, emoji sequences, and normalization where relevant.
- Set document language with
langand mark inline language changes so pronunciation and processing can adapt. - Use
Intl.NumberFormat,Intl.DateTimeFormat,Intl.RelativeTimeFormat,Intl.Collator, andIntl.PluralRulesrather than hand-built locale rules. - Support locale-aware sorting/search, calendars, currencies, units, date input, number parsing, and validation. Formatting output does not imply safe parsing of user-entered localized strings.
- Use logical CSS properties (
margin-inline-start) and layout that tolerates direction changes, string expansion, and alternate scripts. - Use locale identifiers and fallback rules consistently; distinguish language, script, region, and user preference (for example
zh-Hant-TW).
Architecture and quality
Keep canonical values (instants, amounts, identifiers) separate from display strings. Store translations with versioning and fallback behavior; avoid concatenating fragments whose word order varies across languages. Test pseudo-locales, long strings, RTL, non-Latin scripts, plural categories, and locale-specific date/number input. Define which system determines locale preference and allow user override where appropriate. Internationalization should be included in component contracts and data schemas, not added as a final translation phase.
Interview questions
- i18n versus l10n? Internationalization makes the system adaptable; localization adapts content and presentation for a particular locale.
- Why avoid string concatenation? Word order, grammar, punctuation, and plural structure vary; translators need whole messages and parameterized tokens.
- Why use
Intl? It uses locale data and handles variation that ad hoc formatting misses. - What is pseudo-localization? A test transformation that expands/accents strings or inserts markers to expose hard-coded text and layout assumptions.
- What is the hardest design mistake to reverse? Often data models that store localized display text instead of canonical values or assume a single script, locale, or direction.