Pseudolocalization: testing your pipeline before a single real translation exists

Pseudolocalization is a test technique, not a translation. It takes your source text and mechanically transforms it — adding accented characters, padding it longer, wrapping it in brackets — to produce a fake translation that no human ever wrote. The point is not to read it; the point is to run your game against it and see what breaks, at a point in development when no real translation exists yet to test with.

What a pseudolocalized string actually looks like

A common transformation takes each source string and does three things to it: replaces plain Latin characters with accented look-alikes, pads the length by roughly a third to simulate a language that runs longer than the source, and wraps the whole thing in brackets so the boundaries of the string are visible on screen.

// Source
"Press Start to continue"

// Pseudolocalized
"[Ṕŕéśś Śťáŕť ťő čőńťíńúé ẃíťĥ éxťŕá ŕőőḿ]"

What it catches

Each part of the transformation is designed to expose a specific class of pipeline bug, before any translator's time is spent finding it by accident:

• Hardcoded strings — any text that stays plain, unaccented source text while everything around it turns into pseudo-text is a string that never went through the localization pipeline at all, usually because it was written directly in code instead of pulled from the string table
• Overflow from expansion — the padded length simulates the fact that translated text is often longer than source text, so any UI element that clips, wraps badly, or overlaps a neighbor under pseudolocalization will very likely overflow again under real translation
• Encoding and font issues — accented and non-Latin-adjacent characters exercise the same rendering path that a real target language will need; if a font is missing glyphs or a rendering pipeline mishandles multi-byte characters, pseudolocalization surfaces it immediately as broken glyphs or boxes
• Concatenation bugs — the bracket markers make the start and end of each string visible, so a screen built by concatenating several strings together at runtime (instead of using a single templated string) shows brackets appearing in the middle of what should be one continuous sentence

How it is generated

Because the transformation is mechanical — character substitution and padding — it can be scripted as a build step that runs over the same string table your real translations will eventually populate, producing a full pseudolocale without needing anyone to translate anything. That is the whole appeal: it costs no translator time and can be regenerated automatically every time the source string table changes, so it stays current with a fast-moving source file in a way that hand-maintained test data cannot.

When to run it in the schedule

Pseudolocalization is most valuable early — ideally as soon as the string table and localization pipeline exist at all, well before a translation vendor is engaged. Running it early catches hardcoded strings and layout overflow while they are still cheap to fix: a UI issue found while the interface is still being built is a design adjustment, while the same issue found after real translations have already shipped is a bug that reads as a translation-quality problem to a player, even though it was really a layout problem all along.

It is also worth re-running whenever the string table changes significantly — a new UI screen, a new content type — since pseudolocalization is cheap enough to treat as a routine regression check rather than a one-time milestone.