Practice locale testing vocabulary: pseudo-localization, date format regressions, number format bugs, and currency symbol positioning errors across locales.
0 / 15 completed
1 / 15
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 / 15
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 / 15
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 / 15
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 / 15
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.
6 / 15
David from the UX team says: 'We're using contextual formatting to ensure date displays are appropriate for each locale. It automatically adjusts based on user settings.' Which of the following best describes what contextual formatting achieves?
Contextual formatting is about dynamic adaptation. It doesn't mean separate files; instead, it leverages locale information to format dates, numbers, and currencies correctly for each user's settings. This differs from a fixed translation table which would lead to inconsistent results across locales. The key difference lies in the system's ability to react to user preferences.
7 / 15
Sarah (QA) reports: 'Our API response for retrieving customer data is returning an unexpected format error for the `billing_address.street` field in the es-ES locale. The server is sending 123 Calle Mayor, but the client is interpreting it as 123, Calle Mayor.' What's likely causing this?
This issue stems from incorrect number parsing. The client is interpreting the comma as a thousands separator, which is common in Spanish number formatting. The API server might be sending the data correctly (123, Calle Mayor), but the client isn't handling that specific format. It's crucial to validate input and output formats for each locale.
8 / 15
During a standup meeting, Ben mentions: 'We found a regression in our German (de-DE) build. The currency is being displayed with a space after the decimal point – 1234.56€ instead of 1234,56€.' This indicates a problem with:
This regression highlights an issue with number formatting. The German locale uses a comma (,) as the decimal separator and a period (.) as the thousands separator. The number formatting library needs to be configured to correctly interpret these symbols in the de-DE locale; otherwise, it will incorrectly add spaces after the decimal point.
9 / 15
Maria writes a PR description: 'Fixed a localization issue where the 'Add to Cart' button text was not properly translated in the Polish (pl-PL) locale. The original English text was displayed directly without any translation.' This situation demonstrates a common problem related to:
This describes a failure in the localization workflow. It indicates that the system didn't properly substitute translated strings into the UI text for the Polish locale. The localization library is responsible for managing these translations and ensuring they're correctly inserted into the application's code; simply concatenating English text doesn't solve the problem.
10 / 15
John is reviewing a code change that introduces support for the Japanese (ja-JP) locale. He notices that all numbers are displayed without any thousand separators. Which of the following best describes the potential impact on user experience?
In Japanese number formatting, thousand separators are generally omitted. While the absence *might* seem easier for some, it can significantly reduce readability and comprehension when dealing with large numbers. The core principle of localization is to adapt formats to match user expectations within a given locale – omitting separators in ja-JP aligns with standard Japanese number representation.
11 / 15
David from the UX team says: 'We're using contextual formatting to ensure date displays are appropriate for each locale. It automatically adjusts based on user settings.' Which of the following best describes what contextual formatting achieves?
Contextual formatting is about dynamic adaptation. It doesn't mean separate files; instead, it leverages locale information to format dates, numbers, and currencies correctly for each user's settings. This differs from a fixed translation table which would lead to inconsistent results across locales. The key difference lies in the system's ability to react to user preferences.
12 / 15
Sarah (QA) reports: 'Our API response for retrieving customer data is returning an unexpected format error for the `billing_address.street` field in the es-ES locale. The server is sending 123 Calle Mayor, but the client is interpreting it as 123, Calle Mayor.' What's likely causing this?
This issue stems from incorrect number parsing. The client is interpreting the comma as a thousands separator, which is common in Spanish number formatting. The API server might be sending the data correctly (123, Calle Mayor), but the client isn't handling that specific format. It's crucial to validate input and output formats for each locale.
13 / 15
During a standup meeting, Ben mentions: 'We found a regression in our German (de-DE) build. The currency is being displayed with a space after the decimal point – 1234.56€ instead of 1234,56€.' This indicates a problem with:
This regression highlights an issue with number formatting. The German locale uses a comma (,) as the decimal separator and a period (.) as the thousands separator. The number formatting library needs to be configured to correctly interpret these symbols in the de-DE locale; otherwise, it will incorrectly add spaces after the decimal point.
14 / 15
Maria writes a PR description: 'Fixed a localization issue where the 'Add to Cart' button text was not properly translated in the Polish (pl-PL) locale. The original English text was displayed directly without any translation.' This situation demonstrates a common problem related to:
This describes a failure in the localization workflow. It indicates that the system didn't properly substitute translated strings into the UI text for the Polish locale. The localization library is responsible for managing these translations and ensuring they're correctly inserted into the application's code; simply concatenating English text doesn't solve the problem.
15 / 15
John is reviewing a code change that introduces support for the Japanese (ja-JP) locale. He notices that all numbers are displayed without any thousand separators. Which of the following best describes the potential impact on user experience?
In Japanese number formatting, thousand separators are generally omitted. While the absence *might* seem easier for some, it can significantly reduce readability and comprehension when dealing with large numbers. The core principle of localization is to adapt formats to match user expectations within a given locale – omitting separators in ja-JP aligns with standard Japanese number representation.
What will I practise in "Locale Testing Vocabulary"?
Practice locale testing vocabulary: pseudo-localization, date format regressions, number format bugs, and currency symbol positioning errors across locales.
How many exercises are in this module?
This module has 15 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 i18n & l10n exercises?
Browse the full i18n & l10n 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.