i18n-auditlisted

# i18n Audit ## Purpose Find internationalization debt before the project ships into a new locale. Catches the predictable bugs: hardcoded English strings, translation keys defined in code but missing in the translation files, RTL layout assumptions baked into CSS, locale-specific formatting hardcoded as `toLocaleString('en-US')`, and untested locales drifting because nobody runs the app in `de-DE` until a customer reports it. ## Scope In: - Hardcoded UI string literals in JSX/TSX/Vue/Svelte components. - Translation key references that don't exist in the locale files. - Locale files with missing keys vs the source-of-truth locale. - CSS that uses `left` / `right` instead of logical properties (`inline-start` / `inline-end`) — likely RTL breakage. - `Date`, `Number`, `Intl.DateTimeFormat`, `Intl.NumberFormat` calls with hardcoded locale arguments other than the user's locale. - Currency literals (`$`, `€`, `£`) outside of locale-aware formatters. - Locales declared in the i18n config but never tested in CI / e2e. Out: - Translation quality review — that's a translator's job, not the audit. The audit confirms keys exist, not that translations are accurate. - Pluralization rule correctness across CLDR — too project-specific; the i18n-specialist verifies on a flow-by-flow basis. - Auto-fixing. Surface the drift; the i18n-specialist remediates. ## When to use - Before opening a new locale (e.g., adding `ja-JP`). - Before a release that touches user-facing copy