前端多语言本地化项目的记录

  • 前期规划
  • 注意项
  • 流程的制定
  • 集成与自动化

# 前期规划

在制定多语言方案前，首先需要确定需要支持的语言和地区，并对具体要翻译语言的工作量进行估计。然后需要选择合适的技术框架和多语言插件。

由于我们的项目是 Vue 框架，我们选择了 vue-i18n-next 作为多语言插件，并使用 JSON 文件格式来存储翻译内容。如果需要使用其他格式如 YAML 或自动导入功能，可以考虑使用 @intlify/unplugin-vue-i18n 插件。

在确定了技术选型后，我们需要制定一个友好的多语言文件结构。常见的方法是在多语言目录下创建内容文件，并在内容文件中使用 KEY 来实现多语言。

第一种:

├─locales
│  ├─en
│  │     index.js
│  │     home.js
|  ├─zh-CN
│  │     index.js
│  │     home.js
|  ├─jp
│  │     index.js
│  │     home.js

第二种：

├─locales
|  ├─index.js
|  ├─home.js

// index.js
{
  "en": {},
  "zh-CN": {},
  "jp": {}
}

在确定多语言方案时，我们也需要规避命名冲突问题，并确定如何使用 namespace 来隔离本地化的 Key。因为存在以下问题：

  1. 同一个词可能有多种含义。
  2. 不同的文件可能会出现同名的 Key。
  3. 某些内容很难命名，难以明确建立 Key。

我们的解决方案是使用文件划分来隔离命名空间，通过增加命名关系来解决冲突。对于命名困难的 Key，我们使用 hash 后的内容作为 Key。此外，我们使用扁平化的 JSON 结构来避免嵌套带来的维护成本和复杂度。

{
  "home.banner.text": "这样命名来减少嵌套",
  "home:banner:text": "也可以使用其他分隔符"
}

# 注意项

确定源语言，源语言作为其他语言的范本。翻译时，对语言文件中所有的 key，按照源语言的内容进行翻译，一般来说会以英文为主，因为英文做 key 更符合命名习惯。

有些内容可能会有特殊的语法，比如英文会有复数形式，vue-i18n-next 支持复数语法，使用 dog | dogs 来定义内容。

有些插值的情况，最好明确插值意义，比如 "{0} is requried"，不如 "{fields} is required" 更容易理解和维护。

文本内如果需要使用 i18n 内的转移字符，可以使用在符号外加上引号和括号 ({'!@#$%^&*'})

# 流程制定

在多语言写作的工作流程中，涉及到产品、设计、开发和翻译人员等多个角色，因此需要一个统一的平台来管理 Key 和内容，以便协作和管理。在这个流程中，产品需求交给设计，设计考虑不同文本长度对设计样式的影响，然后交给前端设置对应 Key，再将需要翻译的其他语言文件交给翻译人员。翻译完成后，前端进行代码的部署上线。

然而，如果中间涉及多个人，时间和复杂程度都会增加。因此，我们需要一个在线的多语言内容管理平台来统一管理 Key 和内容，以便所有人在这个平台上进行协作和管理。

如果内容较少，翻译人员可以接受 JSON 等文件形式。也可以使用 git 进行管理，但需要一定的时间成本和技术门槛。在线表格工具也可以用来管理内容，但缺乏版本控制和协同功能。

目前已经有很多线上的成熟产品可以使用，我们选择了 localazy (也是 vue-i18n-next 的赞助商)。localazy 支持多人协作、版本管理、评论、翻译审查和自动翻译等功能，同时支持代码接入和 CI 集成，非常符合我们的需求。

# 集成与自动化

为了增加 Key，我们将在前端增加相应的代码，并将 localazy 的提交流程纳入其中。这样，新增的源语言 Key 文件将被推送到平台上，然后通知翻译人员进行文本更新。一旦翻译人员完成更新，我们将在 CI 流程中增加一个 localazy 拉取的阶段，可以手动或自动触发，以完成多语言文件的更新。

前期规划
注意项
流程制定
集成与自动化