Re: #428 Accept-Language ordering for identical qvalues

Amos Jeffries <> Sat, 19 January 2013 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 369D921F854B for <>; Fri, 18 Jan 2013 20:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rnVS2Tq3LCpj for <>; Fri, 18 Jan 2013 20:32:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3596A21F84C7 for <>; Fri, 18 Jan 2013 20:32:09 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TwQ46-00031U-MO for; Sat, 19 Jan 2013 04:29:58 +0000
Resent-Date: Sat, 19 Jan 2013 04:29:58 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TwQ40-00030k-Ib for; Sat, 19 Jan 2013 04:29:52 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1TwQ3y-0003IA-LF for; Sat, 19 Jan 2013 04:29:52 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id 4A1ABE71B7; Sat, 19 Jan 2013 17:29:25 +1300 (NZDT)
Message-ID: <>
Date: Sat, 19 Jan 2013 17:29:20 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nicholas Shanks <>
CC: "Roy T. Fielding" <>, Julian Reschke <>,
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.9
X-W3C-Hub-Spam-Report: AWL=-0.862, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1TwQ3y-0003IA-LF c4bb76b82803e3dd4363847aa7bce8c1
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16020
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> 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?