Re: [Ltru] Macrolanguage usage

Doug Ewell 2008-05-25 23.58:

> Leif Halvard Silli <lhs at malform dot no> wrote:

[ macrolanguage things answered at bottom ]

>>> but some creators of language tags and locale identifiers feel it is 
>>> important to apply region subtags consistently.)
>>
>> To follow the same pattern throughout, you mean. Could be. But I guess 
>> this pattern arises in the first place because one knows about the 
>> need to discern between e.g. en-US and en-GB. To use the region tag 
>> *only* when needed would be too much hazzle, I guess ...
> 
> Why would it be a hassle?

I guess OpenOffice prefers the logic that "all with the same tag 
belong together". (There is both spelling, thesaurus and 
hyphenation for the same language.)

>> (The irony, in the OpenOffice case, is that the nn_NO and nb_NO hyph 
>> dictionaries are *identical*. As is, btw, the en_US, the en_GB and the 
>> en_CA hyph dictionaries.)
> 
> Exactly.  [...]  I don't know whether hyphenation rules differ between 
> Bokmål and Nynorsk, but I suspect they do not. [...]

Right.

>>> 2. It would be impossible to tell whether a non-initial two-letter 
>>> subtag such as 'tw' referred to a region, as in "zh-TW" (Taiwan), or 
>>> an extlang, as in "ak-tw" (Twi).

   [...]

> But if you have a combination region/extlang subtag, you MUST look into 
> the Registry to find out that 'TW' in "zh-TW" refers to a region, and 
> 'tw' in "ak-tw" refers to an extlang.

Yes, I was very formalistic when I spoke about "knowing that it is 
in the region/extlang group."

[...]

> Under the existing rules, if you have a tag "xx-TW" you know that 'TW' 
> is a region, without having to know what 'xx' stands for, or even what 
> 'TW' stands for.  This a valuable property,  [...] 

I can see a value.

>>> 3. It would be impossible to write a tag for, say, "Cantonese as used 
>>> in Singapore" that also expressed the macrolanguage relationship --  
>>> whatever that may be -- between 'zh' and 'yue'.
>>
>> Yes, one would have to choose between 'yue-sg' and 'zh-yue'. The same 
>> would go for Mandarin in China. Either 'cmn-cn' or 'zh-cmn'.
> 
> Don't you consider it a problem that it would be syntactically 
> impossible to express "Cantonese, encompassed by Chinese" and "Cantonese 
> as used in Singapore" in the same tag?  Wouldn't that take away a lot of 

> the value of having extlangs in the first place?

You could say so. However, the usefulness of very long tags and 
the fallback behaviour one could get from that, was also 
questioned. You could call the proposal a compromise in that 
sense. A little from both options, but not  - as the co-chair 
suggested (as a last option) - both simultaneously. (No completely 
free choice between extlang and no-extlang - as the co-chair 
hinted, if I interpreted him correctly.) Stricter rules, in order 
to cover all macrolanguages by the same scheme. Such was the thought.

>>>> And this is a special kind of language negotiation. For a small 
>>>> macrolanguage like NOrwegian, we suddenly get 3 options. If instead 
>>>> we had extlang for Norwegian, we would in reality only have two 
>>>> options.
>>>
>>> This isn't new or sudden.
>>
>> Pardon me for using colorful language (the word "suddenly").
> 
> There's nothing wrong with the way you expressed it.  I like colorful 
> language.  But there still isn't anything sudden about it.

Whether we got 'nn' and 'nb' then or had "suddenly" gotten 'nob' 
and 'nno' today was still not my point. The point was that a 
macrolanguage tagging method would in fact be simpler for users to 
understand.

> Randy has already stated that he doesn't see any WG support for your 
> proposal, and Kent Karlsson has joined me in being firmly against it. 
> There is an important decision yet to be made by the WG -- to have 
> extlangs or not -- and I'm afraid your continuing to push the "combined 
> region/extlang subtag model" is simply clouding the issue.

Right. I see that point. I am dropping the proposal.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru