tldr: Internationalization (i18n) testing verifies your app handles locales, right-to-left languages, date and number formats, and pseudo-locales without breaking layout or logic. The bugs are subtle, the impact is severe in non-English markets, and most teams test it once and forget.
What i18n testing covers
Five layers, each with its own bugs.
Translations
Strings are translated, no string is missing, no translation is hardcoded back to English. Test by switching language and walking the full app.
Layout
German is longer than English. Some strings expand 30 to 50%. Test that buttons, menus, and forms still fit. Pseudo-locales (where every string gets bracket characters and length expansion) make layout problems obvious.
Right-to-left languages
Arabic and Hebrew read right to left. The whole UI needs to mirror: navigation, icons, animations, scrollbars. Test with a real RTL locale, not just direction CSS toggles.
Date, number, and currency formats
12/03/2026 is March 12 in the US and December 3 in Europe. Currency, decimals, thousands separators, calendar systems. Test with each target locale's actual formats.
Character encoding and input
Unicode in names, addresses, search inputs, file uploads. Emoji. Combining characters. Test that data round-trips correctly through the database, search, and export.
Pseudo-locale testing
A pseudo-locale generates a fake language by transforming every string: longer strings, bracket characters, accents on every letter. Microsoft popularized "qps-ploc."
Why use it: pseudo-locales surface layout, hardcoded string, and encoding bugs without needing translations. Run pseudo-locale tests in CI on every UI change. The bugs are caught months before any real translator finds them.
What gets missed
Hardcoded strings. A button label that was added without going through the i18n system. Pseudo-locales catch these.
Concatenated strings. "You have " + count + " items" works in English. In Russian, the noun changes form based on count. Use proper i18n libraries with plural rules.
Sort order. Sorting "ä" varies by locale. Test that lists sort correctly per locale.
Time zones. A user in Tokyo creating an appointment for "tomorrow at 9am" should not be confused by UTC storage. Test that user-facing times are in user-facing time zones.
Tools
- i18next, react-intl, format.js. i18n libraries with built-in pseudo-locale support.
- Crowdin, Lokalise, Phrase. Translation management platforms.
- Locize. Translation review with screenshots.
- Pseudo-locale generators. Built into most i18n libraries.
How AI testing fits
AI testing platforms run the same flow across multiple locales without per-locale code. Bug0 tests in any locale you point it at. Layout problems and missing translations surface in the test artifacts: screenshots and DOM snapshots.
FAQs
When should I start i18n testing?
Before you ship to a non-English market. Before is dramatically cheaper than after.
How many locales do I need to test?
The ones you actively support, plus a pseudo-locale. For broader coverage, pick one each of: Latin script, RTL, CJK (Chinese/Japanese/Korean), and a complex script like Thai.
What about regional differences within a language?
Real differences exist (en-US vs en-GB date formats, en-AU vs en-IN dates). Test each region you actively serve.
How does Bug0 handle i18n?
Bug0 runs flows in any locale and captures localized screenshots automatically. Layout and translation issues become visible in the test artifacts.