How much longer your UI text gets in translation.
Everyone has heard the rule of thumb that German runs about 30% longer than English. It’s true for paragraphs, and badly wrong for the strings that actually break layouts: buttons, tab labels, badges and headlines. Short text grows the most, and it lives in the tightest boxes.
The shorter the string, the bigger the growth
The most-cited numbers come from IBM’s globalisation guidelines, republished by the W3C in its article Text size in translation. They give the average expansion from English into European languages, by the length of the English source:
| English source | Translated length |
|---|---|
| Up to 10 characters | 200–300% |
| 11–20 characters | 180–200% |
| 21–30 characters | 160–180% |
| 31–50 characters | 140–160% |
| Over 70 characters | 130% |
(The published 51–70 row reads 151–170%, which breaks the trend and is probably a typo, so it’s left out here.)
Read the top row again. A label under ten characters can come back two to three times as long. That’s not a quirk of one language. A long sentence gives a translator room to rephrase and compress, while a single word has exactly one translation and it’s whatever length it is. “Save” becomes “Speichern” in German: four letters to nine. “Settings” becomes “Einstellungen”: eight to thirteen.
The W3C article has a cleaner example from Flickr’s “392 views” counter. Measured against the English word “views”, the Portuguese and French versions came out 2.6 times as long, German 2.8 times and Italian (“visualizzazioni”) 3 times. That’s a label that sits next to a number in a row of metadata, exactly the kind of thing designers size to fit the English.
Where it actually breaks
Expansion only hurts where the box doesn’t grow with the text. In a typical app that means a short list of places:
- Tab bars and segmented controls. Fixed widths divided equally, with the longest label setting the limit for all of them.
- Buttons with a fixed width, especially two side by side, where one long label shoves the other.
- Badges, chips and pills drawn to hug a word like “New” or “Pro”.
- Single-line headers that truncate with an ellipsis, which in a nav bar can leave nothing but the first few letters.
- Text set into images, from onboarding art to store screenshots, where nothing reflows at all.
Compound words make it worse. German, Dutch and Finnish build long nouns by joining shorter ones, and a long word with no spaces can’t wrap. The W3C example is “Input processing features”, which can become “Eingabeverarbeitungsfunktionen”: thirty letters with no place to break. If your layout’s plan for long text was “let it wrap to two lines”, a word like that defeats it. It either overflows the container or gets broken mid-word wherever the renderer gives up.
Fewer characters isn’t the same as narrower
Chinese, Japanese and Korean translations often have fewer characters than the English, which makes them look safe. They aren’t, necessarily. Each character is roughly square and much wider than a Latin letter, so the W3C counts a CJK character as two English characters of width. Its example is “desktop” becoming “デスクトップ” in Japanese: one character fewer, and noticeably wider on screen.
The other direction is height, and that’s the one most layouts never consider. Thai, Devanagari (Hindi), Arabic, Tibetan and the CJK scripts generally need taller glyphs or more space between lines than Latin text at the same point size. In the W3C’s comparison, two lines of Thai take around 150% of the vertical space of two lines of Latin text. A fixed-height card that fits two lines of English can clip the tops of Thai vowel marks or the tails of Hindi letters even when the translation is no wider.
Shrinking doesn’t solve everything either. A translation that comes back much shorter can leave a big empty gap in a layout designed around the English, which looks broken in its own way.
Testing for it without a translator
You don’t need real translations to find these problems. Both platforms ship fake languages built for exactly this.
On iOS, Xcode has a set of pseudolanguages under Product > Scheme > Edit Scheme > Run > Options > App Language. According to Apple’s documentation, the Double-Length Pseudolanguage doubles every localizable string, the Accented Pseudolanguage adds accents to test tall ascenders and descenders, the Tall Pseudolanguage simulates scripts that need much more vertical space, the Bounded String Pseudolanguage wraps strings so truncation is obvious, and there are right-to-left options too. Run the app in each and click through every screen.
On Android, add pseudoLocalesEnabled true to your debug build type (the
Kotlin DSL spelling is isPseudoLocalesEnabled = true), then pick a pseudolocale in
the device’s language settings. The
Android docs
describe en-XA as adding accents, padding each string with extra text and bracketing it so
you can see where it was cut off. ar-XB flips the layout right to left.
One catch: both tools work on the platform’s own string files. If your strings come from somewhere else, as they do in Flutter, React Native or a server-driven UI, the pseudolanguage won’t touch them. In that case, write the same thing yourself: a debug flag that returns every string wrapped in brackets and padded to double length, plus a long compound word for the shortest labels. It’s an afternoon of work, and it finds most of the bugs a real translation would.
Designing so you rarely need the test
- Size by content, not by the English. Let buttons and chips grow with their label, and give tab bars a plan for long labels (smaller type, two lines, or icons only) before a translation forces one.
- Budget for the short strings. If a label is under ten characters in English, assume it can triple. Longer copy can work with the 130–160% figures.
- Leave vertical room. Use line heights and container heights that grow with the text instead of fixed pixel boxes.
- Allow breaks inside long words. Turn on hyphenation where the platform supports it, so a thirty-letter German noun wraps instead of overflowing.
- Never truncate the only label. An ellipsis on a description is fine. An ellipsis on the button that says what the button does is a bug.
The same problem on your store page
Screenshot headlines are short strings set into images, so they hit both problems at once: high expansion and nothing that reflows. A four-word English headline that fills two lines can need three in German. ShotCanvas translates headlines and renders a full screenshot set per language, with templates that measure each translated headline and resize it to fit rather than clipping it.