2012-03-29 22:02, Matthew Nuzum wrote:
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
