Section 42 · Team & Development
Internationalization (i18n)
Audit guide for internationalization practices - translation frameworks, locale handling, and multi-language support
This guide walks you through auditing a project's internationalization practices.
The Goal: Translation-Ready by Default
Internationalization isn't just translation — it's building software that can be translated. The goal is:
- Framework in place — i18n library configured and working
- Automated extraction — Strings flow from code to translators without manual copying
- Locale-aware — Dates, numbers, currencies format correctly per locale
- Tested — Different locales validated before release
Retrofitting i18n is expensive. This guide verifies the practices that make it painless.
Cross-references:
- Section 8 (Testing & Code Metrics) — Testing infrastructure
- Section 14 (Documentation) — Documentation practices
- Section 41 (Accessibility) — Some overlap (screen readers need proper lang attributes)
Before You Start
- Confirm this applies — This section is for projects that need multi-language support. Single-locale internal tools, CLIs, and backend APIs can skip this audit.
- Identify scope — What languages/locales are required? Are RTL languages (Arabic, Hebrew) in scope?
- Check the tech stack — React, Vue, Next.js, Angular all have different i18n patterns
Multi-Language Support
An i18n framework provides the foundation: string lookup, interpolation, pluralization, and locale switching. Required if multi-language support is needed.
“Adding a new language — how long would that take?”
Automated extraction ensures all translatable strings are captured. Manual copy-paste to translation files is error-prone.
“How often do translation keys drift from the actual UI?”
Without a documented workflow, translations become a bottleneck. Developers need to know how strings flow to translators and back.
“Who translates new strings, and how long does it take?”
When a translation is missing, the app needs to know what to show. Without a fallback, users see translation keys or blank content.
“Missing translation — what does your user actually see?”
Best Practices
Hardcoded strings bypass the translation system entirely. Lint rules should enforce using i18n functions for user-facing strings.
“How many English strings are hiding in your components?”
Dates, numbers, and currencies format differently across locales. Use Intl API or locale-aware libraries for formatting.
“What does $1,234.56 look like to a German user?”
RTL languages (Arabic, Hebrew, Farsi, Urdu) require mirrored layouts. CSS logical properties or RTL tooling needed for proper support.
“Flip to Arabic — does your layout mirror or break?”
Different languages have different plural rules (English has 2, Russian has 3, Arabic has 6). String concatenation breaks pluralization.
“"1 items" — still lurking somewhere in your UI?”
Testing
Tests should validate behavior across locales, not just the default language. At minimum, smoke tests for non-default locales.
“Your tests pass in en-US — what about fr-FR?”
Pseudo-localization transforms strings to reveal hardcoded text, test expansion, and find truncation issues before real translations.
“Any hardcoded text hiding from your translation pipeline?”
German is ~30% longer than English, Finnish can be 40%+ longer. UI must handle text expansion without breaking layout.
“Your UI in German — does anything overflow or truncate?”