持续本地化：它是什么以及它是如何工作的

持续本地化是一种与开发同步翻译和审阅内容的做法，而不是在代码发布后作为一个单独的阶段。它将翻译直接集成到敏捷和 CI/CD 工作流中，因此新功能可以同时进入每个市场和每种语言，无需单独移交给翻译团队。

敏捷开发是围绕快速、持续的迭代构建的。但大多数翻译流程仍然围绕瀑布式思维构建：开发完成后，一批字符串被打包并发送出去进行翻译。这种不匹配正是持续本地化所修复的问题。

本指南涵盖了持续本地化的实际含义、为什么传统的翻译工作流在敏捷开发下会崩溃、持续本地化在实践中是如何工作的，以及如何实施它。

为什么传统的翻译不适用于敏捷开发？

在瀑布模型中，项目的每个步骤都必须在下一个步骤开始之前完成。翻译通常是这些步骤之一，且在最后才进行。

这会产生两个问题。首先，翻译中的任何延迟都会延迟整个发布，因为在每种语言准备好之前，任何内容都不能发布。其次，修复后期发现的问题，无论是翻译错误、不适合 UI 的字符串还是缺少上下文，都意味着要重新开启一个已“完成”的阶段，这在设计上既缓慢又具有破坏性。

一些翻译供应商称自己是敏捷的，却没有改变底层工作流：字符串仍然在冲刺结束时被打包成套件并发送给单独的团队。结果是同样的脱节，只是换了个标签。本地化经理最终需要在开发人员和翻译人员之间进行协调，他们是在不同时间处理产品的不同部分，这增加了每次发布时的协调开销。

敏捷是如何改变本地化的？

敏捷开发是在小的、迭代的周期中工作，而不是一个漫长的顺序构建。应用于本地化，这意味着翻译与开发在同一个周期内进行，而不是在开发之后。

不再是在项目结束时一次性进行大量翻译，而是内容持续地以与开发人员发布时相同的批量流转到译员手中。本地化团队在冲刺阶段嵌入式工作，而不是等待交接。

这种转变让团队能够更快地交付，并能及早发现和修复问题。这确实意味着本地化流程本身、工具、工作流和团队结构必须进行重构，以支持持续流动，而不是周期性的批量处理。

持续本地化的工作原理

持续交付（即保持产品随时可发布的状态）是持续本地化所借鉴的模型。开发人员不想在发布前等待数天进行 QA、本地化和测试；他们希望在更改准备就绪后立即发布。

对于本地化团队而言，这意味着管理持续的内容流，而不是大型的周期性交付。在实践中，这通常通过自动化触发器运行：当开发人员在原文/源语存储库中添加或更改字符串时，它会被自动获取并路由进行翻译，而无需任何人请求“字符串冻结”来为译员争取时间。

这就是工具发挥作用的地方。一种直接连接到您的存储库的 翻译管理功能，以及一种可以通过 webhook 或 API 事件自动触发翻译工作流的 编排功能，才是让“持续”真正实现持续，而不仅仅是“频繁”的关键。Phrase Strings 专为此而构建：它通过 API 或 CLI 与您的存储库同步，因此字符串更改会在发生时流入翻译，而翻译后的字符串也会以同样的方式流回您的存储库。请参阅 API 和开发者文档 以了解集成的工作原理。

开发团队的目标是尽可能减少阻碍：他们持续发布，而本地化在后台保持同步，仅呈现真正需要开发人员关注的反馈。

持续本地化的优势

将本地化引入开发周期，而不是在开发周期之后进行，这改变了译员和开发人员的协作方式。译员不再是被动的本地化工具包接收者，而是开始与构建产品的人员并肩工作。

更短的发布周期

本地化不再作为单独的阶段处于关键路径上，因此整体上市时间得以缩短。Pega 将翻译周转时间缩短了高达 75%，使过去比英语版本滞后长达四周的营销内容缩短至最少一周，且无需增加人手。一家 全球 SaaS 公司 走得更远：在自动化其 Web 内容翻译后，发布周期从数周压缩到多语言的当日发布，外部供应商成本降至零。

更好的质量

译员在真实的产品上下文中工作，而不是面对脱节的字符串列表，这能减少错误并减少后续查询。问题在相关开发人员还在存储库中工作时就会浮现，而不是几周后。

同步全球发布

消除开发和本地化之间的滞后意味着功能可以同时在每个市场发布，而不是在随后的几周或几个月内错开推出。

您如何实施持续本地化？

转向持续本地化是一个流程更改，而不仅仅是工具更改。一些实践可以让过渡更顺畅：

1.为团队准备好一种不同的工作方式。

做好团队的准备，让他们欢迎更改，而不是回避。越是拒绝更改的必然性，它到来时带来的冲击就越强烈。

2.在更改当前工作流之前，先绘制出当前工作流。

将本地化视为内容的流动，并找出它目前停滞的地方。如果整个过程看起来太大而无法一次性解决，请从阻力最小的单个步骤开始，然后从那里展开。

3.自动化交接工作

手动批处理字符串、通过电子邮件发送文件以及将翻译后的内容重新集成回存储库，正是持续本地化在实践中失效的地方。将您的 TMS 直接连接到您的问题跟踪器（例如，通过 API 连接到 Jira 等工具），可以使内容和查询在无需人工干预的情况下持续流动。

4.保持一个稳定的、专注的翻译团队。

随着时间的推移，与同一产品合作的译员能够建立起轮换人员无法比拟的产品知识和一致性。开发人员也会学会信任他们熟悉的译员所提供的反馈，而不仅仅是信任工单上的一个名字。

5.为译员提供上下文，而不仅仅是字符串

截图、短片或链接的工单可以将模棱两可的字符串转化为快速、准确的翻译。缺失上下文是导致翻译错误和返工的最常见原因之一。

6.将其视为持续进行的过程，而不是一次性的迁移

预计在初始发布后会对工作流进行迭代。敏捷方法论是持续本地化能够发挥作用的前提：如果开发本身不是迭代的，那么使本地化变得敏捷的好处就很有限。

持续本地化对每个团队都值得吗？

如果您的产品以敏捷节奏发布给全球受众，那么答案是肯定的：仍然基于瀑布式假设运行的翻译工作流将会在每次发布时不断阻碍您的工作。持续本地化使翻译与开发保持相同的节奏，因此它不再是一个单独的项目，而是成为产品发布方式的一部分。

持续本地化常见问题解答