What is pseudo-localization, and which defects does it catch before any translation exists?

### What pseudo-localization is Pseudo-localization is a build-time transformation that replaces every extracted source string with an algorithmically mangled version of itself, then runs the product against that fake locale. Nothing is translated; the point is that nothing *needs* to be. The transformation is deterministic, costs nothing per run, and can therefore sit in the pipeline from the first sprint — long before a translation budget exists. A conventional transform does four things at once: - **Accents or script-shifts every letter** ("Save" becomes something like "Šàvé"), so text that has gone through the catalogue is visually obvious and text that has *not* stands out as plain source language. - **Pads the string** by a fixed percentage, to simulate expansion. Padding of roughly a third to a half is the common rule of thumb; the real expansion depends heavily on string length — short labels expand proportionally far more than paragraphs — and any single percentage is a heuristic, not a measured law. - **Wraps the string in visible boundary markers**, so a sentence assembled from several fragments shows up as several bracketed pieces in a row. - **Optionally mirrors** the pseudo-locale's declared direction, to get an early look at a right-to-left rendering path. ### What it actually catches Because the transform touches only strings that came from the catalogue, the *absence* of the transform is the signal. A pseudo-localized build reveals, cheaply and repeatably: - **Strings never extracted.** Anything rendering in plain source text is hardcoded past the extraction step, or built at run time from code, or arriving unwrapped from a downstream service. - **Expansion and truncation.** Containers that were sized to the source string clip, ellipsize, wrap badly or push controls out of reach once every string is 40% longer. - **Concatenation.** Boundary markers appearing mid-sentence prove a sentence was assembled from parts, which is unfixable by translation alone. - **Encoding and font path failures.** Characters outside the source alphabet arriving as replacement glyphs, question marks or mojibake point at a byte-level assumption somewhere in storage, transport, logging or rendering. - **Byte-based truncation.** A string cut at a byte count rather than a character count splits a multi-byte character and produces a broken final glyph. - **Fixed-width and overflow assumptions** in exports, receipts and printed documents, which are usually the last surfaces anyone checks. ### What it cannot tell you Pseudo-localization is an internationalization test, not a localization test. It says nothing about whether real wording reads naturally, whether the plural forms of a genuine locale are correct, whether the term matches the glossary, whether a date order or currency convention is right for a region, or whether the tone suits the audience. It also gives only a rough hint about a right-to-left rendering: mirrored pseudo-text exercises the direction plumbing, but not the mixed-direction ordering of real text with embedded numbers and identifiers. Treat a green pseudo-localized run as "the product is ready to receive translations", never as "the product is ready for that market". ### Running it as a gate The pattern that works is a selectable pseudo-locale in the same build the team already runs — chosen by a setting, not a separate branch — plus a scripted walk through the critical flows capturing every screen, and a small set of assertions that can be automated rather than eyeballed: no visible string lacking boundary markers, no clipped text node, no replacement glyph in the captured text, no message containing two closing markers followed by an opening one. The visual review that remains is a human pass over the captured screens. ### A worked example A utility billing portal ran its first pseudo-localized pass over 2,600 catalogue entries and a scripted walk of 41 screens. Seventeen strings rendered in plain source text: fourteen were toasts and error messages built in code, two came unwrapped from a downstream statement service, and one — "Duplicate charge reversed" — was generated inside the payment path, which is exactly the message a customer sees during the incident they are most upset about. A further nine containers clipped under padding, all of them table headers on the account statement. None of that required a translator, a vendor contract or a single translated word; it required one pipeline job and an afternoon of screenshot review, and it was found roughly four months before the first locale shipped. ### Where it sits in the order of work The sequence that avoids rework is: extract strings, run pseudo-localization until it is clean, fix the internationalization defects it exposes, *then* buy translation. Reversing that order means paying for translation of a build that cannot display it, and re-testing every locale after each structural fix.