Your Design System Passed Every Audit. It Still Breaks in German.

Your design system passed the accessibility audit. It passed the dark-mode QA cycle, the contrast-ratio check, the token-consistency review. Ship it. Six weeks later, the German build has a button whose label wraps to three lines and collides with the icon next to it, the Arabic build has a chevron pointing the wrong direction because nobody mirrored it, and the Russian build is displaying "5 файлов" when the grammar rule for that specific number requires a different word ending entirely. None of this shows up in an English-only design review, because nothing in the review process was built to notice it.

That's not a translation problem. Translation is what happens after the actual failure, which is architectural: the design system was built as if "content" were a fixed, short, English-shaped string, and every layout decision — button width, token spacing, line-height, icon direction — quietly inherited that assumption. Localization isn't the thing that broke your design system. It's the thing that revealed the design system was never actually language-agnostic to begin with.

The Word "Content" Is Doing a Lot of Hiding

Open almost any component library's documentation and you'll find spacing tokens, color tokens, elevation tokens, motion tokens — a meticulously specified system for everything except the one variable guaranteed to change the most across markets: the text itself. Buttons get a fixed max-width and a truncation rule as an afterthought. Cards get a "title" slot sized for a five-word English headline. Nobody asks what happens to that same component when the equivalent phrase in Finnish is nine words long, because in an English-only design process, that question never has an occasion to come up.

Design tokens promised to be the neutral, portable layer that made systems consistent across every surface. In practice, most token systems encode spacing and sizing decisions calibrated against English string lengths, then get treated as universal constants once they ship. A token isn't neutral if it was tuned against one language's typical word count and then exported as a global default. It's a local decision wearing a global label.

Why German Breaks Your Button, Specifically

This isn't a vague "some languages are longer" hand-wave — it's measurable and well-documented. A May 2025 Smashing Magazine piece on integrating localization into design systems puts German and French text expansion at roughly 30% to 35% longer than the equivalent English source string, consistently enough that any component sized tightly around an English label is functionally guaranteed to break once translated. That's not a rare edge case triggered by one unusually long word. It's the median outcome for two of the most commonly localized languages in enterprise software.

Pluralization compounds the problem in a way English-first teams routinely miss entirely, because English has one of the simplest plural systems in the world — singular, plural, done. The Unicode Common Locale Data Repository's plural rules specification documents six distinct plural categories used across the world's languages: zero, one, two, few, many, and other. Russian needs different word endings depending on whether a count ends in 1, in 2 through 4, or in 5 through 0 — three grammatically distinct forms for what an English component treats as a single interpolated {count} variable. A component API with one string slot for "N items" isn't missing a nice-to-have. It's structurally incapable of being grammatically correct in most of the languages your product ships to.

RTL Isn't a Mirror Flip

Right-to-left support gets treated, in a lot of component libraries, as a CSS direction: rtl toggle — flip the layout, flip the icons, ship it. Material Design 3's bidirectionality and RTL foundations documentation makes clear how much that oversimplifies the actual problem: bidirectional text means Arabic or Hebrew content can contain embedded left-to-right runs — a product name, a number, an email address — that need to render correctly within a right-to-left paragraph, not just have the whole layout mirrored wholesale. Icons that imply direction — arrows, chevrons, "back" buttons — need conditional logic based on reading direction, not a blanket transform applied at the CSS layer. A design system that treats RTL as "flip everything" will produce interfaces that are directionally consistent and semantically wrong, which is arguably worse than being obviously broken, because it looks correct enough that nobody flags it in review.

The Tooling Quietly Reinforces the Blind Spot

None of this is purely a design-discipline failure — the tools designers actually use don't make the invisible problem visible. Figma Variables, as of this writing, still has no native support for pluralization rules or RTL-aware mirroring; teams patch the gap with third-party plugins, which means the capability exists only for teams that know to go looking for it. A designer working in an English-only file, with English-only components, using a tool that doesn't surface expansion or plural-form warnings, has no mechanism inside their actual workflow that would ever prompt the question "what does this look like in Russian." The audit passes because the tool never asked.

That's the real structural failure underneath the broken German button: it's not that anyone decided localization didn't matter. It's that the entire chain — tokens, component APIs, the design tool itself — was built without a checkpoint where the question could even get asked, so it doesn't get asked until a translated build ships and a user in Berlin reports a button that doesn't fit its own label.

So Actually — Design for the String You Haven't Written Yet

The fix isn't "hire more translators earlier," though that helps. It's a design-system-level admission that layout, tokens, and content architecture were never actually language-agnostic, and building them as if they were future-proof was always going to break somewhere past the first language. That means reserving real expansion space in component width defaults instead of sizing tight to an English label. It means component APIs that accept CLDR plural categories as a first-class input, not a downstream string-formatting hack. It means testing RTL with actual bidirectional content — a name, a number, a URL — embedded in the flow, not a mirrored screenshot that looks right at a glance.

None of that is exotic engineering. It's available today, in the same tools already in use. The gap isn't capability. It's that "content" got treated as a fixed-width afterthought for long enough that most design systems never had to prove they could survive a sentence they didn't write themselves.

Next time your design system passes an audit, ask what language that audit was conducted in — and whether the system would have passed in the other five your product actually ships to.