Internationalization (i18n) is the practice of building software so it can be adapted to different languages, regions.
Internationalization (i18n) is the engineering discipline of building software so it can operate in multiple languages, regions, currencies, and cultural conventions without code changes per locale. Localization (l10n) is the ongoing work of producing the translations, cultural adaptations, and regional content. The distinction matters: i18n is architectural and belongs up front; l10n is content and can grow incrementally. Most retrofit horror stories are companies that skipped i18n architecture, then discovered that hardcoded English strings had metastasized across the codebase.
(1) Every user-facing string extracted into translation files, never inlined. (2) Number, date, and currency formatting via ICU (Intl API in JavaScript, similar in every language) — never hand-formatted. (3) Layout that handles text expansion (German is 30% longer than English) and RTL scripts (Arabic, Hebrew reverse the entire layout). (4) Sorting, casing, and search that respect locale (Turkish 'i' behaves differently than English). (5) Time zones and calendar systems (not everyone uses the Gregorian calendar). Doing all this from day one adds 10-20% to feature time; retrofitting it later adds months of pure refactoring work with no user-visible benefit.
JSON key-value files are the modern default (i18next, react-intl, FormatJS all support them). Key by semantic meaning, not by English text — 'button.submit' not 'submit_button' — so the same key can produce different English variants in different contexts. Use ICU MessageFormat for pluralization and gender: '{count, plural, one {# item} other {# items}}' handles English's 2-form plural and 20+ other languages' plural systems in one syntax. Ad-hoc string concatenation for plurals produces incorrect grammar in most languages.
Two approaches. (1) Managed translation service — Lokalise, Phrase, Crowdin. Engineers push new strings; translators (in-house or contracted) produce translations in a UI; translations pull back into the codebase. Standard for teams at scale. (2) Manual with contractors — export CSV, email to translators, import back. Fine at very small scale, painful past a few hundred strings. Whichever approach, never machine-translate blindly to production — MT quality is close but breaks in embarrassing ways for the strings customers see most (nav, CTAs, errors).
Adding a locale is not free — translation costs, review costs, ongoing maintenance for every new string. Sequence by market signal: which locales are already using the English product (analytics answers this), which markets does sales/CS want to enter, which regulatory jurisdictions require local-language interfaces. Common phasing: English, then Spanish + French + German (highest ROI for most Western SaaS), then Japanese/Portuguese-BR/Chinese depending on strategy. Launching 15 locales badly is worse than launching 3 excellently.
True localization is more than translation. Address formats differ by country (postal codes, state/province, ordering); currency displays differ ($1,234.56 vs. 1.234,56 €); phone number formats vary; tax display (VAT-inclusive vs. exclusive) is regulated in EU/UK vs. optional in US. Legal texts (privacy policy, terms) may need to be locally reviewed for GDPR (EU), LGPD (Brazil), or other frameworks. Assume each new market has 2-4 weeks of non-translation work per market that's easy to underestimate.
Investor directory · Fundraising library · Articles A–Z · Company funding database