FW: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

Forwarding...

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, November 02, 2009 10:04 AM
To: Phillips, Addison
Cc: John Cowan; LTRU Working Group; HTTP Working Group
Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

Phillips, Addison wrote:
>> Phillips, Addison scripsit:
>>
>>> I tend to think that HTTP's requirements are most like what the
>>> Lookup algorithm provides. That is, you can (and must) return
>>> exactly one result for a given request.
>> Actually, no; that's an oversimplification of HTTP.  
> 
> Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). 
> 
> This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to.
> 
>> The question is, then, what to do if there is no resource that
>> specifies
>> those minimum requirements.  Apache in this case applies the lookup
>> algorithm
>> to loosen the client requirement in hopes of finding something
>> usable.
>>
> 
> Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely.
> 
> Addison

Several of us just met at the W3C TPAC, and we produced the following 
proposal (this is the full text for the Accept-Language definition):

-- snip --
5.4.  Accept-Language

    The "Accept-Language" request-header field can be used by user agents
    to indicate the set of natural languages that are preferred in the
    response.  Language tags are defined in Section 2.4.

      Accept-Language   = "Accept-Language" ":" OWS
                        Accept-Language-v
      Accept-Language-v =
                        1#( language-range [ OWS ";" OWS "q=" qvalue ] )
      language-range    =
                <language-range, defined in [RFC4647], Section 2.1>

    Each language-range can be given an associated quality value which
    represents an estimate of the user's preference for the languages
    specified by that range.  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." (see also Section 2.3 of [RFC4647])

    For matching, Section 3 of [RFC4647] defines several matching
    schemes.  Implementations can offer the most appropriate matching
    scheme for their requirements.

       Note: the "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
       identical to the matching scheme that was previously defined in
       Section 14.4 of [RFC2616].

    It might be contrary to the privacy expectations of the user to send
    an Accept-Language header with the complete linguistic preferences of
    the user in every request.  For a discussion of this issue, see
    Section 7.1.

    As intelligibility is highly dependent on the individual user, it is
    recommended that client applications make the choice of linguistic
    preference available to the user.  If the choice is not made
    available, then the Accept-Language header field MUST NOT be given in
    the request.

       Note: When making the choice of linguistic preference available to
       the user, we remind implementors of the fact that users are not
       familiar with the details of language matching as described above,
       and should provide appropriate guidance.  As an example, users
       might assume that on selecting "en-gb", they will be served any
       kind of English document if British English is not available.  A
       user agent might suggest in such a case to add "en" to get the
       best matching behavior.
-- snip --

The change is that the definition of matching is now delegated to RFC 
4647, and we just mention that the "Basic Filtering" scheme is identical 
to what RFC 2616 used to say.

See also 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/181/181.diff> 
for the proposed change as a diff from the text in -08.

Feedback appreciated,

Julian

Received on Monday, 2 November 2009 18:31:38 UTC