持续本地化因其优雅而受到开发人员的青睐。 从理论上讲,它允许您将本地化流程转变为无缝工作流程,其中字符串会不断被翻译、审查和更新,任务没有开始或结束。
应用程序、网站和文档始终是最新的,因为更改会永久地通过系统。 在开发者领域,这是一个乌托邦。这是一个乌托邦,因为它不现实。
持续本地化是一个依赖于人工干预的技术过程。 您必须依靠工作流程中涉及的每个人正确、按时地完成任务。 因此,最终的持续本地化最佳实践不以任何具体步骤为中心,而是以建立问责制和可衡量标准的混合系统为中心。
为什么持续本地化可能不起作用
从开发人员的角度来看,持续本地化非常好,但从业务管理的角度来看就不那么好了。 本地化过程远不止是翻译。 它需要积极管理人员、账单、报告和其他业务标准。
持续本地化,同时,完全是关于代码和内容。 目标是尽快让字符串上线。 这对开发人员来说是一个理想的工具,但对业务管理来说却是一个噩梦。 在纯粹的持续本地化过程中,编码人员创建一个字符串,它显示在一个接口中。
翻译人员可能会也可能不会拿起它并翻译它。 翻译后,字符串将经过质量管理流程,然后重新集成到原始产品中。 所有这些都在一个连续的循环中发生,没有任务或分配的项目。 这是一种自由流动、灵活的系统,几乎没有监督。在内容翻译量很少的情况下,比如一个小型应用程序或网站,这可能会奏效。
众包环境也是如此,没有人担心应付账款或投资回报率。 然而,对于一个企业环境,其中有数百页的内容和语言需要考虑,纯粹的持续本地化过程并不理想。 相反,更明智的做法是采用理论中最好的部分,并使用它来创建一个具有明确监督的结构化流程。
在混合模型中,持续定位的理论仍然存在。 但是,该过程本身会触发步骤和基准,从而实现更好的管理。
混合解决方案是持续本地化最佳实践的终极
持续本地化有一个总体最佳实践,它将影响流程的所有部分。 这涉及使用一种内置监督和问责制的混合模式。 虽然工作流程可能没有明确的开始或结束,但仍有一些基准可用于指导项目。在混合模型中,持续定位的理论仍然存在。 但是,该过程本身会触发步骤和基准,从而实现更好的管理。 它的工作原理如下:
- 客户端提交一串文本进行翻译。
- 创建的客户档案包含翻译记忆库、公司词汇表、账单信息和译员偏好。
- 提交会触发分配翻译和 QA 审核以及构建完成时间表的任务。
- 为该任务分配一个整体项目,该项目建立应付账款、应收账款和报告范例
- 经验丰富的翻译人员 使用现有的翻译记忆库和其他公司词典来指导他们翻译字符串。
- 然后,将翻译后的字符串一起发送以进行 QA。
- 审阅会批准翻译或进行更改。
- 完成的字符串将提交发布,并自动重新集成到产品中。
- 业务经理审核发票并付款。
- 他们可以随时选择根据他们在该地区的结果运行报告,以帮助确定未来的战略。
混合流程与纯连续流程之间的区别在于,混合流程定义了步骤和责任。 经理可以轻松查看所有内容的位置并预测截止日期。 如果有错误,他们可以追踪并纠正它们。 它增加了对持续流程的监督,同时利用了自动化的优势。
企业模型的持续本地化过程需要使用单一的localization management platform。
如果没有平台的结构,一个旨在优雅和简单的流程就会变得笨拙且难以管理。
持续本地化最佳实践是通过创建项目和基准来对您提交的工作进行监督。 这样,您就可以获得不断移动和重新集成字符串的好处,同时减少截止日期、计费和任务管理方面的混淆。
持续本地化只是一个简单的工具,适用于开发人员,而混合持续本地化是一个企业范围的解决方案。