在之前的一篇文章里，我们总结了公司做好产品本地化翻译面临的三大难题：公司内的不同部门互为孤岛，系统之间缺乏集成，缺乏标准化的翻译流程。

管理一家大型软件公司的本地化，是一项很有挑战性的工作。而要实现敏捷本地化，背后的挑战就更大了。无论公司规模大小，转向敏捷本地化，都需要对整个工作流程进行大幅度调整，而且这项工作不仅会涉及到本地化部门，更会联动开发工程师、产品经理等等相关上游岗位的同事。

俄罗斯计算机安全产品企业卡巴斯基就实施了敏捷本地化改造，公司文档和本地化团队的 Ekaterina Galitskaya 和 Darya Egorushina 详细讲述了他们使用在线工具，更可靠、更灵活和更自动化地实现移动产品本地化，提升本地化能力和效率的过程。

她们的分享十分详尽，其中提到的很多产品本地化的痛点，也同样是国内大小科技公司正在面对的。后半部分对于本地化项目管理时间成本的统计，则直观地说明了流程设计、用对工具提升效率、节约成本的巨大作用。

我们团队负责为公司的移动安全应用编写界面文案和帮助中心文章，同时完成这些内容的本地化。我们将在本文中向大家介绍一下我们当初面临的痛点、实现敏捷本地化过程中面临的挑战，以及我们最后采用的解决方案。

面临的痛点

与许多其他公司一样，卡巴斯基也在此前转向了敏捷开发，因此产品发版周期大大缩短，以前每隔几个月才发布一次新版本，现在变成了每两周一次。大家可能会觉得，现在每个新版本中的字符串数量变少了，工作会不会变轻松呢？事实上并没有：我们仍然必须让这些字符串完成整个本地化翻译和语言测试的过程，但给我们的时间却更少了。

还有一种常见的误解，认为移动应用里的文本量不大。我们也想啊！但并不是。拿卡巴斯基举例，每个应用的界面文本量就有大约 25000 个单词，然后我们有大约 10 个应用，然后每个应用需要翻译成近 20 种不同的语言。除此之外，每星期我们都会接到新的界面文案和文档。

结果本地化翻译事实上成为了整个发版过程中的瓶颈。产品经理甚至都叫不出本地化团队成员的名字，因为在他们看来，所有翻译都是「一下子就能神奇地完成」。但在实施敏捷本地化项目的过程中，他们意识到，所有本地化相关的问题其实都比自己预想得更复杂。

以上便是产品本地化面临的第一个「拦路虎」：企业内部对本地化工作的认知不足。「本地化环节成为瓶颈」，其实是对产品本地化工作定位错误/整体性认识不够造成的必然结果，并非一定是本地化部门/团队的失职。
——产品本地化实务

卡巴斯基的本地化通常包括两个阶段：翻译和语言测试。

翻译阶段

翻译阶段面临的问题是，由于工作流程和 CAT（计算机辅助翻译）工具的限制，需要人工操作的工作量太大。具体而言：

• 由于我们原先使用的工具不支持多分支产品本地化流程，我们必须手动创建用于翻译的增量包，然后在翻译完成后将它们推回分支里
• 不同应用和每种语言翻译的一致性难以保证
• 如果在翻译启动之后源文本发生更改，我们无法同步进行额外内容的翻译，必须要等上一个版本的翻译就绪，才能进行额外内容的翻译
• 变量、URL 等源文本中不应被翻译的元素被错误地翻译、撇号（'）未被转写成「\'」，再加上其他人为失误，经常导致代码编译时发生错误

对于涉及到多个岗位和内外部环节的工作，大量人工操作的事务性工作会给最终交付的质量留下很多隐患。
——产品本地化实务

语言测试阶段

文本翻译可能三到五天就能完成，但之后的语言测试流程却会长达两周。你可能会问：「语言测试到底是什么？」

语言测试的主要目的，是把翻译导入到产品中，查看是否有不符合界面语境的翻译错误。我们的翻译团队水平确实过硬，而且对我们的术语了如指掌，但在不知道整个界面长什么样子的情况下翻译，或者仅仅是翻译一个按钮或标题的文案，很容易出现翻译错误。

