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.
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.
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!
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?
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.
