Language of web applications

As I venture into the world of client side applications I find an issue with localization. So the normal way browsers and the web handle languages is fairly sensible. Each web request has a header "Accepts-Language". The over-engineered header has a list of language with weighted preferences. The server can then pick out the language to send based on what languages it has available and what the preferences sent are. All the markup generated by the server can now use the language in question.

So this seems nice and fairly straightforward, but once you have client side applications things get a little more complex. The reason is that JavaScript, for security purposes, does not have access to the header information of the request. What JavaScript does have access to is a set of properties exposed by the browser that include the installation language of browser. This seems great for normal use because most people are going to be browsing in the language their OS and browser are installed in. But what if we use these properties and it turns out the language the browser requests isn't the same as the browsers installed language? We are creating a web site that ignores the protocols headers that specifically negotiate language. This seems like a path to erroneous behavior and hard to diagnose bugs.

So another popular option is to include the language in a form that is readable by both client and server. This is done by adding something to the query string like "lang=en" or "l=en". This is nice and it allows you to do things like put controls in your page that control what language your page is in, but you become bound to the query string parameter and relying on a specific query string parameter to always be present is probably not the greatest way of doing things.

So one possibility is to have a web service that echoes back language selection, but this isn't necessary if you have the query string info. So I think what makes sense is to check the query string. On a failure check a web service. This allows for sensible and expected default behavior, but also allows you to be flexible since your application can modify the language you are using.