软件本地化的难点

Source: Dev.to

本地化很少仅仅是翻译。一旦支持多于一种语言，每一次 UI 更改都需要额外的关注。译者需要上下文，占位符必须保持正确，UI 必须能够容纳更长的文本，并且审查必须及时进行，以免发布延误。小问题容易被忽视，而且往往在后期才显现，此时修复成本更高。

根据我的经验，最困难的部分是将本地化作为构建和交付产品的常规环节。本篇文章介绍了在多语言项目中最常浪费时间的问题，以及帮助团队减少意外、顺利交付的实践。

Collaboration

协作在每个软件团队中都至关重要，但本地化提升了难度。你需要在不同角色之间、常常跨时区进行协调，细小的延迟或不明确的决策很快会导致大量返工。当所有权不清晰时，同一字符串会被多次重写，决策在每次评审中都会被重新打开，导致难以判断哪些内容已经真正可以发布。

以下是本地化工作中反复出现的两个协作问题。

1. 前期没有共享计划

设计 可能在优化语调和 UI 适配，工程 可能在优化实现和复用，而翻译人员只能猜测你真正的需求。结果可预见：重复翻译、冗长的评审讨论以及用词不一致。

帮助方法 是在翻译开始前就对齐。将以下决策明确下来：

• 语调与风格（正式 vs. 非正式，友好 vs. 技术）
• 关键术语（功能名称和产品概念）
• UI 限制（文本出现的位置，是否需要换行，关键情况下的最大长度）
• 最终批准人（产品经理、设计师或本地化经理）

你仍然会迭代，但拥有统一的方向可以消除大部分可避免的返工。

2. 工作流缺失或过于繁重

没有清晰的工作流时，基本问题难以回答：哪些内容已翻译，哪些已更改，哪些被阻塞，谁负责最终签字？ 工作流过于严格时，本地化会成为每一次小改动的阻碍。

帮助方法 是制定一个简单的流程，让所有人都能遵循，并随着时间自动化：

1. 添加或修改字符串
2. 通知翻译人员
3. 完成翻译
4. 进行评审
5. 本地化质量检查
6. 发布

翻译错误

即使拥有优秀的译者和完善的流程，问题仍然会出现。棘手之处在于，很多问题并不是“语言错误”。它们是 集成问题：文本本身是正确的，但在 UI、功能或你的应用所期望的格式规则下却不合适。我看到的最常见的问题可以归为以下五类。

1. 缺乏上下文的翻译

交付字符串的方式很重要。如果译者只看到一个仅包含孤立文本的 CSV，他们就只能猜测：

• 字符串的使用场景（按钮、标题、提示、验证错误）
• 功能到底是做什么的
• 你想要的语气（正式还是随意）
• 占位符的含义以及它们的行为（{count}、%s、{name}）

这种猜测会导致来回沟通、重复翻译以及用词不一致。

帮助方法 是在交付字符串时附带上下文。如果可能，使用支持以下功能的 TMS（翻译管理系统）：

• 每条字符串的描述或开发者备注
• 截图或 UI 预览
• 术语表和已批准的词汇
• 翻译记忆库和审校步骤

市面上有很多工具可以实现这些功能。关键是选择一个能够集中本地化工作、让协作变得轻松，并在同一平台上管理字符串、上下文和审校的工具。Localizely 对我来说效果不错，但任何支持此工作流的工具都可以。

2. 语法和格式错误（ICU、复数、占位符）

ICU 消息格式和占位符很容易被破坏。缺少一个大括号或重命名了 token，可能导致生产环境中出现原始的 {count}，甚至在最坏情况下触发运行时错误。

帮助方法 是在发布前捕获这些错误：

• 及早验证 ICU 语法和占位符
• 将占位符不匹配设为硬错误
• 使用能够强制执行复数规则和必需变量的平台或工具

3. 文本长度不适配 UI

