L LocaleProof Pro Join the waitlist

Localization QA · Cheat sheet

Text expansion by language: the cheat sheet

A button that fits perfectly in English will overflow in German, wrap awkwardly in French, and sit half-empty in Japanese. Here are the numbers to design with — before translation breaks your layout in production.

Updated July 2026 · 6 min read

TL;DR

Average expansion vs. English, by language

Typical length change when translating English UI text. Treat these as planning ranges, not guarantees — real strings vary a lot (see the string-length table below).

Language Typical length vs. English What usually breaks
German+20–35%Long compound words that can’t wrap (Benutzereinstellungen)
Dutch+20–35%Compounds, like German
Portuguese+20–30%Buttons and tab labels
Polish+20–30%Long words + grammatical cases multiply variants
Spanish+15–25%Sentence-style microcopy
French+15–20%Articles and prepositions inflate short labels
Italian+10–25%Similar to Spanish
Russian / Ukrainian+15–25%Cyrillic glyphs also render wider in many fonts
Finnish±0–30%Total length varies, but single agglutinated words get very long
Arabic+20–25%RTL mirroring + taller script; test alignment, not just width
Hebrew±0–15%RTL mirroring is the bigger risk
Japanese−10–50%Shorter, but glyphs need more line height; no word breaks
Chinese (Simpl.)−20–50%Half-empty buttons; increase line height ~1.5×
Korean−10–15%Taller glyph boxes; check vertical clipping

The shorter the string, the worse it gets

Averages hide the real danger: short strings expand the most. IBM’s classic globalization guidelines — still the industry planning baseline — put it like this:

English source length Extra space to reserve
Up to 10 characters (“Save”, “Continue”)+100–200%
11–20 characters+80–100%
21–30 characters+60–80%
31–50 characters+40–60%
51–70 characters+30–40%
Over 70 characters (paragraphs)+30%

The W3C’s “Text size in translation” article shows the same pattern with real-world data: the English word “views” grew to “visualizzazioni” in Italian — a 140% expansion on a single label.

7 layout rules that survive localization

  1. Let containers grow. Auto-layout with hugging beats fixed widths for buttons and chips. If a width must be fixed, size it for German, not English.
  2. Reserve 35–50% for short labels. Navigation, tabs, buttons — the shorter the copy, the bigger the buffer.
  3. Never rely on single-line fit. Decide upfront: does this element wrap, truncate, or scale? “It just fits” is not a policy.
  4. Watch the unbreakable words. German and Finnish produce single words longer than your whole button. Test word length, not just string length.
  5. Give CJK vertical room. Chinese and Japanese are shorter but taller — bump line height and check fixed-height rows for clipping.
  6. Mirror-test for RTL. Arabic and Hebrew flip the layout direction; icon + label pairs and progress patterns break first.
  7. Pseudo-localize before handoff. Don’t wait for real translations — simulate worst-case text while the design is still cheap to change.

Check your Figma file against these numbers — in one click

LocaleProof is a free Figma plugin that simulates worst-case translations (pseudo-localization + the expansion ratios above) and highlights exactly which text layers overflow — with a clickable report and one-click restore. 100% client-side.

FAQ

How much longer is German text than English?

On average 20–35% longer, but short UI labels can double. The bigger risk is single compound words that can’t wrap inside a fixed-width button.

What is pseudo-localization?

A QA technique that replaces your source text with accented, padded strings (e.g. “Continue” → “[Çóñţîñúé·····]”) so untranslated and clipped text becomes obvious — before real translations exist. Standard practice at Microsoft, Netflix, and most i18n-mature teams. Full walkthrough: Pseudo-localization in Figma: a complete guide.

Should I design in the longest language?

Design in your source language, but test in the longest one you ship. Flexible containers plus a worst-case preview catch 90% of layout breaks without redesigning everything. For the full pre-handoff routine, see our i18n design QA checklist.