Pseudo-localization is a testing method that replaces an app's source text with an altered version, using accented characters, longer strings and visible markers, to find internationalization problems before any real translation begins. It shows hard-coded strings, truncated text, broken layouts and encoding issues in minutes, without waiting for translators. This guide explains how pseudo-localization works, what it catches and how to add it to your development process.
What Pseudo-Localized Text Looks Like
The English string Save changes might become [Šåṽé çĥåñĝéš ~~~~]. The text is still readable for developers and testers, but it is clearly different from the source:
- Accented characters test whether fonts and encoding support non-ASCII text.
- Extra length, often 30 to 50 percent, simulates languages such as German or Finnish that need more space.
- Brackets or markers at the start and end show whether a string is cut off.
- Right-to-left pseudo-locales can mirror text direction to test RTL layouts.
What Pseudo-Localization Catches
| Problem | How it shows up |
|---|---|
| Hard-coded strings | Text stays in plain English while everything else is pseudo-localized |
| Truncation | The closing marker is missing or text is cut off |
| Layout problems | Buttons, menus and labels overflow or overlap |
| Encoding issues | Accented characters appear as question marks or broken symbols |
| Concatenation | Sentences built from fragments show several separate markers |
| Images with text | Text inside images is not affected and stands out |
How to Pseudo-Localize Your App
- Externalize strings into resource files, as described in our guide to what is i18n.
- Generate a pseudo-locale automatically from the source files with a script or your framework's built-in tools.
- Run the app in the pseudo-locale and click through every screen.
- Log and fix issues in code and design, not in translations.
- Repeat in CI so new screens are checked before every release.
Built-In Support in Frameworks
Android includes two pseudo-locales: en-XA for accented, expanded text and ar-XB for right-to-left testing. You can enable them in the build configuration and choose them in the device language settings, as described in the Android pseudolocales documentation. Many JavaScript i18n libraries and localization platforms also offer pseudo-localization plugins or settings.
Pseudo-Localization vs Localization Testing
Pseudo-localization tests whether the product is ready for translation. Localization testing checks the real translated product for linguistic, visual and functional issues. The first saves time and money; the second protects quality at release.
Best Practices
- Pseudo-localize early, ideally from the first sprint of a new feature.
- Use realistic expansion rates for your target languages.
- Include both an accented and a right-to-left pseudo-locale if you plan RTL markets.
- Never ship pseudo-localized strings to production.
- Share screenshots with designers so they plan for longer text.
From Pseudo-Localization to Real Translation With WordBeam
When your app passes pseudo-localization, it is ready for real languages. WordBeam imports resource files such as JSON, XLIFF, PO, CSV and XLSX, protects keys and placeholders, and combines translation memory, glossaries and AI engines for fast first drafts. Workflow automation and Git integrations on the Studio plan keep translations in step with development. Try it free for 14 days.
Frequently Asked Questions
What is the purpose of pseudo-localization?
To find internationalization bugs such as hard-coded text, truncation and encoding problems before translation starts.
Is pseudo-localization the same as machine translation?
No. Pseudo-localization does not translate anything. It transforms the source text in predictable ways for testing.
How much should pseudo-localization expand text?
Many teams use 30 to 50 percent, with more for very short strings, because short labels often grow the most in translation.