Your Design Breaks in German (And Arabic, and Japanese)

The rule of thumb most designers half-remember is that translated text is "about 30% longer." That number is roughly right for long-form paragraphs and badly wrong for the strings that actually break interfaces.

Expansion is inversely proportional to string length. A paragraph of English translated into German might grow 20 to 30%. A single word on a button can grow 100% or more. The shorter the string, the higher the variance — and interfaces are made almost entirely of short strings. Buttons, labels, menu items, table headers, tab names, form field labels, status badges. Every one of these is a place where a short English word becomes a long German or Finnish or Russian one.

German is the usual example because of compounding — the language builds long single words where English uses several short ones. But it's not unique. Russian, Polish, Finnish, and Portuguese all expand significantly. French tends to run 15 to 20% longer than English. Spanish similar. The languages that contract rather than expand — Chinese, Japanese, Korean — create the opposite problem, which we'll get to.

The design implication is that any component sized to fit its English content is a component that will break. This includes fixed-width buttons, navigation bars with items spaced to fill exactly, table columns sized to their headers, tabs designed to fit across a container, and badges or pills sized around a specific word. All of these are extremely common, and all of them are the result of designing around content that will change.

The alternative isn't difficult: design components that grow with their content, test them with the longest plausible string rather than the English one, and give every text-bearing element room to expand without pushing its neighbors off the screen. A designer who habitually pads their labels by 40% and checks that the layout still holds has solved most of this problem before it exists.

Arabic, Hebrew, Persian, and Urdu read right to left, and the naive assumption is that supporting them means flipping the interface horizontally. This is close to correct and wrong in the specific ways that matter.

What genuinely mirrors is the reading order and the spatial logic that follows from it. Navigation runs from the right. Sidebars move to the opposite side. Text alignment flips. Progress moves right to left. Back and forward arrows swap directions, because "back" means "toward where you came from," and in an RTL layout that's the other way. Icons that imply directional flow — arrows, chevrons, indentation, breadcrumbs — flip with the layout.

What does not mirror is anything with a meaning independent of reading direction. Clocks still run clockwise. Media playback controls conventionally stay as they are, because play/pause/rewind refer to the direction of a physical tape, not of text. Numbers are written left to right even inside RTL text, which means a phone number or a price inside an Arabic sentence runs the opposite direction from the words around it. Logos generally don't flip. Photographs of real objects don't flip. A checkmark doesn't flip.

The distinction matters because a blanket CSS transform that mirrors everything produces an interface full of small wrongness — backwards clocks, reversed logos, flipped photographs — that reads as carelessness to a native speaker.

The technical implementation is where the design system earns its keep. Modern CSS provides logical properties — margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of left — that describe position relative to reading direction rather than to the screen. A design system built on logical properties supports RTL by setting a direction attribute. A design system built on physical properties requires every spacing value in the product to be revisited. This is a decision made once, early, by whoever writes the first components, and it determines whether RTL support later is a day of work or a quarter of it.

Chinese, Japanese, and Korean create the inverse of the expansion problem and several problems that have no equivalent in European languages.

Text contracts. The same meaning takes fewer characters. A button that reads "Download" in English might be two characters in Chinese. This produces layouts that look sparse and unbalanced — components sized generously for expansion now contain almost nothing, and a design tuned for European text lengths can feel empty.

Line breaking works differently. Chinese and Japanese don't use spaces between words, so line breaks can occur almost anywhere. This is convenient for layout but it means text wraps in places that break meaning if not handled properly, and rules exist about which characters may not start or end a line. A layout that assumes word-boundary wrapping is making an assumption those languages don't share.

Characters need more vertical space. CJK glyphs are denser and more complex than Latin ones. At the font sizes that work comfortably for English body text, Chinese and Japanese characters become hard to distinguish — the strokes merge. CJK text generally requires a larger minimum size and more generous line height than Latin text at the same nominal size. A type scale designed entirely around Latin text will produce CJK text that's technically rendered and practically unreadable.

Font fallback becomes visible. Your brand typeface almost certainly doesn't include CJK glyphs — comprehensive CJK fonts contain tens of thousands of characters and are built separately. When your product renders Japanese, the browser falls back to a system font, and the visual identity you carefully specified is replaced by whatever the operating system provides. Designing for this means choosing the fallback deliberately rather than accepting the default, and accepting that the brand's typographic identity will be expressed differently in these languages than in Latin ones.

