Practise vocabulary for pseudo-locales, character substitution, text expansion simulation, and layout bug detection.
0 / 5 completed
1 / 5
Pseudo-localization is used during development to:
Pseudo-localization replaces each character with a visually similar but different character (a → ȧ, b → ƀ) and wraps text with padding markers. Any string that does NOT change is hardcoded. Text expansion reveals layout issues before real translations exist.
2 / 5
Text expansion simulation in pseudo-localization is important because:
Text expansion guidelines: German +30%, Finnish +35-50%, other European languages +20-35%. 'Submit' (6 chars) might become 'Absenden' (8 chars) in German and 'Soumettre' (9 chars) in French. Test with 40% expansion as a conservative minimum.
3 / 5
The phrase 'pseudo-localization revealed that 12 UI strings overflow their containers' means:
Overflow bugs manifest as: truncated text (...), broken layouts, text overlapping adjacent elements, or buttons that are too small for their labels. Pseudo-loc finds these before translators deliver real translations — much cheaper to fix early than during final localization QA.
4 / 5
A bidirectional pseudo-locale (like en-xb) is used to:
RTL pseudo-locale (en-xb or similar) enables RTL testing before RTL translations exist: set the document dir to rtl, apply bidi characters, verify the layout mirrors correctly. Many teams skip RTL testing until late in the cycle and discover fundamental layout architecture issues then.
5 / 5
In pseudo-localization, wrapped strings using brackets like [!!! Ȧccȯȣnṫ !!!] serve to:
Bracketing serves dual purposes: (1) strings without brackets are hardcoded — they never passed through the i18n pipeline. (2) brackets appearing in the middle of a sentence reveal incorrect string concatenation ('Please [click here] to continue' shows that 'click here' is a separate string that should be embedded).