因此在语言测试环节，我们通常会通过屏幕截图，由人工检查所有应用界面。这能让我们发现很多问题，比如：

• 译文超长
• 如果免责声明或财务信息漏译，有时候还会有法律风险
• 文本未被翻译，显示英文原文——这背后的原因可能是译者出错，也可能是文案文本被直接写入了代码中，没有外部化成字符串
• 不了解上下文导致的翻译错误，比如按钮上的「Download」本应翻译成「请下载」，却被错翻成了「下载」

产品本地化翻译质量好坏，除去译者水平因素，最大的决定因素就是「上下文」，而为译者提供字符串对应的上下文，仰仗的就是产品本地化整体工作流程的设计。
——产品本地化实务

光是截图就会花掉大量时间。如果一项新功能涉及到 40 屏的界面，并且需要翻译成 20 种语言，可能花费需要 70 个小时的人工。

如果像之前三个月发布一次新版本，这些工作可能还可以忍受，但现在我们是两周发布一版，所以这一切让本地化团队不堪重负。必须尽快改变这种情况。

我们当时有两个选择：

1. 请一批本地化新手来完成事务性工作，同时降低需要进行本地化翻译的内容量——很明显，这都会影响我们产品最终的本地化质量
2. 实现工作流程自动化

我们选择了后者。

使用在线 CAT/TMS 工具的好处

选择 CAT/TMS 解决方案时，我们没有选用需要在公司和译者端配置服务器端和客户端的本地化解决方案，而是选择了集成现成的在线工具，希望实现以下一些目的：

1. 更少的内部审批和许可步骤，避免预算审批、生成软件序列号等等琐事
2. 上手就能用的基本功能，我们可以马上开始使用，无需等待功能开发配置
3. 轻量级的服务器要求——这也是为了避免冗长的内部项目审批流程
4. 价钱合理，最好是免费的——至少可以免费使用
5. 客户支持充分，我们不必内部找人来维护系统
6. 满足安全要求，我们连接别人的服务相对比较方便，因为让别家服务接入我们的系统，需要复杂的审批流程
7. 多分支产品支持，可以同步翻译多个功能模块的内容
8. 支持增量翻译，从而可以让新旧内容翻译同时推进
9. 可以自定义字符串解析规则，尽可能多地把对译者翻译有帮助的内容传递到位
10. 我们可以在翻译平台内与译者沟通
11. 我们可以随时在翻译平台上找到更多的自由译者，提升我们的产能
12. 我们可以通过一张收据支付所有语言和项目的费用，避免一个项目多次报账审批的情况

敏捷本地化项目实施前后对比

为了更好地体现差异，我们把敏捷本地化项目实施前后在工作流程和效率方面的提升都详细列在了下面。

工作流程

项目实施前

实施敏捷本地化项目前，我们完成翻译和语言测试需要经历将近 30 个步骤：

翻译：

1. 从代码库的不同分支手动提取要翻译的文本
2. 手动筛选增量待译文本
3. 把待译文本打成包
4. 把文件包上传到 FTP 服务器
5. 给翻译供应商、自由译者或我们在各地的同事写一大堆电子邮件
6. 翻译完毕后，从 FTP 服务器上把译文下载下来
7. 把翻译加载到 CAT 工具里，确保一切正常
8. 将翻译后的字符串手动上传到代码库，而且还要确保不能混淆各个分支
9. 初步编译程序包，修正错误，最后完成编译
10. 提交增量翻译——事实上就是把以上整个流程再跑一遍

语言测试：

1. 开始编译程序包，等它完成
2. 如果由于本地化翻译错误无法编译，就重新编译一次
3. 如果应用没有调试菜单，就需要配置专门的测试环境
4. 把 20 种语言的所有相关界面都截好图
5. 和 QA 团队一起弄明白要怎样找到仍然缺失的界面截图
6. 创建和命名截图包
7. 把截图包上传到 FTP 服务器
8. 将任务分配给翻译供应商，请他们检查翻译
9. 回答供应商和译者的问题
10. 接受修正建议并调整翻译
11. 编译程序包（有时候会花很长时间）
12. 如果编译错误，就再编译一次
13. 再次截图，为二次测试做准备
14. 再次上传截图并将任务分配给翻译供应商
15. 再次和供应商沟通各种事情
16. 如果翻译有调整，就再做一次测试