不同语言的文本长度差异很大。英文下恰好的文字在德文或法文中往往会溢出，导致截断、元素重叠或在布局紧凑时出现尴尬的换行。

帮助方法：

• 告诉译者长度重要时的限制是什么
• 为按钮和导航项提供更短的备选方案
• 在字符串旁保留备注，例如 “按钮标签，最多 12 字符”
• 尽可能进行伪本地化和基于截图的 UI 检查

许多 TMS 也能通过存储备注并标记超出字符限制的字符串来提供帮助。

4. 硬编码文本未进入翻译流程

这是经典的“多数已本地化”产品问题：某个界面仍是英文，邮件模板未本地化，或横幅图片中的文字使用了错误语言。通常是因为这些文本不在常规的字符串管道中。

常被遗漏的地方：

• 代码常量和共享 UI 组件
• 图片和横幅
• PDF 文档
• 邮件内容
• 推送通知
• 最终呈现在 UI 中的后端错误信息

帮助方法 是将其视为 QA 检查项，对所有面向用户的呈现层进行审计，而不仅仅是应用 UI。

5. 跨产品保持术语一致性

用户对不一致的术语比对细小的语法错误更敏感。如果 “Workspace” 在 UI、入门指南和文档中被翻译成三种不同的说法，产品会显得不够精致。

帮助方法：

• 为关键概念维护术语表或词库
• 使用翻译记忆库并加入真实的审校步骤
• 明确谁负责术语管理，避免每次发布都重新争论

一致性能够建立信任，降低认知负荷，尤其在复杂产品中尤为重要。

SEO 问题

(内容在原始片段中被截断。请在此添加有关本地化 URL、元标签、hreflang 和站点地图处理的相关要点。)

本地化的技术 SEO

本地化不仅是内容任务；它也是一个技术 SEO 项目。常见的失败模式是翻译页面，却没有为搜索引擎提供正确的结构和信号，以便正确索引每个语言版本。其结果可能是内容重复、错误语言在错误国家的排名，或本地化页面根本无法被发现。

有助于成功的做法

• 选择一种 URL 策略并坚持使用，例如 /de/ 或 de.example.com。
• 实施 hreflang 让 Google 知道向哪些用户提供哪个语言版本。
• 不要 基于请求头或 Cookie 从同一 URL 提供多种语言。这会导致爬取困难且容易出现误索引。
• 本地化标题、描述和结构化数据，并针对每个语言进行关键词研究。直接翻译往往会错过该市场用户实际搜索的词汇。

难以衡量本地化投资回报率

本地化通常是有回报的，但用数据证明可能比预期更难。主要问题是归因：本地化间接影响获取、激活和转化，且影响往往在数周或数月后才显现。

有帮助的做法

• 在每个地区预先定义成功指标，并确保跟踪能够支持这些指标。查看地区特定的登录页面、漏斗、事件，以及热图和会话录制等定性信号。
• 能够的话以受控方式推出。先从一个市场开始，对比前后 cohort，或进行地域实验。
• 将本地化视为产品投资。预测预期的提升，提前衡量流量和注册等领先指标，并接受收入提升可能会滞后。

结论

本地化之所以困难，并不是因为翻译文本本身困难，而是它贯穿整个产品。它出现在工程和构建流水线、设计和布局、产品决策、质量保证、发布管理、SEO，甚至是衡量成功的方式上。耗时最多的问题往往是可以避免的：缺少上下文、所有权不明确、字符串格式脆弱、UI 约束，以及在不减慢交付速度的前提下保持高质量。

对我而言，最始终有效的做法是把本地化视为一个 持续的系统，而不是一次性项目。这意味着：

• 明确的职责分工
• 轻量但真实的工作流
• 对 ICU 和占位符的提前验证
• 可靠的本地化质量保证
• 共享的语气和术语规则

有了这些基础，添加新语言就会成为可重复的流程，而不是临时的紧急演练。

希望这能帮助你避免一些常见的陷阱，以更少的意外推出多语言功能。