[whatwg] Client side value for language preference
Matthew Nuzum
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! ♫
Jukka K. Korpela
> 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
– –
> Browsers support a value called navigator.language but it does not
> convey the same information as the HTTP header.
Browsers have different features in this respect, but indeed they are
quite distinct from the language preferences.
The language preferences used to have little impact, because few sites
made use of them. And most users never learned about them, and there was
little reason to learn… and therefore the settings are often inadequate,
so it was a vicious circle. Well, still is. But interactive applications
like many Google services are changing the situation: the language
preferences sent are used to affect the language in generated texts and
user interfaces, rather than just selecting between language versions of
documents.
> Some browsers have gotten smarter and now send the first value from
> the user's language preference, which is definitely an improvement.
I think browsers have generally sent an Accept-Language header
constructed from user preferences, for many years. The problem is that
these settings seldom reflect the user’s real preferences, because the
defaults generally depend on the browser language, or on the system
language, not on any action by the user. If you use an English-language
browser, the preference defaults might contain just English in different
flavors, even though English might be the user’s fourth-best language.
> What would be great is if client side scripts could access the same
> information the server side code could access.
Sounds like a useful thing. It would support the idea of enabling
standalone applications that can run offline, too. Along similar lines,
it might be useful to give access to other settings that affect HTTP
headers, but language settings seem to be far more important than other
settings.
Note, however, that the idea postulates a simple model where the header
only depends on certain settings and is the same for all resources. But
this is probably acceptable. It is difficult to imagine a situation
where a user preferred HTML documents in French and images in Italian,
for example.
> 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.
I think the simple idea of a string is the best way to go. Anything
beyond that can be handled by a library that can be written in a
cross-browser way—not quite trivial, but surely doable. The problem is
to get some basic data from the browser in well-defined way. I’d suggest
a name like
navigator.acceptLanguage
> 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.
Actually, it’s the q (weight) values that matter, not the order, so a
routine that selects the most preferred language would need to compare
them. Moreover, the language negotiation mechanism can be more
complicated: it need not select the language with highest q value, since
the resources themselves may have been classified as having different
qualities. This might not matter in most cases, but applications should
still have access to the full information, with q values, either in form
of an Accept-Header string or as a constructed array or object. I’m just
spelling this out to emphasize that simple information about the most
preferred language is not enough, even if the information is taken from
user preferences.
Yucca
Matthew Nuzum
> On Thu, Mar 29, 2012 at 10:02 PM, Matthew Nuzum <ne...@bearfruit.org> wrote:
>> 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.
>> navigator.language.preference = [{lang:'en-gb', weight: 0.7},{lang:
>> 'en-us', weight: 0.7},{lang:'en', weight: 0.3}];
>
> used significantly considering that the HTTP header has not been used
> that much?
I've used the HTTP header numerous times and I know many people that
have. It is so commonly used that Apache even has built in support to
make use of it when serving content.
For example, if you visit http://start.ubuntu.com/9.04/ you'll be
presented with a page that is probably in your language (we translated
it into 42 languages). The way the content negotiation feature of
Apache works is that you name pages in a pattern like this:
index.html.en, index.html.fi, etc. You can see how we did that here:
http://bazaar.launchpad.net/~ubuntu-start-page/ubuntu-start-page/trunk/files/head:/www/9.04/
It's quite easy to make use of this feature and I think it might be
more commonly done than you suspect. And if we were to make it even
easier to do I think that it would increase in use.
For example, maybe a site can't afford translation but a small library
could be included that formats dates and numbers based on a user's
language preference. No more wondering if 2/3/12 is in March or in
February.
Henri Sivonen
> For example, maybe a site can't afford translation but a small library
> could be included that formats dates and numbers based on a user's
> language preference. No more wondering if 2/3/12 is in March or in
> February.
The reader doesn't know that the site tries to be smart about dates
(but not smart enough to just use ISO dates), so scrambling the order
of date components not to match the convention of the language of the
page is probably worse than using the convention that's congruent with
the language of the page.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Tim Streater
> 2012-03-30 17:22, Henri Sivonen wrote:
>
>> On Fri, Mar 30, 2012 at 5:08 PM, Matthew Nuzum<ne...@bearfruit.org> wrote:
>>> For example, maybe a site can't afford translation but a small library
>>> could be included that formats dates and numbers based on a user's
>>> language preference. No more wondering if 2/3/12 is in March or in
>>> February.
>>
>> The reader doesn't know that the site tries to be smart about dates
>> (but not smart enough to just use ISO dates),
>
> mankind is used to. Sometimes ISO dates are the least if evils, but they
> are not proper localisation.
+1
>> so scrambling the order
>> of date components not to match the convention of the language of the
>> page is probably worse than using the convention that's congruent with
>> the language of the page.
>
> <input type=date> and relatives are supposed to deal with?
>
> There is absolutely no way in HTML, in HTML 4 or in HTML5, to say that
> input of dates should be accepted according to a specific convention.
> What users get is an US convention, or a local convention as per the
> browser, quite independently of the (declared or implied) locale of the
> page.
There's no way to ask the OS what the user prefers, I suppose?
--
Cheers -- Tim
Matthew Nuzum
Your points are well taken. My illustration was just an example of
what could easily be possible if client side code could access the
user's preferences. I do believe that the design could be created in a
way that does not confuse users.
I look forward to having the option to work that out.
Steve Axthelm
>Is there a reason to believe that this client-side solution would be
>used significantly considering that the HTTP header has not been used
>that much?
Don't know about significantly, but I recently used the HTTP
headers for a group of support pages that had many localizations
and would have really liked to have been able to handle the
entire logic for that on the front-end.
Regards,
-Steve
--
Steve Axthelm
ste...@pobox.com