W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Accept-Language prefix matching (was: A broken browser)

From: Maurizio Codogno <mau@beatles.cselt.stet.it>
Date: Thu, 9 Jan 1997 15:59:07 +0100 (MET)
Message-Id: <199701091459.PAA23947@beatles.cselt.stet.it>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: mduerst@ifi.unizh.ch, masinter@parc.xerox.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2274
Martin wrote:

% Now for the question of prefix matching. The RFC indeed defines
% prefix matching, very clearly and consistently. But this prefix
% matching works only one way:

[definition omitted]

% To give an example, we have the following situation:
% Accept-Language      Document        Match?
% language-range       language-tag
% en                   en              YES
% en-us                en-us           YES
% en                   en-us           YES
% en-us                en              NO?!
% en-us                en-uk           NO?!
% The idea is that Accept-Language defines language-ranges,
% whereas the documents will be tagged exactly. I don't know
% exactly how the group arrived at this asymmetry, but I
% guess the basic thought was that for documents, it would
% be clear whether it was US or British English (and
% likewise in other cases), whereas the user would in
% general not care much about the difference. Prefixes
% (ranges) would therefore be used in Accept-Language, but
% not in document tags.
% Several points lead to the fact that the situation is not
% (or should not be) as asymmetric as described in the RFC.
% - Rarely both en-us and en-uk documents are prepared, and
% 	thus the authors don't care about distinguishing
% 	and just tag them with "en".
% - In some cases, there may be no actual difference, and it
% 	would be strange to label a document as en-us if it
% 	is just as well en-uk.
% - Tagging is in many cases done via file names. Something
% 	such as text.en.html and text.fr.html is preferred
% 	to text.en-us.html and text.fr-ch.html.
% - In many cases, language selections on the browser side
% 	are connected to locales. These include a lot of
% 	details where small differences matter, and are
% 	therefore finely granulated. I don't think Windows
% 	or the Mac have something like a "generic English"
% 	configuration.

I personally do not see why a person/browser should ever define 
en-uk unless he/she/it wants to give different q values to 
en-uk and en-us. 

My first reaction would be to add to the definitions that the server,
when receiving an Accept-Language header line which contains a sublanguage
without the father language, MUST (should?) automagically add a q value
for it, which has to be set as (minimum of these)/2 . But I fear that
sometimes this is wrong, since 14.4 says also

      Note: This use of a prefix matching rule does not imply that
     language tags are assigned to languages in such a way that it is
     always true that if a user understands a language with a certain
     tag, then this user will also understand all languages with tags
     for which this tag is a prefix. The prefix rule simply allows the
     use of prefix tags if this is the case.

Received on Thursday, 9 January 1997 07:02:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC