3

当前在 JavaScript 中处理 i18n 的最佳实践是什么？

我听说过一些关于使用 PHP/Rails/etc 输出所有 i18n 字符串的建议。放入包含数千个变量的格式化 JavaScript 文件，但这听起来太粗糙了；此外，需要有一种方法来检测将要加载到给定页面上的 JS 文件实际上需要哪些 i18n 字符串，但我现在不知道如何实现这一点。

我听到的其他一些建议涉及在后端和前端之间设置某种 API，使用格式良好的 JSON 作为 i18n 字符串的载体，但这仍然不能解决我可能不需要的冗余字符串的问题。

目前在 JavaScript 中关于 i18n 的一些最佳实践是什么，如果可能的话，还有一个解决方案来检测和仅发送给定页面上实际需要的那些字符串？

4

2 回答 2

2

The 'best practice' really depends on how you build you application. Two examples:

  • Single page app. Of course you'd want to just load all of the needed strings for you entire application in one go, as constantly fetching new strings would be a waste of time and resources.
  • Page with some JS-based content. If you keep reloading the JS, you probably want to reduce the amount of strings as much as possible, and maybe even integrate the entire i18n dict in your HTML to avoid a AJAX call.

Either way, you'll want to reduce the amount of strings sent to the client to a bare minimum. While there are a lot of approaches, my favorite is to use pre-compiled templates (I like Mustache using Twitter's Hogan.js) with i18n extensions that don't only return a function to generate the HTML, but also a list of all translatable strings.

What you definitely don't want to do is to build a function that checks whether you already have a translation and if you don't then ask the server. This will make everything very slow and you don't want that. Either pre-load all translations, or don't translate those parts.

于 2013-04-11T23:55:12.663 回答
0

这取决于您所说的“i18n”是什么意思。从您的问题来看，您似乎只是指可翻译的字符串提取。在这种情况下，我倾向于从后端生成的单个 JS 脚本。这可能包含数组中的所有可翻译字符串和一些查找方法。我不知道您是否称其为“千变量方法”，但这就是我所倾向于的。我知道您可能不喜欢alert(tr.getString("some.key"))在代码中包含类似的内容，但是既然您询问了最佳实践...

我见过很多解决方案，但其中大多数只是重新发明轮子。问题是，在大多数情况下，轮子都是方形的……

话虽如此，i18n 比简单的字符串提取要广泛得多。您必须注意区域格式支持、正确的排序规则、对可本地化的支持（提取字符串只是其中的一部分）等等。我不能真正谈论“最佳实践”，因为这个问题太宽泛了。但是，我可以说的是，它确实取决于平台（即编程语言）。

于 2013-04-12T17:08:31.180 回答