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

Question

我将i18n支持添加到一个相对较新的应用程序中。这是一个模块化的应用程序。现在，我们只需要英语(为了测试目的也许还有拉丁语)，但我想确保我们不会对自己开枪。我有两个想法来组织翻译文件：

1. 一个大的全局翻译列表，每个字符串都使用在任何模块中。这将导致全局文件的一定数量的争用。这个文件会更大，我想知道下载时间。
2. 每个模块都有自己的翻译文件。这将对多个模块中出现的字符串造成一定数量的重复。如果我们把这些文件送出去翻译的话，我们就得把它们合并起来。

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

哪一种方式是最好的组织文件？或者还有什么别的办法让我错过。

Answer 1

通过每个模块都有一个文件，您将重复自己。如果在十个模块中使用该字符串，则必须将“发生的错误”翻译十次。我的建议是将所有翻译聚合到一个大JSON文件中，该文件的结构如下：

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

您将在它自己的对象中包装模块特定的转换，并在对象中包含公共字符串。

附带注意:您可以从John的博客帖子中学习关于i18n in JavaScript的内容。

Answer 2

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

背景

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

1. 开发企业级站点/系统；
2. 在一个大团队里工作。

一年多来，我一直在研究一个角度应用程序，它需要一个庞大的开发团队，并且是一个相当大的系统。

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

1. 取决于开发人员的技能集和时间框架，在已经很大的语言文件中添加新的字符串会滋生懒惰，“噢，我将把它放在这里，稍后再进行重构”。这将导致不必要的重复，如果使用相同的心态来尝试并找到一个已经存在的项目。
2. 在大文件和大团队注意事项上，如果两个人在同一个文件上工作，并且发生冲突，冲突解决可能会导致错误并浪费时间。
3. 如果您的框架/技术支持较小的文件，则可以延迟加载。为什么要为您可能不使用的子系统加载语言文件？

摘要与建议

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

为你的项目做最好的事情，这是时间框架和需求。为了节省长期运行的时间，如果您正在处理一个大型系统，请从单独的文件开始。从一开始就制定一个标准，并坚持下去以节省时间。