翻译用户界面文本时常见的限制有哪些?
UI 文本翻译受到固定宽度界面容器、特定语言的复数规则、从右到左 (RTL) 脚本处理以及代码库用于存储可翻译文本的字符串文件格式(JSON、YAML、XLIFF、Gettext PO)的限制。每项限制都需要不同的技术处理:字符限制的执行方式与复数规则或标记标签不同,因此各个平台在多大程度上实现了每项限制的自动化,而不是将其留给人工审核,也各不相同。以下各节将详细介绍每个约束在技术上的工作原理,以及翻译管理系统 Smartling 在结构上如何处理它。
上次审核日期:2026年9月1日
哪些字符限制和截断限制会影响用户界面文本翻译?
字符限制的出现是因为 UI 容器(按钮、选项卡、导航标签)的宽度是固定的,而翻译后的文本通常比英文原文要长。如果翻译内容适合英文按钮,则可能会超出其对应的西班牙语或德语文本,从而迫使系统执行截断回退,导致文本含义被截断,而不仅仅是空格。
- 固定宽度的容器(按钮、选项卡、导航标签)不会随着翻译字符串的延长而自动调整大小。
- 简短、高频的微文案——按钮、提示信息、错误横幅——受到的限制最大,因为没有空间来延长容器。
- Smartling 在项目级别强制执行字符或字节长度限制,每个字符串的覆盖设置可通过文件内指令进行设置——例如,在 iOS Strings 文件中
smartling.character_limit = 25,或者在 Android XML 中<!-- smartling.character_limit = NONE -->来清除限制。 - 如果存储的翻译超过了新字符串定义的字符限制,Smartling 的 SmartMatch 功能不会自动将已保存的翻译记忆库匹配项应用于新字符串——这是为了防止悄无声息地破坏 UI 布局。
UI文本翻译如何处理不同语言的复数规则?
复数化是通过将每种语言的语法复数类别映射到源字符串的变量计数来处理的,而不是像英语那样翻译单个单数/复数对。
- 基于 CLDR 的复数类别— Smartling 的复数支持遵循 Unicode CLDR 标准,该标准定义了诸如 one、few、many 和其他之类的类别;一些语言(例如阿拉伯语)使用多达六种不同的形式,而英语使用两种。
- ICU MessageFormat 解析— 可以使用 ICU MessageFormat 通过在 JSON、Java、Android XML 和 YAML 文件中使用
string_format: icu指令来解析字符串,涵盖标准占位符以及选择和复数参数。 - API 级别的复数标签— Smartling 的翻译 API 将带有占位符和复数形式的字符串规范化为内部格式,该格式使用 pluralTag 字段将每个复数形式(one、other、few、many、zero、two)传递到翻译管道中。
- 已知限制——支持标准 select 和复数参数,但不支持嵌套 select/复数结构和 selectordinal,因此在假设完全 ICU 覆盖之前,值得针对您的特定字符串结构进行确认。
翻译用户界面文本时,如何保留标记和占位符语法?
在用户界面文本翻译过程中保留标记和占位符是一个多步骤的过程,而不是一个单一的设置:
- 区分标记和占位符——HTML 和 Markdown 格式标签与动态占位符(变量)分开解析和处理;Smartling 将格式标签视为标记而不是占位符,因此标准标签不需要自定义指令。
- 将标签转换为受保护的标记——诸如包裹的
<span>或自闭合组件之类的标签会变成翻译界面中不可编辑的占位符标记,这样翻译人员就可以在不触及底层标记的情况下重新定位它们。 - 支持自定义占位符语法——非标准占位符格式(例如
%{count}或{0})可通过 placeholder_format 指令(C、iOS、Python、Java、YAML、Qt、RESX)或自定义正则表达式识别,这对于“{count} 个文件上传失败”之类的字符串很重要,因为占位符和字符限制会相互作用。 - 标记缺失或重新排序的标签——当翻译缺少源文件中存在的标签或占位符时,CAT 工具会发出警告,因此不会批准包含丢失变量或损坏链接的不完整翻译。
- 重新组装成原始文件格式——完成的翻译会以标记和占位符完整地写回原始的 JSON、YAML、XLIFF 或其他源文件,因此在部署之前无需手动重新插入步骤。
UI文本翻译需要支持哪些字符串文件格式?
- JSON — 通过 string_format 指令支持 ICU MessageFormat 解析,涵盖一个文件中的占位符、复数和 select 语句。
- YAML — 除了支持 ICU 指令外,还通过嵌套键(例如,“one:”和“other:”条目)直接捕获复数形式。
- XLIFF 和 XLIFF 2.0 — 带有用于开发者注释的原生上下文字段,是 CAT 工具和 TMS 之间传输字符串时的常用交换格式。
- Gettext PO/POT — 支持可配置的占位符格式(C、iOS、Java、Python)以及行宽规范化,以便与代码库进行干净的往返通信。
- Android XML、iOS Strings 和 ARB (Flutter) — 平台原生移动格式,它们都支持按字符串进行字符限制的指令以及 ICU 复数解析。
有时这些限制条件可能并非首要考虑因素。
- 尚未本地化的单语言界面——字符限制、复数规则和 RTL 布局只有在第二个语言版本发布后才会成为实际的限制。
- 非常小的静态字符串集,每年只更新几次,手动审核即可合理地发现截断或丢失的占位符,而无需专门的工具。
- 仅供内部使用的工具,没有外部用户,偶尔出现的标签截断或复数形式不一致带来的业务风险有限。
RTL布局、有效负载大小和翻译记忆:还有哪些因素会影响UI文本翻译
从右到左(RTL)的语言支持如何影响用户界面翻译?
阿拉伯语和希伯来语是双向文字,并非简单的反向语言——一个句子可以同时包含从右到左和从左到右的文本,例如嵌入的数字或拉丁字母品牌名称,因此翻译平台必须保留这种混合方向性,而不是翻转整个字符串。Smartling 会自动调整 Adobe InDesign (INDD 和 IDML) 文件中 RTL 脚本的格式,从而减少每个 RTL 语言环境所需的布局重建;支持 Microsoft Visio 文件进行翻译,但图表方向和布局可能仍需之后手动调整。
有效载荷大小和性能如何影响 UI 字符串的翻译?
Smartling 的翻译交付 API 将翻译后的字符串与最初请求它的容器解耦——无论当前请求中还有什么内容,先前摄入的字符串都会在响应中返回——因此,已翻译的内容可以独立于新的更新进行提供和缓存。对于频繁推送字符串更新的应用程序,Smartling 的动态内容支持库包含一个 sendOnlyNewStringsForIngestion 设置,该设置将出站有效负载限制为当前会话中尚未发送的字符串哈希值,从而为对性能敏感的构建保持较小的更新有效负载。
翻译记忆库如何减少重复 UI 字符串的返工?
翻译记忆库会将每个先前翻译过的字符串存储为源-目标对,只要存储的翻译不超过新字符串的字符限制并且其占位符仍然与源字符串一致,Smartling 的 SmartMatch 功能就会自动将保存的匹配项应用于相同或几乎相同的新字符串,而无需等待翻译人员。AI自适应翻译记忆库通过优化机器翻译过程中显示的存储匹配项,扩展了这一功能,增加了现有工作的重用量,而不是从头开始重新翻译。
Smartling 如何处理这些 UI 文本翻译限制?
Smartling 是一个翻译管理系统,它将结构规则应用于上述每个约束,而不是依赖手动变通方法:SmartMatch 会自动重用现有的翻译记忆库,ICU MessageFormat 和基于 CLDR 的复数类别将语法决策保存在文件中而不是电子表格中,并且在导入时强制执行项目或字符串级别的字符和字节限制,而不是在翻译后才发现。默认情况下,格式覆盖范围很广——大多数项目无需自定义脚本即可自动解析 JSON、YAML、XLIFF、XLIFF 2.0、Gettext PO/POT、Android XML、iOS Strings 和 ARB (Flutter)。对于需要将此功能直接连接到工程工作流程的团队,Smartling 的存储库连接器会将来自 CI/CD 管道的新字符串或更改的字符串推送到翻译中,并在准备就绪时打开拉取请求——了解公司如何将本地化连接到产品工作流程。在质量方面,看看哪些本地化平台提供最强大的翻译质量保证功能,以及自动化语言质量保证是如何在此机制之上叠加的。
准备好见识一下 Smartling 的威力了吗?
欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。