ISO 639-3 releases list of 2009 changes

[Leif Halvard Silli]

It is for compatibility reasons that I disagree with how CLDR does it. 
The best thing would be to treat 'no' as locale in itself, independent 
from 'nb' and 'nn' - but to recommend against actually using 'no' as a 
locale. And then to operate with more or less obligatory fallback from 
'nn' to no' and from 'nb' to 'no'.  The same looks to me as workable 
for 'sh'. I also think that, at least for Norwegian, 'no' can function 
as a "shadow locale" which to which the things that 'nn' and 'nb' share 
is linked. (For instance, I cannot tell how illogical it is when Mac OS 
X operates with 'Bokmål fonts' or 'Nynorsk font' - 'Norwegian fonts' at 
least makes some sense.) If this policy is claimed to be incompatible 
with something, then that can only judged by evaluating a concrete such 
example. 

For those that actually do use 'no', or 'sh' or 'zh' as the primary 
locale, however, then the fallback order should look differently. If 
there absolutely needs to be only /one/ rule for what 'no/sh/zh' should 
fallback to _first_, then of course it would be smart to, as the main 
rule, fall back to the majority language.

Leif

Mark Davis ☕, Fri, 22 Jan 2010 11:12:41 -0800:
> The macrolanguage mechanism might be perfectly fine for some applications.
> For internationalization, however, the thought of changing all use of "zh"
> to "cmn" is simply bizarre; it'd be like getting all the people driving on
> the left side of the road (GB, AU, JP,...) to switch to the right. Ain't
> gonna happen. On the other hand, mapping "cmn" to "zh" for lookup is
> absolutely feasible, and maintains compatibility. And the instability in ISO
> 639-3, where any language could suddenly become a macrolanguage makes it
> even worse.
> 
> So for compatibility and stability reasons, in Unicode we map the
> predominant encompassed subtag to the macrolanguage. The "no" and "sh"
> predated the macrolanguage mechanism, and are handled differently -- also
> for compatibility. (Although frankly, in an ideal world we'd also map "nb"
> to "no", and "sh" to "sr".)
> 
> Mark
> 
> 
> On Fri, Jan 22, 2010 at 10:49, Leif Halvard Silli <
> xn--mlform-iua at xn--mlform-iua.no> wrote:
> 
>> John Cowan, Fri, 22 Jan 2010 11:03:19 -0500:
>>> Mark Davis ☕ scripsit:
>> 
>> ( I placed back the cappuccino letter that John's mailer destroyed.)
>> ;-)
>> 
>>>> The way we have it set up, it isn't for us to decide. But consumers
>>>> of BCP47 (like CLDR) do have to, if ISO continues to change
>>>> languages into macrolanguages
>> 
>> If you by that mean that CLDR should try to annulate the effect of
>> macrolanguages, then I think rather the opposite is the way to go.
>> Though, of course, every case should be treated independently, I guess.
>> 
>>>> (will German be next?).
>>> 
>>> Very improbable, given the description of 'de(u)' in Ethnologue.
>>> Though Ethnologue is no more immune to error than ISO 639 [*], it does
>>> provide the denotation of the vast majority of 639-3 code elements, and
>>> http://www.ethnologue.com/show_language.asp?code=deu is clearly about
>>> Standard German as spoken from Belgium to Kazakhstan, not any other kind
>>> of German.  It would be a massive and unnecessary widening of the term
>>> to turn it into a macrolanguage of any sort.
>> 
>> But even so, the CLDR issue can be looked at from another angle than
>> the one Mark does:
>> 
>> It has been pointed out that CLDR is derived from BCP47 and not the
>> other way around. Currently the CLDR treats 'no' as a synonym of 'nb'
>> (I would like to file a bug against this when I have power to follow it
>> up ...)  However, just as CLDR this way overrules the effect of a
>> macrolanguage classification,  it could also go the other way and
>> effectively treat 'de' as a macrolanguage/fallback code for  e.g.
>> 'gsw'. That to me seems as often a quite reasonable think to do. It
>> would not not need to affect how language tagging should be performed
>> however - it could remain "forbidden" to tag "gsw" content as "de".
>> --
>> leif halvard silli
>> _______________________________________________
>> Ietf-languages mailing list
>> Ietf-languages at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>>