目前在 JavaScript 中处理 i18n 的最佳实践是什么？
我听说过一些关于使用 PHP/Rails/etc 输出所有 i18n 字符串的建议。放入包含数千个变量的格式化 JavaScript 文件，但这听起来太粗糙了；此外，需要有一种方法来检测将要加载到给定页面上的 JS 文件实际上需要哪些 i18n 字符串，但我现在不知道如何实现。
我听到的一些其他建议涉及在后端和前端之间设置某种 API，使用格式良好的 JSON 作为 i18n 字符串的载体，但这仍然不能解决我可能不需要的冗余字符串的问题.
目前关于 JavaScript 中 i18n 的一些最佳实践是什么，如果可能的话，还有一个解决方案可以检测和仅发送给定页面上实际需要的那些字符串？
【问题讨论】：
标签： javascript internationalization
“最佳实践”实际上取决于您构建应用程序的方式。两个例子：
无论哪种方式，您都希望将发送给客户端的字符串数量减少到最低限度。虽然有很多方法，但我最喜欢的是使用带有 i18n 扩展的预编译模板（我喜欢使用 Twitter 的 Hogan.js 的 Mustache），这些扩展不仅返回生成 HTML 的函数，还返回所有可翻译的列表字符串。
您绝对不想要做的是构建一个函数来检查您是否已经有翻译，如果没有，则询问服务器。这将使一切变得非常缓慢，而您不希望这样。要么预加载所有翻译，要么不翻译这些部分。
【讨论】：
这取决于您所说的“i18n”是什么意思。从您的问题来看，您似乎只是指可翻译的字符串提取。
在这种情况下，我倾向于从后端生成的单个 JS 脚本。这可能包含数组中的所有可翻译字符串和一些查找方法。我不知道您是否称其为“千变量方法”，但这就是我所倾向于的。我了解您可能不喜欢在代码中包含 alert(tr.getString("some.key")) 之类的内容，但既然您询问了最佳做法...
我见过很多解决方案，但其中大多数只是重新发明轮子。问题是，在大多数情况下，轮子是方形的……
话虽如此，i18n 比简单的字符串提取要广泛得多。您必须注意区域格式支持、正确的排序规则、对可本地化的支持（提取字符串只是其中的一部分）等等。 我不能真正谈论“最佳实践”，因为这个问题太宽泛了。但是，我可以说的是，它确实取决于平台（即编程语言）。
【讨论】：