行业观察 | 舜禹环球通：什么是持续本地化？

容易忽视的开发瓶颈

上世纪八九十年代，为了更好地协作开发大型程序，出现了相对固定的软件开发流程：软件开发人员花费数周或数月编写代码，再由QA团队进行测试，最后将发布的产品交由运营团队部署，即经典的“瀑布模型”。该模型的特征为各步骤按部就班，产品完整度高，但开发时间较长，容易和用户需求出现偏差，导致大量成本损耗。

为了避免这些问题，在本世纪初，“敏捷模型”出现了：先划分一个个小需求，然后针对性地开展开发和测试，从而使版本间的发布间隔得以大幅降低，让产品能持续根据用户反馈开展调整。

随着互联网的兴起，同类产品的竞争日趋激烈，于是出现了“DevOps”概念，将运营也纳入了敏捷开发流程，让产品在快速迭代的同时，还能迅速占领市场和用户心智。要实现这一点，就需要持续地开发、集成、测试、部署和监控，并需要新版本时刻都可上线。

这一切都需要严密的流程及现代化的工具作为支撑。

但是，界面词 (UI) 作为产品必不可少的一部分，其翻译过程还处于原始阶段：据一项调查显示，18.5%的团队用Excel来传输多语言字符串；有48.1%甚至没有用任何工具，就是文本传来传去。而如今，界面词的内容时刻都在更新，如果都用手动的方式导入导出，再本地化成十几种语言，那么该产品的产品经理或运营除了收发文件，别的活都没时间干了。

如果让专人去串联开发团队和翻译公司，一切按手动的方式解决，不难想象，这名员工也将陷入无止境的沟通、确认、协调之中，而没有时间站在更高的角度对整体进行质量、时间及风险等方面的控制。由于本地化通常位于开发流程的靠后环节，用于评估质量的时间本身就少，而若本地化效果不好，又会对用户体验有非常大的负面影响，因此，若缺乏整体规划，本地化的效果就存在相当大的不确定性。如果存在政治敏感类的问题，还有可能会带来更严重的后果。这样，本地化甚至会成为开发瓶颈。

要如何突破呢？

持续本地化

试想若存在以下流程：

1. 新的/更新的代码（包括界面词之类的资源文件）被推至内容来源（如代码仓库）。

2.需要更新的资源文件被自动识别出来并被推至TMS（翻译管理系统）。

3. 译员登录TMS翻译。

4.翻译完成后的资源文件被推至原来的内容来源，并与原来的资源文件合并。

即，用自动化的方式进行文件的转换和流转，让资源文件的本地化一直处于持续生产和交付的状态。

这就是“持续本地化”：它在开发环境和翻译环境间架起了桥梁，通过自动化的方式，将人从事务性的工作中解放出来，并将开发和翻译的关系从串行变为并行。

持续本地化也存在着独特的挑战。当然，专业的语言服务商，搭配合适的TMS，便可以有效应对：

挑战一：双向连接

TMS并非为界面词本地化量身定制。毕竟，在本地化世界中，界面词只占待译内容的一小部分——更多的是文档、表格、书籍、多媒体等等，这些内容载体有着自身的复杂度。为了处理它们，TMS已经比较臃肿了。何况，TMS还要考虑和CAT（计算机辅助翻译工具）的连接，毕竟真正干活的是译员，如果连接性差而影响到译员，TMS不会受到欢迎。因此，在本世纪初，TMS较少与内容来源连接，因为当时资源文件基本是离线文件，线下发送即可。当时也有一些中间件与TMS连接，但中间件作为第三方软件，有着不稳定、更新慢等劣势，根本的解决之道还是将TMS直接与内容来源连接。

如今，市面上支持连续本地化的TMS（如Lokalise），与大多数内容来源可以做到无缝连接——内容来源的任何变化，都会在TMS中自动转化成待译任务；同时，界面、操作都对译员相当友好。

挑战二：见微知著

界面词大多短小精悍，并且和具体环境共同呈现才能传递完整信息。让译员直接翻译难度挺大。因此，开发团队有义务加入尽可能多的额外说明给译员，并在译员有疑问时及时解答；译员也需要下载相应产品，打开实际的界面亲自操作，尽快熟悉起来。这样，从一段不明就里的词汇组合，加上一些语焉不详的描述，才能推出大致的使用场景，从而选择合适的译文。

现在市面上有的TMS（如Gridly）支持多媒体内容（如图片、音/视频）的自动化推送，这样译员在TMS中便可以实时待译文字的上下文，提升效率和准确率。

挑战三：人才难觅

对译员而言，界面词属于那种忙活半天，进度条却没啥变化的内容。而且，这种内容并非偶发，而是可能天天会有。让译员只啃骨头不喝汤，肯定难以为继，这就是考验语言服务商的时候了。并且，界面词翻译需要尽量固定译员，否则即使有TM的支撑，也难免出现不一致或是功能上的理解错误。

对任何语言服务商而言，每天分配译员合适的工作量都并非易事：任务量每天在变；译员也会突发个人事务。语言服务商要通过和客户的沟通，较为准确地预知工作量，将界面词与内容较多的文档搭配起来分配给译员，维持译员的日产出；同时也可借助AI，将译员擅长的领域与待译文件的领域匹配，借助数据而非纯凭项目经理的感觉和经验来分配项目。

挑战四：多人协作

一个短短的界面词，可能出自产品经理之手，也可能是UX写手和设计师讨论的结果；定稿后，需要由负责本地化的同事发送给供应商的PM，再由PM分发给译员；有时候先翻成英语（中轴语言），再分发给各个语种的译员。这个长链条的每个环节都可能要找前道环节答疑解惑，甚至指出他们的错误。而工种的不同，决定了对翻译认知上的差异；有差异则意味着要沟通要输出，要花更多时间去磨。

现在，大多数CAT/TMS工具都支持生产端的沟通，如PM和译员、译员和译审，可以是实时聊天，亦可添加批注。部分TMS也支持翻译团队与需求方的沟通，如Lokalise在和Figma这样的设计工具通过API连接后，可实现翻译团队与设计师的沟通。

动手试试

下面我们简单实操一下，通过将Lokalise与GitHub连接，演示一下持续本地化。

在GitHub上找一款合适的应用，条件设为：

android language:java pushed:>2022-01-01 in:description game

即，搜索今年更新的安卓游戏，编程语言为java。

搜到一款小游戏Vector-Pinball还挺合适。在GitHub中fork一下，把源代码复制到自己的仓库中，就可以随意修改了。

先看看能否正常运行：

原来是一款弹珠游戏。查看其资源文件，发现包含数个语言版本，但没有中文：

下面我们就将其本地化成中文，同时模拟一些场景来尝试持续本地化。为此，就需要用到一些具备以下功能的工具：

1. 能与代码库 (GitHub) 连接，实时探测到资源文件的更新，并拉取这些更新。

2. 能与CAT工具连接，将更新推入CAT工具，或者本身包含CAT模块。

3. 能将CAT的译文导回代码库。

前文提及的Lokalise就是一款这样的云端工具，有14天的试用期。注册完成后，首先新建项目：

然后，选择要连接的内容来源：

再和pinball的代码连接（在此之前，已经将原始的英文字段复制到新建的文件夹“values-zh”中）：

选择要拉取的文件：

拉取完成后进入翻译编辑器界面：

翻译编辑工具的界面都是比较相似的，其中的作业细节不做赘述。

下面我们来假设一个场景：如果字符串有更新，Lokalise这样的工具能否检测并自动拉取？

答案是肯定的，将Lokalise和GitHub连接即可。实现方式是，在GitHub中启用webhook，在其中输入Lokalise项目的URL地址：

下面我们开始实验：在GitHub中编辑源代码，添加一个字段再更新一个字段（72行增加内容、增加74行），代码从

变为：

在Lokalise中，与原始代码对应的界面为

在代码更新后，界面也随之更新：

这样，资源文件发生任何更新，都会实时同步到Lokalise中，这个过程无需任何人工参与。

翻译完成之后，便可提交至代码库中相应的语言资源之下，任务完成。

结语

持续本地化易被忽视。不过正因如此，其流程一旦更新就会带来显著提升，为整体带来的益处也更为明显。而且，目标语言越多，越能体现持续本地化的价值，因为其结构不会因语言对变多而更为复杂。

“持续本地化”来自软件开发语境，但并不代表它只适用于开发场景。它的内核其实是自动化：用工具实现内容的识别、推送、提醒、检查、返回、发布，解放人力资源，让人能发挥更大的价值。

在数字化的大趋势下，各种信息载体的处理方式都在升级，无论是代码，还是文档、图形或多媒体，都会有自身的“持续本地化”之道。