利用 Bluemix 的 Globalization Pipeline 服务实现程序的持续翻译

开始之前

随着敏捷开发和持续交付等理论逐渐成为业界共识并付诸实践，全球化/本地化领域传统的“抽取英文源字串人工翻译-翻译返回打包-翻译验证性测试-修改打包再进行回归测试”的工作流程显然已成为了视敏捷为生命的 DevOps 实践的瓶颈。而在机器翻译技术日臻完善的背景下，应用机器翻译实现程序翻译的自动化并纳入 DevOps 的生命周期看上去是一个不错的选择。本文介绍的就是这样一个服务-由 IBM 全球化部门在 Bluemix 上新推出的 Globalization Pipeline 服务，该服务隶属于 DevOps 服务群组，其在基础 DevOps 生命周期中新增了程序界面的机器翻译以及程序上线后在线改进翻译的能力。

传统程序翻译的交付流程及挑战

长期以来，全球化软件生产领域一般采取的是如下图所示的生产流程：“开发团队抽取英文源字串提交给翻译团队->翻译团队按字收费翻译后返回开发团队->开发团队构建含有翻译的安装包->测试团队获取含有翻译的安装包并与翻译团队协作执行翻译验证性测试->翻译团队根据测试结果修改翻译并返回开发团队->开发团队构建含有新版翻译的安装包->测试团队与翻译团队协作执行翻译回归测试”。

图 1. 传统程序翻译的交付流程

该流程冗长复杂，再加上各个翻译团队和开发测试团队所处时区可能不同，像 2,3,5,6 这种传送翻译包和安装包的过程很可能会延宕数日，这极不符合敏捷和 DevOps 的要求。所以如果有一个服务能够完成“实时”的翻译获取和翻译完成后自动的打包构建，将极大地简化全球化应用的交付过程。由 IBM 全球化团队研发的 IBM Globalization Pipeline 服务就在做这么一件事。

IBM Globalization Pipeline 服务简介

IBM Globalization Pipeline 服务提供了机器翻译和界面翻译实时编辑的能力，这使得客户可以快速翻译 Web 或移动应用界面。该服务可以直接在本地单独使用或者在 Bluemix 应用中调用。它提供了快速创建，维护，修订翻译的能力，这一切只需要很少的人力而且还可以通过 Bluemix 仪表板或者 RESTful API 无缝集成到程序的交付管道中，完全不需要脱离现有的 DevOps 交付管道。以上赋予了用户无需重新构建和部署就可以将应用发布到全球客户手中的能力。

借助 IBM Globalization Pipeline 服务，用户可以创建资源包，资源包中包含了将被翻译的界面字串源文件。资源文件可以是下面格式的任何一种，唯一的要求是文件中必须以键值对来代表程序中的界面字符串：Java Properties、JSON、AMD i18n。

除此之外，界面字串源文件还必须遵守下列规则：

-每个键最多 126 个字符

-每个值最多 2048 个字符

-每个资源文件最多包含 500 个键值对

-每个资源文件不大于 2MB

当合规的源文件上传后，文件中的内容使用机器翻译技术可以翻译成下列语言：简体中文，繁体中文，法文，德文，意大利文，日文，韩文，巴西葡萄牙文和西班牙文。虽然现阶段源文件只支持英文，但是随着 IBM Globalization Pipeline 服务的日臻完善，相信未来将会有越来越多的源语言与目标语言被支持。

在创建语言包之后，用户可以随时移除语言，编辑生成的翻译，甚至更新语言包中的源文件并重新生成翻译。如果原始的源文件被更新，源文件中的键值对会与最新版本的源文件进行比较，只有变化的键值对会被翻译。下面我们就看一下 IBM Globalization Pipeline 服务仪表板中是如何提供这些操作的。

IBM Globalization Pipeline 服务仪表板

IBM Globalization Pipeline 服务简单高效的用户界面使得将应用全球化变得很简单，下面将介绍如何通过 IBM Globalization Pipeline 服务仪表板来快速地翻译 Bluemix 应用。

