PDA

View Full Version : [JS] Dynamic Language Changer



BYK
12-02-2007, 03:40 PM
1) CODE TITLE: Dynamic Language Changer

2) AUTHOR NAME/NOTES: BYK

3) DESCRIPTION: This library is a quick&efficient dynamic language changer/loader. What it does exactly is loading the given language from the appropriate XML language file which will be created by you and then apply it directly to the opened page without reloading it. You can understand what I mean from the demo page below. There is one downside of using this library, search engines can not load the language dynamically so you have to put something statically for search engines to see and index.

Note: With some discussions under this topic, this kind of changing language is found not a good way of managing regular sites. So if you are not designing a non-public web application, we recommend not to use this script as a language manager.

4) URL TO CODE: http://amplio-vita.net/JSLib

Demos are on the given URL but a direct link to the demo page is here: http://amplio-vita.net/JSLib_files/dynamicLangChanger/example.htm

Note: This library is a part of the amplio-vita JSLib project and needs its ajax_main.js to run. All explanations are made on the uncompressed library as comments. Please give feedback to improve our library.

Twey
12-02-2007, 06:19 PM
This is bad. Content negotion, including language selection, should be done server-side.

BYK
12-02-2007, 06:41 PM
You are right in an aspect but this system has a quick change advantage. I do not like a huge reload when I just change the language(yes from user side, changing language is a minor thing from my point of view :)) and if this is a web application which does not require a search engine indexing, this script might come useful.

But I would also like to learn why do you think we should stricktly manage the language elements server side if you don't mind explaining :)

Twey
12-02-2007, 06:53 PM
It shouldn't be necessary to manually change the language in most cases. The server should read the user's Accept-Language header and serve the appropriate language automatically.

BYK
12-02-2007, 06:57 PM
Oh I understand and agree with you but I also insist on there are some cases where this way of changing language might come useful. Thank you very much for the explanation.

Twey
12-02-2007, 08:51 PM
In a few very rare cases, yes.

BYK
12-02-2007, 09:57 PM
Actually this method does not prevents server-side language detection and server-side language element insertion(as you suggested) but only introduces a new way of changing it.

But of course as in the example, someone can decide only to use this system for language management which brings some advantages(again in my point of view) as listed below:
1- Speed
2- Usability on a non-server-side-programmed site(plain html)
3- Reduction of the database server load or server-side scripting language parser load

So I do not think there are "few very rare" cases ;)

Twey
12-02-2007, 10:23 PM
Actually this method does not prevents server-side language detection and server-side language element insertion(as you suggested)I suggested no such thing. However, if they are used in tandem (which they must be: see my response to your second advantage) your third advantage is negated.
1- SpeedNo. All the data is still downloaded, just at a different time. Also, if the default language is different to the user's preferred language (which you cannot find out client-side) the data is downloaded at least twice.
2- Usability on a non-server-side-programmed site(plain html)A plain HTML page alternative must be offered even when using this script, since users without Javascript cannot otherwise access the content in their language.
3- Reduction of the database server load or server-side scripting language parser loadOh, come now. The differences here (even disregarding usability issues; allowing a non-Javascript alternative as well would actually increase server load) are a drop in the torrent of load generated by a standard dynamic site.

BYK
12-03-2007, 07:05 AM
I suggested no such thing. However, if they are used in tandem (which they must be: see my response to your second advantage) your third advantage is negated.

Didn't you told that language selection and changing of language elements(if a change is needed) should be done server-side or did I just misunderstand your previous answers?


No. All the data is still downloaded, just at a different time. Also, if the default language is different to the user's preferred language (which you cannot find out client-side) the data is downloaded at least twice.

Actually no, not all data is downloaded, at least when changing the language. Because some non-changing scripts, page layouts and many other stuff remains where just some texts and images are reloaded. Also if the user does not uses cache, this method surely prevents the non-langugage-dependent images from reloading.

And as you have suggested, looking at the Accept-Language header and putting the "changeLanguage(*theDeterminedLanguageCode*)" function to the onload part of the body from server-side is a good solution. Also this is not a must for using the script. Although it's not preferable the webmaster can choose not to load the language when the page is loaded and let the user to chose from a dropdown list if he/she can not determine the language from server-side.


A plain HTML page alternative must be offered even when using this script, since users without Javascript cannot otherwise access the content in their language.

