现有 JavaScript 应用程序的国际化和本地化
到目前为止，我正在为我的 JavaScript 应用程序（使用 jQuery UI 构建）的 i18n 和 l10n 使用 Globalize。这可行，但它将我的代码与另一个特定的库联系起来。现在我正在寻找一种方法来克服这个问题，因为我重用了一些现在不支持 i18n 的源代码，我宁愿不改变它。我并不是在谈论使用 i18n 的全局接口，我可以在其中插入任何实现。总结一下：如何在不更改源代码的情况下向现有应用程序添加 i18n 和 l10n 支持？我不是在问这是否是一个好主意，我是在问这是否可能以及如何实现。
到目前为止，我已经提出了这些方法，但都有各自的缺陷：
如果我依赖 jQuery 的使用（在我的例子中我可以），我可以替换 text/val/append 等。方法，即所有操作 DOM 的方法。但这样的情况有很多，每个人的行为都略有不同。我还可以更进一步，替换 DOM 方法。
遍历 DOM 并替换文本节点和表单值。这可行，但成本高昂，而且动态变化很难检测，因为没有标准化的方法来做到这一点。
这些为 i18n 问题提供了部分解决方案，但对于 l10n 来说，这两种方法都不起作用。
您将如何解决向现有应用程序添加 i18n 和 l10n 支持的问题？
So far I'm using Globalize for i18n and l10n of my JavaScript apps (built with jQuery UI). This works, but it ties my code to another specific library. Now I'm looking for a way to overcome this issue because I reuse some source that does not support i18n right now and I would rather not change this. I'm not talking about using a global interface for i18n where I could plug in any implementation. To summarize: How do I add i18n and l10n support to existing applications without changing it's source? I'm not asking if this is a good idea, I'm asking if this is possible and how.
So far I've come up with these approaches, but both have their flaws:
If I'd rely on the use of jQuery (which I could in my case), I could replace the text/val/append etc. methods, i.e. all that manipulate the DOM. But there are quite many of these, of which everyone behaves a little different. I could also take this a step further and replace the DOM methods.
Walk the DOM and replace text nodes and form values. This would work, but it is expensive and dynamic changes are hard to detect since there is no standardized way to do it.
Those provide a partial solution to the i18n problem, but for l10n neither of this may work.
How would you approach the problem of adding i18n and l10n support to existing apps?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短的回答：
如果不更改应用程序的源代码，就无法向应用程序添加 i18n 支持。
让我详细说明一下。使用 i18n 需要做的是：
没有可以在不修改源代码的情况下完成这些事情。对不起。
广告1。外部化字符串似乎很容易，对吧？只需遍历 DOM 并用翻译后的文本替换任何实例即可。
不，不是那样的。首先，您可能还有不可访问的文本，例如 JavaScript 驱动的错误或信息消息（即通过alert() 函数）。这不是 DOM 可访问的。其次，总是存在复合消息，即您输入一些数字（“12 条记录与您的查询匹配”）。翻译时，通常需要对句子重新排序（即数字放在最后）。您需要分析每个句子的数字或日期并对其进行特殊处理。如果你放置一个可变字符串会怎么样？您将如何克服这种情况（特别是如果该字符串可能随着时间的推移而改变）？
广告2。 &广告3。格式化和解析很容易，对吧？嗯，是的，如果您知道区域设置。不幸的是，检测区域设置的唯一明智的方法是在服务器端执行此操作（来自 Accept-Language 标头）。客户端对它的支持几乎不存在（对于许多浏览器）或严重损坏（对于其他浏览器）。所以你甚至不知道要使用哪个区域设置。当您无法修改底层 JavaScript 时，您将如何接受即本地日期？
广告4。对不同颜色的支持是可以实现的，但是唯一的方法是为每个 DOM 元素手动设置它。祝你好运。
添加额外的图像或声音理论上需要将它们放置在正确的目录中并修改 DOM 以便使用适当的图像或声音。再次祝你好运。
基本上，您想减少工作量，对吧？事实证明，通过实施非标准解决方案（这实际上不是行业标准所建议的），您最终将做更多工作，或者您的 i18n 支持将是（让我用这个委婉说法）可怜。
The short answer:
There is no way to add i18n support to an application without changing it source.
Let me elaborate on that. What you need to do with i18n is:
None of these things could be done without modifying source code. Sorry.
Ad1. Externalizing strings seems easy, right? Just walk through DOM and replace any instances with translated text.
No, it is not like that. Firstly, you probably also have non-accessible text like JavaScript-driven error or information messages (i.e. via alert() function). This is not DOM-accessible. Secondly, there always be compound messages, i.e. you put some numbers ("12 records matches your query"). When translating, it is common need to reorder the sentence (i.e. number comes last). You would need to analyze each sentence for numbers or dates and treat it specially. And what if you put a variable string? How you would overcome this situation (especially if this string could be change over time)?
Ad2. & Ad3. Formatting and parsing is easy, right? Well, yes if you know the locale. Unfortunately, the only sensible way to detect locale is to do that on the server side (from Accept-Language header). Client-side support for it is virtually non-existent (in case of many browsers) or severely broken (in case of others). So you don't even know which locale to use. And how will you accept i.e. local date, when you cannot modify underlying JavaScript?
Ad4. Support for different colors is achievable, however the only way to do that is to set it manually for each DOM element. Good luck with that.
Adding additional images or sounds theoretically requires placing them in right directory and modify DOM so that appropriate ones would be used. Again, good luck with that.
Basically, you want to reduce amount of effort, right? Turns out that by implementing non-standard solution (this is actually not what industry standards suggests) you will end-up doing more work, or your i18n support would be (to let me use this euphemism) poor.