前言
最近在维护一份多元易用的工具站开发，想着先把基础的框架能力先确定了方便未来扩展，否则等项目复杂起来再去调整就比较耗时。所以这篇文章主要是对国际化方案的一个设想，先记录一下避免后续忘记。
现在市面上的国际化方案可以大致分为三种：
- 一种是传统的
i18n方案，vue和react都有对应的库可以使用。 - 另一种则是通过借助
Google等翻译API的能力在编译阶段进行翻译和保存配置文件。 - 其他则是在
i18n的基础上进行封装和优化，使其更在编写业务时更简洁方便
作者接触过传统i18n的业务开发，发现其中有几个比较让人在开发中比较难受的点。一个是在开发中需要在标签语法通过i18n函数加上对应各种语言的Token来进行文本的描述，具体写法如下所示：
function App() {
const { t } = useTranslation();
return <h2>{t('Welcome to React')}</h2>;
}
t函数里的Token对应的则是各种语言的映射配置文件：
{
"en": {
"Welcome to React": "Welcome to React and react-i18next"
}
}
这种写法让人难受的点在于业务开发时，看到对应的token都无法明确知道这块文本的具体含义，对于刚接触项目的同学来说简直就是噩梦，因为使用token去做映射意味着当我们需要通过页面中的文本去查找对应代码时，发现永远无法在第一次检索就能找到对应的代码块，需要先找到配置文件中的文本，再去检索文本token对应代码所在的位置。
第二种通过翻译api进行自动翻译的自动国际化方案，我觉得是可行的，但是作者没有去实操过他们的库，看过对应的文章分享，其中的思路和实现方法确实能够解决传统i18n国际化中的一些缺点并且能够减少大量花在翻译处理上的时间，其中一篇文章中描述的思路如下：
插件基于babel去解析页面中的目标字符，然后统一翻译，翻译结束之后会生成一个json的配置文件，如果认为谷歌翻译不准确，就可以通过修改json文件的内容更换翻译内容。而且翻译的key是基于hash算法生成类似对称加密，相同的字符key都是一样的，所以不会反复翻译。同时翻译是统一收集字符之后再组装翻译文本，翻译之后然后切割翻译内容写入json配置，不用担心发出大量翻译请求。 链接：juejin.cn/post/730151…
最终设想
作者的最终设想则是在两者的基础上进行结合和优化，借助翻译api自动翻译的能力减少大量基础翻译的工作，在自定义函数中编写业务需要的中文文本，通过babel的AST解析能力，加上对称算法的能力自动生成唯一的token，并通过token加翻译文本生成不同语言的配置文件放在约定路径中。自定义函数则是通过localstorage确定当前的语言并引用约定路径的国际化配置文件进行映射。
其中要实现和优化的地方有如下几点：
- 在编译过程中避免对已存在的
token进行重复翻译和覆盖 - 在还未生成相应
token或配置文件时，需要做好兜底处理 token生成算法的选择及生成AST时函数中的翻译和配置文件生成的处理- 为当前解决方案做好独立成库的准备，预留拓展能力
总结
写下这篇文章主要是因为作者想把当前的设想先记录下来，未来有时间了再去实现，目前主要的工作还是在工具站中各项功能的业务实现，先不考虑太多优化和拓展方面的实现，先确保基础功能的正常使用，不断拓展和优化工具站的实用功能当前的主要开发目标。
也欢迎各位对工具站提功能或建议，你们就是我的产品经理
作者会持续进行更新，欢迎各位watch或者star。
