多语言软件 i18n 的手动实现流程,及痛点

更新日期: 2022-10-18 阅读次数: 1731 字数: 718 分类: 头痛的问题

手动 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 是送代金券这个太麻烦,而且本身在国内没法直接使用谷歌的服务。

tags: i18n

关于作者 🌱

我是来自山东烟台的一名开发者,有敢兴趣的话题,或者软件开发需求,欢迎加微信 zhongwei 聊聊, 查看更多联系方式