Localization QA · Guide

Pseudo-localization in Figma: a complete guide

Your design looks perfect in English. Then the German strings come back from translators, and half the buttons overflow. Pseudo-localization catches that months earlier — with fake translations you can generate today, right in Figma.

Updated July 2026 · 7 min read

What is pseudo-localization?

Pseudo-localization (also “pseudo-loc” or a “pseudo-locale”) is a QA technique that transforms your source strings into fake “translations” that look foreign and behave like the worst-case real language — without waiting for translators. A typical transformation:

Every element of that ugly string is doing a job:

The technique is decades old on the engineering side — Microsoft ships pseudo-locales (qps-ploc) inside Windows, and Netflix has written publicly about pseudo-localizing its UIs to catch expansion bugs before translation. For expansion numbers per language, see our text-expansion cheat sheet.

Why run it at design time, not just in code?

In most teams pseudo-localization lives in the build pipeline — a compile flag QA engineers flip. That’s valuable, but it has a structural flaw: by the time pseudo-loc runs in a build, the design is already “done”. Every layout break it finds becomes a bug ticket, a design revision, a rebuild and a re-review. The feedback loop is weeks long.

• • In production: a broken German button costs a bug report, a translator round-trip, a hotfix.
• • In a staging build: it costs a ticket, a design change, a rebuild.
• • In Figma: it costs a drag of a resize handle. That’s the whole fix.

Designers are the only people who can fix layout flexibility before it hardens into code — but they’re the one group that classic pseudo-loc tooling never reaches. Bringing the simulation into Figma closes that gap.

Option 1 — pseudo-localize by hand

No tooling required, works today:

1. Duplicate the frame you want to test (keep the original untouched).
2. For every text layer, expand the string by the worst ratio you ship — a safe default is +35–50% for labels under 20 characters (pad with “·” or repeat the last word).
3. Wrap each string in [ brackets ] so truncation is visible.
4. Swap a few letters for accented versions (à, é, ñ) to stress fonts and line height.
5. Scan the frame for overflow, clipped brackets, and squashed diacritics; fix containers, then delete the duplicate.

Honest assessment: this works for one screen and falls apart at ten. Manual padding is guesswork, you’ll miss layers, and nobody re-runs it after every copy change. Which is why it’s worth automating.

Option 2 — one-click pseudo-localization with LocaleProof

LocaleProof is a free Figma plugin that automates the whole loop — and, unlike manual pseudo-loc, it also measures the result instead of leaving you to spot damage by eye:

1. Select the frames you want to test and run the plugin.
2. Pick languages (de, fi, fr, ar, ja…) — it applies each language’s real-world expansion ratio, plus an adjustable length buffer, accented characters and bracket markers.
3. Run check. Every text node is compared against its container; overflowing layers are flagged with the exact pixel overflow (e.g. “+17px”) in a clickable report — click a row, jump to the layer.
4. Fix and restore. Adjust the flagged containers, then hit Restore — your original copy comes back in one click (originals are cached before any mutation).

It’s 100% client-side (networkAccess: none in the manifest) — nothing leaves your Figma file. One honest v1 limit: it flags fixed-size and fill containers (buttons, cards, table cells); auto-layout frames that hug their text grow instead of overflowing, so give those a quick visual pass for layout shift.

What to look for after pseudo-localizing

1. Horizontal overflow in fixed-width buttons, tabs, chips and table cells — the classic break (see how to find text overflow in Figma for detection methods).
2. Missing brackets — a “[” without its “]” means the string is truncated somewhere.
3. Clipped diacritics — accents cut off by tight line-height or fixed-height rows.
4. Layout shift in hugging frames — the frame didn’t overflow, but it grew and pushed siblings around. Is the new layout still acceptable?
5. Untransformed text — plain-English strings inside a pseudo-localized screen are copy baked into images or components that translators will never receive.
6. Wrapping decisions — for each flagged element, decide explicitly: wrap, truncate with tooltip, or widen. “It fits in English” is not a policy.

Where it fits in your workflow

The teams that get the most out of pseudo-loc treat it like spellcheck, not like an audit:

• • Before dev handoff — make it a design-review checklist item for any product shipping in 2+ languages (here’s our full i18n design QA checklist).
• • After major copy changes — new microcopy resets your worst case.
• • When defining components — pseudo-localize the component sheet once, and every instance inherits sane sizing.

FAQ