Building a global-ready app starts with internationalization (i18n) — but testing ensures it stays that way across languages. Let’s walk through why thoughtful i18n testing matters and how to make it effective.
Developers often focus on building features and adding i18n. But QA engineers play a critical role in ensuring a product works flawlessly for users across the globe.
In my previous article on i18n vs l10n, I explained why proper internationalization matters and how AI can help with localization. In this one, we’ll go deeper into what QA should focus on. In the examples below, I use i18next because it’s one of the most popular and feature-rich localization frameworks for JavaScript, making it easy to demonstrate concepts like pluralization and interpolation. Even if your project uses a different format (not JSON), you should still ensure it supports at least plural forms and interpolation — these are essential for providing robust internationalization capabilities. Here’s your checklist to guarantee quality:
1. All User-Facing Strings Are Extracted for Translation
- Switch the app to a test locale (e.g., pseudo-language) and verify that all user-visible text appears translated, with no hard-coded or untranslated strings left.
2. Plural Form Coverage
- Check that all required plural keys (_one, _few, _many, _other) are present — particularly for complex-plural languages like Polish, Russian, or Arabic.
In my previous article, I noted that developers often define only _one and _other for English, and localization teams may not add the rest. With l10n.dev, extra forms are auto-added during i18next file translation, ensuring full support for target languages.
3. Placeholder Protection (interpolation)
- Confirm that dynamic placeholders ({{name}}, {{count}}, etc.) remain untouched during translation to avoid runtime issues.
l10n.dev preserves placeholders and understands their meaning for safer translations.
4. Date, Number & Currency Formats
- Ensure locale-aware formatting: e.g., 1,234.56 (US) vs 1.234,56 (Germany), 24-hour vs 12-hour clock, different first days of the week.
- Check currencies are correct for the target market — they should not be changed during translation.
- Verify date/time accuracy across all relevant time zones.
As highlighted earlier, l10n.dev intelligently converts formats — for example, turning “Founded on July 4, 1776” into “1776年7月4日創設” for Japanese locale.
5. Text Length & UI Layout
- Some languages (like German or Russian) tend to be 30–40% longer than English. Your UI should adapt without truncation. Simulate long strings and ensure buttons, labels, and menus resize gracefully.
- Languages like Arabic and Hebrew are read right-to-left (RTL). Verify that text alignment, icons, and navigation reverse correctly.
If a translation is longer than the source, AI i18n translator can intelligently shorten it without losing context. Example: “administrator” → “admin” in space-limited UI components.
6. Missing Keys & Fallbacks
- Run localized build and click through screens to confirm no fallback keys (like auth.login.title) appear accidentally.
l10n.dev preserves translation files structure and key ordering for cleaner diffs and easier review.
7. Contextual Variants
- Ensure that gender (e.g., _male, _female), tone (formal/informal), or role-based translations are properly used. Keys like greeting_formal vs greeting_informal should render correctly based on context.
8. Encoding and Character Support
- App should handle all Unicode characters — including emojis, right-to-left scripts, and accented letters.
Automating i18n Testing with Pseudo-Localization
Pseudo-localization is the process of transforming your app’s source text into an altered, fake “language” to mimic how UI behaves after translation. Automation QA teams can use this to detect i18n issues before the real translation arrives.
Why It’s Useful
- Exposes layout breakages caused by text expansion.
- Surfaces encoding issues by adding accented characters.
- Ensures all strings are translatable (no hard-coded text).
- Reveals placeholder mishandling.
- Helps define translation length limits (e.g., maximum allowed characters).
Automation Strategies for QA
1. Accented & Non-Latin Characters
- What to do: Replace Latin letters with accented forms or different scripts. Example: “Save” → “Šàvē”
- QA check: Ensure all characters display correctly and nothing breaks due to encoding.
2. Text Expansion Simulation
- What to do: Automatically expand each string by ~30–40% to mimic long languages like German or Finnish. Wrap with markers for easy clipping detection. Example: “Save” → [★ Šàvēēēēē ★]
- QA check: Use automated screenshot comparison to spot UI overflow, clipping, or misalignment.
3. Placeholder Stress Testing
- What to do: Replace interpolation variables (placeholders) with visible markers (e.g., , ). Example: “You have {{count}} items” → “You have items”
- QA check: Run regression tests; fail if a marker is missing, or escaped (<COUNT>).
4. RTL Simulation
- What to do: Wrap text in right-to-left (RTL) markers \u202E${text}\u202C to simulate Arabic or Hebrew.
- QA check: Verify alignment, text direction, and mirroring are correct.
5. CI/CD Integration
- What to do: Add pseudo-localization to your automated test pipeline.
- QA check: Block deployment if tests detect missing translations, broken placeholders, or layout issues.
Below the screenshot is a pseudo-localization example used to identify potential internationalization (i18n) issues. The font and size are identical on both sides, but supporting other scripts often requires more space:
To automate pseudo-localization, check out pseudo-l10n — an npm package that generates pseudo-localized JSON files with configurable text expansion, accented characters, visual markers, and RTL support. Install with npm install -g pseudo-l10n and run pseudo-l10n en.json pseudo.json to instantly create test locales.
By automating i18n testing, you ensure that localization becomes smooth, fast, and cost-effective. With AI localization, l10n.dev can help you get there.
Thanks for reading!
Top comments (0)