创建 IBM Globalization Pipeline 服务

1. 从 Bluemix 仪表板的导航栏单击目录

图 2. 从 Bluemix 仪表板进入服务目录

2. 选中 DevOps 类服务后单击其中的 Globalization Pipeline 服务

图 3. 选择 DevOps 类服务中的 Globalization Pipeline 服务

3. 选择工作空间和是否需要将服务绑定到现存应用上

图 4. 创建 Globalization Pipeline 服务

创建资源包

1. 在 IBM Globalization Pipeline 服务仪表板的摘要标签页单击新建资源包

图 5. 新建资源包-1

2. 输入资源包 ID，选择源语言，上传源文件，选择文件格式和目标语言。

图 6. 新建资源包-2

资源包被创建之后，上传的源文件会被翻译成所有指定的目标语言，新建的资源包出现在资源包标签页可供进一步管理，如图 7 所示。在该列表中可以删除语言包，删除时与其关联的所有翻译均会被删除。

图 7. 资源包列表

管理资源包

单击某个资源包之后可以管理该资源包，如图 8 所示，与资源包相关的重要信息都可以在这里被访问到。用户可以看到各个目标语言翻译的状态（根据资源包所处的进度状态不同，每个语言翻译的状态可以是以下状态：正在翻译，翻译失败，已完成翻译）、添加或者移除语言，修改翻译或者提供源文件的更新。

图 8. 资源包中的资源列表

更新源文件可通过单击英语行末的上传图标进行，如图 9 所示。新版源文件中的键值对会与之前上传的版本进行比较。只有新增或修改的键值对会在源文件上传之后被翻译。

图 9. 更新源文件

此外资源详情页还提供了以下功能：向现存资源包添加目标语言、从现存资源包删除目标语言、下载目标语言翻译、查看和编辑翻译。

IBM Globalization Pipeline 服务提供了人工事后编辑翻译的能力，该功能允许母语为目标语言或者熟悉目标语言的人修改机器翻译的结果以提高翻译的质量或者修改机器翻译的措辞，比如对于产品名称的翻译。如图 10 所示。

图 10. 查看和更新翻译

当资源文件中含有太多字串时，还可以通过搜索功能搜索具有特定键、值、或者翻译的字串，如图 11 所示：

图 11. 搜索字串

用户管理

管理应用程序翻译有时候会涉及不同的角色，用户可能需要为资源包设置访问限制，为不同的角色赋予不同的操作权限。IBM Globalization Pipeline 服务提供了一种简单的方法来创建用户并分配独特的权限，这样使得对翻译资源包的访问限制变得很简单。

在图 11 中单击“用户”标签页可以进入用户页面，如图 12 所示。目前列表中的三个用户是在创建服务或者调用服务时系统自动生成的：注释为空的用户为创建服务时生成的默认系统管理员用户，可以直接在本地应用中基于该用户使用服务；另外两个用户为 Bluemix 中的应用在调用服务时服务自动为每个 APP 实例分配的用户。

图 12. 用户列表

在仪表板中单击图 12 中的“新建用户”即可手动创建角色，创建角色时不仅可以基于用户需要执行的任务提供不同等级的访问权限，还可以针对一个或多个特定的资源包设定访问权限，如图 13 所示。

图 13. 新建用户

IBM 机器翻译最佳实践

正如那些使用过机器翻译在线翻译网站或者文本片段（比如使用电子词典）的人们所熟悉的那样，机器翻译可以高效地提供一段源文本的大致含义。然而，机器翻译的质量和有效性受限于目标语言和采用的机器翻译引擎而参差不齐。影响机器翻译质量的的核心因素之一即是原文的质量。含有大量俗语、不完整的句、不正确的标点以及模棱两可的单词或短语的文本很难恰当地被翻译。

当你使用 IBM Globalization Pipeline 服务进行机器翻译的时候，有一些针对英语原文的基本写作指导，他们不仅能提高原文的质量，还可以提高机器翻译的质量，如下表 1 所示：

表 1.IBM 机器翻译之原文写作最佳实践

