AJAX 应用程序中的国际化和本地化 [关闭]

Question

概述

我想听听有关我将 AJAX 应用程序国际化的方法的反馈。这是一种合理的方法吗？什么样的其他方法值得考虑？以下是该应用程序的摘要：

• AJAX 应用程序从使用 i18n 生成的服务器端生成的单个 HTML 页面运行
• HTML 页面导入 JQuery 和插件
• 根据需要使用 XHR 加载服务器生成的 i18n HTML 模板
• 从 REST url 加载 JSON 格式的应用程序数据
• 使用模板和数据组合结果

更多详情

构建一个重 ajax 的应用程序，它几乎只是一个标准的 HTML 页面。此页面是通过服务器端框架动态生成的，并在服务器端完全国际化。此页面加载 JQuery 以及几个插件。

从现在开始，应用程序主要只执行 XHR 请求。其中一些请求是针对 HTML 模板（带有占位符的 HTML 代码的 sn-ps），JQuery 使用这些模板在页面上生成动态内容。这些类型的请求通常不包含任何应用程序数据，而只是应显示数据的位置的占位符。这些 sn-ps 是在服务器端动态生成的，并且使用了 i18n。每个模板只需要请求一次。

应用程序正在使用的大部分请求都是针对应用程序数据的。该数据通过 XHR 请求检索到输出 JSON 数据的 REST 服务。然后，jQuery 代码使用这些原始数据来填充模板并构建页面的各个部分。数据数组导致模板重复。因为这些数据是来自数据库的，所以没有对其执行 i18n。

客户端国际化

如果 UI 最终需要任何其他 i18n 字符串，它们可以存储在 JSON 中，并作为初始 HTML 页面的一部分或作为返回 JSON 键/文本映射的特殊 REST url 提供。错误消息等功能可能需要这个。

客户端本地化

这让我想到了本地化。日期和金钱之类的东西将以标准化格式在 JSON 数据中传输。因此，由客户以正确的格式为客户显示此信息。我不认为这会是一个太大的问题，或者会吗？

如果可以，也许我应该让服务器端根据客户端区域设置返回适当的格式字符串。客户可以使用DateJS 之类的东西来格式化日期。我还不太确定，特别是因为 DateJS 太大了。但还有其他更小的客户端选项。

资源

我找到了一些可能对此有所帮助的 jQuery 插件。有人对他们有什么要说的吗？或者认识其他人？

• jQuery Localisation
• jQuery i18n plugin
• Javascript i18n the almost doesn't suck
• jQuery Localize

Answer 1

您的方法让我很感兴趣，因为这是我们过去使用的方法。我在这样做的背后有一些学习。以下是一些想法 - 希望对您有所帮助！

注意：我刚刚写了这篇文章，并意识到大部分内容与单页应用程序方法有关，而不是本地化！对不起。这里有一些你可能会觉得有用的学习，但如果你只对本地化部分感兴趣，请跳到从 REST urls 以 JSON 格式加载应用程序数据部分！

从单个 HTML 页面运行的 AJAX 应用程序使用 i18n 生成服务器端
一页网络应用程序 - 即：由 AJAX 刷新内容的单个页面组成 - 根据我的经验，构建起来非常有趣。保持界面尽可能简单和灵活只能在这里为您提供帮助。一旦你进入更复杂的界面，你最终可能会依赖不断增加的插件池。这真的取决于你的应用程序做了什么，所以我不能对此发表太多评论。

然而，根据我的经验，我在使用 XHR 驱动的 UI 的单页应用程序中遇到的主要问题是内存管理。围绕动态创建的对象的浏览器内存处理比以前要好得多，确保您自己的代码和第三方插件也具有良好的内存使用率是一个很好的挑战。我发现并非总是如此。如果您的应用程序预计会话时间很短，那就太好了 - 这应该不是问题。如果您认为人们会在您的应用程序上花费一段时间（可能一整天或几天），那么您一定要认真考虑这一点。以我的经验，无论浏览器制造商说内存管理有多好，或者你觉得你的代码/第三方代码在内存管理方面有多好，它仍然不是完美的。现在，我们的单页应用程序仍然会出现一些退化。

