Integrating Localization Into Design Systems — Smashing Magazine

Designing for Every Language: A Case Study in Localization-Ready Systems

Product designers Rebecca and Mark at SAS, the analytics and AI company, build and maintain the token packages and component libraries for the SAS Filament Design System. Because SAS serves a global customer base, designers use Figma libraries to create high-fidelity UX specifications. A persistent challenge: these files are typically crafted in English, inadvertently overlooking multilingual principles. This leads to layout breakage, text overflow, and errors with right-to-left (RTL) languages, which ultimately cascade into usability problems within the final applications. The push to solve this led to a deeper investigation into how to embed localization into a design system from the ground up.

Research revealed that the body of knowledge on combining localization with design tokens and Figma Variables is thin. Most challenges—managing regional typography, dynamically adapting layouts—were only partially addressed or entirely absent in existing literature. What follows is a narrative of practical problem-solving. It’s not presented as the definitive solution, but rather as a contribution to a much-needed conversation on handling language-switching complexities within a design system.

Defining the Terms: Internationalization vs. Localization

Understanding these two distinct disciplines is foundational. Internationalization (I18n) is the preparatory engineering phase. It ensures the design is structurally flexible enough to be adapted to different regions. In Figma, this translates to using placeholder text for dynamic content, setting constraints so frames can expand or contract with text changes, and supporting bi-directional text layouts.

Localization (L10n) is the active adaptation phase. It involves changing text, adjusting layout for language-specific quirks like longer strings or RTL languages (e.g., Arabic), and validating cultural relevance. Ultimately, these practices are integral to delivering inclusive and accessible global user experiences.

Framing the Challenge: Existing Token Architecture

The Filament Design System’s tokens are stored in JSON files within a proprietary app called “Token Depot” on a corporate GitHub. The Tokens Studio plugin (pro plan) converts these files into Figma libraries. For clarity: all design tokens are treated as variables, but Figma styles also exist as “recipe cards” for specific HTML elements. For example, an H2 style is a named collection of font-family, font-size, and font-weight token values.

A major refactoring effort in 2022 created semantic token names to enable theme switching. Tokens were grouped into categories: Color, Typography, Space, Size, Style, Motion, and Shadow.

Initially, locale handling was an afterthought, appended to the theme logic:

• A core folder stored language-agnostic values.
• Brand folders held theme-specific JSON files, treated by default as “English.”
• A separate languages folder contained override files per locale.

These locale overrides were minimal, focusing mostly on typography because fonts behave differently across languages. For example, Chinese, Japanese, and Korean (CJK) fonts often lack true bold variants. To prevent synthetic faux-bolding, token values for font-weight were overridden from 700 down to 400. Additional overrides included font-family, letter-spacing, font-style, and font-variant. By 2023, Figma only supported mode switching for themes—language options weren’t yet a design consideration.

Evolving the Framework: The Impact of Density

The scope shifted with the introduction of dynamic density switching. Solving this required a period of meticulous taxonomy work—defining precisely which of the ~300 design tokens would be influenced by density versus those that wouldn’t. This analysis produced three distinct categories:

Unaffected by Theme or Density:

• All color groups (brand, base)
• Motion and shadow
• Border and outline sizes
• Font style, weight, overflow, and case tokens

Impacted by Density:

• Typography specifics (font and icon sizes, line-height)
• Text and paragraph spacing
• Border radius
• Base spacing values

Impacted by Theme:

• Color type tokens (action, body, status, text, etc.)
• Font-family definitions
• Focus and action focus styles

This expansion added font sizes, line heights, spacing, and border-radius to locale-specific value changes. Detailed calculations were documented for how the type scale adjusted across locales and densities.

The token architecture was subsequently restructured with a clear separation:

1. Core tokens were updated at the source.
2. New folders were introduced within each brand: a density folder and a language folder.

Rationalizing the number of JSON files became a priority. Too many files create bugs and slow down performance. Instead of building files for each language-density combo, the languages were grouped into four typographically similar categories:

• Western European and Slavic: English, French, German, Spanish, Polish.
• Chinese Languages: Simplified and Traditional scripts.
• Middle Eastern and East Asian: Arabic, Hebrew, Japanese, Korean, Thai, Vietnamese.
• Global Diverse: African, South Asian, Pacific, Indigenous, Uralic, and Turkic groups.

These became the basis for the new JSON files. Each generated file represents one density level (e.g., comfortable and compact) and contains the necessary tokens—font sizes, icons, line-height—for a category that shares layout characteristics.

Building on this foundation, values for line-height, icon and font sizes, spacing, and border-radius were universalized by language category. Only a folder of per-locale overrides (for items like font-family that vary even within a category, like CJK languages) was positioned above the core and theme folders.

The seed of this entire project was a simple idea: with Figma Variables and advanced design tokens, a UI design could, in theory, flip dynamically between themes, densities, and even languages—just like a well-structured app. This case study shows that barrier remains partially eased and fully avoidable by front-loading i18n strategy into the foundational design architecture.

Figma Variables: Where Token Migration Hits Reality

Moving tokens from JSON into Figma via Tokens Studio promised a clean bridge between design and code. In practice, the plugin’s 2.0 release changed the workflow substantially, and adapting revealed several gaps between what design tokens support and what Figma variables can actually do.

Import Headaches and Duplicate Collections

The first obstacle was the import process itself. The $metadata.json and $themes.json files did not overwrite correctly, leaving duplicate collections in Figma after variable export. Recreating the theme structure inside the plugin did not help. The workaround was to delete both files from the repository before pulling the updated GitHub repo into the plugin, but even then, redundant collections needed manual removal during export.

Once the tokens were successfully brought in as variable names with the required modes, some values were still missing. Typography variables, in particular, fell short of expectations. Figma’s default “auto” line-height multiplier is 1.2, which falls below the WCAG minimum of 1.5. The token values relied on line-height multipliers — valid in CSS but not accepted as Figma variable values, since Figma does not support percentage-based variables.

The team resolved this by manually calculating pixel line-height values for every typography size, locale category, and density combination. These were entered as local variables in Figma, completely separate from the design token system. The approach worked for density and locale switching but required creating hundreds of local variables by hand. Grouping font sizes and line heights into Figma styles needed additional manual work because of the missing support for multipliers or percentages.

Some concrete examples illustrate the scope:

• For CJK locales, medium and low density use a base font size of 16px, while high density uses 18px.
• Western European and Slavic languages use 14px for medium density, 16px for high, and 12px for low density.

Rendering Mismatches Beyond Line Height

The line-height issue was not the only disconnect between Figma and web rendering. In Figma, line height centers text visually inside the text box. In CSS, line height affects spacing differently depending on the box model. The mismatch forces manual adjustments, especially with upcoming CSS properties like leading-trim that will change how leading is handled.

Letter spacing presents another difference. CSS defaults to normal for letter-spacing, but Figma requires numeric values. Locale-specific resets to normal could not use variables, complicating implementation.

Font-family stacks also posed challenges, particularly for mixed-script content. A typical Chinese stack, for example, starts with AnovaUI (the brand font) to keep Latin characters and symbols consistent, then falls back through 微软雅黑体, Microsoft YaHei New, 微软雅黑, Microsoft Yahei, 宋体, SimSun, Helvetica Neue, Helvetica, Arial, and finally sans-serif. But Figma designs that only use AnovaUI cannot preview locale-based substitutions via system fonts, making it difficult to evaluate mixed-content designs during the design phase.

The Ghost Variable Problem

As the team prepared to publish the new library, one more issue surfaced: Figma ghost variables. These are variables that persist in a project even after no longer being linked to any design tokens, themes, or components. They typically arise from incomplete deletions, improper imports, or outdated metadata files. Ghost variables show up in the variable management panel but remain disconnected from any meaningful use.

The impact on design work is significant:

• Clutter and confusion: Longer variable lists make it harder to identify what is actively used versus obsolete.
• Redundant work: Designers may spend time trying to use variables that do not function as expected, leading to inefficiencies or design inconsistencies.
• Export and sync problems: Ghost variables can cause errors, duplicates, or conflicts when syncing with a design system repository, breaking alignment between system and Figma.
• Maintenance overhead: Manually finding and deleting ghost variables is time-consuming, especially with extensive variable sets.
• Thematic inconsistencies: Ghost variables may reference outdated styles, undermining a unified look across themes.

Cleaning them up required inspecting each component individually. By selecting a symbol and navigating the applied variable modes, the team could identify which older variable versions were still connected. Both the component library and the icon library contained disconnected variables, compounding the issue. Traversing the layer panel with the help of the “Swap Variables” plugin made it possible to remap all ghost variables in symbols. Skipping this clean-up step would have blocked designers from accessing overrides for theme, density, and locale.

Building Symbols for Language Swapping

To make symbols work with language switching, every text layer had to be linked to the new variables for font family, font size, and line height. The team deliberately avoided using Figma variables to define text strings per locale. With the breadth of products and solutions, maintaining translations in that form would be impractical. Instead, the “Translator” plugin handles translated content.

After remapping all text layers to variables and integrating the Translator plugin, whole screens could be swapped to another language for testing. This surfaced layout issues in symbols that did not support text wrapping when needed — for longer German words or shorter Japanese strings — so those symbols were converted to auto-layout for flexible resizing, ensuring they could scale for multilingual use.

Designer Guidance: The Multilingual Cheat Sheet

Delivering the component library to product designers came with a “Multilingual Design Cheat Sheet” covering practical guidance for setting up mockups with localization in mind:

1. General principles: Build flexible layouts that handle text wrapping and rights-to-left (RTL) orientations. Test with real content to surface spacing and wrapping issues, and research cultural expectations to avoid costly missteps.
2. Text and typography: Stick to the design system fonts for full language coverage. Avoid custom fonts lacking bold or italic variants for CJK scripts. Reserve extra space for languages like German or Finnish. Use auto-layout rather than fixed-width containers to keep text readable. Rely on variables for line height since tokens adjust it per language. Use bold sparingly — tokens override it in some languages — preferring size or color for emphasis.
3. Layout and design: Mirror layouts for RTL languages such as Arabic and Hebrew, aligning text, icons, and navigation accordingly. Use auto-layout to accommodate varying text lengths. Never embed text in images. Maintain generous spacing around text to prevent crowding.
4. Language-specific adjustments: Adapt formats by locale (e.g., YYYY/MM/DD versus MM/DD/YYYY) and use metric or imperial units per region. Test alignments for both LTR and RTL flows.
5. Localization readiness: Avoid idioms and cultural references that do not translate. Provide space for localized images where needed. Test with translation plugins and real translations rather than lorem ipsum. Involve native speakers for language-specific usability, and check RTL mirrored layouts and interactions for usability.

Building Localization-Ready Systems: What Worked and What Didn’t

Creating a design system that handles multiple languages is rarely a straight path. For our team, the process of integrating localization into a structured design workflow surfaced several clear takeaways about where design tools help, where they fall short, and how process changes can prevent costly rework.

Key Lessons From the Localization Process

Treating internationalization as a post-launch concern is the fastest route to cascading technical debt. Multilingual design principles need to be embedded from the first wireframe, because retrofitting text expansion, right-to-left support, and locale-specific typography into an established system is orders of magnitude more work than building for it initially.

The refactor toward semantic tokens proved foundational. Abstracting design decisions into purpose-driven variables (rather than purely visual ones) drastically reduced the complexity of adjusting for different languages and made the entire token set easier to maintain across themes and densities. When tokens describe intent, not just appearance, swapping values for a German or Arabic locale becomes a data exercise rather than a design challenge.

Figma variables offer promise but carry sharp limitations. The introduction of native variable support opens up smarter workflows, but the current feature set is missing critical pieces. Line-height values must be given as fixed numbers, not percentages, which breaks fluid type systems. Setting up variable collections for each locale is largely manual, even with plugins.

The necessity of automation was a recurring theme. Hand-recording typography and density-specific values for every theme and language is slow and error-prone. Custom plugins — particularly a small set built for translating strings and swapping variable sets between themes or locales — made the difference between a feasible workflow and an unsustainable one.

Close collaboration with front-end engineers mattered as much as any technical fix. Restructuring JSON token files impacted runtime performance on the consumer side, so design and development had to align on the shape of the data before committing to a new structure. No amount of design-side polish compensates for a format that degrades page load times.

Testing with real translated content was shown to be non-negotiable. Issues such as ungraceful text truncation, broken RTL mirroring, and mismatched font fallbacks stayed hidden until actual translations were poured into flexible layouts. English-only previews simply do not reveal these problems.

What Comes Next for Better Multilingual Support

Looking ahead, the roadmap focuses on eliminating the remaining manual friction points and expanding what the design system can offer to global teams.

• Automatic RTL mirroring. Creating tooling that can reflow a layout for right-to-left languages reliably — beyond just flipping horizontal padding — so Arabic and Hebrew layouts receive equal design attention without full manual overhauls.
• Stronger Figma integration. Advocating for variable enhancements, especially percentage-based line-heights and more robust methods to import variables between files without losing connections.
• Deeper automation for token management. Building more advanced plugins to compute token values across multiple themes, densities, and locales, reducing hand-coding that is prone to mistakes.
• A repeatable testing framework. Creating a standard process for native-speaker testing and validating designs with realistic content early, so localization defects surface in design review, not customer support tickets.
• Expanding the multilingual design reference. Continuing to evolve a shared resource that catalogues localization patterns, gathering feedback from design teams to make it more useful in practice.
• Open conversations with the community. Publishing findings and methods to help other teams building global design systems, with the intent of shifting the broader industry away from defaulting to English-first, left-aligned layouts.

The immediate goal is a design system that feels native to every language it serves, empowering designers to think beyond a single-locale default. Making that work requires pairing stronger conventions with better tooling and real-world testing earlier in the workflow.