[whatwg] Client side value for language preference

[Matthew Nuzum]

Hello, on every HTTP request your browser sends header called
Accept-Language with a value something like this:

    en-gb,en-us;q=0.7,en;q=0.3

This is sent to all domains wither your request is for an image, an
html file, a js script, or whatever. This gives server-side code some
nice capabilities, one of the foremost being the ability to localize
content.

As you all are well aware, more and more application logic is being
done on the client side. In some cases, even HTML templating is being
done there. In a few project I've been involved with recently it would
have been nice to be able to identify the user's preferred language
client side.

Browsers support a value called navigator.language but it does not
convey the same information as the HTTP header. On many browsers it
simply indicates which language the browser is localized in. For
example, if you speak Spanish but buy a computer in America which
comes with Firefox pre-installed then despite what language you prefer
it will be en-us.

Some browsers have gotten smarter and now send the first value from
the user's language preference, which is definitely an improvement. I
suspect this was done in order to preserve backwards compatibility, so
much of the useful information is left out.

What would be great is if client side scripts could access the same
information the server side code could access. That could be done
simply be creating a new property that contains the same string as is
sent to the server. It's easily parseable. But if we're going to make
a new interface then maybe it would be good to make one that reduces
the amount of work that client side developers would need to do.

A very naive and probably flawed example could be:

navigator.language.preference = [{lang:'en-gb', weight: 0.7},{lang:
'en-us', weight: 0.7},{lang:'en', weight: 0.3}];

Then JS could:

var n = navigator.language.preferences
for (i in n) {
  // check if n[i].lang is supported by the application, if so do
something about it
}

This would give users a list of languages with the first in the list
being the most preferred.

Another option is:
navigator.language.preferences =  { "en-gb": 0.7, "en-us": 0.7, "en": 0.3 }
(thanks to Corey Frang for suggesting this)

It's definitely nice and terse but I wasn't sure if browsers
consistently returned the properties in the order they're defined. If
so then this code would work:
for ( locale in navigator.language.preferences ) {
    // if locale is supported by the application then break
}

locale is the user's first choice that is supported by the application

Why am I writing this? Well, my hope is that browser makers will see
the value of being able to access this property client side and
provide a consistent way to access it.

I'd love to hear your thoughts on the matter, also thanks for
considering my first post to the list.

--
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