A QA engineer asks: "Why do we run pseudo-localization tests before sending content to translators?" Which answer is most accurate?
Pseudo-localization is a shift-left testing technique for i18n — it surfaces layout and extraction bugs before they become costly translation rework.
Running pseudo-locale (e.g., en-XA) before sending to translators catches: (1) hardcoded strings that were never extracted — they appear as plain English while everything else is in the pseudo-locale; (2) UI truncation — buttons and labels with expanded pseudo-text overflow their containers; (3) missing placeholder handling — if pseudo-locale shows {username} literally instead of a name, the interpolation is broken; (4) non-Unicode characters — fonts that can't render accented characters show boxes. All of these are engineering bugs, not translation bugs — they should be fixed before translators see the strings.
Key vocabulary: • pseudo-localization — test with fake expanded/accented strings before real translation exists • l10n readiness test — verifying the app handles translated content correctly at the engineering level • hardcoded string — a string in application code that was not extracted to a resource file; will never be translated
2 / 10
A developer creates a pseudo-locale by replacing "Submit" with "[Ŝúbmïţ šóméẃhéré lóñgér]". What are the three specific i18n issues this pseudo-string is designed to detect?
A well-designed pseudo-string simultaneously tests three failure modes: truncation (string length), encoding (Unicode), and extraction (brackets expose hardcoded strings).
The three-in-one design: (1) Length expansion — padding "Submit" (6 chars) to "Ŝúbmïţ šóméẃhéré lóñgér" (26 chars) simulates German or Finnish expansions; any button that only fits 10 characters will visibly overflow; (2) Unicode/font handling — accented characters (ú, ï, ñ) expose fonts that only support ASCII, encoding issues (Latin-1 vs. UTF-8), and rendering bugs; (3) Hardcoded string detection — the surrounding [brackets] make it easy to spot English text that was never extracted: if you see "Hello, John! [Ŝúbmïţ]", the "Hello, John!" part was hardcoded and needs to be extracted.
Key vocabulary: • string expansion — simulating longer translated text to find UI layout issues • bracket wrapping — [string] notation to identify untranslated hardcoded strings visually • Unicode coverage test — accented characters verify font and encoding can handle non-ASCII
3 / 10
A frontend engineer is asked to create a pseudo-RTL locale for their React app. What is the purpose of a pseudo-RTL test?
Pseudo-RTL testing validates the layout engine's RTL support before committing to an Arabic or Hebrew localization — finding directional bugs early.
Common RTL layout bugs found by pseudo-RTL testing: (1) icons facing the wrong direction (a forward arrow should face right in LTR, left in RTL — many teams forget to flip directional icons); (2) text alignment — CSS text-align: left should become text-align: right or use logical properties (text-align: start); (3) flex-direction — some flexbox layouts use row but should use row-reverse in RTL; (4) absolute positioning — elements positioned with left: 0 need to be mirrored to right: 0 in RTL. A pseudo-RTL locale (e.g., using document.dir = 'rtl') surfaces all these without needing real Arabic text.
Key vocabulary: • pseudo-RTL locale — a test locale that enables RTL layout direction without real RTL translations • directional icons — icons like arrows, back/forward buttons that must be mirrored in RTL layouts • logical CSS properties — padding-inline-start (vs. padding-left), border-inline-end; automatically handle RTL without media queries
4 / 10
A localization engineer reports: "The pseudo-localization pass revealed 23 untranslated strings." What does this mean and what action is needed?
Untranslated strings in pseudo-localization output = hardcoded strings — they are engineering bugs, not translation gaps, and must be fixed by the developer.
When the pseudo-locale is active, every string extracted to the resource file appears in the fake accented format. Strings that appear as plain English are hardcoded — the i18n function was never called for them. The fix for each: (1) identify the source code location of the hardcoded string; (2) replace the literal string with a call to the i18n function (e.g., t('error.network.timeout')); (3) add the key and source string to the resource file; (4) re-run pseudo-localization to verify it now shows the accented version. If these are not fixed before sending to translators, those strings will never be translated in any locale.
Key vocabulary: • untranslated string (pseudo-l10n context) — a hardcoded string not extracted to the resource file; invisible to translators • string extraction — replacing hardcoded text with i18n function calls (t('key'), gettext('msgid')) • resource file — the file (en.json, messages.xliff) containing all translatable string keys and source values
5 / 10
A project manager asks: "We're targeting German, Finnish, and Japanese — should our pseudo-locale simulation account for both string expansion and string contraction?" Which answer is correct?
Both expansion (German, Finnish) and contraction (Japanese, Chinese) cause layout problems — professional i18n testing accounts for both extremes.
Expansion problems: buttons overflow, labels truncate with ellipsis, tooltip boxes grow too tall. Contraction problems: buttons have excess whitespace and look unbalanced, form fields look misaligned when labels are much shorter than designed, navigation menus have uneven tab widths. A thorough pseudo-localization strategy uses two pseudo-locales: (1) an expanded locale (all strings padded to 140-150% of English length) and (2) a contracted locale (all strings shortened to 60-70% of English length). Many TMS platforms generate both types of pseudo-locale automatically. The goal: a layout that looks good at both extremes will likely handle all real translations well.
Key vocabulary: • string expansion — target language text is longer than source; causes truncation and overflow • string contraction — target language text is shorter; causes alignment and whitespace issues • expansion ratio — typical expansion rates: German +30-40%, French +15-20%, Finnish +40-50%, Japanese -20-30% vs. English
6 / 10
David (Senior Developer) comments on your PR: 'This pseudo-locale is great! But I'm seeing a lot of 'missing key' errors. Can you explain what that means in the context of our localization workflow?' Which explanation best addresses David's concern?
'Missing key' errors in pseudo-localization don't necessarily represent a bug. They highlight that the simulated locale doesn't have enough translated strings to fully match its configured locales - this is precisely what David is referring to. The system is flagging areas where translations are genuinely absent, prompting a deeper investigation into string expansion and potential locale mismatches.
7 / 10
Sarah (Localization Engineer) sends you this Slack message: 'Just ran the pseudo-localization for French. The output shows 17 instances of '[LocaleName]' placeholders remaining untranslated. This is significantly higher than our usual rate – around 3-5. What could be causing this?' Which response best addresses Sarah's observation?
Sarah's observation points towards a potential issue with the pseudo-locale simulation itself. The higher rate of '[LocaleName]' placeholders suggests that the system isn't correctly modeling the intricacies of French string expansion – this is a common problem when the simulation doesn't fully account for locale-specific rules and variable usage.
8 / 10
You're writing the description for a PR that introduces a new pseudo-locale for Spanish. Which of the following statements best summarizes its purpose and scope? Consider this text to be going into the PR's description field.
The core function of a pseudo-locale is not simply translation but rather *simulation*. It's designed to proactively identify problems related to string expansion/contraction and RTL layout – aspects that often get overlooked during initial translation workflows. Option 1 accurately reflects this focused testing purpose.
9 / 10
Mark (Product Manager) asks: 'We're planning a new international rollout targeting Brazilian Portuguese and Dutch. Should we create separate pseudo-locales for each or can we leverage one shared simulation?' What's the most effective approach?
While a single shared pseudo-locale *can* be efficient initially, it's crucial to recognize that Portuguese and Dutch have distinct linguistic features (e.g., different string expansion rules, RTL conventions). A dedicated approach – creating separate simulations – ensures the simulation accurately reflects the nuances of each language and avoids misleading results. This is a critical consideration for accurate localization testing.
10 / 10
The output of your pseudo-localization run for Japanese shows: '35 untranslated strings – predominantly variable placeholders and date/time formats.' What's the *primary* next step you should take?
The key insight here is the type of strings flagged – variable placeholders and date/time formats. These are often the most complex and error-prone areas in localization. Prioritizing translation based on frequency of use ensures that the highest-impact issues are addressed first, optimizing the localization process.
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.