Internationalization Auditor

When to use

Use this skill before launching in a new locale, when preparing a codebase that was built English-only for international markets, or when auditing an existing localized product that has quality issues. Catching i18n problems late is expensive — strings baked into screenshots, layouts that break in German, dates that confuse users. Trigger when the user mentions internationalization, localization, i18n audit, translation readiness, RTL support, or locale bugs.

Inputs to gather

• Current and target locales (languages and regional variants: en-US, de-DE, ar, ja-JP)
• The i18n library in use or under consideration (i18next, FormatJS/React-Intl, next-intl, gettext, ICU MessageFormat)
• Whether the UI must support right-to-left (RTL) languages (Arabic, Hebrew)
• Whether content is user-generated (needs server-side translation pipeline) or developer-authored
• The translation workflow: in-house translators, vendor, community, machine translation
• Existing translation file format and tooling (JSON, xliff, PO, translation management system)
• The deployment model: per-locale builds, runtime locale switching, or SSR with locale routing
• Screenshots/design mocks for the target locales if available

Procedure

1. Find all hardcoded user-facing strings. Run a static scan for string literals in components, templates, error messages, emails, and notifications that are displayed to users. Exclude developer-facing strings (logs, internal error details). Every flagged string must be moved to a message catalog with a stable key. This is the foundational step — without it, nothing else can be translated.
2. Audit date, time, number, and currency formatting. Find every place dates or numbers are rendered or parsed and confirm it uses a locale-aware formatter (Intl.DateTimeFormat, Intl.NumberFormat, or the library equivalent). Flag hardcoded date formats (MM/DD/YYYY), string concatenation of dates, and manual number formatting. Verify currency values carry their currency code and aren't just numbers with a symbol appended.
3. Verify pluralization and gender rules. English has simple pluralization (one/other), but many languages have more forms (Arabic has six, Russian has three, Polish has three). Audit every string that contains a count and confirm it uses ICU MessageFormat plural rules (or equivalent), not a naive 'item' + (n !== 1 ? 's' : ''). This is a very common, very visible bug in localized products.
4. Check interpolation and message structure. Confirm all interpolated strings use named placeholders ({name}, {count}) with the i18n library's syntax, never string concatenation or template literals. Word order differs by language — 'Welcome, {name}' may become '{name}さん、ようこそ' — so placeholders must be positional-safe and reorderable.
5. Assess RTL readiness. If RTL locales are in scope, audit for hardcoded left/right and padding/margin values that won't mirror. Confirm the layout uses logical properties (start/end, inline-start) or a framework that flips automatically. Test with an RTL locale and check for broken icons, misaligned text, and truncated content.
6. Audit layout tolerance for text expansion. Translated text is often 30–50% longer than English (German, French) or shorter (Chinese, Japanese). Find buttons, table columns, nav items, and form labels with fixed widths or text-truncation that will clip or break translations. Use flexible layouts and test with the longest likely translations.
7. Validate the translation workflow. Confirm message catalog files are extractable from code (via a tool like i18next-parser, formatjs extract) and can be exported to the translator's format, then re-imported. Check for missing keys (used in code, absent from catalog) and stale keys (in catalog, no longer used). Ensure the build fails if a key is missing for a locale.
8. Check locale routing and detection. Verify the app detects the user's locale (Accept-Language header, URL path, saved preference) and serves the right translations. Confirm locale switching doesn't require a full reload where avoidable, and that the chosen locale persists.

Output format

An i18n audit report with: a count and inventory of hardcoded strings by file, the date/number/currency formatting findings, the pluralization and interpolation issues, the RTL and layout-expansion risks, the translation-workflow gaps (missing/stale keys, extraction config), and a prioritized remediation plan with the recommended i18n library and message-catalog structure.

Common pitfalls

• Shipping with English pluralization logic that produces '1 items' in languages with different rules.
• Using string concatenation instead of named placeholders, breaking word order in translation.
• Hardcoding dates as MM/DD/YYYY, which is ambiguous and locale-incorrect.
• Fixed-width buttons that clip the 40%-longer German translation.
• Missing the translation extraction step, so new strings never reach the message catalog and silently render their key.
• Forgetting RTL layout, so the Arabic version is a mirror-broken mess.
• Not failing the build on missing translation keys, so a locale silently falls back to English.