将本地化集成到设计系统中——Smashing Magazine

作者：Rebecca Hemstad & Mark Malek
2025年5月12日 | 0条评论 | 15分钟阅读
设计系统、Figma、案例研究、本地化

了解两位设计师如何应对为全球用户构建支持本地化的设计系统所面临的挑战。本案例研究深入探讨Rebecca和Mark如何结合Figma变量和设计令牌解决多语言设计问题，如文本溢出、从右到左（RTL）布局和字体不一致。他们分享了关键经验教训和遇到的障碍——包括Figma的限制——以及他们开发的解决方案，以创建能够跨语言、主题和密度无缝适应的动态、可扩展设计。如果您正在设计系统中应对国际化的复杂性，本文正适合您。

Mark和我在SAS担任产品设计师，SAS是分析和人工智能领域的领导者，全球公认将数据转化为有价值见解的公司。我们的主要职责是支持SAS Filament设计系统的令牌包和组件库。SAS的客户群是全球性的，意味着来自不同国家、文化和语言的人们与使用Filament设计系统构建的产品进行交互。

SAS设计师使用Filament设计系统团队开发的Figma库来创建UX规范。这些高保真设计通常以英语制作，无意中忽略了多语言原则，可能导致布局问题、文本溢出以及从右到左（RTL）语言的挑战。这些问题会级联到应用程序中，最终为SAS客户带来可用性问题。这凸显了在设计过程开始时优先考虑本地化的必要性。

随着Figma变量的引入以及设计令牌的进步，我们看到了设计师的机会。我们设想了一个系统，其中Figma设计可以动态切换主题、密度甚至语言。

“这将使我们更有效地设计和测试多语言功能，确保我们的设计系统既灵活又可适应。”

在研究设计系统的本地化集成时，我们意识到现有文档在支持设计令牌和Figma变量中的本地化和国际化方面存在显著差距。我们面临的许多挑战，如跨区域管理排版或动态适应布局，在可用资源中未记录或仅部分解决。

我们的故事展示了如何将多语言设计的基本原则与设计令牌相结合，以帮助应对设计系统中语言切换的复杂性。我们并不认为我们的方法是最好的，但鉴于该主题缺乏可用文档，我们希望它能启动对话。

但在开始之前，理解本地化（L10n）和国际化（I18n）之间的区别至关重要。

本地化（L10n） 指的是为特定语言、地区或文化适应设计的过程，涉及以下内容：

• 翻译文本；
• 调整布局以适应语言特定要求，如更长或更短的文本字符串或从右到左（RTL）文本（如阿拉伯语）；
• 确保视觉元素在文化上适当并与目标受众产生共鸣。

国际化（I18n） 是准备阶段，确保设计灵活并可适应不同语言和地区。Figma中的关键考虑包括：

• 使用占位文本来表示动态内容；
• 设置动态调整大小的约束以处理文本扩展或收缩；
• 支持需要RTL布局的语言的双向文本。

这些概念不仅是多语言设计的基础，而且对于向全球用户提供包容和可访问的体验至关重要。

Figma设置前：构建框架

理解我们的设计令牌系统

在深入之前，关键要理解我们的设计令牌存储在JSON文件中。这些JSON文件在一个我们称为“Token Depot”的应用程序中管理，托管在我们的企业GitHub上。

我们使用Tokens Studio插件（专业版计划）将这些JSON文件转换为Figma库。对我们来说，设计令牌与变量同义——我们不创建仅在Figma中存在的额外变量。然而，我们确实在Figma中创建样式，作为特定HTML元素的“配方卡”。例如，H2可能包括字体家族、字体大小和字体粗细的组合。

需要注意的是，我们的设计令牌值直接与基于CSS的值相关联。

初始设置：主题切换和本地化

2022年，我们承担了重构所有令牌名称以更具语义的巨大任务。当时，我们只关心产品中的主题切换。

我们的令牌被重新分类为以下组：

• 颜色
  • 品牌颜色（SAS品牌颜色）
  • 基础颜色（对品牌颜色的引用）
• 排版（例如，字体、间距、样式）
• 空间（例如，内边距、外边距）
• 大小（例如，图标、边框）
• 样式（例如，焦点样式）
• 动效（例如，动画）
• 阴影。

在我们的早期设置中：

• 一个核心文件夹包含不受主题或品牌影响的值的JSON文件。
• 品牌文件夹包括三个JSON文件（每个主题一个）。这些默认被视为“英语”。
• 一个单独的语言文件夹包含对其他区域的覆盖，堆叠在品牌文件之上以替换特定令牌值。

