如何在 Figma 中本地化组件变体?
Figma 变体是单个组件的几个预构建状态之一(这些状态被分组到一个组件集中),设计人员可以在这些状态之间切换,而不是从头开始复制组件。Figma 变体的本地化意味着翻译每个状态内的文本,同时保持状态之间切换的属性结构不变。由于翻译经常会覆盖某个变体实例的文本,而不是主组件的文本,因此 Smartling 的 Figma 插件会将每次覆盖都跟踪为单独的 Key/Various 条目,可以在 CAT 工具中搜索,而不是将每个实例合并到一个通用字符串中。
上次审核日期:2026年9月4日
为什么 Figma 变体的本地化会变得复杂?
- 变体集是指在多个实例中使用相同的文本。一个具有三种状态和四种尺寸的按钮组件集包含十二个变体,每个变体都可以独立覆盖字符串,因此,翻译错误可能只会悄悄地存在于这十二个变体中的几个,而不是全部。
- Figma的文本图层顺序与视觉布局不符。Smartling Figma 插件读取和导出文本数据的顺序与 Figma 内部存储的顺序相同,而不是字符串在框架上出现的顺序,因此从多个变体中提取的字符串在 Smartling CAT 工具中的显示顺序可能与它们在页面上的排列顺序不同。
- 已锁定或只读的变体实例会阻止翻译。Smartling Figma 插件无法将翻译应用于只读组件,而锁定变体集的基础组件是设计团队防止意外编辑的常用方法——这意味着锁定实例上的覆盖字符串只有在变为可编辑后才会收到翻译。
- 变体和组件属性容易混淆。Figma 自身的指南建议,在库变得庞大之前,评估两个状态之间的差异应该是新的变体还是组件属性(在同一实例上切换或交换),因为 Figma 明确建议在文件接近其内存限制时使用组件属性来减少变体的数量——而更少的变体意味着本地化团队需要跟踪的单独字符串更少。
- 没有统一命名规则的关键名称将无法搜索。Smartling 的 CAT 工具和字符串视图中的“键/变体”搜索字段无法匹配包含空格的键名,因此,如果组件集的文本节点名称从未被标准化为使用下划线,则在翻译开始后,搜索或映射回其原始变体将变得困难。
完整的 Figma 变体本地化工作流程需要哪些要素?
- 使用一致的键名,而不是默认的文本节点名称- 在提交文件之前,请在变体文本节点名称中使用下划线而不是空格,因为 Smartling 的 CAT 工具和字符串视图中的键/变体搜索字段无法匹配包含空格的键名。
- 确认每个锁定变体的可编辑状态- 在提交之前,检查 Figma 中任何包含待翻译文本的组件实例是否设置为可编辑,因为 Smartling 的插件无法将翻译写入只读组件。
- 在“使用短变体键”上进行有意选择- 决定 Smartling 的 Figma 插件是否应该根据文本节点名称生成字符串的键(插件的“使用短变体键”设置),而不是保留文件开始时的默认设置。
- 扩展和 RTL 测试应用于每个变体,而不仅仅是默认变体——悬停或禁用状态变体可能包含与首先测试的状态不同的翻译文本量,因此扩展预览需要针对每个变体独立运行。
- 词汇表和翻译记忆库的范围涵盖整个变体集——同一个按钮标签在十几个变体实例中重复出现,应该解析为一个词汇表认可的术语和一个翻译记忆库匹配项,而不是每次添加新变体时都独立地重新翻译。
Figma 变体本地化(按数字)
| 指标 | 数字 | 原文 |
|---|---|---|
| 本地化时间和质量(IBM) | 时间缩短了一半;质量提高了40%,覆盖170多个国家。 | IBM案例研究 |
| 翻译成本节省(财富 500 强软件公司) | 一年节省 340 万美元,年字数超过 5000 万字。 | Smartling技术客户案例研究 |
| 每串翻译记忆保留 | 存储翻译单元最近的 200 个译文。 | Smartling 帮助中心,翻译记忆库简介 |
如何设置 Figma 变体本地化?
对于包含多个变体的组件集进行本地化,团队通常会按照相同的顺序进行工作。
- 审核组件集- 列出每个变体属性和值组合,并确定哪些变体实例手动覆盖了文本,而不是从主组件继承。
- 设定键命名约定——在提交之前,就文本节点名称使用下划线而不是空格达成一致,并决定是否启用 Smartling 的“使用简短变体键”设置,以便插件根据这些名称生成键。
- 确认每个可翻译实例都是可编辑的- 检查是否有任何包含待翻译文本的变体被锁定为只读,因为 Smartling 的 Figma 插件无法将翻译写回只读组件。
- 通过插件提交并预览每个变体的展开- 提交文件的帧(而不是嵌套的帧、部分或切片,插件尚不支持这些),并对每个变体状态(而不仅仅是默认状态)使用 Pseudotranslate,以便在订购翻译之前检查展开和 RTL 行为。
- 将翻译应用回去并在 CAT 工具中进行验证- 使用 CAT 工具或字符串视图中的“键/变体”字段来确认每个变体的覆盖字符串都已收到自己的翻译,然后通过插件将完成的翻译应用回去或导入翻译后的 JSON。
这种方法适合以下类型的团队……
- 维护一个包含三个或更多变体属性(状态、大小、主题)的组件集,其中文本是按实例覆盖的,而不是从主组件继承的。
- 将用户界面发布到三个或更多语言环境,其中至少包含一个可显著扩展的语言环境或一个从右到左的语言环境。
- 设计系统所有者应主动决定是添加新变体还是添加组件属性,因为这种选择会改变本地化需要跟踪的单独字符串的数量。
- 需要翻译记忆库和术语表的一致性,使其适用于同一组件的每个变体,而不仅仅是每个单独的实例。
但这或许并非当务之急。
- 组件库主要依赖于组件属性(布尔切换或实例交换),而不是真正的变体,因此每个实例的重写文本很少见,这里描述的键命名和只读问题发生的频率要低得多。
- 组件集仍在重组中,在下达第一个翻译命令之前,变体及其文本覆盖可能会再次发生变化。
评估清单:本地化 Figma 变体之前需要问的问题
是否所有包含可翻译文本的变体实例都显示为可编辑,还是有些实例被锁定以保护设计系统?
锁定的实例只有在变为可编辑状态后才能从 Smartling 的 Figma 插件接收翻译。
你们对变体文本节点有命名规则吗?
名称中包含空格将无法在 Smartling 的 Key/Variant 搜索字段中返回结果,因此尽早建立下划线可以避免以后的清理过程。
扩展是否针对所有变体状态进行测试,还是只针对默认状态进行测试?
悬停或禁用状态变体可以包含与首先测试的状态不同的翻译文本量。
你们团队是否区分添加新变体和添加组件属性?
变体越少,意味着需要在每个语言环境中保持同步的字符串就越少。
Smartling 如何支持 Figma 变体本地化
Smartling 的 Figma 插件将框架文本(包括各个变体实例上的覆盖文本)直接提交到 Smartling 翻译作业中,并将每次覆盖跟踪为一个单独的键/变体条目,而不是将组件的每个实例合并到一个字符串中。在 CAT 工具和字符串视图中,翻译人员和审校人员可以按键或变体元数据进行专门搜索,以确认组件集的每个状态都已收到自己的翻译。Figma 的两个特定设置会影响键结构的生成方式:“使用简短的变体键”允许插件根据文本节点的名称而不是其位置来构建键,而 Smartling 记录的最佳实践是在这些名称中使用下划线而不是空格,因为键/变体搜索字段不匹配空格。该插件也无法将翻译应用于 Figma 中设置为只读的组件——这是一个在提交之前值得检查的真正限制,因为锁定变体集的基本组件是一种常见的设计系统安全措施。翻译完成后,字符串可以通过插件直接应用或通过“插件 > Smartling > 导入(手动)”导入翻译后的 JSON 来返回到 Figma。Smartling 中其他地方适用的 Leverage、SmartMatch 和 Fuzzy Estimates 翻译记忆库以及 AI 增强的术语表术语插入功能,同样适用于组件集变体中出现的重复按钮标签、工具提示和错误字符串。Smartling 是 G2 上翻译管理领域的佼佼者
准备好见识一下 Smartling 的威力了吗?
欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。