Pseudo-Localization in Design Review: Find Text Overflow Before Translation

Pseudo-localization can reveal UI problems before they become expensive to fix. A checkout button reads “Pay.” In German, it becomes “Jetzt bezahlen.” In the design file, it looked fine because the design file was in English.

By the time anyone sees the problem, the string has been translated, exported, imported, and built. Fixing it now needs a designer to adjust the component, an engineer to update the layout, localization to re-export the file, and QA to retest the screen. Four people and a sprint, for something that took one person ten seconds to cause.

The key point is that pseudo-localization itself is not new. Most localization teams have been using it for years. The real issue is when it is performed.

Typically, pseudo-localization happens after the design or development handoff, when identifying and fixing localization-related layout issues can be costly and time-consuming. By moving it earlier into the design review stage, teams can identify potential issues before handoff, when the solution is often nothing more than a simple five-minute layout adjustment.

Why should pseudo-localization run before translation?

Because pseudo-localization during design review is the last moment you can change a component without opening a rework loop. W3C guidance on text size in translation specifically warns designers to allow for expansion when content moves between languages, and design review is where that allowance either exists or does not.

The failures show up immediately. A payment button renders “Pay” as [Þåý!!!!!!] and collides with a price. A settings tab exposes a fixed 80-pixel container. A modal title wraps to three lines and pushes the primary action below the fold at 320 CSS pixels, the width referenced in WCAG 2.2 Reflow.

It also surfaces source ambiguity, which is a quieter benefit. The English navigation label “Home” can be read as a residence and translated into French as “maison” when the software context calls for “Accueil”. A pseudo-review cannot translate the word. It can force a source note before the string ever leaves design, which is the cheapest point at which that defect can be fixed.

What should a pseudo-localization review test?

Five failure classes: Expansion, character coverage, variable safety, directionality, and language metadata.

The lang and dir checks deserve their own attention. W3C guidance on declaring language explains how language metadata supports processing and accessibility, and separate W3C guidance on text direction explains why direction should be declared rather than inferred. The two attributes are not interchangeable, and treating them as interchangeable is one of the most common ways an Arabic build can end up being unusable. Do not limit the review to long marketing copy. Short UI strings carry disproportionate risk, because they sit inside compact components. A three-letter English label fits neatly inside a pill. Its pseudo-localized version will tell you whether that pill was ever going to survive German.

How much expansion should you simulate?

Use two profiles rather than one, because expansion is not uniform. W3C guidance notes that shorter source strings expand proportionally more than longer ones, which is the opposite of where most designers assume the risk sits.

A moderate profile suits body copy, descriptions, and multi-line content, where a modest increase rarely breaks a flexible container. An aggressive profile belongs to the compact components: Buttons, tabs, badges, pills, table headers, form labels, navigation items. Those tend to be fixed-width by habit and short by design, so they absorb the largest proportional growth in the least available space.

W3C reproduces average expansion rates published by IBM for English into European languages. They are worth knowing precisely, because they show how sharply the risk concentrates in short strings.

The W3C article gives a concrete illustration. The Flickr interface label “views” became “visualizzazioni” in Italian, a ratio of 3 to the English source. German “-mal angesehen” came in at 2.8, French “consultations” and Portuguese “visualizações” at 2.6. Korean “조회” was shorter than the English at 0.8, which is a useful reminder that expansion is not universal.

Set the aggressive profile based on your actual target languages. A product launching in German, Finnish, Polish, and Russian needs more rigorous testing than one launching in Japanese and Korean, where character-based scripts can often take up less horizontal space than English. If you are going to set one number and leave it at that, base it on a ten-character label translated into Italian, rather than a paragraph translated into Japanese. How do you run the review in Figma?

Use two pseudo locales, one expanded Latin and one RTL, mirroring Android’s documented en-XA and ar-XB pseudolocales.