我们的JSON文件配置为英语默认。其他区域通过一组包含英语覆盖的JSON文件管理。这些覆盖最小，主要关注字体和排版调整。例如，粗体字型经常造成问题，因为许多语言如中文、日文或韩文（CJK语言）字体缺乏明显的粗体版本。因此，我们在CJK区域中将字体粗细令牌值从700替换为400。

我们还更新字体家族、字母间距、字体样式和字体变体令牌的值。在Figma中，我们的应用程序屏幕最初以英语设计，2023年，我们仅实施了主题切换模式，没有语言选项。此外，我们创建了详细列表来记录哪些设计令牌可以转换为Figma变量，哪些不能，因为变量的初始发布仅支持有限集。

引入密度切换

在我们产品中引入密度切换标志着一个重要的转折点。这一变化使我们能够重新审视和改进如何处理本地化和令牌管理。我们首先必须弄清楚必要的令牌排序。我们最终得到了以下列表：

受主题和密度影响的令牌

• 不受主题或密度影响：

  • 颜色
    • 品牌颜色
    • 基础颜色
  • 动效
  • 阴影
  • 大小
    • 边框大小
    • 轮廓大小
  • 排版
    • 基础字体大小
    • 字母间距和单词间距
    • 溢出、文本和单词样式令牌。

• 受密度影响：

  • 排版
    • 字体大小
    • 行高
    • 字体间距
  • 大小
    • 边框半径
    • 图标大小
  • 空间
    • 基础间距。

• 受主题影响：

  • 颜色
    • 操作、正文、容器、数据可视化、显示、标题、高亮、图标、标签、状态、语法、标签、文本、缩略图和零状态
  • 大小
    • 边框大小
  • 排版
    • 字体家族
  • 样式
    • 操作（焦点样式）。

随着密度的引入，我们将区域特定值更改扩展到字体家族、字母间距、字体样式和字体变体令牌之外，额外包括：

• 字体大小
• 图标大小
• 行高
• 间距
• 边框半径。

重新审视我们的类型比例并执行大量计算后，我们记录了所有区域跨密度所需的令牌值更改。这一基础工作使我们能够有效地处理JSON文件的重构。

JSON文件重构

在我们的令牌存储库中，我们：

• 更新了核心文件夹中的令牌。
• 在每个品牌中添加了密度文件夹和语言文件夹。

与我们的前端开发团队合作后，我们决定最小化JSON文件的数量。太多文件引入复杂性和错误，并阻碍性能。我们没有为每个语言-密度组合创建JSON文件，而是定义了以下语言类别：

语言类别

• 西欧和斯拉夫语言
  • 波兰语、英语、法语、德语和西班牙语
• 中文语言
  • 简体和繁体脚本
• 中东和东亚语言
  • 阿拉伯语、希伯来语、日语、韩语、泰语和越南语
• 全球多样化
  • 非洲、南亚、太平洋和土著语言、乌拉尔语和突厥语组。

这些类别成为我们的JSON文件，每个密度级别一个文件。每个文件包含字体大小、图标大小、行高、间距和边框半径值的令牌。例如，所有中文区域共享一致的值，无论字体家族如何。

此外，我们添加了一个包含每个区域JSON文件的文件夹，覆盖核心值和主题文件夹，如字体家族。

Figma设置：桥接令牌和设计

Token Studio挑战

重构JSON文件后，我们预期获得Tokens Studio插件中对排版变量的支持。相反，Tokens Studio发布了2.0版，引入了工作流程的重大转变。以前，我们直接将JSON文件导入Figma，并避免通过插件推送更改。适应新版本要求我们重新学习如何有效使用插件。

我们的第一个挑战是导航导入过程的复杂性。$metadata.json和$themes.json文件在导入期间未能正确覆盖，导致在导出变量时Figma中出现重复集合。尽管在插件内重新创建了所需的主题结构，问题仍然存在。为了解决这个问题，我们在将更新的GitHub存储库拉入插件之前，从存储库中删除了现有的$metadata.json和$themes.json文件。然而，即使有这个解决方案，我们仍必须手动删除在导出过程中出现的冗余集合。

一旦我们使用Tokens Studio插件成功将令牌从JSON文件迁移到Figma，我们遇到了下一个挑战。

最初，我们仅在Figma中使用“英语”和主题模式，主要依赖样式，因为Figma的早期变量发布缺乏对排版变量的支持。现在，随着实施主题、密度和语言切换的目标，我们需要利用变量——包括排版变量。虽然令牌迁移成功将令牌名称作为变量名称和必要模式引入，但一些值缺失。

