javascript - AJAX 应用程序中的国际化和本地化

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




概述

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

从使用 i18n 生成的服务器端的单个 HTML 页面运行的 AJAX 应用程序

HTML 页面导入 JQuery 和插件

使用 XHR 根据需要加载服务器生成的 i18n HTML 模板

从 REST url 加载 JSON 格式的应用程序数据

使用模板和数据组合结果

更多细节

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

从现在开始，应用程序主要只执行 XHR 请求。其中一些请求是针对 HTML 模板(带有占位符的 HTML 代码片段)，JQuery 使用这些模板在页面上生成动态内容。这些类型的请求通常不包含任何应用程序数据，而仅包含数据应显示位置的占位符。这些片段是在服务器端动态生成的，并使用 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 格式的应用程序数据部分!

从使用 i18n 生成的服务器端的单个 HTML 页面运行的 AJAX 应用程序
单页 Web 应用程序 - 即:由一个页面组成，其中的内容由 AJAX 刷新 - 根据我的经验，构建起来非常有趣。保持界面尽可能简单和灵活只能在这里帮助您。一旦您进入更复杂的界面，您最终可能会依赖于不断增加的插件池。这实际上取决于您的应用程序的功能，因此我无法对此发表过多评论。

然而，根据我的经验，我在使用 XHR 驱动 UI 的单页应用程序中遇到的主要问题是内存管理。围绕动态创建的对象的浏览器内存处理比以前好得多，确保您自己的代码和第三方插件也有良好的内存使用是一个很好的挑战。我发现情况并非总是如此。如果您的应用程序的 session 时间预计很短，那就太好了 - 这应该不是问题。如果您认为人们会在您的应用程序上花费一段时间(可能一整天或几天)，那么您肯定要认真考虑这一点。以我的经验，无论浏览器制造商说内存管理有多好，或者您觉得您的代码/第三方代码在内存管理方面有多好，它仍然不完美。我们现在仍然在我们的单页应用程序上遇到一些降级。
因此，我们采用了一种混合方式，将应用程序拆分为多个逻辑区域，每个区域设置 1 页。通过这种方式，浏览器可以不时卸载整个页面，因此可以享受良好的清除。对我们来说，这是一个更好的解决方案。话虽如此，这真的取决于您，您的应用程序做什么以及您希望用户在一个 session 中与其交互多长时间。这在极少数情况下也很好，因为应用程序的一部分出现问题会导致整个页面瘫痪。这绝对是一种更糟糕的情况，但我宁愿重新加载一个应用程序区域而不是整个应用程序。

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

根据需要使用 XHR 加载服务器生成的 i18n HTML 模板
也是不错的做法。执行此操作时，值得考虑您的用户在浏览器执行工作时所看到的内容。当您在后台加载内容时，您希望让他们看到一些东西。我相信你已经想到了这一点。然而，在这种方法中我不能强调的一件事是错误恢复和反馈。如果出现问题并且页面没有正确加载并且用户留下一个残缺的应用程序 - 这不是一个好的界面体验!花很多时间考虑用户需要知道什么(如果有的话)出了什么问题，以及如何从中恢复的清晰说明总是值得的。一些用户很偏执，往往会经历这样的循环:出了问题 -> 是我的错 -> 我打破了它，现在我感到内疚和责备 -> 我讨厌使用这个东西。用户，他们认为:出了点问题 -> 可能不是我的错 -> 这东西很垃圾 -> 我讨厌使用这个东西。这些显然不是你得到的唯一类型的用户，但基本上:任何你能做些什么来将用户从“我讨厌使用这个东西”的端点上转移，更好!再一次，我相信你已经考虑过了!

从 REST url 加载 JSON 格式的应用程序数据
再一次，一个很好的方法。我们自己用过。将数据与界面分开的感觉很棒。在您的评论中，您说:
“因为这个数据来自数据库，所以没有对其进行i18n”我们过去所做的是编写一个数据过滤系统，对原始数据进行操作以使其易于使用，有时在将其发送回客户端之前更安全。大多数服务器端平台都非常擅长从 session 信息中获取诸如区域设置之类的详细信息，因此这可能是您应用本地化更改的地方。如果您正在编写一个可扩展的系统，那么打开一种拦截器/ Hook 系统，由此扩展也可以在某些点修改数据。世界是您插入贝类的选择，可以这么说。

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

对不起，如果我胡说八道。我是 stackoverflow 的新手 - 如果我做错了，请原谅我!