在之前的一篇文章里，我们总结了公司做好产品本地化翻译面临的三大难题：公司内的不同部门互为孤岛，系统之间缺乏集成，缺乏标准化的翻译流程。
管理一家大型软件公司的本地化，是一项很有挑战性的工作。而要实现敏捷本地化，背后的挑战就更大了。无论公司规模大小，转向敏捷本地化，都需要对整个工作流程进行大幅度调整，而且这项工作不仅会涉及到本地化部门，更会联动开发工程师、产品经理等等相关上游岗位的同事。
俄罗斯计算机安全产品企业卡巴斯基就实施了敏捷本地化改造，公司文档和本地化团队的 Ekaterina Galitskaya 和 Darya Egorushina 详细讲述了他们使用在线工具，更可靠、更灵活和更自动化地实现移动产品本地化，提升本地化能力和效率的过程。
她们的分享十分详尽，其中提到的很多产品本地化的痛点，也同样是国内大小科技公司正在面对的。后半部分对于本地化项目管理时间成本的统计，则直观地说明了流程设计、用对工具提升效率、节约成本的巨大作用。
我们团队负责为公司的移动安全应用编写界面文案和帮助中心文章，同时完成这些内容的本地化。我们将在本文中向大家介绍一下我们当初面临的痛点、实现敏捷本地化过程中面临的挑战，以及我们最后采用的解决方案。
与许多其他公司一样，卡巴斯基也在此前转向了敏捷开发，因此产品发版周期大大缩短，以前每隔几个月才发布一次新版本，现在变成了每两周一次。大家可能会觉得，现在每个新版本中的字符串数量变少了，工作会不会变轻松呢？事实上并没有：我们仍然必须让这些字符串完成整个本地化翻译和语言测试的过程，但给我们的时间却更少了。
还有一种常见的误解，认为移动应用里的文本量不大。我们也想啊！但并不是。拿卡巴斯基举例，每个应用的界面文本量就有大约 25000 个单词，然后我们有大约 10 个应用，然后每个应用需要翻译成近 20 种不同的语言。除此之外，每星期我们都会接到新的界面文案和文档。
结果本地化翻译事实上成为了整个发版过程中的瓶颈。产品经理甚至都叫不出本地化团队成员的名字，因为在他们看来，所有翻译都是「一下子就能神奇地完成」。但在实施敏捷本地化项目的过程中，他们意识到，所有本地化相关的问题其实都比自己预想得更复杂。
以上便是产品本地化面临的第一个「拦路虎」：企业内部对本地化工作的认知不足。「本地化环节成为瓶颈」，其实是对产品本地化工作定位错误/整体性认识不够造成的必然结果，并非一定是本地化部门/团队的失职。
——产品本地化实务
卡巴斯基的本地化通常包括两个阶段：翻译和语言测试。
翻译阶段面临的问题是，由于工作流程和 CAT（计算机辅助翻译）工具的限制，需要人工操作的工作量太大。具体而言：
对于涉及到多个岗位和内外部环节的工作，大量人工操作的事务性工作会给最终交付的质量留下很多隐患。
——产品本地化实务
文本翻译可能三到五天就能完成，但之后的语言测试流程却会长达两周。你可能会问：「语言测试到底是什么？」
语言测试的主要目的，是把翻译导入到产品中，查看是否有不符合界面语境的翻译错误。我们的翻译团队水平确实过硬，而且对我们的术语了如指掌，但在不知道整个界面长什么样子的情况下翻译，或者仅仅是翻译一个按钮或标题的文案，很容易出现翻译错误。
因此在语言测试环节，我们通常会通过屏幕截图，由人工检查所有应用界面。这能让我们发现很多问题，比如：
产品本地化翻译质量好坏，除去译者水平因素，最大的决定因素就是「上下文」，而为译者提供字符串对应的上下文，仰仗的就是产品本地化整体工作流程的设计。
——产品本地化实务
光是截图就会花掉大量时间。如果一项新功能涉及到 40 屏的界面，并且需要翻译成 20 种语言，可能花费需要 70 个小时的人工。
如果像之前三个月发布一次新版本，这些工作可能还可以忍受，但现在我们是两周发布一版，所以这一切让本地化团队不堪重负。必须尽快改变这种情况。
我们当时有两个选择：
我们选择了后者。
选择 CAT/TMS 解决方案时，我们没有选用需要在公司和译者端配置服务器端和客户端的本地化解决方案，而是选择了集成现成的在线工具，希望实现以下一些目的：
为了更好地体现差异，我们把敏捷本地化项目实施前后在工作流程和效率方面的提升都详细列在了下面。
实施敏捷本地化项目前，我们完成翻译和语言测试需要经历将近 30 个步骤：
翻译：
语言测试：
现在，我们整个本地化翻译只需要 9 步：
整个本地化翻译过程结束！项目整体复杂度降低了三分之一，我们团队的工作和之前相比简直有了云泥之别！
所有数字都指的是每次发布一款应用的新版本（两周一次）时，本地化流程所需要的时间（以小时计）。
| 步骤 | 之前 | 现在 |
|---|---|---|
| 从所有分支里提取字符串 | 1 | - |
| 提取增量字符串，并将它们上传到 CAT 工具 | 4 | 0.25 |
| 创建 20 多种语言的翻译工作包 | 0.5 | - |
| 将 20 多种语言的翻译工作包上传到 FTP 服务器 | 0.5 | - |
| 与 20 多种语言的翻译供应商/译者沟通，确认他们可以开始工作 | 2-3 | 2-3 |
| 在翻译平台把任务分配给翻译供应商/译者 | - | 0.25 |
| 回答译者的问题 | 2-4 | 0.5 |
| 审阅和确认翻译 | 1 | 0.25 |
| 编译程序包 | 最多 8 小时 | 0.25 |
| 增量翻译 | 8 | 0.25 |
| 获取截图 | 16-32 | 8（使用自动截图工具） |
| 将截图上传到 FTP 服务器 | 8 | 1 |
| 与翻译供应商/译者沟通，最终敲定翻译 | 8 | 1 |
| 更新资源文件 | 8 | 2 |
| 将更改写入代码库 | 8 | 0.25 |
| 每个应用的每个版本需要的总时间 | 84 小时 | 最多 17 小时，节省了 77%！ |
在采用了敏捷本地化流程之后，我们还收获了更多益处：
相信随着时间的推移，我们还会找到其他方法来提升卡巴斯基本地化的效率和质量。最重要的是，本地化再也不会成为版本发布的瓶颈了。
以下是我们采用在线 CAT/TMS 工具后采取的一些具体做法，放在这里供大家参考。这些做法有些做起来并不容易，但都有助于让本地化流程更顺畅、更不容易出错。
希望这些信息能帮到大家！
如果你是在科技公司里接触过或者直接从事产品本地化/翻译项目管理的同学，不妨来填一下这个问卷，咱们一起来总结出中国科技公司面临的产品本地化难题和痛点。调查结果将择期在「产品本地化实务」与大家分享 😃
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。