[JS] Dynamic Language Changer

[BYK]

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/d...er/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]

This is bad. Content negotion, including language selection, should be done server-side.

[BYK]

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]

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]

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]

In a few very rare cases, yes.

[BYK]

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]

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- Speed

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.

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 load

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.

[BYK]

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]

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 engines

Web 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.

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.