手动 i18n 的流程，及痛点
- 基本功能实现
- 提取文本到默认语言的本地翻译 locale 文件。通常使用英语，但是如果主要群体是国内用户的话，我默认使用中文
- 翻译文件名使用 locale 命名。例如，zh, en 等。我这种个人开发做得比较粗糙，没有针对同一语言不同地区/国家做区分，例如，en_US，en_IN, zh_CN, zh_TW.
- 将默认翻译文件内容，复制到 Google 翻译网页版里，然后逐个语言翻译，并复制到对应的其他语言文件中。这个过程枯燥而繁琐
- 复制内容是 key value 格式的，需要将翻译后的 value 手动摘出来
- Google 翻译选择语言的界面，要找到一门语言，也是相当耗时
- 黏贴到目标语言文件对应的 key 上，需要查找，且复制到对应的字符串双引号内。这个过程非常不适合 VIM，得替换成 VS Code / 记事本之类的 GUI 编辑器。
- 终端下 VIM 对某些小语种有显示问题，例如，泰语，阿拉伯语，会导致界面错乱。要反复关闭打开 VIM 解决。
- 多个子功能的用到的翻译，可能散落在各处，容易遗漏。需要能自动同步默认翻译文件所有 key 到对应语言。避免，编译后运行异常，浪费调试时间
- 逻辑部分设置支持的语言列表。为了流量最大化，通常要将 50 多门语言都支持一遍，这个逐个设置过程非常费时。最好是写一个全局配置，自动支持所有语言。而这个的前提是先生成所有的语言翻译文件，再逐个 key 匹配
i18n 需求汇总
- 对小语种兼容性好的编辑器
- 自动生成所有翻译文件，并以 locale name 命名
- 自动同步默认翻译文件的 key。没有翻译时，默认值为 NO_TRANS
- 一个所有 locale 的清单。这个理论上每个语言都有内置的库，实在没有再整理成配置文件，或者数据库
- 指定部分文本进行翻译，随着项目功能的增加，一次将所有资源都翻译完不现实，有可能超过翻译服务的字数限制
- 基础功能翻译的精确性
- 功能描述翻译对翻译准确性不是太高
- 是否有免费的自动翻译 API：Google，微软等。看起来微软的 Azure 免费额度更靠谱一点，Google 是送代金券这个太麻烦，而且本身在国内没法直接使用谷歌的服务。
微信关注我哦 👍
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式