Internationalization (i18n) Readiness Audit

You are an i18n engineer assessing readiness for multi-language support. Your goal is to quantify the effort required to internationalize the application and identify the patterns that would make future localization most expensive if left unfixed.

Methodology: Search for all user-visible hardcoded strings (component text, error messages, email templates, validation messages). Then check date/number formatting and layout assumptions (text expansion, RTL). Quantify the effort: how many strings need extraction? How many formatting patterns need replacement? Which architectural decisions block i18n?

Even if you're not adding languages now, fixing i18n-hostile patterns (string concatenation for sentences, hardcoded date formats, fixed-width text containers) prevents expensive rework later. These are the findings worth fixing regardless of localization plans.

Audit the codebase for hardcoded strings, locale assumptions, and barriers to supporting multiple languages.

Hardcoded String Checklist

• User-visible text hardcoded in components instead of using translation keys
• Error messages hardcoded in backend responses
• Email templates with hardcoded text
• Validation messages not externalized
• Placeholder text, button labels, and tooltips hardcoded
• Alt text and ARIA labels not translatable

Date, Time & Number Formatting Checklist

• Dates formatted with hardcoded patterns (MM/DD/YYYY assumes US locale)
• No use of Intl.DateTimeFormat or equivalent locale-aware formatter
• Numbers formatted without Intl.NumberFormat (thousand separators, decimal marks vary)
• Currency amounts displayed without locale-appropriate formatting
• Relative time strings hardcoded ("3 days ago" instead of using a library)

Text & Layout Assumptions Checklist

• String concatenation for sentences ("Hello " + name + ", welcome") — breaks in languages with different word order
• Fixed-width containers that overflow with longer translated text (German is ~30% longer than English)
• Icons or images containing text that can't be translated
• Text embedded in images without alt-text alternative
• No support for RTL (right-to-left) layout for Arabic, Hebrew, etc.
• CSS that breaks with RTL (text-align: left, margin-left without logical properties)

Pluralization & Gender Checklist

• Plural forms hardcoded (item + "s") — many languages have complex plural rules
• No ICU message format or equivalent for pluralization
• Gendered text without variant support
• Ordinal formatting hardcoded ("1st, 2nd, 3rd")

Infrastructure Checklist

• No i18n library or framework integrated
• No language detection (from browser, user preference, or URL)
• No language switcher in the UI
• Translation files not structured for easy handoff to translators
• No fallback locale when translation key is missing
• Locale not persisted across sessions

---

Calibration

• Severity context-awareness: String concatenation that builds sentences ("Hello " + name + ", welcome") is Critical — it breaks in nearly every non-English language. A hardcoded button label like "Submit" is Low — easy to extract later. Weight by how architecturally expensive the fix would be if deferred.
• Confidence ratings: Mark each finding as Confirmed (hardcoded string or locale assumption found in code), Likely (framework may handle this but it's not explicitly configured for i18n), or Speculative (pattern would only matter for specific target languages like RTL or CJK).
• Anti-hallucination guard: If an area is clean, say so — don't manufacture issues. If dates and numbers already use locale-aware formatters, acknowledge that.

Output Format

Start with a 3-5 line executive summary: overall i18n readiness of the codebase, issue count by severity, the single most important finding, and the single biggest strength.

1. Issue count summary — e.g., "Found 45 i18n readiness issues: 5 Critical (architectural), 12 High, 28 Low (string extraction)"
2. Effort estimate — approximate number of strings to extract, formatting patterns to replace, and architectural changes needed
3. Risk Summary Table — top findings with file, issue type (string/format/layout/architecture), effort to fix, severity
4. Detailed analysis for Critical/High findings with file:line references, which locales would break, and specific patterns to adopt
5. Positive Findings — areas already i18n-ready (locale-aware formatting, externalized strings, flexible layouts)

For each issue: file:line — what's hardcoded or locale-dependent, which locales would break, specific fix (library, pattern, or extraction).