Turns interface strings into recognisably «foreign» but readable ones: one pass reveals hardcoded strings, future overflow and truncation. Placeholders are never touched. Everything runs in your browser.
Your locale file never leaves the page — everything runs in your browser
Anything still in plain text does not pass through the localisation system. This finds what neither grep nor review catches: labels inside third-party components, error messages and hints baked into the code.
Future overflow
Length
+30 % · +60 %
The text is lengthened artificially so the container breaks early — before translation is even ordered. Thirty per cent covers a typical European language, sixty the hard case like German.
Truncation and concatenation
Borders
[ … ] ← markers
The start and end markers are gone — the string was either truncated by length or assembled from pieces. Both break on the first language with a different word order.
Encoding problems
Font
Ŝéţţîñĝŝ → ??????
Diacritics render as boxes or question marks — the font lacks the glyphs, or an encoding was lost along the way. On plain Latin without diacritics this is invisible.
04
Protected constructs
Format
Example
Where it appears
{0}, {1}
Файл {0} из {1}
.NET, Java
{name}, {{count}}
Привет, {name}
i18next, Vue, Handlebars
ICU MessageFormat
{count, plural, one {# файл} other {# файлов}}
Full nesting support
%s, %d, %1$s
Найдено %d совпадений
C, PHP, Python
%(name)s
Привет, %(name)s
Python
<b>, <a href=…>
Читайте <a href="/help">справку</a>
Markup inside strings
, &
1 299 ₽
HTML entities
[[link]]
См. [[Главная]]
Wiki markup
Parsing is done by tokenization: the string is split into protected and translatable parts before any substitution. A regex replace eventually eats the contents of a placeholder — and the locale file stops working.
05
Frequently asked questions
A technique that turns interface strings into a recognisably «foreign» but still readable form: «Settings» becomes «[!!! Ŝéţţîñĝŝ ᐊᐊᐊᐊ !!!]». One pass surfaces three things that otherwise appear only after translation comes back — hardcoded strings, containers that will overflow, and text that gets truncated or concatenated. Microsoft, Chrome and Firefox all use it as a standard step before shipping a localised build.
Run your locale file through pseudolocalization and open the app. Anything still in plain text does not go through the localisation system — it is hardcoded. This finds what neither grep nor review catches: forgotten labels, error messages and strings baked into third-party components, without touching a line of source.
A translation produces real text in another language and needs a translator, time and money. Pseudolocalization translates nothing: it distorts the source mechanically to check whether the interface is ready for any translation at all. It takes a second and happens before translation is ordered — that is the whole point.
Thirty per cent covers a typical European translation; sixty covers the hard case, like German with its compound nouns. Start with the medium level — it already catches overflowing buttons and menu items. Take the heavy one when the interface has passed medium and you want headroom.
No, and that is the tool's primary requirement. The string is split into protected and translatable parts before any substitution: `{name}`, `{count, plural, …}`, `%s`, `%1$s`, `<b>`, ` ` and `[[link]]` reach the output byte for byte. A regex replace eventually eats the contents of a placeholder — there is none here.
No. The transformation runs entirely in your browser and makes no network request, neither when you paste the text nor when you copy the result. Your locale file never leaves the tab — which matters more than it sounds, because interface strings routinely carry internal project names, client names and labels for features that have not shipped yet.