除了遵循以上指导，强烈建议任命母语使用者来审阅和编辑机器翻译的结果。最后，还应从终端用户那里搜集反馈，他们才是翻译的有效性和正确性的最佳评判者。

IBM Globalization Pipeline 服务使用范例

IBM Globalization Pipeline 服务使用起来非常方便，不管是本地应用还是 Bluemix 中的应用都可以方便地调用该服务获取机器翻译，而且还能将该过程集成进现有的持续交付管道或者 IBM DevOps 服务中的交付管道，后文将从三个具体示例进行演示。

本地 node.js 应用调用 IBM Globalization Pipeline 服务示例

本地项目（参考 gp-nodejs-sample ）可以通过 IBM Globalization Pipeline 服务提供的凭证方便地调用该服务，凭证可在如图 14 所示中获得，将该凭证内容拷贝至 local-credentials.json 文件即可让本地应用合法获得服务的客户端 gpClient 继而使用该服务。

图 14. IBM Globalization Pipeline 服务凭证

之后即可按照上文服务简介中描述的那样依次创建 IBM Globalization Pipeline 服务、在仪表板中新建对应名称的资源包、上传源文件和添加目标语言。经过以上简单配置以后，程序中即可访问该翻译资源，比如在本地 node.js 应用中可以这样使用：

清单 1. 在本地 node.js 应用中使用 IBM Globalization Pipeline 服务

... var gpCred = require('./local-credentials.json');//get local credential var gpClient = require('g11n-pipeline').getClient(gpCred);//get pgClient var mybundle = gpClient.bundle('hello');//get bundle  app.get('/', function (req, res) {  mybundle.getInfo({}, function (err, projInfo) {  ...  }); });  app.get(/^//(/w+)//hello/, function (req, res) {  var lang = req.params[0];  mybundle.getEntryInfo({ resourceKey: 'hello', languageId: lang}, function (err, data) {  ...  }); });  app.get(/^//(/w+)/, function (req, res) {  var lang = req.params[0];  mybundle.getStrings({ languageId: lang}, function (err, entry) {  ...  }); });

运行该应用后可以发现此时本地应用已经可以遍历显示出 IBM Globalization Pipeline 服务中提供的翻译，获取众多语言翻译的时间只需短短的几秒钟，如图 15 所示：

图 15. 本地 node.js 应用使用 IBM Globalization Pipeline 服务示例

Bluemix Node.js 应用调用 IBM Globalization Pipeline 服务示例

修改上面的示例中的 manifest.yml 文件后即可将该应用通过 CF 客户端部署到 Bluemix 平台上使之变成一个 Bluemix 应用，如清单 2 和清单 3 所示:

清单 2. Bluemix 应用部署配置文件 manifest.yml

applications: - name: gp-nodejs-sample-sj  services:  - Globalization Pipeline-i1  disk_quota: 384M  host: gp-nodejs-sample-sj  name: gp-nodejs-sample-sj  path: .  domain: mybluemix.net  instances: 1  memory: 512M

清单 3. 通过 CF 客户端将本地 node.js 应用部署到 Bluemix

The path which mainfest.yml is>cf login -u IBM_ID -o Organization -s Space The path which mainfest.yml is>cf push gp-nodejs-sample-sj

与调用 Bluemix 服务中的其他应用一样，Bluemix 应用可以通过读取环境变量识别调用服务，如清单 4 所示，其中“process.env.BUNDLE_ID”可通过在应用程序仪表盘中的环境变量标签页中增加一个用户自定义变量的方式添加，用以声明我们将要调用的资源包的名字。

清单 4. 在 Bluemix Node.js 应用中使用 IBM Globalization Pipeline 服务

... var appEnv = require('cfenv').getAppEnv(); var gpClient = require('g11n-pipeline').getClient({appEnv: appEnv});  var mybundle = gpClient.bundle(process.env.BUNDLE_ID); ... 将 lBM Globalization Pipeline 服务集成进 IBM DevOps 交付管道