This is needed actually not for the "user without Javascript(because they are not too much)" but for the search engines and I mentioned it becuse this may turn into a downside. Actually when using JS in my pages, sometimes I really neglect the users who don't use JS where I should not to.


Oh, come now. The differences here (even disregarding usability issues; allowing a non-Javascript alternative as well would actually increase server load) are a drop in the torrent of load generated by a standard dynamic site.
The differences here are not a drop. Think of it, if you do the entire language management from server-side, with using a database. Everytime a page is loaded, you have to connect to the database, go into the language tables, do a query, split the query, then -at last- select from that query which both brings a load to the database server and the server-side scripting language parser. Or as an alternative let's assume you are using an external language file just like here, again you have to parse that file in the server-side which brings a load to the server. But if you use this client-side method, server just sends the language file and then the browser sets the language. If the user is using a cache it is even more efficient because most probably the xml file will be sent only once.

Twey
12-03-2007, 08:31 AM
Didn't you told that language selection and changing of language elements(if a change is needed) should be done server-side or did I just misunderstand your previous answers?I did say that. That doesn't mean that there can't be a helper client-side, there's just no significant benefit to doing so. If it suits you, fine, but it must only exist as an augmentation to the server-side backend, as is the case with all Javascript.
Actually no, not all data is downloaded, at least when changing the language. Because some non-changing scripts, page layouts and many other stuff remains where just some texts and images are reloaded.I meant the language-dependent data. The other data will likely be cached anyway.
And as you have suggested, looking at the Accept-Language header and putting the "changeLanguage(*theDeterminedLanguageCode*)" function to the onload part of the body from server-side is a good solution.No, he/she would have to load it without Javascript for non-JS users.
Also this is not a must for using the script. Although it's not preferable the webmaster can choose not to load the language when the page is loaded and let the user to chose from a dropdown list if he/she can not determine the language from server-side.But this renders it inaccessible to non-JS users who don't speak the default language.
This is needed actually not for the "user without Javascript(because they are not too much)" but for the search enginesWeb statistics are notoriously unreliable, but I'd hazard a guess that there are more non-JS users than, say, Safari users. There are also a number of people who have JS but for whom changing the content of the page would probably not work properly, such as screen-reader users.
Actually when using JS in my pages, sometimes I really neglect the users who don't use JS where I should not to.This means you are going about web design entirely the wrong way. You create a working, accessible HTML page, then you add styles to make it pretty, then you add scripts to make it flash and whiz and buzz and do tricks. Read this page (http://www.howtocreate.co.uk/tutorials/design/introduction).
Everytime a page is loaded, you have to connect to the database, go into the language tables, do a query, split the query, then -at last- select from that query which both brings a load to the database server and the server-side scripting language parser.But in a dynamic site you'll probably do that for every page anyway. The only difference would be a WHERE lang = %s clause.
But if you use this client-side method, server just sends the language file and then the browser sets the language.First the server sends the (unwanted) default language file, then the user has to set the language, then the server sends another language file -- unless you intend to have only one language file, in which case the load is many times greater because the user has to download all the text of the page/site in every language available even though they'll probably only use one or two.
If the user is using a cache it is even more efficient because most probably the xml file will be sent only once.And there's nothing to stop a webmaster allowing caching of a dynamically-generated page, either.

djr33
12-03-2007, 08:38 AM
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
12-03-2007, 08:51 AM
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
12-03-2007, 09:04 AM
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
12-03-2007, 09:16 AM
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/innerHTML_alternatives/.
elements = container.getElementsByTagName('*'); //get all sub elements under the containerBeware! 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
12-03-2007, 09:20 AM
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
12-03-2007, 09:24 AM
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
12-03-2007, 09:28 AM
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
12-03-2007, 09:31 AM
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 :p

BYK
12-03-2007, 09:46 AM
elements = container.getElementsByTagName('*'); //get all sub elements under the containerBeware! 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
12-03-2007, 11:27 AM
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.

BYK
12-03-2007, 04:00 PM
If you use text node, then the HTML tags would have no effect which greatly reduces the system's openness. Also parsing the data coming from the XML file will both increase the client's load and the codes complexity very much. So as long as it works fine both on FF and IE this method is OK I think although I'm not very happy with using the innerHTML property.

Actually I heard rumours that a new Web standart, which includes this DOM issues and the xmlHTTPRequest object's standartisation, will be announced soon. Do you have any information about that?