几个月之前，我们讨论了在使用 Scrum 开发框架的编程世界中，敏捷开发如何越来越有助于加快产品上市。在互联程度日益提高的数字世界中，软件开发从未停止 —— 即使是在一种版本已经发布后；不同国家的用户也越来越多地要求，希冀能在同一时间看到本地语言的最新软件版本。
过去，开发团队的本地化过程采用传统的瀑布式方法，并且需要对产品进行定期编码，这导致大量的代码只能分批发出去翻译。
而要想进行产品更新，则编码工作必须停止，从而将内容分成多个部分发给翻译公司。之后，本地化的内容才能被上传到系统中并进行发布。
开发者通常需要几天甚至几周才能等到翻译发回；而且在有些情况下，廉价、低质的翻译会导致质量问题和进一步的延迟。有时，产品在当地市场上发布时，部分内容还保留着源语言 —— 通常是英文。对于最终用户来说，这不仅看起来不专业，而且经常会让本地市场的用户使用过时的产品，而且这些产品还在使用他们看不懂的语言。
全新方式
各企业开始意识到现有方法存在的问题，并开始启用持续本地化，以便使用不同语言的各地区用户可以在同一时间获得同一软件。
对于开发人员而言，持续本地化可以和他们的敏捷开发流程保持相同步调。
持续本地化最常用于需要不断更新以保持可用性的移动应用程序，它与敏捷开发迭代保持同步，以更频繁的小包形式对内容进行本地化，而非频率较低的大批量本地化。
从本质上讲，持续本地化带来了一种轻松、快速和有效的本地化流程；同时，它还可以用于开发人员最常用的各种格式。
持续交付还消除了传统批处理本地化过程中通常会遇到的潜在障碍，例如 QA 编辑人员冗长的审稿时间。这种精简翻译方案的主要优点在于，开发团队可以专注于编程，而无需暂停开发流程。
成功的关键
虽然产品的本地化版本总是稍微落后于源语言版本，但源语言中的代码行仍可能出现在尚未翻译的本地化版本中。成功的关键在于尽量减少接触点，并使用一致的文件传输方法。
通过在敏捷开发框架中集成本地化自动化平台，开发人员可以为每个项目创建自定义工作流程，推送待翻译的内容字符串，获取翻译并将其导回至产品 —— 这将加快生产周期、节省资金并获得更高质量的翻译。
无论是公司内部的翻译团队，还是熟知应用程序本地化的知名语言服务提供商，开发人员所合作的译员在通过这个强大的简化流程进行内容本地化时，必须能够接受紧迫的交稿周期。
交稿延迟可能意味着对目标市场产品更新的严重滞后。因此，从事关键任务系统开发的团队应宁求稳妥，与语言服务提供商合作。
关系的管理
时间限制是敏捷开发人员共有的难题，为了让项目按时顺利发布，科技公司通常会聘请专业的内部项目经理和审核人员来监督本地化过程，以便开发人员能够专注于构建项目。
这还包括确保集成的本地化自动化平台平稳运行，将作业分配给译员，并及时反馈对产品的审校意见。
积极主动的本地化项目经理还应注重向公司内部更广泛的团队普及持续交付的复杂性，尤其是针对在以前的项目中与本地化专家有不愉快合作经历的开发团队。
应鼓励与语言服务提供商合作的开发团队邀请译员在内部完成需要特定技能的任务，例如引入一位擅长双向语言翻译的译员。举例来说，如果使用检查静态源代码的工具，阿拉伯语会是很大一个难题。在这种情况下，在运行之前，让一位经验丰富的双向语言专家来负责检查代码，可能是一种最有效的方法。
持续本地化流程能够取得成功，灵活的工作流程至关重要。事实上，思科系统国际化架构师 Gary Lefman 解释说，“我们做事没有固定的方式”，这家位于加州的科技巨头的工作流程可以适应每一种开发团队工作风格。
对于不熟悉持续本地化的公司而言，开发团队应花时间建立一个有效的工作流程，以确定何时应将内容字符串发送给译员，以及何时该发布产品。但是专家们认为，为单个开发团队确定正确的工作流程花费的时间越多，结果就越好。
虽然持续本地化的过程会导致更高的本地化成本，但有效的持续交付策略必将能够使开发人员更快地将产品推向市场，以使用户能够以本地语言体验最新的内容。这对于开发团队和最终用户来说是一个双赢的结果。
随着移动应用程序以及思科和 Evernote 等大型科技公司对于持续本地化早期发展的推动，可以大胆预见这种方法未来将成为敏捷开发团队的行业标准。