当在 DevOps 管道中使用 IBM Globalization Pipeline 服务时，用户可以自动地将字符串翻译成其他的语言，IBM Globalization Pipeline 将使用机器翻译翻译源文件的过程作为持续交付管道中构建和部署流程的一部分。在 IBM Globalization Pipeline 项目中的机器翻译的结果也可以进行二次修改，因此翻译人员或者母语使用者可以审阅机器翻译的结果并保证翻译的质量。

我们还是以 gp-nodejs-sample @GitHub 为例演示该功能，首先需要将此项目拷贝（Fork）到自己的 GitHub 库中以便在 IBM DevOps 服务（参考 基于 Bluemix 开发云实现一站式的 DevOps ）中能够直接基于该库创建项目。

项目创建好之后，进入构建和部署功能区将机器翻译翻译源文件的过程配置进 DevOps 交付管道，具体步骤如下：

1. 添加一个暂存区。暂存区命名为“暂存区-翻译”，输入类型选择为“SCM 存储库”，如图 16 所示：

图 16. 创建翻译暂存区

2. 在翻译暂存区配置翻译作业。新建一个作业，作为类型选择为“构建”，构建器类型选择为“IBM Globalization Delivery”，源文件名填写为项目中需要翻译的文件名（含后缀），全球化项目前缀填写为要创建的资源包的名称（注意要与程序中调用的资源包名称或环境变量名称对应）如图 17 所示：

图 17. 在翻译暂存区配置翻译作业

3. 创建部署暂存区。输入类型选择为“构建工件”，暂存区设置为紧邻的上一个暂存区即“暂存区-翻译”，作业选择为翻译暂存区中执行翻译进程的“作业-翻译”作业，如图 18 所示。由于翻译文件并没有被提交到存储库中去，只有这样配置才能保证翻译文件可被打包进应用程序。

图 18. 创建部署暂存区

4. 在部署暂存区配置部署作业。新建一个作业，作业类型选择为“部署”，部署程序类型选择为“Cloud Foundry”，应用程序名称填写为 mainfest.yml 中指定的名称，如图 19 所示：

图 19. 在部署暂存区配置部署作业

经过以上配置，特别是在配置翻译暂存区时勾选了“只要将更改推送到 Git 就运行作业”（见图 16）和在配置部署暂存区时勾选了“当前一暂存区完成时运行作业”（见图 18），现在只要修改了英文源文件并提交到存储库中，DevOps 交付管道就会自动依次执行翻译和部署作业。执行翻译作业时 IBM Globalization Pipeline 服务会自动根据翻译暂存区中的配置创建资源包。为了明显期间，我们先在 IBM Globalization Pipeline 服务仪表板中删除前两个示例中创建的资源包 hello（如何删除请参考创建资源包一节），然后在 IBM DevOps 代码编辑功能区中将源文件中的字串由"Hello there, world!"改为"Wow, I made it!"并提交代码（参考 基于 Bluemix 开发云实现一站式的 DevOps ，此时我们进入构建和部署功能区可以看到翻译作业正在运行，如图 20 所示，翻译作业执行成功后部署作业也会执行。

图 20. 翻译进程融入自动交付管道示例

部署作业也运行完成后我们单击图 20 右下角所示的程序链接可以看到翻译已经生成且被打包进入应用程序，如图 21 所示：

图 21. 更改源文件后翻译自动打包

诚然，机器翻译的结果并不一定很理想，比如此例。因此请读者在使用时请尽量参考表 1 里的 IBM 机器翻译之原文写作最佳实践，相信在熟悉机器翻译的局限之后写出的源字符串应该会有比较好的翻译结果。不过即使翻译结果还不理想也无所谓，IBM Globalization Pipeline 服务提供了翻译的在线翻译能力（参考管理资源包一节），翻译的更新可以实时地反映在应用上，如图 22 所示：

图 22. 更改翻译后应用自动更新

总结

综上所述，IBM Globalization Pipeline 服务完美地完成了“实时”的翻译获取和翻译自动打包构建的需求，这极大地地简化了全球化应用的交付过程，补齐了 DevOps 在生产领域的又一块短板。