因此，我们采用了一种混合方式，将应用程序拆分为逻辑区域，并设置每个区域 1 页。这样，浏览器就可以轻松地卸载整个页面，因此可以享受良好的清除。对我们来说，这是一个更好的解决方案。话虽如此，这完全取决于您，您的应用程序做什么以及您希望用户在一个会话中与它交互多长时间。这在极少数情况下也很好，因为应用程序的某个部分出现问题会破坏整个页面。这绝对是一个更糟糕的情况，但我宁愿重新加载一个应用程序区域而不是整个应用程序。

HTML 页面导入 JQuery 和插件
爱它。我对 jQuery 比较陌生（已经走 ExtJS 路线），但我听说有一些很棒的 jQuery 插件，并且背后有一个很好的可靠社区。

根据需要使用 XHR 加载服务器生成的 i18n HTML 模板
也是一个不错的方法。执行此操作时，值得考虑您的用户在浏览器执行工作时所看到的内容。当您在后台加载内容时，您想给他们一些东西看。我相信你已经想到了这一点。然而，在这种方法中我不能强调的一件事是错误恢复和反馈。如果出现问题并且页面无法正确加载并且用户留下一个残缺的应用程序 - 这不是一个好的界面体验！总是值得花大量时间考虑用户需要知道什么（如果有的话）出了什么问题，以及如何从中恢复的清晰说明。一些用户偏执并且倾向于经历以下循环：
出了点问题 -> 这是我的错 -> 我弄坏了它，现在我感到内疚和受到指责 -> 我讨厌使用这个东西。
或者，你会得到彻底的铁氟龙用户，他们的想法是：
出了点问题 -> 不可能是我的错 -> 这东西是垃圾 -> 我讨厌使用这个东西。
那些显然不是只有您获得的用户类型，但基本上：您可以做的任何事情都可以将用户从“我讨厌使用这个东西”端点转移，更好！再一次，我相信你已经考虑过了！

从 REST url 加载 JSON 格式的应用程序数据
再一次，一个不错的方法。我们自己用过。将数据与界面分开感觉很棒。在您的 cmets 中，您说：
“因为这些数据来自数据库，所以没有对其执行 i18n”
我们过去所做的是编写一个数据过滤系统，从而对原始数据执行操作数据以使其用户友好，有时更安全，然后再将其发送回客户端。大多数服务器端平台都非常擅长从会话信息中获取诸如语言环境之类的详细信息，因此这可能是您应用本地化更改的地方。

如果您正在编写一个可扩展的系统，那么打开它可能会很好建立一种拦截器/钩子系统，扩展也可以在某些点修改数据。可以说，世界是您插入贝类的选择。

最后一件事：用户“旅行”
这更多是关于单页应用程序方法的说明，真的。如果您采用一页区域的路线，它也会帮助您决定如何分割区域。应用程序用户讨厌不得不做他们已经做过的事情，并认为他们不应该做多次。如果您的用户“旅行”通过您的界面系统并且出现问题，则需要刷新页面才能从中恢复（再次出现更糟糕的情况！），因此他们必须再次“旅行”相同的界面才能到达该地方他们想成为，这对他们来说会很累。例如，在我们的一个单页应用程序中，用户通过数据视图样式菜单系统访问功能。如果出现需要刷新页面的严重错误，他们必须再次通过相同的菜单系统才能到达同一个地方。解决方案是将感兴趣的区域移到单独的一页区域，并让菜单退出点跳转到这些页面。这样，如果确实发生了需要刷新页面的不可恢复错误，则刷新会将它们保持在他们感兴趣的区域。

对不起，如果我胡扯。我是 stackoverflow 的新手 - 如果我做错了，请原谅我！

Answer 2

找到了这个解决方案：
http://github.com/eligrey/l10n.js/
但它不使用模板...
无论如何，它可能对某人有用。