• Extract source strings from the design file so every visible label carries a string ID. Orphaned text layers are a localization risk in themselves, because engineering cannot map them to resource files.
• Generate pseudo strings with variables preserved. If {userName} becomes editable text, you have already found a handoff defect.
• Apply pseudo strings to the component library before individual screens. Otherwise, a broken button variant reappears across every checkout, account, and onboarding flow, and you fix it five times.
• Review the smallest supported breakpoint first, including the 320 CSS pixel Reflow condition. Overflow that passes on desktop routinely fails on mobile.
• Log each issue with component, string ID, viewport, screenshot, and owner. A ticket that says “German will be longer” gives engineering nothing to reproduce.

The pseudo-output should look deliberately noisy. Brackets show where a string starts and ends. Accents reveal encoding and font problems. Padding characters expose fixed-width components. For RTL, pseudo-bidi text should make direction defects obvious long before Arabic or Hebrew linguists see final copy.

Agree on the pass condition before the review, not during it. A pseudo-localized button may wrap if the component specification allows two lines and the tap target remains functional. A navigation tab that truncates the active page name, however, should fail because the user loses their sense of location. Without an agreed pass condition, the review can quickly turn into a debate about personal preference. What actually generates the pseudo strings?

Three approaches, and most teams use more than one, because design-time and build-time reviews catch different things.

• Design-file plugins. Figma community plugins pseudo-localize selected frames in place, flag overflowing text layers, and restore the original copy afterwards. Earliest check, cheapest fix. Check whether the plugin processes content locally, since pre-release product copy often cannot leave the design environment.
• Platform pseudo-locales. Android ships en-XA and ar-XB as built-in test locales, which is the most reliable way to catch defects that only appear once strings pass through the real resource pipeline. This runs against a build, not a design file.
• Build-time transformation. Most i18n libraries can apply a pseudo-transform to resource bundles in a staging build, catching concatenation and runtime composition defects a static review cannot see.

The sequence that produces the least rework is plugin first, build second. The design pass removes the layout defects. The build pass removes the pipeline defects. Running only the second one is the timing problem this article exists to solve.

What can pseudo-localization not catch?

Quite a lot, and being clear about it keeps teams from treating a clean pseudo pass as evidence that a product is ready for a market.

• It does not check translation quality. Terminology, tone, register, legal precision, and market fit are all invisible to it. A screen can pass every check and still say the wrong thing.
• It misses overflow in containers that grow. Hugging auto-layout frames expand with their content rather than clipping it, so automated overflow flags will not fire. These still need a visual pass for layout shift.
• It does not fully validate RTL. Pseudo-bidi exposes obvious direction and mirroring defects. Real Arabic and Hebrew bring shaping, ligature, numeral, and punctuation behaviour that only a rendered build with real text will show you.
• It does not predict per-language length. A pseudo profile approximates worst-case expansion. It does not tell you what the German string will actually be, and real terminology can be shorter or considerably longer.
• It does not test dynamic composition. Strings assembled at runtime, or lengths driven by user data, need build-time testing.

The honest position

Design-time pseudo-localization removes one specific category of preventable rework: Layout breaks that have nothing to do with translation quality and everything to do with a component built for one language. It does not replace localization QA. A team that treats it as a substitute will ship linguistically wrong content in beautifully intact containers.

What do localization and engineering need afterwards?

A structured handoff package, and the same discipline that applies to translatable units applies to design context. OASIS published XLIFF 2.1 as a standard in 2018, later published as ISO 21720:2024.

Localization needs the source string, string ID, product area, screenshot, character constraints, and any note that explains ambiguous meaning. That “Home” example should carry a note reading “main application landing screen”, which prevents a literal translation before it ever reaches linguistic review.

Engineering needs the same evidence framed differently. Each defect should say whether the fix belongs to the design system, the layout code, or the string. If three cards fail because a title container has a fixed height, engineering updates the component. Asking translators to shorten every language instead is how the same defect returns next release.

Use BCP 47 language tags consistently in planning. RFC 5646 defines the structure behind tags such as fr-CA and ar-SA. A design review does not need every locale rendered, but the handoff should show which ones need RTL, non-Latin scripts, or market-specific terminology.

How do you know the review is working?

Track four things: Defects by component, defects by breakpoint, placeholder integrity failures, and RTL blockers.

