[nawitus]

>It works by scanning the DOM for translatable content, and injecting translations on-the-fly after the page loads

I don't like this approach because it makes the framework/library harder to integrate with other DOM-modifying frameworks like data binding frameworks that are very popular these days. A more modular approach in my opinion would be to simply provide a function/functions to do the localization conversions. That can easily be integrated to any data binding framework.

>(this happens so quickly that the user never sees the text in the original language)

And if you use it with something like AngularJS, the end result is visual flicker after DOM changes..

[cj]

Localize.js is fully compatible with all DOM-modifying frameworks (Backbone, Angular, etc). Localize.js doesn't actually replace existing DOM elements, rather it simply changes the existing elements' contents as to not interfere with bindings.

We've also spent a ton of time making sure there's zero visual flicker as the DOM changes take place. We have a bunch of companies using it to translate Angular and Backbone apps (for example, http://venzee.com/ and https://www.verbling.com).

[nawitus]

But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Localize.js function to translate text.

[cj]

We use MutationObserver (https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...) to detect when content on the page changes, so when you add (or change) a <div> on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM.

Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We're hoping this will make localization more accessible to startups / companies who don't have weeks or months to spend manually internationalizing their application.

[schrodinger]

At first I was turned off by your approach, but the more I hear your points and think about it the more I like it.

I wouldn't use it for greenfield development, but it's definitely a great option for websites that wouldn't otherwise be localized. It's great for people to have a near-zero-development option to translate existing sites.

I'd certainly rather have websites translated using this approach than not translated at all!

[uptown]

Could implementing things this way cause a problem if another script also post-processed your pages? Could you wind up in a loop where each script kept modifying the page in response to the changes made by the other script?

[cj]

Technically, it's possible. To get stuck in a loop you'd have to have another script that uses MutationObserver to reverse the changes that Localize.js makes to the DOM. We haven't run in to this yet, but I'll see if there's a way to safeguard against this.

[ttty]

Please stop.. Don't do things this way. This is like jquery monkey patch hell..