i18n-and-localizationlisted

# i18n and localization Scope: i18n-and-localization — message extraction, ICU pluralization, RTL layout, and date/number formatting for user-facing strings. It does not own in-app content moderation, legal-notice translation review, or performance — those stay with their existing owners. ## 1. Translation-key discipline - **Never interpolate user-facing text with string concatenation.** Every user-facing string gets a stable, hierarchical **key** (`checkout.summary.itemCount`, not `"You have " + n + " items"`) — concatenation breaks the moment a translator needs to reorder words, and many languages do reorder them. - **Keys describe location/purpose, not the English source text.** A key named after the English string (`"you_have_n_items"`) drifts the moment the English copy changes; a purpose-scoped key doesn't. - **No string ever ships hardcoded outside the catalog** — including error messages, `alt`/`aria-label` text, empty states, and toast copy. A string left out of extraction is a string that silently stays English forever. - Keep **one source-of-truth locale** (usually `en`) authoritative; every other locale is a translation of it, not an independent edit — otherwise locales drift out of sync with no way to tell what's stale. ## 2. Message extraction - Use an extraction tool (`react-intl`/FormatJS's `extract`, `i18next-parser`, `lingui extract`) that scans source for the translation-call sites and generates/updates the catalog automatically