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

Question

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

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

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

score 4 · Accepted Answer

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

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

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

旁注：您可以从 John Resig 的博客文章中了解 JavaScript 中的 i18n。

score 0 · Accepted Answer

遇到这个问题并认为我会对此给出另一种看法。

背景

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

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

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

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

总结与建议

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

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

2 回答 2