Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support.

i18n & Localization Internationalization (i18n) and Localization (L10n) best practices. 1. Core Concepts Term Meaning i18n Internationalization making app translatable L10n Localization actual translations Locale Language + Region (en US, tr TR) RTL Right to left languages (Arabic, Hebrew) 2. When to Use i18n Project Type i18n Needed? Public web app ✅ Yes SaaS product ✅ Yes Internal tool ⚠️ Maybe Single region app ⚠️ Consider future Personal project ❌ Optional 3. Implementation Patterns React (react i18next) Next.js (next intl) Python (gettext) 4. File Structure 5. Best Practices DO ✅ Use translation keys, not raw text Namespace translations by feature Support pluralization Handle date/number formats per locale Plan for RTL from the start Use ICU message format for complex strings DON'T ❌ Hardcode strings in components Concatenate translated strings Assume text length (German is 30% longer) Forget about RTL layout Mix languages in same file 6. Common Issues Issue Solution Missing translation Fallback to default language Hardcoded strings Use linter/checker script Date format Use Intl.DateTimeFormat Number format Use Intl.NumberFormat Pluralization Use ICU message format 7. RTL Support 8. Checklist Before shipping: [ ] All user facing strings use translation keys [ ] Locale files exist for all supported languages [ ] Date/number formatting uses Intl API [ ] RTL layout tested (if applicable) [ ] Fallback language configured [ ] No hardcoded strings in components Script Script Purpose Command scripts/i18n checker.py Detect hardcoded strings & missing translations python scripts/i18n checker.py <project path

i18n-localization