Practice locale testing vocabulary: pseudo-localization, pseudo-translation testing, locale-specific regression, RTL layout testing, text expansion testing, and character encoding issues.
0 / 5 completed
1 / 5
A QA engineer says: "We run pseudo-localization on every build to catch i18n issues early." What is pseudo-localization?
Pseudo-localization is a developer-time testing technique. It applies a transformation to all strings: add ~30-40% length padding (to simulate German/Finnish expansion), add accented characters (to test character encoding), and wrap strings in visible markers (to detect concatenation bugs). It catches problems before translations exist: truncated buttons, hardcoded English strings that bypass the i18n system, and layout breaks from longer text. It is fast, automated, and runs in CI.
2 / 5
A localization engineer reports: "The UI broke in RTL layout — the sidebar appeared on the wrong side." What is RTL layout and why does it require special testing?
RTL support is a full layout engineering challenge, not just text direction. Issues to test: navigation and breadcrumbs flow right-to-left, icons with directional meaning (arrows, chevrons) need to flip, form fields align differently, CSS margins and padding swap sides (margin-left ↔ margin-right), and third-party components that do not support RTL appear broken. Arabic and Hebrew together represent hundreds of millions of users — RTL testing is not optional for global products.
3 / 5
A QA report notes: "German strings are approximately 30% longer than English — several buttons are truncating the translated text." What is 'text expansion testing'?
Text expansion is one of the most common causes of i18n bugs. English is a compact language — most other languages are longer. Design with English strings, and buttons, labels, and nav items often truncate in German, Finnish, or Polish. Testing approach: use pseudo-localization with 30-40% string lengthening as a baseline, then test with real translations. Common fixes: dynamic font sizing, flexible button widths, abbreviated labels, or redesigned layouts with more text space.
4 / 5
A bug report states: "Locale-specific regression in the fr-CA locale — the date formatting shows MM/DD/YYYY instead of DD/MM/YYYY." What is a locale-specific regression?
Locale-specific regressions are tricky because they only manifest in certain locales — English-only testing misses them entirely. Common causes: a developer hardcoded a date format string instead of using the i18n library, a new feature bypassed locale-aware formatting, or a library upgrade changed default locale behaviour. Prevention: locale-specific automated tests for date/number/currency formatting, and CI that runs tests in multiple locale configurations, not just en-US.
5 / 5
A developer files a bug: "Character encoding issue — special characters in the Bulgarian translation are showing as question marks in the database." What does a character encoding issue mean in i18n context?
Character encoding issues in i18n: the classic cause is UTF-8 vs. Latin-1 (ISO-8859-1) mismatch. A database column set to Latin-1 cannot store Cyrillic, Chinese, Arabic, or many other scripts. The fix is ensuring UTF-8 throughout the entire stack: database connection, table/column collation, HTTP response headers (Content-Type: charset=UTF-8), file encoding, and API serialisation. A single non-UTF-8 link in the chain corrupts multilingual text. Modern best practice: UTF-8 everywhere, no exceptions.