Answer in brief
Multilingual UI breaks when components assume English-sized text. A token strategy can make expansion, script height, RTL flow and visual regression part of the system rather than late exceptions.
The token problem is not translation; it is hidden geometry
A multilingual interface usually fails before a translator touches it. The failure is already encoded in a fixed button width, a two-line card title with no overflow policy, a navigation item whose padding was tuned around six English letters, or an icon positioned with a hard-coded left offset. Translation simply reveals those assumptions. A useful token system therefore describes not only colors and spacing values, but the geometry a component is allowed to negotiate when content changes.
W3C internationalization guidance makes the underlying risk concrete: translated text does not preserve source length, and very short strings can expand far more than long paragraphs. German and Finnish can also produce long compound words that offer fewer natural wrap points, while scripts such as Thai, Arabic, Devanagari, Chinese and Japanese may demand different vertical space. The system has to tolerate width, height and line-breaking changes simultaneously rather than treating “longer text” as the only localization problem.
That changes the design question from “What is the button width?” to “What are this button’s minimum size, inline padding, maximum growth behavior and wrapping rules?” Tokens are strongest when they capture those durable decisions. A fixed pixel value can still exist, but it should sit inside a semantic contract explaining what may expand, what must remain stable and what happens when the content exceeds the preferred shape.
Tokenize relationships, not screenshots
A screenshot is one successful arrangement of content. A design token should describe the relationship that made the arrangement successful. For multilingual products, that means distinguishing fixed requirements from elastic ones. Touch target minimums may be fixed. Inline padding may be stable within a component family. Text columns may have preferred maximum measures. But the distance allocated to a label should rarely be encoded as a rigid width simply because it looked balanced in the source locale.
A practical token layer can include semantic values such as control-inline-padding, control-block-padding, label-gap, compact-line-height, reading-line-height, content-max-inline-size and minimum-control-block-size. The exact naming is less important than the logic. Components then consume those semantics instead of inventing local numbers. When typography changes by locale, a token alias can adjust line height or font fallback without forcing designers to retune every card and dialog individually.
The same principle applies to density. “Compact” should not mean “never grows.” A compact component can preserve smaller padding while still allowing a second line or additional block height. This is especially important in enterprise interfaces where translated labels, user-generated names and localized dates coexist. The goal is a controlled range of valid states, not a promise that every locale will reproduce the English screenshot pixel for pixel.
Build text expansion into component contracts
Every text-bearing component needs an explicit answer to three questions: may the text wrap, may the container grow, and what happens when both are exhausted? Buttons often work best with horizontal growth first and limited wrapping only when product context permits it. Tabs may need scrolling or an alternative overflow pattern. Cards can usually grow vertically. Table columns may need priority rules rather than uniform compression. These decisions should be documented once in the component specification and exercised in every locale.
W3C’s reflow criterion is a useful discipline even when the immediate task is localization rather than accessibility. It asks whether information and functionality remain available when content must reflow in constrained space. A multilingual system benefits from the same mentality: when width disappears, content should reorganize instead of silently vanishing. Fixed-height containers are particularly risky because a translation can create a second or third line that gets clipped without producing an obvious horizontal overflow signal.
Pseudo-localization should therefore be part of design review, not only engineering QA. Replace source strings with exaggerated versions containing roughly expanded text, accented characters and deliberately long tokens. The aim is not to simulate a real language perfectly; it is to expose brittle layout assumptions. If a component breaks under synthetic stress, production localization will eventually find the same weakness in a less predictable and more expensive place.
Fluid type must account for script height as well as width
Responsive typography is often designed around viewport width, yet multilingual typography adds a second axis: the metrics of the script and chosen fallback font. Two fonts set to the same nominal size can have different x-heights, ascenders, descenders and apparent density. Some writing systems need more line space to remain readable and to avoid collisions between marks. A single compressed line-height token chosen for Latin capitals can become visibly broken when another script enters the same component.
The safer model separates type role from the exact font metrics used to render that role. A “label-small” semantic token can map to a locale-aware font family, size, weight and line height. Where a script needs additional block space, the locale layer can adjust the mapping without changing component structure. That is more maintainable than embedding special-case CSS in every product surface and makes the exception visible to both design and engineering teams.
Fluid sizing should also have floors and ceilings. If type scales continuously with viewport width but a translated label already consumes more lines, shrinking the type to force the source composition back into shape can damage legibility. Treat wrapping and reflow as legitimate outcomes. The typographic system should preserve reading quality first; the component should absorb the geometric consequence. That is the opposite of squeezing language until it fits a predetermined box.
Directionality belongs in tokens and APIs, not in last-minute CSS
Right-to-left support is not achieved by flipping the whole screen like an image. Arabic and Hebrew interfaces combine RTL text with numbers, Latin product names, email addresses and other LTR fragments. Unicode’s Bidirectional Algorithm exists because these mixed runs need rules for visual ordering. Product code still has to provide correct base direction and isolation around embedded content so punctuation, numbers and adjacent strings do not reorder in surprising ways.
At the design-system level, replace physical concepts such as margin-left and border-right with logical concepts such as inline-start, inline-end, block-start and block-end wherever the meaning follows reading direction. Component APIs should expose “leading” and “trailing” slots rather than “left icon” and “right icon.” That gives the layout permission to mirror appropriately while keeping the component’s semantic structure intact.
Icons require a separate decision. A chevron indicating “next” in a directional sequence may need to reverse; a camera, microphone, warning symbol or brand mark usually should not. Even punctuation has direction-sensitive behavior: W3C notes that mirrored characters such as parentheses are handled according to directional context. The reliable rule is to mirror semantics, not pixels. Every directional asset should be classified, tested and documented rather than handed to a global transform.
Truncation is a content policy, not a spacing fix
Ellipses can make a broken layout look tidy while hiding the fact that information has been removed. That trade-off is acceptable in some places, such as a secondary filename inside a constrained list, but dangerous in others. A primary call to action, an error reason, an account name that distinguishes one record from another, or a legal status may be the exact content the user needs. The decision to truncate should therefore be made by information priority, not by visual inconvenience.
Tokens can help by separating truncation behavior from typography. A component might expose one-line, two-line and unrestricted content modes, each with defined overflow handling. Product teams can then choose deliberately. The full string should remain accessible where practical, and the interaction for revealing it must work with keyboard, touch and assistive technology. A tooltip that appears only on mouse hover is not a complete recovery mechanism.
Localization also changes what is safe to abbreviate. W3C cautions that abbreviations do not transfer cleanly between languages; some languages may not have a natural short equivalent. If an interface depends on “Acct.” or “Qty.” to fit, the design is already transferring a layout problem to translators. Prefer labels that can occupy variable space, or redesign the information architecture so the component does not depend on English-specific compression.
Screenshot testing should represent linguistic risk, not every locale
A global product does not need thousands of full-page snapshots to gain value from visual regression. It needs a small, intentional matrix that stresses the dominant failure modes. Include a long-string LTR locale, an RTL locale, a locale using a taller or visually dense script, and a pseudo-localized build that exaggerates expansion. Add the product’s highest-risk components: navigation, forms, tables, modals, toasts, filters and any surface with fixed-height content.
The screenshots should run at the same responsive breakpoints used for the source locale, because localization and responsive behavior interact. A label that fits on desktop may force a wrap at tablet width; that wrap can increase card height; the new height can push an action below the fold or collide with an absolutely positioned badge. Regression tests are most useful when they catch that chain rather than merely proving that glyphs appeared.
Automated comparison still needs human review. A pixel diff can tell you that a layout changed, not whether the new line break is semantically good, whether an icon mirrored correctly or whether mixed-direction text reads naturally. Pair automated screenshots with periodic native-speaker or localization review for critical flows. The test suite protects structural invariants; language review protects meaning. Neither is a substitute for the other.
A practical adoption sequence for an existing design system
Start with evidence rather than a token rewrite. Inventory current production bugs and identify recurring failure types: clipped labels, fixed-height controls, misordered RTL content, over-truncated navigation, icon mistakes and typography collisions. Map each bug to the design decision that enabled it. This produces a shortlist of system-level constraints worth tokenizing and avoids creating a large theoretical taxonomy that components never consume.
Next, convert physical spacing to logical spacing in shared primitives, define growth and wrapping contracts for the most reused text components, and introduce locale-aware typography aliases. Add pseudo-localization fixtures directly to the component playground so designers can trigger them without engineering support. Then add representative visual regression cases. The most valuable first targets are primitives used everywhere: buttons, inputs, list rows, cards, dialogs and navigation items.
Finally, treat multilingual resilience as a release criterion. A component is not “done” because it matches one Figma frame; it is done when its valid content states, direction states and overflow behavior are specified and tested. That does not eliminate localization work. It changes its economics. Translators and locale specialists can focus on language and cultural correctness instead of repeatedly discovering that the product’s geometry was never designed to contain real language in the first place.
Practical checklist
- Replace left/right spacing tokens with logical start/end tokens where direction can change.
- Stress-test buttons, tabs, cards and tables with expanded and tall-script sample strings.
- Define wrapping, growth and truncation rules for every text-bearing component.
- Audit icons for semantic direction before mirroring them in RTL layouts.
- Capture representative screenshots for LTR, RTL and long-string locales.
Questions and answers
Should a design system create separate tokens for every language?
Usually no. The more scalable pattern is to create semantic tokens for behaviors that languages can stress: inline spacing, block spacing, line height, minimum control size, content width, wrapping and direction. Locale-specific overrides are useful when a script or product requirement genuinely needs them, but duplicating an entire token set per language creates drift. Start with shared semantic rules, then add narrowly scoped locale aliases only when testing demonstrates a repeatable need.
How much extra width should designers reserve for translated interface text?
There is no single safe percentage. W3C guidance notes that short English strings can expand dramatically in translation, while longer passages usually expand proportionally less. The practical answer is not to reserve one fixed buffer but to let components grow, wrap or reflow according to explicit rules. Pseudo-localization with deliberately lengthened strings is more reliable than guessing a universal multiplier, especially for buttons, tabs, filters and compact navigation.
Should every icon be mirrored in a right-to-left interface?
No. Icons that express physical direction or sequence may need mirroring, while icons that represent stable objects, brands, media controls or culturally established symbols may not. The decision should be semantic, not mechanical. Text direction also affects punctuation and mixed-script content through the Unicode Bidirectional Algorithm. A robust system therefore treats icon direction, text direction and layout order as related but separate concerns that are reviewed in context.
Is truncation an acceptable solution for localization overflow?
It can be, but only when the hidden content is nonessential or can be recovered through another interaction such as expansion, a tooltip or a detail view. Truncating a primary action, price, error message or legal label can destroy meaning. Prefer wrapping, flexible width or reflow first. If truncation is retained, define it as a component-level content policy and verify that screen readers and keyboard users can still access the full information.