Lingui.js—React 前端国际化工作流解决方案

       js 日期国际化，轮子满天飞，ECMAScript 推出原生Intl对象后，百花齐放的局面才开始迅速向原生靠拢… 并直接导致 moment.js 的弃坑 ，进化向了 luxen.js。采用js原生API的国际化日期库(day.js) 开始涌现，并以"玲珑小巧、相恨建晚的真香"姿态迅速抢占了相关市场份额，引领了一波国际化库迭代的潮流。react 前端国际化解决方案也在不断演进，如react-18next、react-intl-universal、Lingui.js 、react-intl (format.js)、fbt、kiwi 等等。除了前两位大哥还停留在对原生js的友好支持外，其余均已迈向工作流化。本文从 传统前端国际化痛点、工作流解决方案、lingui.js 与 format.js(react-intl)对比 三个方面引入和介绍react国际化工作流的基本概念和流程，以及为什么推荐使用 lingui.js。

传统前端国际化痛点：

       笔者之前采用react-intl-universal。开始做点样例用起来还挺顺，文案按需加载照这着官方示例稍作修改即可。可是做着做着就发现不对劲了，json的文案得编辑通常需要集中管理，一个语言对应一个json文件。工作流程大致如下：每次新增个组件，遇到需要需要国际化的地方，都得小心翼翼的去locales目录下修改相应的json文件。并且命名还得有点规则。一不小心名字就冲突了，一不小心就遗漏了。国际化文案通常得由码农们自己去维护这几套json文案。组件新增、修改变化频率高，翻译协作困难。

       如果想CDN发布国际化资源，json格式是首选。但集中的方式维护 json 文案比较麻烦，首先想到要有个支持js的，import来，export去，按组件管理文案，名字不就不容易冲突了吗？于是就找到了 react-18next、react-intl(<5版)。这么一看就能按组件分割开不同的国际化文档了。

       这种方式由于采用js，如果国际化文案需要做动态加载时，通常会被分块打包到chunk块中。使用js，文案管理是清晰点了，名字也不容易冲突，但是遗忘导致不同步问题还是不能解决，工作的流程依然没有改变，团队协作依然困难。这种作坊式国际化的弊端总结如下：

1. 维护国际化文案繁琐且困难，开发麻烦
2. 无法知道项目中是不是还有未同步的文案，
3. 调试查找麻烦 国际化涉及到多个相关人员，团队协作困难
   正因为如此，不少库就提出了国际化全流程解决方案。

react国际化工作流解决方案

       目前react国际化工作流的解决方案，基本大同小异，核心的步骤通过命令完成提取，翻译，合并。 以format.js 为例， 国际化工作流解决方案通常分为以下步：

       提取：通过命令将组件或代码中的 defaultmessage 聚合到一个JSON或po文件中，并随附说明，以便翻译。
       消息上传：此步骤将需要翻译的中间文案上传至翻译供应商(或翻译团队)。
       翻译下载：将翻译供应商(或翻译团队)将翻译的结果提交给代码团队。
       编译合并：代码团队通过命令，这将把翻译消息编译合并后提交回代码库。

       如果这个抽象图看起来太抽象，不之所云，不够直观，由于Lingui.js与 format.js国际化流程基本一致那么，以Lingui.js 结合上诉步骤，json格式为例：

       kiwi,fbt 的国际化工作流也大致类似。有些额外在IDE环节，或者翻译环节丰富了些工具。以kiwi官方文档的国际化全流程解决方案为例：

       fbt 和 kiwi 方案，有点复杂，上手难度较大，配置较多，踩坑多。简单上手，推荐使用lingui.js或者format.js。

lingui.js 与 format.js(react-intl)对比

该对比内容源自 Comparison with react-intl 官方文档，保留原汁原味，其中复数内容基本相同，故省略，其余仅作少量修改

       react-intl无疑是react最流行和使用最广泛的i18n库。lingui.js在很多方面非常相似：两个库对（消息的ICU-消息格式）使用相同的语法，而且它们也有非常相似的API。

       以下是react-intl 一个示例：

<FormattedMessage
   id="welcome"
   defaultMessage={