Re: Issue 113, was: Proposed resolution for Issue 13 (language tags)

Frank Ellermann wrote:
> Julian Reschk wrote:
> 
> [...] 
>>> Felix Sasaki wrote:
>>>> ...
>>>> RFC 4647 defines a basic language range in sec. 2.1
> [...]
> 
>> Proposed text:
> [...]
> 
> Fine.
> 
>> Each language-range MAY be given an associated quality value which
>> represents an estimate of the user's preference for the languages
> 
> Optionally s/MAY/can/.  The syntax has it clear that "q=" <qvalue>
> can be omitted.

+1

> Do you have a special reason to write "q" "=" instead of "q=" ?
> Is this a place where you actually want some kind of *WSP "=" *WSP ?

This is text inherited from RFC 2616. Let's discuss LWS issues 
separately from this issue.

>> would mean: "I prefer Danish, but will accept British English and
>> other types of English."
> 
> Maybe note that this list is not supposed to be sorted by <qvalue>s.

I'd prefer not to change things that aren't broken. Has this come up 
before? Would it be sufficient just to shuffle the language-ranges in 
the example to make the point?

>> The special range "*", if present in the Accept-Language field,
>> matches every tag not matched by any other range present in the
>> Accept-Language field.
> 
> Better add an example here, where the <qvalue> of "*" is not the
> smalles in the list.  That is a pathological case, you'd get get
> an "anything is better than something" effect:
> 
>    Accept-Language: da, en-gb;q=0.8, en;q=0.7, *;q=0.75
> 
> What does this mean if only "en" and "es" content is available ?

Again, did this come up before? Is there a problem we need to solve?

I'm not against examples, but we should use them carefully.

>> I also note that "Basic Filtering" is case-insensitive, which it
>> wasn't in RFC2616.
> 
>  [RFC 2616 page 29]
> | all tags are case-insensitive
> 
> Nothing new here, IMO.

OK.

BR, Julian

Received on Saturday, 2 August 2008 06:38:13 UTC