Pseudolocalization is the only locale you can test before you have one

A test locale before a translated product

You can test whether a doorway admits a wide load before the real shipment arrives. Push a wide stand-in through it. If the stand-in catches, the doorway needs work. If it passes, you have learned something about width, not whether the shipment will arrive intact.

Pseudolocalization works the same way. It takes source-language messages and deliberately distorts them while leaving them readable: accented characters, extra length, visible boundaries, or a right-to-left presentation. No translator has to finish a target language first. Android calls these generated test languages pseudolocales and provides separate variants for expansion and right-to-left behavior ¹.

“Before you have a locale” means before you have a translated target build. The product already has a source locale. You can also test real locale data without translated UI. The special value of a pseudolocale is that it makes the message pathvisible while stressing the interface it feeds. That is a narrower, more useful claim than saying a fake language proves the product is ready for every real one.

The fake text has to take the real path

A pseudo build should select a locale, load messages through the application’s ordinary lookup path, format them, and render them on actual screens. If a team only transforms a screenshot, it has tested pixels. It has not tested whether a source string was extracted, whether the right key was loaded, or whether that key survives formatting.

Android’s pseudo IDs follow normal locale naming conventions and can be parsed by BCP 47 compliant software. Its English XA variant accents, expands and brackets messages; its AR XB variant exercises right-to-left presentation ¹. The point is not the exact accent marks. The point is that the same lookup that would eventually fetch French or Arabic now fetches a conspicuous test value.

Shopify described a useful version of this during its own internationalization work. It intercepted translation calls, changed the returned characters and lengthened the text. That let engineers distinguish extracted content from old hardcoded copy in the running product, and inspect the layout under longer words ². The mechanism mattered because it ran at the boundary real translations would later cross.

Unchanged English is a clue, not a verdict

Open a pseudo screen and find an ordinary English label amid accented, bracketed messages. That is a useful lead. It might be a literal in the component, a fallback after a missing key, or content fetched from outside the message catalog. Android explicitly names untransformed text as a way to spot messages that cannot be translated ¹.

But ordinary English is not automatically a defect. A product name, a code sample and a user’s own text may need to stay exactly as they are. Mark the expected exceptions, then investigate the rest. Otherwise the same visual signal that finds a missed button will send a team after strings it should never translate. The decision still depends on where a value came from and where it flows. We examined that distinction in translatable is a destination, not a property.

A pseudo run also catches a subtler defect: text assembled from fragments. Android brackets each message unit so a sentence made from multiple keys shows multiple boundaries. A translator cannot freely reorder the sentence when its pieces are stored apart ¹.

source messages  delete_prefix = "Delete "  delete_suffix = " files?"​schematic pseudo screen  [Đëľëţë ] 5 [ fïľëš?]

Make the layout fail on purpose

An English label that fits is no evidence that its translation will. Expansion pushes text against buttons, tabs, dialogs and narrow columns. A useful check looks for clipped glyphs, overlapping controls and actions that disappear when their labels wrap. It also checks whether the control remains usable after the text grows. Android’s English XA variant is designed to reveal precisely this kind of layout breakage ¹.

Direction is a separate test. A wide left-to-right string can fit perfectly while an RTL screen leaves its navigation on the wrong side, misplaces punctuation or scrambles a mixed-direction phrase. Android’s AR XB pseudo variant exists to make those failures visible before anyone has written Arabic copy ¹. Run both variants. Passing the expansion case says nothing about mirroring.

Choose how hard the stand-in pushes. A tiny expansion can leave a rigid button looking healthy. A deliberately longer message exposes its fixed width. The chosen distortion is part of the test, so a green result is only meaningful beside the transformation that produced it.

A green pseudo run needs a stated pass condition

“The pseudo build passed” can mean the message files parsed. It can mean the home page rendered. It can mean somebody inspected every important screen at narrow and wide widths. Those are different claims.

Write down the contract for the run. Which routes and states were exercised? Which visible strings are expected to transform? Which ones are intentional exceptions? Which widths were checked for clipping? Was the RTL variant navigated, or merely launched? Did a placeholder or plural message still format with real sample values? The answers tell a reviewer what the green check actually covers.

Keep structural checks alongside the visual pass. A pseudo message that looks fine can still have lost a placeholder or a plural branch. Parsing and comparing message structures gives that failure a deterministic gate. The visual run catches what a parser cannot: where the resulting text lands in the interface.

The stand-in cannot speak for a real locale

A stand-in does not speak the target language. It cannot tell you whether a phrase is grammatical, polite or appropriate for a market. It cannot tell you whether a real translation chose the right terminology. The pseudo text was generated from the source, so it contains none of those decisions.

It also does not replace tests of locale data. Dates, currencies, number formats, sorting and plural behavior vary by locale. W3C explicitly treats support for those preferences as part of internationalization even when no content has been translated ³. Unicode CLDR supplies the locale data many applications use for them ⁴. A pseudo string can show that a date label has room; a real locale and representative values are needed to test the date itself.

This is why a passing pseudo run is evidence of a tested path, not a certificate of localization readiness. It narrows the defects that translation would otherwise discover late. It leaves linguistic and market-specific questions open for real target-language review.

Keep the test before and after translation arrives

Run the pseudo variants while the product still has only one language, then keep running them as source messages and screens change. A translated build arriving later does not stop new English literals, fixed widths or physical left-and-right assumptions from entering the code. The same probe that found the first defect can catch the next one closer to the change that caused it.

Start with one real route and one explicit pass condition. Make every visible message go through the ordinary locale lookup, verify the intended exceptions, and look at the expanded and RTL versions of that route. Then add the states that matter. This turns pseudolocalization from a demonstration into a test whose failures someone can fix.

The plank in the doorway is useful because it is wider than the opening. A pseudo run is useful when it is designed to catch on the assumptions a real translation would hit later.

References

1. 1.Android Developers Test your app with pseudolocales Android Developers
2. 2.Blais, 2018 Lost in Translations: Bringing the World to Shopify Shopify Engineering, 10 October 2018
3. 3.W3C Internationalization Localization vs. Internationalization W3C Internationalization
4. 4.Unicode Consortium Unicode CLDR Project Unicode CLDR