Building for a global audience requires more than translating strings. Dates, numbers, currencies, pluralization, and text direction all vary by locale. Proper internationalization (i18n) makes these differences feel natural to users everywhere.
Core Concepts
i18n vs L10n
Internationalization (i18n): Building software to support multiple locales Localization (L10n): Adapting content for specific locales
Locale Identifiers
Format: language-REGION
Examples:
en-US (English, United States)
en-GB (English, United Kingdom)
es-ES (Spanish, Spain)
es-MX (Spanish, Mexico)
zh-CN (Chinese, Simplified)
zh-TW (Chinese, Traditional)
String Translation
Using react-i18next
Translation Files
Usage in Components
Pluralization
Complex Pluralization Rules
Using ICU Message Format
Date and Time
Using Intl.DateTimeFormat
Relative Time
Numbers and Currency
Number Formatting
Currency Formatting
Percentage and Units
RTL Support
CSS Logical Properties
Document Direction
Bidirectional Text
Content Management
Translation Workflow
1. Extract strings from code
$ i18next-scanner
2. Send to translation service
- Lokalise, Phrase, Crowdin
3. Translators work on strings
4. Import translations back
5. Review in context
6. Deploy
String Extraction
Testing i18n
Pseudo-Localization
Integration Tests
Best Practices
String Guidelines
Key Naming
Conclusion
Internationalization is an investment that pays off as your user base grows globally. Build i18n into your architecture from the start—retrofitting is painful and error-prone.
Use established libraries, follow locale-aware formatting standards, and test with pseudo-localization. Your global users will appreciate an app that speaks their language naturally.