Practice locale testing vocabulary: pseudo-localization, date format regressions, number format bugs, and currency symbol positioning errors across locales.
0 / 5 completed
1 / 5
The QA team uses ___ localization to test UI layout before translations are available.
Pseudo-localization replaces each source string with an artificially lengthened version using accented characters (e.g., '[Ţĥĩś ĩś ã ţēśţ śţřĩńĝ]'). It simulates translated text to find UI truncation, hard-coded strings, and layout bugs without needing real translations.
2 / 5
The tester reports: '___ localization expands strings by 30%.' Why does this matter for UI design?
Pseudo-localization typically expands strings by 30-40% (some tools go up to 100%) to simulate languages that are longer than English. This reveals UI components that will break when real translations arrive for verbose languages.
3 / 5
The regression report says: 'The ___ format is wrong for ja-JP — it shows MM/DD/YYYY instead of YYYY/MM/DD.'
Date format regression means the application is displaying dates in an incorrect format for the specified locale. Japanese (ja-JP) uses YYYY/MM/DD; US English uses MM/DD/YYYY; ISO 8601 uses YYYY-MM-DD. Mixing these is a common i18n bug.
4 / 5
CI catches a ___ format regression in de-DE: 1,234.56 is displayed as 1.234,56 in one component and 1,234.56 in another.
German (de-DE) uses a period (.) as the thousands grouping separator and a comma (,) as the decimal separator — opposite to US English. A number format regression means some components are formatting 1234.56 correctly as '1.234,56' while others are not.
5 / 5
A tester files a bug: 'The ___ symbol appears on the wrong side in the fr-FR locale — it should be 42,00 € not €42,00.'
Currency symbol positioning is locale-specific. In French (fr-FR), amounts are formatted as '42,00 €' with the symbol after the amount and a non-breaking space. In US English, the dollar sign precedes the number: '$42.00'. Getting this wrong is a visible l10n defect.