排版变量在概念上有前景，但在实践中令人失望。例如，Figma的“自动”行高乘数默认值为1.2，低于WCAG最低要求1.5。此外，我们的令牌值使用行高乘数，这些值在Figma变量值中无效。虽然基于百分比的行高值在CSS中有效，但Figma变量不支持百分比。

我们的解决方案涉及手动计算所有排版大小、区域类别和密度的行高像素值。这些值作为本地变量输入Figma，独立于设计令牌系统。这使我们能够为密度和区域切换实施正确的行高更改。然而，这个过程是劳动密集型的，需要手动创建数百个本地变量。此外，由于缺乏对行高乘数或基于百分比的变量的支持，将字体大小和行高分组到Figma样式中需要额外的手动努力。

示例：

• 对于CJK区域，中低密度使用16px的基础字体大小，而高密度使用18px。
• 西欧和斯拉夫语言使用14px用于中密度，16px用于高密度，12px用于低密度。

额外挑战

Figma与Web渲染 在Figma中，行高在文本框中视觉上居中文本。在CSS中，它根据盒子模型以不同方式影响间距。这种不匹配需要手动调整，特别是考虑到即将到来的CSS属性如leading-trim。

字母间距问题 虽然CSS默认字母间距为“正常”，但Figma需要数值。区域特定重置为“正常”无法利用变量，使实施复杂化。

字体家族堆栈 中文示例堆栈： font-family-primary: ‘AnovaUI’, ‘微软雅黑体’, ‘Microsoft YaHei New’, ‘微软雅黑’, ‘Microsoft Yahei’, ‘宋体’, ‘SimSun’, ‘Helvetica Neue’, ‘Helvetica’, ‘Arial’, sans-serif。

从西方字体开始确保拉丁字符和符号的正确渲染，同时保持品牌一致性。然而，Figma的设计仅使用AnovaUI（SAS品牌自定义字体）无法通过系统字体预览基于区域的替换，使混合内容设计的评估复杂化。

最后，当我们准备发布新库时，我们遇到了另一个挑战：Figma幽灵变量。

什么是Figma幽灵变量？

Figma“幽灵变量”指的是即使不再链接到任何设计令牌、主题或组件，仍保留在Figma项目中的变量。

这些变量通常由于不完整的删除、不当的导入或过时的元数据文件而产生。幽灵变量可能出现在Figma的变量管理面板中，但实际上是“孤立的”，因为它们与任何有意义的用途或引用断开连接。

为什么它们给设计师带来问题：

• 杂乱和混淆 幽灵变量使变量列表更长且更难导航。设计师可能难以识别哪些变量正在积极使用，哪些已过时。
• 冗余工作 设计师可能意外尝试使用这些变量，导致效率低下或设计不一致，当幽灵变量不按预期功能时。
• 导出和同步问题 当与设计系统或存储库导出或同步变量时，幽灵变量可能引入错误、重复或冲突。这使维护设计系统和Figma之间的一致性复杂化。
• 增加维护开销 检测和手动删除幽灵变量可能耗时，特别是在具有广泛变量集的大规模项目中。
• 主题不一致 幽灵变量可能创建跨主题的不一致，因为它们可能引用过时或不相关的样式，使确保统一外观和感觉更难。

解决幽灵变量需要仔细管理设计令牌和变量，通常涉及清理过程以确保只有相关变量保留在系统中。

清理幽灵变量

为避免我们Figma库中的问题，我们首先必须逐个组件隔离幽灵变量。通过选择Figma中的符号并导航应用的变量模式，我们很好地了解了符号仍连接到哪些旧版本变量。我们在组件库和图标库中发现了断开的变量，这导致系统中复合的幽灵变量。我们发现，通过遍历图层面板以及一个名为“Swap Variables”的出色插件，我们能够重新映射符号中的所有幽灵变量。

如果我们没有完成清理步骤，设计师将无法访问主题、密度和区域的覆盖。

为本地化设计符号

为确保Figma符号支持语言交换，我们将所有文本层链接到我们的新变量，包括字体家族、字体大小和行高。

我们不使用Figma的变量功能为每个区域定义文本字符串（例如，英语、西班牙语、法语），因为考虑到我们产品和解决方案的广度和深度，这将是一项过于艰巨的任务。对我们来说，使用现有插件，如“Translator”，提供了我们所需的内容。

