i18nlisted

# Internationalization (i18n) Internationalization is not translation — it is the engineering discipline of making an application locale-aware so translation is a content change, not a code change. Hardcoded strings, locale-blind formatting, and LTR-only layouts all become bugs the moment a second locale is needed. Build the scaffolding before the second locale arrives, not after. ## When to use - Preparing an application for multiple locales (message extraction, locale routing, formatting) - Adding RTL support or locale-specific pluralization/gender rules - Auditing an existing app for hardcoded strings or locale-blind formatting - Triggers on "i18n", "localization", "l10n", "RTL", "国际化", "本地化", "多语言" **Not for:** frontend visual design (use `frontend-design`); API contract design (use `api-design`). i18n is a cross-cutting implementation discipline touching frontend, backend, and build tooling. ## Steps ### 1. Audit the locale surface Before writing code, find every locale-sensitive surface in the application: - Hardcoded user-facing strings (UI labels, error messages, email templates, push notifications) - Formatted values: dates, times, numbers, currencies, percentages, units - Pluralization and gender-dependent phrasing - Layout assumptions: LTR-only CSS, fixed-width containers, text concatenation - Locale-affecting config: timezone handling, first-day-of-week, calendar system _Verify: the audit produces a list of locale-sensitive surfaces grouped by type, not a