Internationalization and localization of existing JavaScript applications

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:

1. 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.

2. 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 standar开发者_StackOverflowdized 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?

---

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:

1. Externalize strings.
2. Format dates, times, numbers, etc. according to a valid locale.
3. Accept user input (i.e. date, time, number) according to a specific locale.
4. Handle cultural bias correctly (i.e. modify colors, images, sounds...).

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.