确保所有文本层重新映射到变量后，连同“Translator”插件，我们能够将整个屏幕交换到新语言。这使我们能够开始测试符号以发现未预见的布局问题。

我们发现一些符号在需要时不支持文本换行（例如，适应德语中更长的单词或日语中更短的单词）。我们隔离了这些问题并更新它们为自动布局以实现灵活调整大小。这种方法确保我们所有的Figma符号可扩展并可适应多语言支持。

交付系统

随着我们的组件库设置支持本地化，我们准备将组件库交付给产品设计师。作为这一步的一部分，我们制作了一个“多语言设计速查表”，以帮助设计师理解如何设置他们的应用程序模型，考虑本地化和国际化。

多语言设计速查表：

一般原则

• 设计灵活布局，可处理文本换行和语言特定要求，如从右到左方向。
• 在设计和开发期间使用真实内容以识别本地化问题，如间距和换行。
• 研究目标受众的文化期望以避免失礼。

文本与排版

• 使用Filament设计系统字体以确保支持所有语言。
• 避免缺乏粗体或斜体样式的自定义字体，用于非拉丁脚本如CJK语言。
• 为德语或芬兰语等语言保留额外空间。
• 避免文本容器的硬编码宽度，使用自动布局以确保长文本字符串可读。
• Filament设计系统令牌按语言调整行高；确保使用变量行高。
• 谨慎使用粗体，因为Filament令牌在某些语言中覆盖粗体样式。相反，选择替代强调方法（例如，颜色或大小）。

布局与设计

• 为RTL语言（例如，阿拉伯语、希伯来语）镜像布局。根据语言流对齐文本、图标和导航。
• 使用自动布局以适应变化的文本长度。
• 避免在图像中嵌入文本以简化本地化。
• 允许文本元素周围充足的间距以防止拥挤。

语言特定调整

• 根据区域适应格式（例如，YYYY/MM/DD vs. MM/DD/YYYY）。
• 基于地区使用公制或英制单位。
• 测试LTR和RTL语言的对齐和流。

本地化准备

• 避免可能翻译不佳的习语、文化参考或隐喻。
• 必要时为本地化图像提供空间。
• 使用Figma翻译插件测试设计的本地化准备情况，并使用真实翻译而非Lorem Ipsum。
• 与母语人士测试语言特定可用性问题。
• 检查镜像布局和交互在RTL语言中的可用性。

经验教训和未来方向

经验教训

总之，构建支持本地化的设计系统是一个复杂但有益的过程，教给Mark和我几个关键经验：

• 本地化和国际化必须早期优先。 忽略设计早期阶段的多语言原则会创建级联问题，后期修复成本高昂。
• 语义令牌是关键。 重构我们的令牌以更具语义简化了本地化过程，减少复杂性并提高可维护性。
• Figma变量有前景但有限。 虽然Figma变量引入了新的可能性，但它们当前的限制——如缺乏基于百分比的行高值和手动设置要求——突出了改进领域。
• 自动化至关重要。 手动努力，如重新计算和输入排版和密度特定令牌的值，耗时且容易出错。像“Translator”和“Swap Variables”这样的插件在简化这项工作中证明 invaluable。
• 协作至关重要。 与前端开发人员的紧密协调确保我们的JSON重构努力与性能和可用性目标一致。
• 用真实内容测试非可协商。 设计问题如文本换行、RTL镜像和字体兼容性仅在用真实翻译和灵活布局测试时变得明显。

未来方向

展望未来，我们的重点是增强Filament设计系统以更好地支持全球受众并简化设计师的本地化过程：

• RTL语言的自动镜像布局。 我们计划开发工具和工作流程，实现从右到左语言的无缝镜像布局，确保如阿拉伯语和希伯来语等语言的可用性。
• 改进的Figma集成。 倡导Figma增强，如基于百分比的行高支持和更好的变量导入处理，将仍然是优先事项。
• 高级自动化工具。 投资更强大的插件和自定义工具以自动化跨主题、密度和区域的令牌计算和管理，将减少手动开销。
• 可扩展的本地化测试框架。 建立母语人士测试和真实世界内容验证的框架，将帮助我们在设计过程早期识别本地化问题。
• 扩展多语言设计速查表。 我们将继续完善和扩展速查表，纳入设计师的反馈以确保它保持有价值的资源。
• 社区参与。 通过分享我们的发现和经验，我们旨在为更广泛的设计社区做出贡献，促进围绕在设计系统中集成本地化和国际化的讨论。

通过这些努力，Mark