javascript find replace

I have a question about optimization, but more on the browser/client side.

I am catering to a few societies that need about 3 different languages. So I'm just putting my user's language type in the php session, and swapping out the text for selected areas on each page they navigate to. So, really nothing complicated.

However, I'm toying with the idea of letting javascript do the find/replace of the selected texts on each page.

There are a few ways to skin this cat, and I've done them all, and they work. However, I do have a few hundred pages, and many words to replace with the correct language text.

If I were to go the Javascript route, does anyone have an opposing view to this? And if so, why? I'm interested in letting the user's browser do the work, rather than my servers constantly finding and replacing, or creating new CONSTANTS for each language specific situation.

I'm worried about their browsers getting slower. But that could be a very small problem.

For those individuals who love to get specifics, here's what I would do with javascript.

I would load a languages.js file with all appropriate word translations for any language I implement. Instead of running a huge find/replace on each page load, I'd localize the find/replace to the specific page, or possibly narrow an element to have an attribute that my scripting would load in the the DOM and perform a find/replace on that alone.

I'm open to better ideas.

Also, for those people who find "over-optimization" useless or "over-doin开发者_开发百科g-it", please don't mention anything. This is for fun and not a critical decision item.

thanks guys!

Well, on the pro side, yes, you are offloading some of the work to the client, but I don't think that's going to make any real difference. You're probably talking about a tiny percentage of the overall performance of the site. The only way to know of course is to test it.

On the con side, you'll be increasing the bandwidth it takes to load your site, since the user will need to load the page plus the language file. It will be cached, if you set it up right, so that's probably not a huge concern either.

Another con is that this will make your site depend on javascript. A non-scripting visitor won't get the translation, and that includes search engines. Whether that matters to you depends on the nature of your site, but in general, that's a pretty big negative.

You'd also have to watch out for "flashing" of the non-localized language. It'd look horrible if the page loaded and then a split second later the language changed to something else. If you are doing the swapping from the DOM ready event ($(function() {}) in jquery, for example), it's probably too late. You could do it from a script you put at the bottom of the page, and that'd probably be ok, but even then, it may depend on the browser and the structure of the markup, not to mention the user's bandwidth and whether the server sends the content in chunks.

I think it comes down to what fits your needs best. Sorry that's not much of an answer, but it's an accurate one I think :)

I agree it is important to keep your server from overload. I would solve the problem one of two ways

1. Use your suggested javascript find and replace, whilst the javascript is working, have a loading.gif spinning round with a message to the effect of 'translating' nearly to explain to users why they must wait. If you are doing a word by word translation, you have to be careful about causing a browser like IE or to moan about having to do work 'The page has become unresponsive'; I would suggest running a setInterval(Translate(), 1) where translate translates a set number of words at a time so the browser doesn't think your script is going in an endless loop.

2. Provided the same sections are translated for all foreign visitors, you could make a PHP script that makes new, translated pages next to the originals. The translated pages could include the translator.php script to do a quick check to see if the original page has changed to decide whether or not to make a new translated page. This would not mean translating a page every time it needs to be viewed in a foreign language, but only a little check to see if the original had changed - putting less load on your server and none on the client side browser.

Personally I would implement 2 if possible to be more low-power-browser friendly (such as mobile devices) but in practice either would do and it's an interesting problem.