对于一个雄心勃勃的高增长业务来说，国际化在大多数情况下的问题不是“是否做不做”，而是“何时做”。然而，大多数企业通常没有意识到，要构建一个真正的全球产品（尤其是数字产品），除了翻译之外，还有很多事情要做。因此，本地化往往是产品推出后才有的想法。 此外，添加新的语言和进入新的市场常常被认为是一次性任务，有明确的项目结束点。但是，数字产品（软件，游戏，应用程序，网站等等）永远不会完结，而且经常不断地改进和更新。这意味着你不断有新的内容需要翻译和本地化。 忽视这一点通常会导致本地化成为危及您扩展国际市场的一个瓶颈，并使其成本和痛苦远远超出必要的范围。更重要的是，对于国际客户来说，用户体验将变得脱节和糟糕，因为整个客户旅程中的大量内容没有被翻译和本地化。防止这种情况发生的唯一方法是确保本地化不是产品发行后才有的打算，而是将其视为企业国际化与持续本地化的必要流程。 持续本地化确实是一个相当大的挑战。在本指南中，我们将探讨: 什么是持续本地化。 本地化的起源以及本地化与软件开发方法的直接联系。 如何成功地将本地化集成到您的产品交付工作流中。 这如何转化为你公司的所有数字内容。 软件开发方法与本地化 从瀑布流本地化到持续本地化 瀑布流本地化 敏捷本地化 连续本地化工作流程 持续的本地化挑战 保持翻译的一致性和准确性 定价和组织翻译 高效的跨职能协作 正确处理工作流程 如何将持续本地化集成到您的产品的持续交付工作流程中 1. 合并您的本地化团队和产品团队 2. 选择正确的连续本地化软件 1.将本地化团队与产品团队合并 2.选择合适的持续本地化软件 持续本地化所有数字内容 关于持续本土化的最后思考 软件开发方法与本地化 如今，本地化涵盖的不仅仅是软件。软件和数字内容之间不再有明确的界限。然而，正是个人电脑和大众市场软件的兴起，才产生了本地化的需求。这要追溯到20世纪80年代，当时第一批成功的美国软件公司（如微软，IBM和甲骨文）最早开始在全球扩展市场。 除了翻译文本之外，您还必须考虑上下文和可用性，调整日期格式与布局，满足法律要求等等。因此，本地化的发展受软件开发发展的影响很大。 虽然自20世纪80年代以来已经引进了许多软件开发方法，但最常见的两种方法是瀑布流本地化和敏捷本地化。在过去的十年中，敏捷本地化已经成为主流。此外，开发新软件的前期技术投资急剧减少（得益于云架构，企业软件大多不再昂贵）。 上述两项进步极大地加快了软件开发的速度。以前，软件基本每年才发布一次。而今天，几周甚至几天就会更新一次。部署这些新版本的成本基本上为零，开发人员能够经常发布更新。另外，新的软件版本通常意味着要翻译新的字符串（文本片段）。 任何阻碍这些产品发布的因素都意味着延迟，需要更长的时间才能上市，最终也需要更长的时间等待从市场反馈中获得新的信息，更多的收入和更少的利润。这通常是本地化开始成为瓶颈的地方。本地化过程需要能够跟上软件开发的演进，这样它就不会停止产品的发布。因此，本地化方法也经历了从瀑布式到敏捷式，再到现在的持续本地化的发展过程。 从瀑布流本地化到持续本地化 翻译行业传统上使用瀑布流本地化，因为大部分工作通常是翻译文档或书籍等。一旦文档完成，翻译工作就开始了。软件则是完全不同的流程，因为软件从未真正完成。 瀑布流本地化 在大多数情况下，本地化还是瀑布流式，仍然是在开发周期的最后阶段计划的。 一旦这个周期结束，开发人员将收集大量不同格式的源语言文件，并将它们发送给翻译人员。对译者来说，这也意味着要做大量的准备，做大量的翻译，进行一轮又一轮的审定，解决问题，然后批准修改。 当文本翻译完成后，翻译人员将把文件（翻译的字符串）发回给开发人员，由他们手动上传文件到应用程序中进行合并并发布。 这种做法不可避免地会造成一个令人头痛的问题，因为: 对于开发人员来说——查找文本并将其分解为字符串的过程是非常繁琐的（尤其是如果您的应用程序中有几十万个单词的话）。 这些翻译文件需要被转换，因为开发人员使用的是与翻译器不同的一组文件格式。这不仅会浪费双方时间，还会损坏文件，导致犯错空间更大。 如果产品的开发没有考虑到国际化，那么就需要重新思考下架构。 手动下载、上传再向多人发送文件的模式，速度太慢而且容易出错。 软件发布被搁置，等待翻译人员完成工作。 在翻译端几乎看不到进展，所以项目经常会被延长。 如果有任何错误，那就意味着重复一遍这个过程。 简单地说，对于采用敏捷本地化的公司来说，这意味着错过最后期限，浪费资源，无休止的来回，漫长的等待时间和机会成本的风险。自然，这也给本地化方法带来了适应的压力。 这也造成了软件开发人员和产品团队之间围绕本地化的负面内涵。 敏捷本地化 顾名思义，敏捷本地化将本地化和翻译纳入一个敏捷的产品开发周期，使这两个过程同时运行。 翻译与敏捷开发周期并行进行，并且以较小的批量进行。这意味着只翻译产品或功能的一部分，而不是一次翻译整个产品。 为了使这种方法获得成功，它需要软件团队的自动化，因为字符串管理和文件交换使用得更为频繁。理想的敏捷本地化工作流是这样的: 带有新字符串的新代码被推送到代码存储库。 系统将自动识别这些变化，并将需要本地化和翻译的新内容被推送到翻译管理系统(TMS)。 译员在翻译管理系统(TMS)上翻译和审查内容。 翻译完成后，内容将被合并回代码存储库中。 然而，实现这一点听起来要比现实容易得多，也要直截了当得多。实际上，这甚至会导致软件团队和本地化团队之间造成更多的摩擦。 首先，翻译人员通常并不熟悉软件开发环境。因此，从他们的角度来看，这只是意味着在更紧急的时间内进行频次更多、篇章更短而且还断章取义的翻译。 在过去，翻译管理系统(TMS)的构建是为了让翻译人员（或LSP）的日子变得更容易，而不是为了开发人员。这意味着可用的自动化并不完全用于管理软件字符串（步骤1，2和4），而更多地用于管理和执行翻译工作。因此，软件团队通常必须构建与这些翻译管理系统连接的自定义集成（内部本地化平台）。然而，这些仍然需要维护并耗费大量的精力（以及构建的时间）。 无法负担自定义解决方案的团队被迫继续使用电子表格和半自动化流程。不幸的是，这并不是过去式。我们在Lokalise定期调查市场，通常超过50%的潜在客户已经有了几种语言的产品或数字资产。然而，这些公司中的大多数并不使用翻译管理系统，或者仅仅使用电子表格来管理翻译过程。这通常是明确地表明他们目前没有一个简化的本地化过程，并且陷入了困境。 持续本地化的工作流程 持续本地化只是朝着本地化自动化和无缝化的方向迈出的又一步。因此，敏捷本地化的目标是什么呢？ 你正在思考敏捷本地化和持续本地化之间有什么区别吗？“持续本地化”并没有官方定义，因此它的定义取决于你问的是谁（译员，开发人员，产品经理等等）。但是，你经常会听到两个关键的区别: 1）在敏捷本地化中，翻译工作发生在敏捷开发周期中，而在持续本地化中，本质上有一个永无止境的开发周期（或翻译工作）。换句话说，这是一个持续的交付与基于工作设置的比拼，这也就导致了第二点。 2）在敏捷本地化中，本地化被集成到敏捷过程中，而在持续本地化中，它被完全集成到软件的持续交付工作流中，这样工程师一旦集成就不用担心了。 持续本地化起源于CI/CD（持续集成和持续交付）方法，这是敏捷方法的一个子集。它也使得完全自主且不间断的翻译工作成为需要。 当新代码不断被推送，软件在开发周期内随时准备发布时（特别是与视频游戏和移动应用程序开发相关的时候）。 在实践中，这意味着更快速的更新，甚至一天可以更新多次。因此，对于本地化，有更小的，更频繁的成批无休止的翻译工作，以及更多的自动化以避免中断。 持续本地化是敏捷软件团队的完美敏捷本地化工作流，这些团队不断地发布大量更新和发布。它免去了过程中的繁琐的人工部分，最终将产品更快地送到终端用户手中。 持续本地化的挑战 与敏捷本地化类似，在您的软件交付工作流中实现持续本地化并使其无缝与高效地转换是不小的壮举。它本来带来了一系列挑战。 保持翻译的一致性和准确性 翻译准确并不是一件容易的事情，在短时间内正确翻译软件产品的一小部分就更难了。上下文，一致性和准确性成为一个真正的挑战。因此，对于译者来说，了解产品和上下文是非常重要的。 同样，软件团队应该明白，计划和了解产品对于翻译人员正确翻译是至关重要的。不相关的小字符串转换请求使这变得有点复杂。 如果你和多个自由译者一起工作，或者做众包翻译，这会变得更加麻烦。每个新人都需要一段时间来适应和了解产品。 定价和组织翻译 翻译员每周只做几次100字左右的工作将变得不再稀奇。这可能使翻译员难以弄清楚如何收费，即最低收费的概念应该如何以及何时适用。 此外，翻译人员需要以一种有效的方式组织他们的工作量，这样他们仍然有足够的带宽来支持内容容量更大的客户机。因此，满足这些较小（但更频繁）的请求可能会成为一个挑战。 高效的跨职能协作 软件开发人员往往没有意识到翻译工作的复杂性，反之亦然。这在本地化中是个越发紧迫的挑战，加上敏捷工作流的速度和压力就更是如此。您需要能够每天翻译，尽快交付并熟悉敏捷本地化的翻译伙伴。 此外，它并不是只有翻译和开发人员，在软件团队中，还有产品经理，设计师，用户体验编写者和营销人员（下面更多关于营销人员）。另外，所有的利益相关者都在追求略微不同的目标。因此，最好的本地化团队是跨职能的，您需要确保所有团队成员在正确的时间获得正确的信息，以满足市场发布的最后期限。此外，所有成员都在规划和执行本地化战略的范围和复杂性方面受过良好的教育。 就像任何一个系统一样，它只有在最薄弱的环节上才会强大和有效。 正确处理工作流程 每个产品团队的工作流程都是独一无二的，这取决于您的产品和技术的具体用例。因此，您需要一个持续本地化平台(CLP)，它需要足够灵活，可以将本地化集成到您的持续交付工作流（CI/CD）中，而无需太多额外投资。 如何将持续本地化集成到产品的持续交付工作流中 1. 将本地化团队与产品团队合并 持续本地化的目的是使本地化完全自动化和无缝衔接，以便您始终能够向所有用户提供全新的和更新的内容，而没有任何阻塞。 但是，必须有人来设置工作流，有人来执行翻译，有人来监督这个过程以确保翻译是准确的，没有错误或漏洞。因此，他们必须确保事情顺利进行。 理想情况下，这意味着本地化团队成为软件开发团队的一部分。当您每天有几十万个字符串被翻译成多种语言并有新的更新时，这在规模上变得更加重要。 一个典型的内部本地化团队至少包括3个软件团队角色: 本地化工程师——负责实施持续的本地化工作流程。 本地化质量保证-——负责本地化产品的质量。 本地化经理——监督整个过程的人，与工程师和译员一起工作，并负责最后期限。 在复杂的组织中，有多个跨职能的团队在不同的产品上工作，这就更棘手了。在每个团队中应该有一个明确的所有者或“本地化倡导者”，因为工作流可能有点不同。 2. 选择正确的连续本地化软件 以下是连续本地化平台(CLP)实现无缝衔接的连续本地化所必须具备的内在特性: 本地化过程自动化——避免任何手动上传，下载和文件交换。在代码存储库中自动检测到新字符串，并将其推送到TMS中进行翻译。一旦翻译完成，翻译就会自动合并回存储库中。 翻译字符串（TMS）的单一真实来源——将需要翻译或调整的每个字符串，图像或项目保存在一个地方。了解所有利益相关者的概况，与之沟通，并在一个地方分配任务。 计算机辅助翻译功能（翻译记忆，词汇表，质量检查）——您的译员将需要翻译功能来确保速度的同时确保质量和一致性。 可视上下文——通过向翻译器展示翻译后的字符串将显示在何处以及如何显示，使用用户界面截图提供尽可能多的上下文。 翻译版本控制——与敏捷软件开发相同，持续本地化意味着多个翻译人员将在您的软件的各种通常不相关的部分上工作。您需要一个版本控制系统来保持所有内容的同步。 轻松集成到您独特的持续交付工作流中——连接您的代码存储库，如GitHub和Bitbucket，以及开发工具，如Jenkins和Docker。 将设计器工具（如Figma，Adobe XD和Sketch-Invite设计器）轻松集成到本地化工作流中。在编码之前开始翻译和测试你的模型和原型，以便及早发现潜在的本地化漏洞。 持续本地化所有数字内容 在本文的开头，我们解释了当今软件和数字内容之间没有明确区分的原因。此外，普通公司如今拥有更多的数字内容。 使您的产品拥有多个语言版本只是最起码的要求。要想在全球取得真正的成功，首先你还需要内容来吸引人们并将其转化为客户。这些内容也将不断更新。 此外，领导或客户将以多种方式与您的公司互动，而不仅仅是与您的产品互动。他们可能会访问你的网站，接受电子邮件，更新社交媒体，或者阅读博客文章。他们可能会与您的实时聊天互动，并阅读您的文档。 此处最重要的是，对他们来说，你只是一个公司，一个品牌，即使你的内容由不同的团队拥有。客户旅程的任何中断都会对你的整个品牌产生负面影响，而不仅仅是你公司的一个部门。 因此，尽管数字内容类型之间的区别并不总是明确的，但它们之间存在着显著的差异: 您需要设置各种不同的连续本地化工作流，因为您的内容可能存储在不同的平台上。例如，你的营销内容可能存储在像WordPress或Contentful这样的内容管理平台上，而你的产品（你的软件）在GitHub上。因此，您需要确保持续本地化平台能够与与内容管理平台以及GitHub集成。 此外，您的客户支持工具（live chat，support Ticket和help center）可能托管在Intercom或Zendesk等平台上。 您的本地化团队必须变得更加跨职能，邀请市场营销，销售和客户支持参与本地化。 翻译软件字符串不同于翻译博客文章和营销内容，因此您需要一个清晰的多语言品牌，编写指南以及内容工具。而且你很可能必须与理解市场营销的翻译伙伴合作。 关于持续本地化的最后思考 释放全球增长是现代企业实现规模扩张所需的关键支柱之一；然而，本地化可能成为，而且通常确实成为一个严重的瓶颈。正确的产品本地化是一个耗时且复杂的过程，但它成为瓶颈的主要原因是企业没有认识到本地化应该是持续的。而且，这适用于产品本地化，也适用于你所有的内容本地化。 想了解如何在您的公司实现互联的持续本地化工作流吗？联系我们在Localise的一位产品专家。 指南 本地化