One of the most common and most damaging localization failures happens in code rather than in layout: sentences assembled by concatenating fragments.

A developer writes something like "You have " + count + " new " + itemType + "." This works perfectly in English and is nearly impossible to translate correctly, because it hardcodes English word order, English pluralization, and English grammatical agreement into the structure of the string itself.

Word order varies enormously across languages. A sentence whose pieces are assembled in English order cannot be reassembled into German or Japanese order, because the translator receives fragments rather than a sentence and has no way to rearrange them.

Pluralization varies more than most English speakers realize. English has two forms: one and many. Russian has three. Polish has three with different rules. Arabic has six — zero, one, two, few, many, other. A system that handles plurals by checking if (count === 1) cannot represent these languages correctly, which means the text will be grammatically wrong in a way native speakers notice immediately.

Grammatical gender affects surrounding words in many languages, so a template that inserts a noun into a sentence may require the article and adjective around it to change form. This is invisible in English and unavoidable in French, German, Spanish, and dozens of others.

The solution is well-established and rarely adopted early: use a message format standard such as ICU that supports plural rules, gender selection, and named placeholders, and give translators whole sentences with variables rather than fragments to assemble. This is a decision about how strings are stored and rendered, made by the engineering team, usually before anyone is thinking about localization at all — which is exactly why it's worth raising during design rather than after.

Beyond text, a set of formatting assumptions are embedded in most interfaces without anyone deciding on them.

Dates are the obvious one: 03/04/2026 means March 4th in the United States and April 3rd in most of the rest of the world, and there's no way for the reader to tell which you meant. Numbers are less obvious and equally treacherous — the decimal separator is a period in some countries and a comma in others, and thousands separators vary between commas, periods, spaces, and apostrophes. A price rendered as 1.500 means one and a half in one country and fifteen hundred in another.

Name fields carry assumptions that are frequently wrong. A form with "First name" and "Last name" fields assumes a naming structure that doesn't apply universally — many cultures order family name first, some people have a single name, some have multiple family names. A form that requires both fields and validates their format will reject legitimate names.

Address formats vary in field order, in which fields exist at all, and in what's required. Postal code formats differ. Phone number formats and lengths differ. A form built around one country's conventions and validated against them will block users from others.

None of these require deep expertise to handle — established libraries format dates, numbers, and currencies according to locale, and address forms can be built to adapt. But they do require the awareness that these are locale-dependent rather than universal, which is the part that's easy to miss when everyone building the product shares the same conventions.

There's a technique that surfaces most of these problems before a single real translation exists, and it takes an afternoon to set up.

Pseudo-localization replaces every string in the product with a modified version of itself — typically lengthened by 40%, wrapped in brackets, and with accented characters substituted for plain ones. "Settings" becomes something like "[Šéţţîñĝš————]". The result is still readable to an English speaker, which means anyone on the team can use the product and immediately see what breaks.

Running the product in pseudo-locale reveals truncated buttons, overflowing containers, broken layouts, and text that was hardcoded rather than externalized — a hardcoded string stays in plain English while everything around it is bracketed and accented, which makes it instantly visible. The accented characters also expose font fallback issues and any place where character encoding is mishandled.

This test costs almost nothing and finds the majority of layout-level localization problems before any translation budget is spent. Teams that run it as part of their normal QA catch these issues continuously rather than discovering them all at once when a market launch is three weeks away.

The reason to treat all of this as a design system concern rather than a translation project is timing. Every fix described here is trivial when it's a convention and expensive when it's a retrofit.

Designing components that grow with content costs nothing at the moment the component is designed and requires rebuilding every component if adopted later. Using logical CSS properties costs nothing when the first stylesheet is written and requires auditing every spacing value if adopted later. Externalizing strings and using a proper message format costs a small amount of setup and requires touching every string in the product if adopted later. Choosing a type scale with headroom for CJK minimum sizes costs one conversation and requires re-deriving the entire typographic system if adopted later.

A product that was built with these conventions can enter a new language market in weeks. A product that wasn't can spend a quarter preparing for a launch that the business already committed to, with a team discovering the extent of the problem while the deadline approaches.

None of this requires deciding to be a global product on day one. It requires not accidentally deciding to be a single-language product on day one — which is what happens by default, quietly, in a hundred small implementation choices that nobody recognized as choices.