Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup

Well, we don't support lookup with *. But if we were to support it, we 
certainly wouldn't return ja-JP (where that is the default) when *-CH is 
requested and (say) de-CH exists.

Mark

Addison Phillips wrote:
> It is merely an example of what one could do. It isn't obligatory. So it isn't that bad, I guess. We don't have text that requires a mapping to basic ranges at the moment and don't necessarily need to introduce it.
>
> On the other hand, I don't think I'd implement an algorithm that way and most underlying locale-like fallback systems will do as I suggested.
>
> Addison
>
> Addison Phillips
> Internationalization Architect - Yahoo! Inc.
>
> Internationalization is an architecture.
> It is not a feature. 
>
>   
>> -----Original Message-----
>> From: Mark Davis [mailto:mark.davis@icu-project.org]
>> Sent: 2006年2月22日 14:54
>> To: John Cowan
>> Cc: ltru@ietf.org
>> Subject: Re: [Ltru] Eliminating the preposterous ASCII ordering in lookup
>>
>> I'm guessing, but only a guess, that this is related to the following text:
>>
>>     
>>> For example, an implementation could return the matching content that
>>> is first in ASCII-order. For example, if the language range were
>>> "*-CH" and the set of content included "de-CH", "fr-CH", and "it-CH",
>>> then the content labeled "de-CH" would be returned.
>>>       
>> "preposterous" is a overblown language. And I strongly disagree with
>> your proposed change. In the example there clearly *exists* content
>> matching *-CH. So returning the default content (which could be, say,
>> Japanese) is clearly *not* what I would have expected!
>>
>> There could, of course, be other strategies for picking a single tag to
>> return from lookup when there are multiple matches for a wildcard. But
>> whatever example we choose should not return something so clearly
>> disconnected from the user's desired outcome. And ASCII is simple to
>> explain.
>>
>> Mark
>>
>> John Cowan wrote:
>>     
>>> It's really laughable to suggest that implementations might use ASCII
>>> tag ordering to make fallback decisions on lookup.  IMHO, the behavior
>>> of extended ranges on lookup should be:
>>>
>>> 	If the first subtag of a language range is '*' and it is
>>> 	followed by other ranges in a priority list, skip it.
>>> 	If the first subtag is '*' and there are no following
>>> 	ranges, return the default content.  All other '*' subtags
>>> 	should be removed before lookup processing is done.
>>>
>>> That is simple, clear, to the point, straightforward, and doesn't
>>>       
>> provide
>>     
>>> preposterous results.
>>>
>>>
>>>       
>> _______________________________________________
>> Ltru mailing list
>> Ltru@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ltru
>>     
>
>
>
>
>   

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru