Thursday, June 19, 2025
HomeWeb developmentIntegrating Localization Into Design Techniques — Smashing Journal

Integrating Localization Into Design Techniques — Smashing Journal


Mark and I work as product designers for SAS, a pacesetter in analytics and synthetic intelligence acknowledged globally for turning information into useful insights. Our major function is to help the token packages and element libraries for the SAS Filament Design System. SAS’ buyer base is world, that means folks from numerous international locations, cultures, and languages work together with merchandise constructed with the Filament Design System.

SAS designers use Figma libraries developed by the Filament Design System crew to create UX specs. These high-fidelity designs are sometimes crafted in English, unknowingly overlooking multilingual rules, which can lead to structure points, textual content overflow, and challenges with right-to-left (RTL) languages. These points cascade into the appliance, finally creating usability points for SAS clients. This highlights the necessity to prioritize localization from the beginning of the design course of.

With the introduction of Figma Variables, alongside the developments in design tokens, we noticed a possibility for designers. We imagined a system the place a Figma design might dynamically change between themes, densities, and even languages.

This may enable us to design and take a look at multilingual capabilities extra successfully, making certain our design system was each versatile and adaptable.

Whereas researching localization integration for design techniques, we realized a big hole in present documentation on supporting localization and internationalization in design tokens and Figma Variables. Lots of the challenges we confronted, resembling managing typography throughout locales or adapting layouts dynamically, had been undocumented or solely partially addressed in accessible sources.

Our story demonstrates how combining foundational rules of multilingual design with design tokens may also help deal with the complexities of language switching in design techniques. We aren’t arguing that our strategy is the very best, however given the dearth of documentation accessible on the topic, we hope it is going to get the dialog began.

However earlier than we begin, it’s important to know the excellence between Localization (L10n) and Internationalization (I18n).

Localization (L10n) refers back to the strategy of adapting designs for particular languages, areas, or cultures and entails the next:

  • Translating textual content;
  • Adjusting layouts to accommodate language-specific necessities, resembling longer or shorter textual content strings or right-to-left (RTL) textual content for languages like Arabic;
  • Guaranteeing visible components are culturally applicable and resonate with the audience.

Internationalization (I18n) is the preparation part, making certain designs are versatile and adaptable to totally different languages and areas. Key issues in Figma embrace:

  • Utilizing placeholder textual content to characterize dynamic content material;
  • Organising constraints for dynamic resizing to deal with textual content growth or contraction;
  • Supporting bi-directional textual content for languages that require RTL layouts.

These ideas should not solely foundational to multilingual design but in addition integral to delivering inclusive and accessible experiences to world customers.

Pre-Figma Setup: Constructing A Framework

Understanding Our Design Token System

Earlier than diving deeper, it’s essential to know that our design tokens are saved in JSON information. These JSON information are managed in an utility we name “Token Depot,” hosted on our company GitHub.

We make the most of the Tokens Studio plugin (professional plan) to remodel these JSON information into Figma libraries. For us, design tokens are synonymous with variables — we don’t create further variables that solely exist in Figma. Nonetheless, we do create types in Figma that function “recipe playing cards” for particular HTML components. As an illustration, an H2 may embrace a mix of font-family, font-size, and font-weight.

It’s necessary to notice that our design token values are immediately tied to CSS-based values.

Preliminary Setup: Theme Switching And Localization

In 2022, we took on the huge job of refactoring all our token names to be extra semantic. At the moment, we had been solely involved with theme switching in our merchandise.

Our tokens had been re-categorized into the next teams:

  • Colour
    • Model colours (SAS model colours)
    • Base colours (references to Model colours)
  • Typography (e.g., fonts, spacing, types)
  • House (e.g., padding, margins)
  • Dimension (e.g., icons, borders)
  • Model (e.g., focus types)
  • Movement (e.g., animations)
  • Shadow.
Groupings of token type.
Our first iteration of token groupings by kind. (Massive preview)

In our early setup:

  • A core folder contained JSON information for values unaffected by theme or model.
  • Model folders included three JSON information (one for every theme). These had been thought-about “English” by default.
  • A separate languages folder contained overrides for different locales, stacked on high of brand name information to switch particular token values.

Our JSON information had been configured with English because the default. Different locales had been managed with a set of JSON information that included overrides for English. These overrides had been minimal, focusing primarily on font and typography changes. For instance, daring typefaces typically create points as a result of many languages like Chinese language, Japanese, or Korean (CJK languages) fonts lack distinct daring variations. Thus, we changed the font-weight token worth from 700 to 400 in our CJK locales.

We additionally replace the values for font-family, letter spacing, font-style, and font-variant tokens. In Figma, our utility screens had been initially designed in English, and in 2023, we solely applied theme-switching modes, not language choices. Moreover, we created detailed lists to doc which design tokens may very well be transformed to Figma variables and which couldn’t, because the preliminary launch of variables supported solely a restricted set.

Introducing Density Switching

The introduction of density switching in our merchandise marked a big turning level. This variation allowed us to revisit and enhance how we dealt with localization and token administration. The very first thing we had to determine was the mandatory token sorting. We ended up with the next record:

Tokens Impression By Theme And Density

Unaffected by Theme or Density:

  • Colour
  • Model colours
  • Base colours
  • Movement
  • Shadow
  • Dimension
  • Border measurement
  • Define measurement
  • Typography
  • Base font measurement
  • Letter spacing and phrase spacing
  • Overflow, textual content, and phrase type tokens.

Tokens Impacted by Density:

  • Typography
  • Font sizes
  • Line Peak
  • Font spacing
  • Dimension
  • Border radius
  • Icon sizes
  • House
  • Base spacing.

Tokens Impacted by Theme:

  • Colours
  • Motion, physique, container, dataviz, show, heading, spotlight, icon, label, standing, syntax, tag, textual content, thumbnail, and zero-stat
  • Dimension
  • Border measurement
  • Typography
  • Font-family
  • Model
  • Motion (focus types).

With density, we expanded locale-specific worth modifications past font-family, letter spacing, font-style, and font-variant tokens to moreover embrace:

  • Font sizes
  • Icon sizes
  • Line peak
  • Spacing
  • Border radius.

Revisiting our kind scale and performing quite a few calculations, we documented the required token worth modifications for all of the locales throughout the density. This groundwork enabled us to deal with the restructuring of our JSON information successfully.

Groupings of token type by mode.
Our up to date JSON information had been grouped by core, theme, and density modes. (Massive preview)

JSON File Restructuring

In our token repository, we:

  1. Up to date the tokens within the core folder.
  2. Added a density folder and a language folder in every model.

After collaborating with our front-end growth crew, we determined to attenuate the variety of JSON information. Too many information introduce complexity and bugs and hinder efficiency. As an alternative of making a JSON file for every language-density mixture, we outlined the next language classes:

Language Classes

  • Western European and Slavic Languages
    • Polish, English, French, German, and Spanish
  • Chinese language Languages
    • Simplified and conventional scripts
  • Center Jap and East Asian Languages
    • Arabic, Hebrew, Japanese, Korean, Thai, and Vietnamese
  • International Various
    • Africa, South Asia, Pacific, and Indigenous languages, Uralic, and Turkic teams.

These classes turned our JSON information, with one file per density stage. Every file contained tokens for font measurement, icon measurement, line peak, spacing, and border-radius values. For instance, all Chinese language locales shared constant values no matter font-family.

Regional groupings of languages.
To reduce efficiency burden, we divided languages into areas. (Massive preview)

As well as, we added a folder containing JSON information per locale, overriding core values and theme folders, resembling font-family.

Figma Setup: Bridging Tokens And Design

Token Studio Challenges

After restructuring our JSON information, we anticipated gaining help for typography variables within the Tokens Studio plugin. As an alternative, Tokens Studio launched model 2.0, introducing a serious shift in workflow. Beforehand, we imported JSON information immediately into Figma and averted pushing modifications again by means of the plugin. Adjusting to the brand new model required us to relearn how one can use the plugin successfully.

Our first problem was navigating the complexity of the import course of. The $metadata.json and $themes.json information didn’t overwrite appropriately throughout imports, leading to duplicate collections in Figma when exporting variables. Regardless of recreating the required theme construction throughout the plugin, the difficulty persevered. To resolve this, we deleted the present $metadata.json and $themes.json information from the repository earlier than pulling the up to date GitHub repo into the plugin. Nonetheless, even with this answer, we needed to manually take away redundant collections that appeared through the export course of.

As soon as we efficiently migrated our tokens from JSON information into Figma utilizing the Tokens Studio plugin, we encountered our subsequent problem.

Initially, we used solely “English” and theme modes in Figma, relying totally on types since Figma’s early variable releases lacked help for typography variables. Now, with the aim of implementing theme, density, and language switching, we would have liked to leverage variables — together with typography variables. Whereas the token migration efficiently introduced within the token names as variable names and the mandatory modes, some values had been lacking.

Typography variables, although promising in idea, had been underwhelming in observe. For instance, Figma’s default line-height multiplier for “auto” was 1.2, under the WCAG minimal of 1.5. Moreover, our token values used line-height multipliers, which weren’t legitimate as Figma variable values. Whereas a percentage-based line-height worth is legitimate in CSS, Figma variables don’t help percentages.

Our answer concerned manually calculating pixel values for line heights throughout all typography sizes, locale classes, and densities. These values had been entered as native variables in Figma, unbiased of the design token system. This allowed us to implement appropriate line-height modifications for density and locale switches. The method, nevertheless, was labor-intensive, requiring the guide creation of a whole lot of native variables. Moreover, grouping font sizes and line heights into Figma types required further guide effort as a result of lack of help for line-height multipliers or percentage-based variables.

Examples:

  • For CJK locales, medium and low density use a base font measurement of 16px, whereas excessive density makes use of 18px.
  • Western European and Slavic languages use 14px for medium density, 16px for prime, and 12px for low density.

Further Challenges

  • Figma vs. Internet Rendering
    In Figma, line peak facilities textual content visually throughout the textual content field. In CSS, it impacts spacing otherwise relying on the field mannequin. This mismatch required guide changes, particularly in mild of upcoming CSS properties like leading-trim.
  • Letter-Spacing Points
    Whereas CSS defaults to “regular” for letter-spacing, Figma requires numeric values. Locale-specific resets to “regular” couldn’t make the most of variables, complicating implementation.
  • Font-Household Stacks
    • Instance stack for Chinese language:
      font-family-primary: 'AnovaUI', '微软雅黑体', 'Microsoft YaHei New', '微软雅黑', 'Microsoft Yahei', '宋体', 'SimSun', 'Helvetica Neue', 'Helvetica', 'Arial', sans-serif.

Beginning with a Western font ensured correct rendering of Latin characters and symbols whereas sustaining model consistency. Nonetheless, Figma’s designs utilizing solely AnovaUI (SAS Model Customized font) couldn’t preview locale-based substitutions by way of system fonts, complicating evaluations of mixed-content designs.

Lastly, as we ready to publish our new library, we encountered yet one more problem: Figma Ghosts.

What Are Figma Ghost Variables?

Figma “ghost variables” consult with variables that stay in a Figma undertaking even after they’re not linked to any design tokens, themes, or elements.

These variables typically come up resulting from incomplete deletions, improper imports, or outdated metadata information. Ghost variables could seem in Figma’s variable administration panel however are successfully “orphaned,” as they’re disconnected from any significant use or reference.

Ghost variables demonstrated in Figma UI.
Ghost variables present in Figma when importing json information. (Massive preview)

Why They Trigger Points for Designers:

  • Muddle and Confusion
    Ghost variables make the variable record longer and tougher to navigate. Designers may wrestle to establish which variables are actively in use and that are out of date.
  • Redundant Work
    Designers may by chance attempt to use these variables, resulting in inefficiencies or design inconsistencies when the ghost variables don’t perform as anticipated.
  • Export and Sync Issues
    When exporting or syncing variables with a design system or repository, ghost variables can introduce errors, duplicates, or conflicts. This complicates sustaining alignment between the design system and Figma.
  • Elevated Upkeep Overhead
    Detecting and manually deleting ghost variables may be time-consuming, significantly in large-scale initiatives with intensive variable units.
  • Thematic Inconsistencies
    Ghost variables can create inconsistencies throughout themes, as they may reference outdated or irrelevant types, making it tougher to make sure a unified feel and look.

Addressing ghost variables requires cautious administration of design tokens and variables, typically involving clean-up processes to make sure solely related variables stay within the system.

Cleansing Up Ghost Variables

To keep away from the problems in our Figma libraries, we first needed to isolate ghost variables element by element. By choosing a logo in Figma and navigating the utilized variable modes, we had sense of which older variations of variables the image was nonetheless linked to. We discovered disconnected variables within the element library and our icon library, which resulted in compounded ghost variables throughout the system. We discovered that by traversing the layer panel, together with a implausible plug-in referred to as “Swap Variables,” we had been in a position to remap all of the ghost variables in our symbols.

If we had not accomplished the clean-up step, designers wouldn’t have the ability to entry the overrides for theme, density, and locale.

Designing Symbols For Localization

To make sure Figma symbols help language swapping, we linked all textual content layers to our new variables, together with font-family, font-size, and line peak.

We don’t use Figma’s variable characteristic to outline textual content strings for every locale (e.g., English, Spanish, French) as a result of, given the sheer breadth and depth of our Merchandise and options, it could merely be too daunting a job to undertake. For us, utilizing an present plug-in, resembling “Translator,” provides us what we want.

After making certain all textual content layers had been remapped to variables, together with the “Translator” plug-in, we had been in a position to swap total screens to a brand new language. This allowed us to begin testing our symbols for unexpected structure points.

Figma plug in Translator.
We use the Translator plugin to check out translating our product mockups. (Massive preview)

We found that some symbols weren’t supporting textual content wrapping when wanted (e.g., accommodating longer phrases in German or shorter ones in Japanese). We remoted these points and up to date them to auto-layout for versatile resizing. This strategy ensured all our Figma symbols had been scalable and adaptable for multilingual help.

Delivering The System

With our element libraries set as much as help localization, we had been able to ship our element libraries to product designers. As part of this step, we crafted a “Multilingual Design Cheat Sheet” to assist designers perceive how one can arrange their utility mockups with Localization and Internationalization in thoughts.

Multilingual Design Cheat Sheet:

  1. Common Rules
    • Design versatile layouts that may deal with textual content wrapping and language-specific necessities resembling right-to-left orientations.
    • Use actual content material throughout design and growth to establish localization points resembling spacing and wrapping.
    • Analysis the cultural expectations of your audience to keep away from fake pas.
  2. Textual content & Typography
    • Use Filament Design Techniques fonts to make sure help of all languages.
    • Keep away from customized fonts that lack daring or italic types for non-Latin scripts like CJK languages.
    • Reserve further area for languages like German or Finnish.
    • Keep away from hardcoded widths for textual content containers and use auto-layout to make sure lengthy textual content strings are readable.
    • The Filament Design System tokens modify line peak per language; be sure to are utilizing variables for line-height.
    • Use daring sparingly, as Filament tokens override daring styling in some languages. As an alternative, go for different emphasis strategies (e.g., shade or measurement).
  3. Format & Design
    • Mirror layouts for RTL languages (e.g., Arabic, Hebrew). Align textual content, icons, and navigation appropriately for the movement of the language.
    • Use auto-layout to accommodate various textual content lengths.
    • Keep away from embedding textual content in pictures to simplify localization.
    • Enable ample spacing round textual content components to stop crowding.
  4. Language-Particular Changes
    • Adapt codecs primarily based on locale (e.g., YYYY/MM/DD vs. MM/DD/YYYY).
    • Use metric or imperial items primarily based on the area.
    • Check alignments and flows for LTR and RTL languages.
  5. Localization Readiness
    • Keep away from idioms, cultural references, or metaphors that won’t translate properly.
    • Present area for localized pictures, if mandatory.
    • Use Figma translation plug-ins to check designs for localization readiness and use actual translations reasonably than Lorem Ipsum.
    • Check with native audio system for language-specific usability points.
    • Test mirrored layouts and interactions for usability in RTL languages.

Classes Realized And Future Instructions

Classes Realized

In abstract, constructing a localization-ready design system was a fancy but rewarding course of that taught Mark and me a number of important classes:

  • Localization and internationalization should be prioritized early.
    Ignoring multilingual rules within the early levels of design creates cascading points which might be expensive to repair later.
  • Semantic tokens are key.
    Refactoring our tokens to be extra semantic streamlined the localization course of, decreasing complexity and bettering maintainability.
  • Figma variables are promising however restricted.
    Whereas Figma Variables launched new potentialities, their present limitations — resembling lack of percentage-based line-height values and guide setup necessities — spotlight areas for enchancment.
  • Automation is important.
    Guide efforts, resembling recalculating and inputting values for typography and density-specific tokens, are time-intensive and liable to error. Plugins like “Translator” and “Swap Variables” proved invaluable in streamlining this work.
  • Collaboration is essential.
    Shut coordination with front-end builders ensured that our JSON restructuring efforts aligned with efficiency and value objectives.
  • Testing with actual content material is non-negotiable.
    Design points like textual content wrapping, RTL mirroring, and font compatibility solely turned obvious when testing with actual translations and versatile layouts.

Future Instructions

As we glance forward, our focus is on enhancing the Filament Design System to higher help world audiences and simplify the localization course of for designers:

  • Computerized mirrored layouts for RTL languages.
    We plan to develop instruments and workflows that allow seamless mirroring of layouts for right-to-left languages, making certain usability for languages like Arabic and Hebrew.
  • Improved figma integration.
    Advocacy for Figma enhancements, resembling percentage-based line-height help and higher dealing with of variable imports, will stay a precedence.
  • Superior automation instruments.
    Investing in additional strong plugins and customized instruments to automate the calculation and administration of tokens throughout themes, densities, and locales will scale back guide overhead.
  • Scalable localization testing framework.
    Establishing a framework for native speaker testing and real-world content material validation will assist us establish localization points earlier within the design course of.
  • Increasing the multilingual design cheat sheet.
    We’ll proceed to refine and broaden the cheat sheet, incorporating suggestions from designers to make sure it stays a useful useful resource.
  • Group engagement.
    By sharing our findings and classes, we purpose to contribute to the broader design group, fostering discussions round integrating localization and internationalization in design techniques.

By way of these efforts, Mark and I hope to create a extra inclusive, scalable, and environment friendly design system that meets the varied wants of our world viewers whereas empowering SAS designers to suppose past English-first designs.

Additional Studying On SmashingMag

Smashing Editorial
(yk)



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments