写信给我们。 创建一个可以在多个市场销售的软件产品是很复杂的。软件本地化在这一过程中扮演着重要的角色，但同时也无意中破坏了这一过程。这是因为本地化实际上是一个瀑布特洛伊木马在一个主要的敏捷开发过程。这种不匹配在早期阶段可能没有问题，但它最终会使本地化成本飙升;它延迟了发布并增加了涉及的每个人的复杂性。更重要的是，效率低下的本地化流程也会阻碍企业以所需的速度扩展。 许多公司通过更换翻译供应商、购买新技术或重组团队来解决这个问题，但这些都不能解决问题。更明智的方法是解决问题的根源——而不是症状——并重新设计本地化流程，使其也变得敏捷。在本文中，我们将讨论持续本地化（CL）模型如何提高敏捷性，并介绍一些实现未来可伸缩性的关键元素。 本地化和敏捷 正如一位顾问同事喜欢说的那样，翻译必须是主要过程的一部分，而不是一个有自己的规则和思想的单独的东西。本文遵循同样的思路——在我们的案例中，主要的过程是软件开发。这就要求本地化也应该严格遵循敏捷原则，以便与创建软件的速度、灵活性和协作性相匹配。 如前所述，转换到CL并不一定需要购买新技术或更换翻译供应商，但它总是涉及开发内部管道的新部分。只有当系统而不是人来做大部分工作时，真正的可伸缩性才是可能的。因此，如果可扩展性是目标，这就是公司应该开始的地方。遗憾的是，翻译专业人员无法自行实现本地化自动化，因此需要其他部门的帮助。 CL与翻译一样，也是一个业务、技术和流程的问题，因此大多数CL从业者都是这样处理的—他们增加了一名产品人员和至少一名软件工程师，与他们现有的本地化专业人员一起工作。虽然不便宜，但拥有一个专门的产品人员和软件工程师是任何自动化的关键先决条件。将这个新团队想象成一个本地化运营团队，反映出开发运营团队在开发流程中所做的工作。 值得注意的是，随着业务的增长，CL团队很少需要更多的人员，因为自动化处理了大多数任务。例如，在CL计划中，不需要本地化项目经理，他们的职责只是建立自动化、改进流程和管理任务逻辑中的异常情况。这与传统的本地化团队形成鲜明对比，传统的本地化团队在工作量增加2-3种新语言或新产品时，就需要增加招聘。这使得CL程序具有更大的可扩展性和未来性。 除了自动化构建能力之外，团队中的产品人员还可以确保本地化在隐喻性的业务谈判桌上占有一席之地，从而确保对这一问题采取更具战略性的方法。如果本地化团队离产品和工程“很远”，传统上很难做到这一点。 技术骨干 除了人员之外，任何CL系统的核心先决条件是自动提取新内容/字符串并将翻译合并回产品中。这包括处理更新、自动分配翻译任务，最好还包括自动生成屏幕截图。这些技术组件至关重要，因为多个团队与多个翻译人员同时处理多个产品，不可能跟踪所有内容并手动提供上下文信息.在这种情况下，传统的本地化团队需要冻结开发，这会给企业带来更多的问题，而不是解决问题。CL程序从不需要冻结，这是另一个优点。 CL的下一个关键部分是错误纠正的自动化。就像新功能总是会有不完美或错误一样，由于工作速度的原因，翻译错误也会发布到生产中。但是，除非人们的生活依赖于你的产品，否则只要有一个快速检测和修复错误的机制，就不应该把这看作是一件坏事。这样的机制可以通过将翻译后的字符串从源代码中分离出来并将翻译存储在云中来创建。在这种情况下，每当翻译人员在翻译工具中更正错误时，系统就可以在当天晚上自动将其发布到生产中。如果是紧急问题，本地化团队甚至可以立即发布修复程序，而不必等待工程师。可以把这看作是软件字符串的“CMS化”——修复UI中的翻译错误应该和在WordPress中编辑内容并实时发布一样快。这是迈向更好可扩展性的又一步。 这种分解的云设置的附带好处是，它们可以有效地作为翻译的备份和版本控制系统。翻译工具通常不具备此功能。有趣的是，分解方法还可以用于快速修复源语言中的错误——否则这将花费不可原谅的长时间。 用户反馈为王 最后一个重要的CL部分是更好的用户反馈收集。与传统观点相反，本地化质量最相关的指标不是另一位翻译人员的审阅，而是最终用户在实际生活中使用产品时的体验。这种方法也比专家审查更具可扩展性和客观性。 衡量本地化用户体验的选项有很多： · 跟踪本地化产品关键部分的用户参与度。如果大约57%的用户在五种语言中点击了关键业务按钮，但只有13%的用户在第六种语言中点击，那么第六种语言可能会有严重的质量问题。 · 对某些页面使用A/B测试，以衡量哪种语言风格更适合目标市场（在花钱本地化所有内容之前）。 · 在产品中添加反馈表单以报告翻译错误。人们确实会留下反馈，尤其是对他们公司生产的产品。 · 偶尔向使用非默认区域设置的用户发送调查问卷，询问他们的体验。 所有这些方法都可以使用公司现有的分析工具，从而降低成本并节省时间。它们可以方便地与产品团队的其他成员一起使用，而不会增加复杂性。 应该注意的是，这种方法可能不能保证一尘不染的质量（特别是对B2C产品，那里的酒吧比B2B更高），但它足以涵盖基本。在此基础上可以进行人员质量审查，但请记住，这是一个不可扩展、昂贵且固有的主观过程。对于决定投资于此的公司，一般建议是自动化流程，尽可能首选trancreation，并专注于在产品UI中完成的审阅（而不是在翻译工具中）。 新的协作模式 本地化中的供应链本质上是使其如此瀑布式的原因—翻译公司不可能在事先锁定工作范围的情况下计算价格和期限。因此，翻译公司无法跳上CL的马车，因为这不仅仅是他们的工作方式必须改变—这是他们的分包商和分包商自由职业者的了。此链阻碍了真正的可伸缩性。 这种翻译供应商的瘫痪迫使CL从业者重新设想自己的本地化流程。他们实现了项目管理的自动化，并开始在内部收集质量指标。他们中的许多人也开始寻找、签约并支付自由译者，采用简单易用的市场和金融科技解决方案。 如果没有翻译公司及其众多的分包商参与，内容创作者和翻译人员之间的沟通将得到改善。澄清问题可以通过聊天应用程序和翻译工具评论直接提出，回复可以迅速交付，并可以促进持续的合作。这就是为什么CL项目的质量从来不会差，尽管它的速度快得令人窒息——稳定的本地化团队相互了解并进行沟通，通常从第一次尝试开始就产生最少的错误。 然而，内部管理翻译人员可能会限制本地化计划的长期可扩展性，而这正是我们试图避免的。每家公司可以管理20名自由译者，但如果是200名呢？幸运的是，这正是翻译公司可以提供帮助的地方—通过将自己定位为CL计划的语言专家提供商，而不是传统的服务提供商。您可以将他们视为人才管理合作伙伴，专门为大中型项目寻找、测试和管理翻译人才库（不处理任何沟通或财务问题）。 那一点点竞争优势 在竞争激烈的现代世界里，每一件能推动企业发展的小事都很重要。持续的本地化为全球竞争力增添了一个全新的超级大国，同时也实现了未来的可扩展性。有时候，在所有条件都相同的情况下，一些公司可能会第一个冲过终点线，仅仅是因为那一点点额外的速度和灵活性。 请在此注册以获取我们关于全球化和本地化问题的时事通讯。