I18n Auditor

The Problem

You're launching in Japan next month. Your React app works perfectly in English. Then you discover that "Welcome back, {name}!" is hardcoded as string concatenation — which puts the name before the greeting in Japanese (where the name comes first). Your date formatting uses new Date().toLocaleDateString() without a locale parameter, so it displays in the user's browser language — except when it doesn't, because some browsers fall back to US English. Your currency displays as $12.99 even for Japanese users. Three locale files are missing 12 keys each. And your sidebar CSS uses margin-left: 16px which breaks when you add Arabic (RTL) support.

Each of these is a different category of i18n failure — structural (hardcoded strings bypassing the translation system), linguistic (text concatenation that breaks word order), formatting (locale-unaware dates/numbers/currency), completeness (missing keys across locales), and layout (LTR-biased CSS properties). A code review catches some. A launch in a new market catches the rest — and by then it's a fire drill.

What You Get

• Hardcoded string detection — finds user-facing text that bypasses the translation system entirely: JSX text content, button labels, error messages, placeholder text, toast notifications, and tooltip strings
• Translation key audit — compares keys across all locale files to find missing translations (key exists in en.json but not ja.json) and orphaned keys (defined but never referenced in code)
• Locale-awareness check — identifies new Date() without locale, .toLocaleString() with hardcoded locale, string concatenation with user data, hardcoded currency symbols, and locale-unaware number formatting
• Pluralization validation — checks ICU message format syntax, missing one/other plural forms, and CLDR plural rule compliance
• RTL CSS audit — scans for LTR-biased properties (margin-left, padding-right, float: left) that need logical equivalents (margin-inline-start, padding-inline-end, float: inline-start)
• Multi-framework support — React (react-i18next, react-intl), Vue (vue-i18n), Angular (@angular/localize), Next.js (next-intl), Node.js (i18next, formatjs), Django (gettext), Rails (i18n), Flutter (intl)

Why This Beats Prompting It Yourself

Manual i18n review requires checking every file for text that should be translated, comparing every locale file for key completeness, examining every date/number/currency format for locale awareness, and auditing CSS for RTL compatibility — a process that takes hours and misses patterns you don't think to check. The auditor runs all six scan categories simultaneously, classifies findings by severity (Critical = string completely bypasses translation; High = translation system used but with gaps), and provides the exact fix pattern for each framework.

Example Session

You: "Audit this React app for i18n readiness. We're launching in Germany and Japan."

Agent:

i18n Audit Report — 14 findings across 8 files
================================================

[CRITICAL] Hardcoded user-facing string bypasses translation system
  File: src/components/Header.tsx:23
  Found: <h1>Welcome to Dashboard</h1>
  Fix: Replace with {t('header.welcome')} or <Trans i18nKey="header.welcome" />

[CRITICAL] Text concatenation breaks word order in other languages
  File: src/components/UserCard.tsx:34
  Found: "Welcome back, " + user.name + "!"
  Fix: Use ICU message: t('welcome_back', { name: user.name })

[HIGH] Missing translation key in locale files
  Key: "settings.notifications.email"
  Missing in: locales/ja.json, locales/de.json
  Present in: locales/en.json (value: "Email notifications")

[HIGH] Hardcoded date format — will not adapt to user locale
  File: src/utils/formatDate.ts:12
  Found: date.toLocaleDateString('en-US')
  Fix: Use navigator.language or

Use Cases

• Pre-launch i18n readiness — scan entire codebase before entering a new market
• PR review for i18n compliance — check that new features use the translation system and don't introduce hardcoded strings
• Translation file health check — verify all locale files are in sync with no missing or orphaned keys
• RTL layout preparation — identify CSS properties needing logical equivalents before adding Arabic/Hebrew support
• Framework migration validation — when switching i18n libraries (e.g., react-intl → next-intl), verify all strings ported correctly

Known Limitations

The auditor performs static analysis on source files — it cannot detect strings rendered from external APIs, CMS content, or dynamic key construction (t('section.' + variable)). Translation quality (accuracy, tone, cultural appropriateness) is not evaluated — only structural completeness. Binary files, minified code, and compiled output are excluded from scanning.