• By component, so the design system owner can see repeat failures in buttons, cards, tabs, and modals.
• By breakpoint, so product teams learn whether mobile layouts rather than language length are driving the rework.
• Placeholder integrity, so engineering can see whether variables such as {count} or %1$s are being damaged during extraction.
• RTL blockers, tracked separately, because a missing dir=”rtl” or an unmirrored navigation icon can make an entire Arabic or Hebrew workflow unusable rather than merely untidy.

If you sell covered digital services in the EU, timing already matters. Directive (EU) 2019/882, the European Accessibility Act, required Member States to apply its accessibility measures from 28 June 2025. That date has passed, so accessible localized UI is a current concern rather than a future milestone. Requirements vary by Member State and change over time, so verify the position for your markets.

The number that matters least is the total defect count. A high first run usually means the review is finally exposing risk that was already there. The better signal is repeat defects in the same components falling across two or three release cycles, because that shows the design system absorbing the lesson rather than the reviewers working harder.

How does GPI support pseudo-localization and localization QA?

GPI by the numbers

Operating since 2001. Over 200 languages. More than 500 enterprise clients, including Fortune 1000 companies. 164,000 completed projects informing the ARTEE 1000 engine. Four ISO certifications with certificates published for download: ISO 17100:2015, ISO 18587:2017, ISO/IEC 27001:2022 and ISO/IEC 27017:2015, the last with all 37 cloud controls implemented. Fourteen native CMS and DXP connectors plus a Translation Services API, free to configure.

We work upstream of translation as well as inside it. Some of what a pseudo review produces lands on us, and some of it is work we have already done.

The pre-translation stage is where the smallest effort produces the biggest return across a multilingual release. Better source context means fewer downstream queries, and localized UI QA can then concentrate on real language quality instead of layout defects that should never have reached a translator.

Frequently asked questions

1- What is pseudo-localization in design review?

Replacing source UI text with simulated localized strings before translation begins. The strings add accents, brackets, padding, and RTL behaviour so reviewers can catch overflow, missing glyphs, broken variables, and directionality defects in Figma, Storybook, or a prototype.

2- Does it replace professional translation?

No. It protects the interface before linguists start. It cannot judge terminology, tone, legal nuance, or market fit. Its value is structural: It shows whether your product can accept translated text without clipping labels, breaking variables, or damaging RTL layouts.

3- How much expansion should the test use?

At least two profiles: Moderate for body copy, aggressive for compact components. W3C guidance on text size reproduces IBM averages showing source strings up to ten characters expanding to 200 to 300 percent of the original, against 130 percent for strings over seventy characters. That is why buttons and tabs need the harder test and paragraphs do not.

4- Should RTL testing happen before Arabic or Hebrew translation?

Yes. Directionality is layout and code behaviour, not only language. Pseudo-bidi strings expose a missing dir=”rtl”, unmirrored icons, wrong field alignment, and punctuation order before Arabic or Hebrew translators receive anything. Full validation still needs a rendered build with real text.

5- Who should attend the review?

The UX owner, design system owner, front-end engineer, product manager, accessibility reviewer, and localization lead. Each owns a different fix: Component behaviour, resource extraction, release priority, WCAG impact, or translator context.

6- What tools generate pseudo-localized strings?

Figma community plugins for design-file review, Android’s built-in en-XA and ar-XB for build testing, and pseudo transforms in most i18n libraries for staging builds. Use a design tool first and a build tool second. They catch different defect classes.

7- When in the release cycle should it happen?

At design review, before handoff, and again on the first build containing real resource files. The first pass catches layout defects while they are still layout adjustments. The second catches pipeline defects that no design-file review can see.

8- What about defects the review cannot flag?

Handle them with a visual pass on a real-text build. Hugging auto-layout frames, RTL shaping and ligature behaviour, and user-data-driven string lengths all need a human looking at a rendered interface. Budget for that pass rather than assuming a clean automated report means the UI is ready.

Where to start

Make pseudo-localization a required design gate for any product moving from one source language into a multilingual release, particularly where WCAG 2.2 Reflow, RTL support, and XLIFF-based handoff are part of the delivery path.

If you do one thing this week, run one expanded pseudo profile across your component library rather than your screens. Components are where the same defect multiplies, and fixing one button variant is usually worth more than fixing twenty screens.