Localization testing
The QA pass that runs your product in each target locale to catch burst layouts, wrong formats, leaked English, and translations that read wrong.
See it
What it is
Localization testing has two halves that need different people. The cosmetic and functional half checks the machine: does the German build overflow, does Arabic mirror properly, does 03/04 render as the right month, does sorting respect Swedish collation, does currency land on the correct side of the number, do untranslated keys leak through. The linguistic half (often called LQA) checks the words: accuracy, tone, formality, and whether product terms match the termbase.
Automate the mechanical half aggressively. Run a pseudo-locale build in CI, fail on any string that resolves to a raw key, assert formatted output with Intl rather than hardcoded expected strings, and take per-locale screenshots on every route so a diff catches the burst button. Pick three sentinel locales that cover the failure modes: one long (de-DE), one right-to-left (ar-EG), one CJK (ja-JP).
Gotcha: reviewing machine translation in a spreadsheet feels like testing and is not. Strings only misbehave in place, where a translator can see that 'Open' was a verb and not an adjective. Test the switch path too: changing locale mid-session, a cached CDN page serving the previous language, and edge data like a user with one name or a 24-hour clock.
Ask AI for it
Write a Playwright localization test suite for this app. Parameterize every test over the locales de-DE, ar-EG, ja-JP, and pt-BR: set the Accept-Language header and the locale URL segment, walk the main routes, and for each one assert no raw translation key is visible, assert no element overflows its container, assert dir='rtl' is applied for Arabic, and capture a full-page screenshot named by route and locale for visual diffing. Add unit tests that check date, number, and currency output against Intl formatters instead of hardcoded strings.