为模块化应用程序组织 Javascript i18n 文件

Question

我正在向一个相对较新的应用程序添加 i18n 支持。这是一个模块化的应用程序。目前，我们只有英语（可能还有用于测试目的的 Pig Latin），但我想确保我们不会自爆。我有两个组织翻译文件的想法：

1. 一个大的全局翻​​译列表，其中包含任何模块中使用的每个字符串。这将导致对全局文件的一定数量的争用。这个文件会更大，我想知道下载时间。

2. 每个模块都有自己的翻译文件。这将导致出现在多个模块中的字符串出现一定数量的重复。如果我们将文件发送出去进行翻译，我们将不得不整合这些文件。

我们正在使用 Javascript，加上 Backbone.js、Require.js、Aura 等，我们正计划使用 i18next。

哪种方式最适合组织文件？或者还有其他我想念的方式。

Answer 1

每个模块都有一个文件，你会重复自己。如果该字符串在十个模块中使用，您将不得不翻译十次“发生错误”。我的建议是将所有翻译汇总到一个结构如下的大型 JSON 文件中：

{
  "common": {
    "welcome": "welcome",
    ...
  },
  "module1": { 
    "loaded": "module1 is loaded"
     ....
  }
}

您将在它自己的对象和对象中的通用字符串中包含模块特定的翻译。

旁注：您可以从 John Resig 的blog post 那里了解 JavaScript 中的 i18n。

Answer 2

遇到这个问题，我想我会对此提出另一种看法。

背景

创建一个庞大的翻译文件是可以的，除非你是：

1. 开发企业级站点/系统，以及；
2. 在大型团队中工作。

一年多来我一直在开发一个 Angular 应用程序，该应用程序需要一个庞大的开发团队，并且是一个相当大规模的系统。

当您的系统变得庞大且您拥有庞大的团队时，单一语言文件不是最佳选择，因为：

1. 根据您的开发人员的技能和时间框架，向已经很大的语言文件中添加新字符串会滋生懒惰，并且''的心态哦，我将它放在本节中，稍后再重构'。如果使用相同的思维方式尝试查找已存在的项目，则会导致不必要的重复。
2. 在大文件和大团队说明中，如果两个人在处理同一个文件并发生冲突，则冲突解决可能会导致错误并浪费时间。
3. 如果您的框架/技术支持，较小的文件可以延迟加载。为什么要为您可能不使用的子系统加载语言文件？

总结和建议

根据我的经验，我的建议如下：

做最适合您的项目、时间框架和需求的事情。如果您正在处理大型系统，从长远来看，为了节省时间，请从单独的文件开始。从一开始就制定标准并坚持下去以节省时间。