Singleton之我见（三）

长久以来，所有软件几乎不约而同的对产品翻译资源文件均采用了作为代码一部分的方式统一发布并高度内聚。这样的方式自然有其显而易见的好处，例如不会因为产品本地化而引入任何新的安全问题，性能问题等。然而他带来的问题也不容小觑，作为资深的国际化开发或测试工程师来说，以下场景想必不会陌生。

客户：贵公司本地化产品中XX页面上的翻译存在歧义，甚至会严重误导用户。

工程师：谢谢您的反馈，我们已详细记录了该问题，将在下个版本中修复。

客户：那下个版本何时发布呢？

工程师：请再耐心等待半年。

客户：……

如果该客户有能力重新回到对话的原点，他是否愿意进行这样一场对话呢？

客户：贵公司本地化产品中XX页面上的翻译存在歧义，甚至会严重误导用户。

工程师：谢谢您的反馈，我们已详细记录了该问题，请您在5分钟后刷新页面，再次关注新的翻译内容。

笔者以为，大部分客户的答案都会是肯定的。

而环顾内业已有的解决方案，似乎并没有人把这样细分的需求放在心上，遑论提上日程，直到Singleton的横空出世，才彻底让翻译资源文件和产品代码解耦合的愿望落地成真，并开花结果。

最新版本的Singleton现已提供了若干个翻译相关的API ，例如translation-product-api就可以获取整个产品定义的组件名、支持的语言列表、所有语言的翻译。

GET /i18n/api/v2/translation/products/{productName}/versions/{version}

参数如下：

productName：（必填），string类型，在Singleton中注册的产品名

version：（必填），string类型，在Singleton中注册的产品的版本

pseudo：（默认值）false，string类型，true或false；返回Singleton中的正式翻译，或pseudo 翻译

关注该字段，我们可以发现，该API已经考虑到了传统国际化测试过程中不可或缺的pseudo测试 ，通过简单的设置，即可完成传统测试中制作pseudo build和执行pseudo testing的过程。

返回值是一个JSON对象，包括了对应产品所有语言的翻译。

举例：

{Singleton service}/i18n/api/v2/translation/products/Testing/versions/1.0.0?pseudo=false

GET/i18n/api/v2/translation/products/{productName}/versions/{version}/componentlist

Singleton开源小组的推荐是，按产品按组件/功能去定义并存储字符串，此API用于获取产品定义的所有的组件/功能列表。

除了获取整个产品，部分组件或功能级别指定语言的翻译同样可以使用translation-product-component-api轻松拿到。

GET/i18n/api/v2/translation/products/{productName}/versions/{version}/locales/{locale}/components/{component}

参数如下：

productName：（必填）string类型，在Singleton注册的产品名

component：（必填）string类型，在Singleton定义的组件/功能名称

version：（必填）string类型，在Singleton中注册的产品的版本

locale：（必填）string类型，想要获取翻译的区域，如ja-JP等

pseudo：（默认值）false；当设置为true时，可以为请求的语言返回伪翻译

machineTranslation：（默认值）false；当设置为true时，可以返回机器翻译

checkTranslationStatus：（默认值）false；当设置为true时，可以检查当前翻译是不是已经准备好了。用户可以根据结果判断是否使用当前的翻译。

关注这里的machineTranslation字段，笔者非常推荐使用该字段替代pseudo的作用，毕竟真实的翻译内容可以更好的帮助测试人员在早期就能发现因为文字长度而引入的layout等诸多问题。

返回值依然是一个JSON对象，包括了请求产品组件或功能对应的翻译。

另外Singleton还提供了字符串级别的API translation-product-component-key-api

获取某个字符串的翻译，使用它来处理前文中提到的局部更新情况，再合适不过。

POST/i18n/api/v2/translation/products/{productName}/versions/{version}/locales/{locale}/components/{component}/keys/{key}

请求参数包括：

productName：（必填）string类型，在Singleton中注册的产品名

version：（必填）string类型，在Singleton中注册的产品的版本

locale：（必填）string类型，想要获取翻译的区域，如ja-JP

component：（必填）string类型，在Singleton定义的组件或功能名称

key：（必填）string类型，是该字符串在组件或功能中的唯一标识符

source：（选填）string类型，源语言字符串，若为空则返回对应的字符串在Singleton的翻译。一旦提供的字符串值和Singleton中存储的值不相同，则直接返回输入的字符串值，不再提供翻译

commentForSource：（选填）string类型，对于源语言字符串的注释

collectSource：默认值为false，一旦设为true，同时Singleton字符串收集功能打开，可以直接发送请求的字符串到Singleton

pseudo：默认值为false，当设置为true时，可以为请求的语言返回伪翻译

machineTranslation：默认值为false，当设置为true时，则返回机器翻译的结果

checkTranslationStatus：默认值为false，当设置为true时，则可以检查当前翻译是否已准备完毕，开发和测试人员可以根据结果判断来决定是否使用当前的翻译

与此同时，Singleton还提供了添加新语言和更新某个语言翻译的API，使用方法与前者雷同，不多累述。在平铺直叙了这些翻译相关API的好处后，一起来关注下笔者更关心的性能问题，在产品中大量引入Singleton翻译API后，关于某项操作的响应时间是否会明显或略微增加呢？这个问题在笔者心头萦绕了很久，直到我看到这样的测试数据。

  

多组数据显示，在使用了Singleton翻译API后，响应时间不升反降，平均时间降低了1-2秒钟。为了一探究竟，笔者联系了Singleton开源团队的核心开发人员并得到他们的答案。根源就在于对这些翻译API的response进行了gzip压缩，而一般产品则依然沿用了json格式进行传输，正是这些体积的减小，直接促使了响应时间的降低。

在排除了performance的疑虑后，Singleton头顶的乌云可谓是散去了一大半。最后的担心就在于安全性，我们下文接着聊。