Practice locale testing vocabulary: pseudo-localization, pseudo-translation testing, locale-specific regression, RTL layout testing, text expansion testing, and character encoding issues.
0 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Sarah (Lead Developer) asks you to review this PR description:
"Fixed a bug where the date format was incorrect for French users. We've updated the `DateTimeFormatter` to use the `fr_FR` locale."
This question tests understanding of PR descriptions and localization. The correct answer highlights the importance of using locale-specific formatting options like `DateTimeFormatter`. Incorrect options suggest a misunderstanding of how localization aims for adaptability across different locales – specifically, that localization isn't just about string replacement but adapting to regional conventions.
7 / 10
David (Senior Developer) sends you this Slack message:
'Just ran a test with the new German locale. The 'Save' button text is truncated after the first three characters! Looks like we need to investigate character limits.' What does 'truncated' mean in this context?
This tests vocabulary around UI limitations. 'Truncated' specifically refers to text being cut off due to exceeding a defined length limit – crucial in localization where character counts are often constrained by platform or design requirements. The other options misinterpret the situation; David is reporting a real issue with the translated string's size.
8 / 10
Maria (QA Lead) reports:
'We've identified a regression in our Spanish locale testing. The application consistently displays the currency symbol incorrectly – it's showing as '€' instead of '$'. This started happening after the recent update to the payment processing module.' What does 'regression testing' indicate?
This question tackles the concept of regression testing. The core meaning is that a previously stable feature—in this case, currency display—has unexpectedly changed its behavior after a code change. This highlights the importance of ongoing testing to prevent unintended consequences and ensures changes haven't negatively impacted existing functionality.
9 / 10
Ben (Developer) writes in a standup update:
'I'm working on adding support for the Japanese locale. I've been focusing on ensuring correct right-to-left (RTL) text rendering, particularly with the navigation menu.' What is 'right-to-left' (RTL) layout?
This tests understanding of RTL layouts. The key is recognizing that RTL refers to the direction in which text flows – from right to left—a critical consideration for languages like Japanese and Arabic where reading patterns differ significantly from English. It's a fundamental aspect of localization testing.
10 / 10
Chloe (Localization Engineer) sends this API response:
{
"locale": "es-MX",
"version": "1.2",
"message": "Error: Invalid locale code."
}
This question examines how localization errors are communicated via APIs. The response clearly indicates an issue: the provided locale code (`es-MX`) was invalid or unsupported by the system. This is a common scenario when incorrect locale codes are used in applications or configurations – often leading to unexpected behavior.
What will I practise in "Locale Testing Vocabulary"?
Practice locale testing vocabulary: pseudo-localization, pseudo-translation testing, locale-specific regression, RTL layout testing, text expansion testing, and character encoding issues.
How many exercises are in this module?
This module has 10 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Localization Engineering Language exercises?
Browse the full Localization Engineering Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.