Re: #428 Accept-Language ordering for identical qvalues

["Adrien W. de Croy" <[e-mail]>]

sorry, missed that ;q=0.8

ignore that comment about order pref

------ Original Message ------
From: "Adrien W. de Croy" <[e-mail]>
To: "Amos Jeffries" <[e-mail]>nz>; "Nicholas Shanks" 
<[e-mail]>
Cc: "Roy T. Fielding" <[e-mail]>om>; "Julian Reschke" 
<[e-mail]>de>; "[e-mail]" <[e-mail]>
Sent: 19/01/2013 8:09:52 p.m.
Subject: Re: #428 Accept-Language ordering for identical qvalues
>
>RFC 2616 already strongly implies (in prose not ABNF) order preference
>
>>From 14.4
>
>"The quality value defaults to "q=1". For example,
>
>Accept-Language: da, en-gb;q=0.8, en;q=0.7
>
>would mean: "I prefer Danish, but will accept British English and
>other types of English."
>
>The prose states a preference of Danish over the following languages.
>
>Actually the non-requirement for a server to take into account any 
>indicated preferences in Accept-* leads to some interesting conundra 
>for caching.
>
>For instance,
>
>GET /something HTTP/1.1
>Host: someserver.org
>Accept-Language: fr
>...
>
>200 OK Document follows
>Content-Language: en
>Vary: Accept-Language
>...
>
>leads to problems when the cache sees a request
>
>GET /something HTTP/1.1
>Host: someserver.org
>Accept-Language: en
>...
>
>Even though it's obvious to send the cached resource, it's not correct 
>since the selecting header does not match between requests. This could 
>be ameliorated if there were ETags since at least the cached version 
>could be checked?
>
>Adrien
>
>
>
>
>------ Original Message ------
>From: "Amos Jeffries" <[e-mail]>
>To: "Nicholas Shanks" <[e-mail]>
>Cc: "Roy T. Fielding" <[e-mail]>om>; "Julian Reschke" 
><[e-mail]>mx.de>; "[e-mail]" <[e-mail]>
>Sent: 19/01/2013 5:29:20 p.m.
>Subject: Re: #428 Accept-Language ordering for identical qvalues
>>On 19/01/2013 1:50 a.m., Nicholas Shanks wrote:
>>>>>On 2013-01-18 09:46, Amos Jeffries wrote:
>>>>>>I'm with Roy on this one. It's not adding any new requirement 
>>>>>>about
>>>I feel I concur with Julian the most.
>>>
>>>On 18 January 2013 12:11, Roy T. Fielding <[e-mail]> wrote:
>>>>Yes. It would also be conformant to send Mäori text.
>>>Use a macron or leave it off ;-)
>>>[Option-a] [a] on a Mac with one of the "Extended" keyboard layouts
>>>
>>>>Ignoring the preferences sent in Accept-Language is conforming 
>>>>behavior.
>>>>
>>>>Conformance is not a relevant issue here. What matters is what the
>>>>user actually prefers. It is my opinion that when a user sets an
>>>>Accept-Language header to
>>>>
>>>>    Accept-Language: en, de
>>>>
>>>>what they are actually saying is that they accept both languages
>>>>but would prefer en if the de representation is no better.
>>>You cannot assume that. They are either using a broken client, or 
>>>both
>>>are acceptable. Please don't change the standard to accomodate broken
>>>clients, especially as these are going to become fewer in number as
>>>time progresses and machines get upgraded.
>>>
>>>>The reason I believe this is because user agents that allow a
>>>>user to send such a header field have explicitly instructed the
>>>>user that the field is ordered (or based the value on some other
>>>>ordered list for the host UI, as is the case for some cell phones).
>>>All UAs I know of that allow users to set an ordered list of
>>>languages, also send auto-generated q-values.
>>>
>>>Do you actually have any statistics to back up your belief, or is it
>>>just a gut feeling?
>>>Some numbers to say that "versions x and earlier of so-and-so browser
>>>on X-series phones allow users to define an ordered list but do not
>>>send q-values; those browsers currently have a worldwide market share
>>>of 0.0001%" would be useful to know whether it's worth ignoring such
>>>broken UAs to pandering to them.
>>>
>>>
>>>FWIW, my usual AL string, in browsers that let you set one, is:
>>>"en-GB, en-IE, en-AU, en-US;q=0, en;q=0.95, fr;q=0.5, de;q=0.5,
>>>zh-Hant;q=0.1, *;q=0.2"
>>>My goals should be self-evident from the q-values, specifically to 
>>>get
>>>english, french or german, to demote 'complicated' Han script and 
>>>fall
>>>back to anything else. The US thing is to see if sites are actually
>>>obeying my preferences (I get many more "y'all"s than 406's sadly!)
>>
>>According to the 2616 spec we are quibbling over you would get en-GB, 
>>en-IE, or en-AU if any of them were available. These being assumed to 
>>be q=1 and all equal valued; one is supposed to be selected 
>>*randomly*.
>>
>>Now suppose you had a blog page with each comment loaded by XHR as a 
>>separate GET request using that AL header and auto-translation of 
>>comments - your page looks like a group of multi-cultural responses 
>>some possibly with pidgin-English style wording despite probably all 
>>actually being en-US text to begin with. AND if you refresh the page 
>>everybodies language changes from what it was last load.
>>
>>Versus a server which assumed en-GB, en-IE, en-AU were equal q=1 and 
>>ordered by preference would supply you with the en-GB for each 
>>response part of the page.
>>
>>Which is the better outcome for web developers to rely on?
>>Which one is easier for servers to write fast code for?
>>
>>Amos
>>
>
>