滴滴出行小程序I18n最佳实践

	背景 I18n = Internationalization 国际化 因为单词由首末字符i/n和中间18个字母组成 简称i18n 对程序来说 就是要在不修改内部代码的情况下 能根据不同语言及地区显示相应的界面 以支持不同 语言的人顺利使用程序。 业务背景 互联网行业进入下半场 精细化运营是关键。多语言支持能让产品更好地服务境内的其他语言用户也为产品 出海打下基础 随着 WeChat/Alipay 的全球化 你的小程序是否做好准备了呢？ 4月初 滴滴出行小程序团队接到支持英文版的需求 预计上线时间为6月上旬。当前滴滴出行小程序集成的众多业务线和各 种公共库 展示给用户的有前端硬编码的静态文本和服务端下发的文案 都要同步接入多语言。考虑到小程序当前的体量光 文本收集、语料翻译 npm package 支持 联调 测试 沟通成本等等 并且前端开发只投入1.5人力的情况下 时间是蛮紧迫的 但是我们抗住了压力 最终英文版滴滴出行小程序如期上线 截止目前运行稳定 用户反馈良好 得到了超出预期的收益。 当然这一切得益于各团队同学的高效工作 和各团队的通力配合 更得益于部门技术团队 Mpx框架优雅的多语言能力支持。 划重点来咯 所谓工欲善其事必先利其器 如果你的公司业务需要开发小程序 也需要接入多语言 那么请搬好小板凳我们来 看一下小程序框架 Mpx 是如何优雅支持多语言能力相信看完这篇可以帮助你认识 Mpx(https://github.com/didi/mpx) 加深对框架的理解，最终利用 Mpx 框架高效迭代小程序 年终奖多出那部分可以打赏一下作者 买杯咖啡哈 以下是滴滴出行小程序的中英文版本对比： 也欢迎大家在微信/支付宝里搜索滴滴出行小程序 实际使用感受下。PS：切换语言的方法是 打开小程序点击左上 角用户头像 进入侧边栏设置页面 点击切换中英文即可体验。 技术背景 在上述业务背景下 Mpx 框架——滴滴自研的专注提升小程序开发体验的增强 型小程序框架内建 i18n 能力便提上日程。 与 WEB 不同 小程序 本文以微信小程序为例 运行环境采用双线程架构设计 渲染层的界面使用 WebView 进行渲染 逻辑层 采用 JSCore 线程运行 JS脚本。逻辑层数据改变 通过 setData 将数据转发到 Native 微信客户端 Native 再将数据转发到渲 染层 以此更新页面。由于线程间通信成本较高，实际项目开发时需要控制频次和数量。另外小程序的渲染层不支持运行 JS 一些如事件处理等操作无法在渲染层实现 因此微信官方提供了一套脚本语言 WXS  结合 WXML  可以构建出页面的结构。 基于小程序的双线程架构设计 实现 i18n 存在一些技术上的难点与挑战 由于 Mpx 框架早期构建起来的强大基础 最终得以优雅支持多语言能力 实现了和vue-i18n 基本一致的使用体验。 使用 在使用上 Mpx 支持 i18n 能力提供的 API 与 vue-i18n 大体对齐 用法上也基本一致。 模板中使用 i18n 编译阶段通过用户配置的 i18n 字典 结合框架内建的翻译函数通过 wxs-i18n-loader 合成为可执行的 WXS 翻译函数 并自动注入到有翻译函数调用的模板中 具体调用方式如下图。 // mpx文件 <template>   <view>     <view>{{ $t('message.hello', { msg: 'hello' }）}}</view>     <!-- formattedDatetime计算属性，可基于locale变更响应刷新 -->     <view>{{formattedDatetime}}</view>   </view> </template> 复制代码 JS 中使用 i18n 通过框架提供的 wxs2js 能力 将 WXS 翻译函数转换为 JS 模块注入到 JS 运行时使运行时环境中也能够调用翻译函数。 // mpx文件 <script>   import mpx, { createComponent } from '@mpxjs/core'   createComponent({     ready () {       // js中使用       console.log(this.$t('message.hello', { msg: 'hello' }))       // 局部locale变更，生效范围为当前组件内       this.$i18n.locale = 'en-US'       setTimeout(() => {         // 全局locale变更，生效范围为项目全局         mpx.i18n.locale = 'zh-CN'       }, 10000)     },     computed: {       formattedDatetime () {         return this.$d(new Date(), 'long')       }     }   }) </script> 复制代码 定义i18n 字典 项目构建时传入 i18n 配置对象 主要包括语言字典和默认语言类型。 new MpxWebpackPlugin({ i18n: {     locale: 'en-US', // messages既可以通过对象字面量传入 也可以通过messagesPath指定一个js模块路径在该模块中定义 配置并导出，dateTimeFormats/dateTimeFormatsPath和numberFormats/numberFormatsPath同理 messages: {   'en-US': {   message: { hello: '{msg} world'         }       },       'zh-CN': {         message: {           hello: '{msg} 世界'         }       }     },     // messagesPath: path.resolve(__dirname, '../src/i18n.js')   } }) 复制代码 如果是通过 Mpx 提供的 cli 工具生成的项目 这部分配置会在 mpx.conf.js 文件中 不光可以直接内 联写在该文件中也可以指定语言包的路径。 以上 Mpx 的 i18n 方案接入成本低 使用优雅 体验优秀。直观感受可参考下面 mpx i18n demo ：https://github.com/didi/mpx/t... 方案 Mpx框架的 i18n 支持几乎完全实现了 vue-i18n 的全部能力下面我们来详细 说明 Mpx 框架 i18n能力的具体实现。 方案探索 基于小程序运行环境的双线程架构 我们尝试了不同方案 具体探索过程如下： 方案一：基于 Mpx 框架已提供的数据增强能力 computed 计算属性 来支持 i18n 。该方案与 uniapp 的实现思路相似 后文会进行对比分析 存在一定不足 包括线程通信带来的性能开销和for循环场景下的处理较复杂等 最终放弃。 方案二：基于 WXS + JS支持 i18n 适配。通过视图层注入WXS 将 WXS 语法转换为 JS 后注入到逻辑层 这样视图层和 逻辑层均可实现 i18n 适配 并且在一定程度上有效减少两个线程间的通信耗时 提高性能。 从性能和合理性上考虑 我们最终采用了方案二进行 Mpx 的 i18n 方案实现。 Mpx i18n 架构设计图 由于各大小程序平台上 WXS 语法和使用均存在较大差异 因此该方案实现过程中也存在一些技术上的难点 这些难点基于 Mpx 框架的早期构建起来的跨平台能力也一一得以攻克 具体如下。 实现难点 WXS 在模板中运行的跨平台处理 WXS 是运行在视图层中的 JS可以减少与逻辑层通信耗时 提高性能 因此 Mpx 框架在迭代初期便已支持在模板和JS运行 环境使用 WXS 语言，并且针对小程序跨平台 WXS 语法进行抹平。 在模板中 Mpx 自定义一个 webpack chunk template 以微信 WXS 作为 DSL 利用 babylon 将注入的 WXS 转化成 ast 然后遍历 ast 节点 抹平各大平台对 WXS 语法的处理差异 输出各平台可以识别的类 WXS 文件。目前主要支持微信 WXS 支付宝(sjs 百度(filter) qq(qs) 头条(sjs)等小程序平台。 WXS 在逻辑层运行的跨平台处理 WXS 与 JavaScript 是不同的语言 有自己的语法 并不和 JavaScript 一致。并且 WXS 的运行环境和其他 JavaScript 代码是隔离的 WXS 中不能调用其他 JavaScript 文件中定义的函数 也不能调用小程序提供的API。 因此在逻辑层 Mpx 将注入的 WXS 语法转化为 JS通过 webpack 注入到当前模块。例如 WXS 全局方法getRegExp/ge tDate在JS中是无法调用的 Mpx将它们分别转化成 JS 模块 再通过 webpack addVariable 将模块注入到 bundle.js 中。 同理 Mpx 会将编译时注入的 i18n wxs 翻译函数和 i18n 配置对象挂载到全局 global 对象上 利用 mixin 混入到页面组件 并监听 i18n 配置对象 这样JS和模板中即可直接调用 i18n 翻译函数 实现数据响应。 以上便是 Mpx 框架在小程序中支持 i18n 能力的技术细节 由于 WXS 是可以在视图层执行的类 JS 语法的一门语言 这样就减少了小程序逻辑层和视图层的通信耗时 提升性能。但是由于实现依赖类 WXS 能力 以及 WXS 执行环境的 限制目前模板上可直接使用的翻译函数包括 $t/$tc/$te  如果需要格式化数字或日期可以使用对应的翻译函数在JS中 Mpx 提供的计算属性中实现。 输出 web 时使用 i18n Mpx同时还支持转换产出H5 而 Mpx 提供的 i18n 能力在使用上与 vue-i18n 基本一致 输出 web 时框架 会自动引入vue-i18n 并使用当前的 Mpx i18n 配置信息对其进行初始化 用户无需进行任何更改 即可输出 和小程序表现完全一致的 i18n web 项目。 对比 上面分析了 Mpx 框架的 i18n 方案的技术细节 我们来看下和其他方案的对比 主要是和 uniapp - 基于 Vue 编 写小程序的方案 和微信官方的方案 两者提供的 i18n 支持与Mpx的对比有何优劣。 uniapp的方案 uniapp 提供了对 i18n 能力的支持 是直接引入vue-i18n。但小程序中无法在模板上调用 JS 方法 本质上是利用 计算属性 Computed 转换好语言 然后利用模板插值在小程序模板中使用。 模板中： <view>{{ message.hello }}</view> JS里需要写： computed: {     message () {      return { hello: this.$t('message.hello') }     }   } 复制代码 因此该方案存在一个性能问题 最终的渲染层所看到的文本还是通过 setData 跨线程通信完成 这样就会导致线程间通信增多 性能开销较大。 并且 早期这种形式使用成本较高 后来 uniapp 也针对其做过优化 实现了可以在模板上写 $t() 的能力 使用上方便了不少。 这个t() 的实现是在编译时候识别到t()的实现是在编译时候识别到t 就自动替换 帮你替换成一个 uniapp 的 computed 数据因此 数据部分还是和之前一样要维护两份。尤其是模板上的for循环 即使 for 里只有一个数据要被转换 整个列表都要被替换成一个计 算属性 在线程间通信时进一步加大了性能开销。 微信官方的方案 微信小程序本身也提供了一个 i18n 的方案 仓库地址是：wechat-miniprogram/miniprogram-i18n 。 这个方案从i18n本身的实现来讲和Mpx框架的设计是类似的 也是基于 WXS 实现 英雄所见略同啊但因为周边配套 上没有完整的体系 整体使用体验上就也略逊于基于Mpx框架来开发支持 i18n 的国际化小程序了。 主要的点就是 官方提供的方案 要基于gulp工具进行一次额外构建 同时在JS中使用时候还要额外引入一个 behavior 去让JS中也可以使用翻译能力。 而Mpx框架通过一次统一的Webpack构建产出完整的内容 用户无需担心语言包更新后忘记重新构建在JS中使用的 时候不光更方便 而且语言信息还是个响应式的 任何组件都可以很方便地监听语言值的变化去做一些其他的事情。 最后 Mpx的 i18n 方案对比微信官方的方案还有个巨大的优点 结合Mpx的跨平台能力 能实现均以这个方案一套 代码产出支持微信/支付宝/百度/QQ/头条多个平台的支持 i18n 的小程序。