[JS] Dynamic Language Changer

[djr33]

It seems cool at first, but I must agree with Twey here.
Such a script really isn't needed. You change the language once. Ignoring even the content header issue, just have a choice, then store a cookie. Then serve the page (or even use JS to switch it), and you don't need to switch it.
Someone wants a certain language.... then they still want it. Even someone bilingual won't need to frequently switch.

I can see some application of this in a learning sense, but only for a specifically designed site, which might have another method anyway to change the content.

The idea is ok, and the script seem to work (though it's quite illegible-- try tabs/returns), but just not all that practical.

[BYK]

It seems cool at first, but I must agree with Twey here.
Such a script really isn't needed. You change the language once. Ignoring even the content header issue, just have a choice, then store a cookie. Then serve the page (or even use JS to switch it), and you don't need to switch it.
Someone wants a certain language.... then they still want it. Even someone bilingual won't need to frequently switch.

I can see some application of this in a learning sense, but only for a specifically designed site, which might have another method anyway to change the content.

The idea is ok, and the script seem to work (though it's quite illegible-- try tabs/returns), but just not all that practical.

It is a fact that language is not an everyday-changing thing for a normal user But the point I'm upset about this discussion is that Twey -somehow- does not accept the solutions such as catching the Accept-Language and then changing the function from server-side to load the appropriate language in the first load.

I agree that there are some downsides of the script but here it is done and anyone considering to use such a thing, he/she is free to use.

By the way you mentioned "illegible" code but the uncompressed version with comments is strictly formatted with tabs and returns, can you send me the version you are seeing?

And of course thak you very much for your feedbacks both Twey and djr33

By the way I have added a note to the first post which tells that this way of changing language is not as good as you think at first

[djr33]

Well, you can see it as well, I'd assume. Just load the .js file that is linked in the source code. It's got a couple commands, then one long line of text, unbroken.

[Twey]

But the point I'm upset about this discussion is that Twey -somehow- does not accept the solutions such as catching the Accept-Language and then changing the function from server-side to load the appropriate language in the first load.

Oh, I accept it, but it's a solution to only one of the problems springing from this approach. There are others, and more important ones too.

On the code itself:
innerHTML is non-standard, and should be avoided where possible. See http://slayeroffice.com/articles/inn..._alternatives/.

elements = container.getElementsByTagName('*'); //get all sub elements under the container

Beware! This will work if the container is document, but document.getElementsByTagName() and HTMLElement.prototype.getElementsByTagName() are different! The latter only finds elements that are direct children of the element.

[BYK]

Because of the ASCII transfer type of the FTP, line breaks changed from [CR][LF] to [LF]. This was the source of "illegible source code" problem and it is corrected. Thank you

@Twey, I see and understand your points and put the necessary note/warning both on the first post and on our site.

[Twey]

Well, you can see it as well, I'd assume. Just load the .js file that is linked in the source code. It's got a couple commands, then one long line of text, unbroken.

This means you're using a rubbish source code viewer that can't recognise UNIX line-breaks

@Twey, I see and understand your points and put the necessary note/warning both onthe first post and on my site.

I since edited my post, sorry.

[BYK]

I since edited my post, sorry.

Was not aware of the difference, working on it.

And a last note, avoiding innerHTML is tricky when cross-browser terms come in. I know that IE does not allow some elements' innerHTML to be changed, but any other method described in the given link is not applicable for this case.

[djr33]

This means you're using a rubbish source code viewer that can't recognise UNIX line-breaks

(Note: this was in reference to what I said, not you, BYK)
Well, if that's the case, then Firefox's "view source" option must just be terrible

[BYK]

elements = container.getElementsByTagName('*'); //get all sub elements under the container

Beware! This will work if the container is document, but document.getElementsByTagName() and HTMLElement.prototype.getElementsByTagName() are different! The latter only finds elements that are direct children of the element.

Changed that part as below

	elements = container.childNodes;

	for (var i=0; i<elements.length; i++) {
		if (elements[i].nodeType==1 && elements[i].getAttribute("langText"))
			...
		else if (elements[i].hasChildNodes()) //if the element has sub nodes
			fillLangTexts(elements[i]); //call to iterate over the sub nodes

I think this is OK now, right?

[Twey]

Yep, that's better.

And a last note, avoiding innerHTML is tricky when cross-browser terms come in. I know that IE does not allow some elements' innerHTML to be changed, but any other method described in the given link is not applicable for this case.

Why? Simply edit the elements' first text nodes' nodeValues in this case. If you need markup, send it in another format, such as XML or JsonML. There are copious DOM converters for both.