项目实施后

现在，我们整个本地化翻译只需要 9 步：

1. 产品文案在代码库中提交新字符串，字符串被自动解析并发到在线 CAT/TMS 工具
2. 本地化项目经理指派任务给译者
3. 在界面截图和开发人员留言的帮助下，译者完成翻译
4. 本地化项目经理检查并确认翻译，然后翻译自动返回到代码库
5. 本地化团队运行自动截图工具，把含有译文的界面保存下来
6. 本地化团队将截图放到 FTP 服务器上，发给负责语言测试的译者
7. 译者对照截图检查翻译，并在必要时修正翻译
8. 修正后的翻译自动返回代码库
9. 本地化团队在代码库中关闭拉取请求

整个本地化翻译过程结束！项目整体复杂度降低了三分之一，我们团队的工作和之前相比简直有了云泥之别！

前后效率对比

所有数字都指的是每次发布一款应用的新版本（两周一次）时，本地化流程所需要的时间（以小时计）。

其他好处

在采用了敏捷本地化流程之后，我们还收获了更多益处：

• 更可靠的编译过程：多亏在线 CAT 工具支持占位符锁定，我们不用再担心出现不需要翻译的文本被翻译，或者撇号没做转写等等问题。
• 由于翻译工具能标记出关键错误，我们还发现了此前翻译中存在的一些问题。
• 不再浪费别人的时间和资源：我们不需要再向 QA 团队借测试机，也不需要再耗费开发团队的时间完成界面截图工作了。
• 译者可以直接在翻译界面打开和查看界面截图，极大地提高了翻译质量。

相信随着时间的推移，我们还会找到其他方法来提升卡巴斯基本地化的效率和质量。最重要的是，本地化再也不会成为版本发布的瓶颈了。

一些实用建议

以下是我们采用在线 CAT/TMS 工具后采取的一些具体做法，放在这里供大家参考。这些做法有些做起来并不容易，但都有助于让本地化流程更顺畅、更不容易出错。

流程整合方面

• 要提前测试代码库和在线 CAT/TMS 工具之间的连接，确保所有字符串都能正确地发送到后者，并在翻译完成后正确地返回，这样才不会到了产品上线的时候发生意外。
• 和工程师统一代码分支命名规则，以便利用程序自动查找需要翻译的特定分支，节省本地化团队和开发人员大量沟通的时间。
• 如有必要，请自定义字符串解析器。例如，在卡巴斯基，我们会把字符串 id、开发者留言和界面截图的链接发送给译者。
• 创建一个定期任务，根据上面和工程师商定的命名规则来查找需要本地化的分支。
• 考虑使用 Kaspresso 框架进行 UI 测试和功能截图。例如，我们的开发人员会为他们用到的每个字符串加上界面截图的链接。当文件被发送到 CAT 工具时，截图链接会自动出现在注释选项卡中。大家可以在这里阅读更多关于 Kaspresso 的信息。

本地化和语言测试方面

• 如果你们已经有现成的术语表，请将它们上传到 CAT 工具，确保翻译的一致性。
• 把公司内部的本地化译者（如果有的话）添加到 CAT 平台上的项目里，让他们在真正着手翻译之前熟悉工具的用法。
• 寻找并筛选自由译者，通过前期培训让他们了解公司的流程，确保他们知道如何使用界面截图、开发人员留言、术语表等功能。
• 必要时，可以寻找翻译供应商完成其他本地化或测试任务。

希望这些信息能帮到大家！

如果你是在科技公司里接触过或者直接从事产品本地化/翻译项目管理的同学，不妨来填一下这个问卷，咱们一起来总结出中国科技公司面临的产品本地化难题和痛点。调查结果将择期在「产品本地化实务」与大家分享 😃