上一篇文章我们讲了语言包的维护，今天继续讲讲语言包的自动翻译。
翻译工作流
我们这里讲的自动翻译指的是机器翻译，虽然机器翻译未必准确，但在它可以帮助我们快速实现原型，这在项目初期确实能很大地提升开发效率。
我们可以将国际化翻译的工作流拆成以下三个阶段：
- 开发阶段：前端开发需要提取和维护
源语言包(Source Language)。比如将页面中的文案提取到 zh 语言包中。接着基于源语言机器翻译到其他语种。 - Review 阶段：这个阶段主要的参与者是专业翻译人员。他们会根据具体的产品需求上下文、以及对目标语种的了解，对机器翻译的结果进行校对。
- 更新阶段：将校对后的语言包回写到项目中，更新和发布。
这里有几个问题:
一） 怎么选择源语言？
如果从翻译的效果上看，英语通常是最好的源语言，以下是 ChatGPT 给出的几个原因：
- 广泛使用：英语是全球最广泛的工作语言和交流语言，许多国家和地区都将其作为第二语言进行学习和使用。
- 丰富的词汇：英语的词汇数量庞大，对各种概念和现象都有准确的描述，这使得从英语翻译到其他语言时可以更准确地表达原文的意思。
- 国际化规范：许多国际化和本地化的标准和规范，如i18n，都是基于英语的，这意味着从英语翻译到其他语言的过程可以更好地遵循这些规范。
- 世界范围内的资源：有大量的从英语到其他语言的翻译资源，这可以帮助翻译者更好地完成工作。
然而作为英语非母语者，实施起来可能会比较麻烦: 一是从业者英语水平良莠不齐，二是我们的产品、需求、原型可能都是以中文为基准的。
因此大部分情况下，我们不得不将中文作为源语言。
二）Review 阶段有什么平台或者工具来支持？
Review 阶段的主要参与者不是开发人员，所以我们需要提供一些简单、易用的工具或平台来支撑他们的校对工作。
比如在我们公司采用的就是最为原始的烹饪方式 ------ Excel 文件 ，这个下文会讲到。我们会将整个项目的语言包汇总到 Excel 中：
专业的翻译人员可以直接校对和编辑这个 Excel 文件，借助一些在线文档工具，可以实现基础的多人协同工作。
校对完毕后，回传给开发者，再同步到项目的语言包。
如果是大型项目，参与的人员会非常繁杂，工作流显然也会比较复杂，可能会涉及多团队、多角色协同...
这时候，可以选择市面上一些更专业的工具或者 SaaS 服务， 比如：
国际化、本地化有非常多成熟的商业化 SaaS 方案， 读者可以通过这个榜单找到更多选择。
不过对于中小型项目，会有中杀鸡用牛刀的感觉。
使用 i18n ally 插件
上一篇文章中，我们简单介绍了 i18n-ally 这个神器。它的能力远远不止这些， 现在我们继续挖掘它的能力。
硬编码自动识别和提取
ally 插件支持识别文件中的硬编码字符串，并支持一键提取。
它会根据当前的使用的框架来改写源文件：
只不过它默认生成的 key 有点不符合需求：
笔者建议手动进行精细化的提取：
机器翻译
i18n ally 插件还内置了强大的机器翻译功能：
- 支持 Google、DeepL、Libre 等机器翻译引擎。
- 可以自动识别出未翻译的 key
- 支持批量翻译
- 支持对 key 进行「重构」。这个很方便，ally 插件会自动更新语言包和相对应的源代码
Review 系统
ally 插件也内置了建议的翻译 Review 工作流：
这种方式简易、精妙。 Review 记录会跟随着代码仓库一起迭代，可以灵活地进行版本化和分支管理。
不用处理因为代码仓库和 Review 工具流的割裂而导致的额外同步问题。
i18n-ally 麻雀虽小五脏俱全，足以应付中小型项目的语言包维护、翻译工作流等需求。
如果你有更复杂的需求， 也可以考虑 i18n-ally 的背后维护团队的商业化产品 ------ lokalise
最后，再次膜拜 Anthony Fu， 真奇人也。
bbt 巴别塔
为了更高效地翻译和生成语言包，我们也开发了一个工具 ------ bbt。这是一个自动化管理和翻译语言包的命令行工具。
它的工作流如下所示：
bbt 提供了三个基础的子命令，分别对应工作流的三个阶段:
- 收集(bbt collect) : 这个阶段会以
源语言为基准，发现并整合当前项目的所有语言包，然后统一写入到bbt.csv文件中。方便下一步处理。 - 翻译(bbt translate) ： 收集到
bbt.csv之后， 就可以调用bbt translate命令进行'机器翻译'。接着，可以选择将机器翻译之后的bbt.csv发送给专业的翻译人员进行校对 - 写入(bbt write) : 将校对/变更后的
bbt.csv回写到语言包中。bbt 会以源语言包为基准，将 bbt.csv 的所有变更回写到语言包，并自动补全缺失的语言包和 key/value。
下面简单演示一下。关于 bbt 的安装和初始化过程，可以参考 Github ，这里就不赘述了。
收集
假设我们的项目结构如下：
- 源语言是 zh
- 支持 zh、en、zh-Hant、ko 四种语言
- 包含 module-1、module-2 两个子模块和对应的
源语言包。
接着，我们可以执行 bbt collect 命令来汇总语言包：
bash
$ bbt collectbbt 会以源语言包为基准，将所有的 key/value 汇总到 bbt.csv 中：
我们可以看到这个文件包含了一些基础的信息，比如语言包的路径、key, 以及翻译的内容。
💡 为什么使用 csv? 因为它是一个纯文本格式，方便在代码编辑器中修改和展示；能够被版本库记录变更历史；最后是可以方便地处理合并冲突。
翻译
接下来就可以执行 bbt translate 对 CSV 进行机器翻译：
bash
$ bbt translatebbt 支持 Google、DeepL、ChatGPT(实验性) 等服务来翻译。翻译完成 bbt.csv 如下所示：
回写
假设翻译和校对流程搞定了，bbt 支持将 bbt.csv 文件的内容同步回项目的语言包，只需要执行 bbt write 命令：
bash
$ bbt writebbt 会以源语言包的基准，补全缺失的语言包、Key/Value、更新变更的内容：
综上，bbt 的核心工作流围绕着单一数据源 ------ bbt.csv 文件展开。和 i18n-ally 相比， bbt 更加擅长批量的语言包翻译和同步工作。
两者不是取代与被取代的关系，而是一种互补关系，笔者更建议将两者结合起来，DX++
总结
本文简单介绍了多语言自动翻译的工作流，这个可盐可甜:
对于中小型项目，使用 i18n-ally 这个神器就可以满足基本需求，它给我们带来了很多便利的功能，让前端国际化的开发体验得到的指数级的提升。
接着我给我们团队开发的工具------ bbt ，带了下货，和 i18n-ally 相比， bbt 更加擅长批量的语言包翻译和同步工作，可以快速根据源语言批量翻译和生成其他语言包。两者可以互补使用，进一步提升语言包的维护效率。
对于大型项目，涉及到复杂的多人协作、需要更专业的翻译服务、语言包管理服务，那么可以考虑市面上一些成熟的 SaaS 服务。
最后求✨✨ ⭐️✨✨ ------ bbt