如果这篇文章有幸被你看到，它将向你展示一段时代的眼泪，因为CF在2020.9.17由于目前无法挽回的中印形势已经正式停止服务……
Club Factory是一个跨境电商App，主攻印度市场，它曾在Google Play购物应用类中排行首位，在短短三年时间里成为印度第三大购物App。
在CF这个app诞生之时它就抱有一个远大志向，为全世界人民提供最平价的非标品。因此在大大大前期我们的app就可以选择数十个国家以及多种语言，其中包括英语、西班牙语、阿拉伯语、葡萄牙语、意大利语、印地语、印尼语、@#￥%&……
在前后端紧密耦合的时期，页面文案翻译全部由静态csv文件一手掌控，商品标题等信息一律使用机器翻译。
就这样度过了翻译质量和翻译覆盖率不作太高要求的漫长时期，终于，本地化项目闪亮登场！
欲征服印度，必先使其看懂我们的App
印度民族众多，语言复杂，《宪法》认证的”正规“语言就有22种之多，其余更有千多种。同为人口极多的国家，远不及普通话在中国的普及程度，在印度，即使英语和印地语同为印度的官方语言，英语的普及程度也只有30%，并主要运用于政治和商业交往场合，而全国范围内能理解印地语的人数占比约为80%，是印度使用人口最多的语言。
因此，App的印地语化必将首当其冲，而App的多语言化也随着迎来了巨大的挑战。
在App从实现简单翻译，到最高优先级要求全链路完整翻译印地语的需求转变中，App背后的技术架构已经发生了巨变。大前端有安卓iOS，RN，front-xxx，pc/m站等项目，后端有各个cf-xxx的微服务应用，其中已经多多少少渗透了App内需要展示的文案。这些文案，有的来源于产品需求、交互设计，有的由大数据挖掘而来，散落在代码的各个角落，简直春风吹又生。但幸运的是，这些野草基本都是可控的，“基本”两个字没法自信地去掉，主要是由于对于商品标题等信息的翻译，似乎还有待商讨。
除此之外，例如商品筛选器Filter过滤值虽然千奇百怪，但仍然是有一定规律可枚举的，相比来说前端静态文案和微服务中的文案就更利于管理了。因此：
只要可控，就能搞事！
上文提到，我们需要搞定的文案主要来源于产品需求、交互设计以及大数据，而这些待翻译内容渗透在前端静态、以及微服务应用的各个角落。
这里我们来举个例子：
想要实现首页翻译，在此之前，我们面临几大难题：
- 技术上，一些项目独自维护一份翻译内容，可能是google文档、或是一份csv，更多项目并没有实现翻译功能。翻译内容散乱、翻译功能欠缺。
- 对于翻译人员、产品、测试来说，翻译内容无迹可寻，增删改查十分困难。
为解决这一系列的问题，在反复研究方案之后。
翻译平台横空出世
我们利用一个现有的开源库traduora，打造了一版CF翻译平台。
平台提出了以下几个核心概念：
- 项目 - Project
- 语言（地区） - Locale
- 词条 - Term
- 翻译 - Translation
我们可以在平台上创建一个翻译项目（Project），每个项目里有对应的词条（Term），和相应的语言（Locale），词条+语言即对应一条翻译（Translation）
来看个具体事例帮助理解：
front-web是前端h5项目，我们为它在平台上创建一个Project。其中，app.error_msg.pay_fail_pending、app.error_msg.per_deal等就是这个项目里的词条，HIndi和English分别为这个项目的两个Locale，其中对应的值，也就是此词条对应该语言的翻译文案Translation。
平台支持最基本的项目、语言、词条、翻译的增删改查操作，此外根据实际需求我们还在平台上加入了根据Tag（业务维度分类）查看，以及翻译人员二次检查等功能，我们希望通过这些功能来提高翻译的正确性和覆盖率。
另外，侧边栏看到的Team是具有此项目操作权限的账号，包括Admin、Editor、Viewer三个角色。通常开发人员为Admin、产品翻译为Editor、测试为Viewer，不同角色拥有不同的操作权限；Import和Export方便用户在界面上进行导入导出操作，平台支持csv、xml、json、strings等所需文件格式；API Keys可以支持开发人员生成一些技术对接所需要的授权秘钥。
除front-web之外，目前平台已接入了安卓、iOS、RN、front-web、cf-msite、category、filter、cf-detail、cf-member等20多个项目，覆盖App各个页面的1w+词条，已填充英语和印地语两种语言的翻译内容，计划在Q1结束之前全部上线。
翻译平台界面其实更多是为翻译、产品、测试服务的一个入口，是数据来源、是操作界面，而接下来重点要讲的是在技术方面：
翻译功能是如何运作的
翻译数据流程如下图所示：
- node-translation-admin是翻译平台的界面项目，node-translation-api为翻译服务接口， node-gateway为前后端Node粘合层
其实图上已经都说清楚了，这里再做一点解释。
我们把目前能够处理的文案主要分成两类：
- 前端静态文案
- 接口返回值
前端静态文案的翻译实现：
-
静态文件可以通过 1. 使用界面Export功能导出，2.使用衍生CLI工具cf-translator一键导出
-
前端项目通过本地静态文件实现翻译（可优化）
-
各项目可以使用cf-i18n库进行翻译功能的实现
-
目前支持：纯文案、带变量动态文案、带html标签文案
接口返回值的翻译实现：
- 微应用服务接口（包括部分club-api接口）统一接入node网关
- 在node网关做翻译动作
- 前端从调用cf-gateway接口，改为使用GraphQL调用node网关
- 目前支持：纯文案、带变量动态文案、接口错误码
当然在实现过程中，特别是node网关的翻译实现，我们遇到了重重困难。有调一次需要翻译130个词的接口、有返回文案格式复杂的接口、有文案带变量的接口、有语言码不统一的接口、返回值与词条无法匹配的接口等等。接口内的情况多而复杂，接口内翻译的实现和性能问题也就成为了两大课题。
当然这些难题最后被一一破解👏👏👏 ，个中技术细节可以另开博文细细说来。
至此，翻译工作终于告一段落，前方还有更多的挑战等待着我们。比如大数据挖来的商品标题、图片翻译、翻译平台更改的实时预览等。
不过好消息是只要我们成功接入了第一种语言，之后的其他语言只需要在平台添加locale即可~
本文搬运自2020.4.1__发布于__公司内部论坛的《翻译的前世今生大总结》。
