Pseudo-Localization — Vocabulary and Techniques

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

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

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

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

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