Re: [Ltru] Consensus call: extlang

Phillips, Addison 2008-06-03 20.32:

>> I share this concern.  It must be crystal clear that 'zh'
>> does NOT mean Mandarin, but rather any kind of Chinese.
> 
> +1
> 
>> Of course, there are cases where one might deliberately be
>> imprecise in tagging, but we should not be so
> 
> It is always permissible to tag Mandarin as 'zh'. It is also

I hear this a lot:

	«'zh' is for all Chinese. But it is permissible to use 'zh' for 
Mandarin.»

If you really want to emphasize that 'zh' is for all, then you 
must start saing that it is permissible to use 'zh' for Cantonese 
- because we allready know that it is allowed for Mandarine.

> permissible, within one's own application, to require that
> people who want something other than Mandarin to use a
> different tag than 'zh'. For example they can be required to
> use the tag (choose one: yue | zh-yue).

Then it is also permissible to require Mandarin users to use 'cmn'.

If we, as Doug said, "believe" in the macrolangauge thing, that it 
describes a real thing, then we should emphasize that it is not at 
all advicable to say that 'zh' means Cantonese or Mandarin in any 
context.

What we *should* say is that the Macrolanguage code should not be 
locked to any particular variety. Application developers should 
strive to keep it as a "free code" - a wild card that can be used 
by any of the encompassed languages.

By wild card I mean this: when I use Mac OS X with Nynorsk as 
preferred langgae, then 'no' should lean towards meaning 'nn'. 
That is: If a text editor is tagged as having 'no' interface, 
then, even if this in reality means that it is Bokmål, still, for 
deciding which spell checking dictionary to use as default (often 
this is synced with the GUI langauge), the application should 
default to 'nn'/Nynorsk. But if I run Mac OS X with Bokmål as 
preferred langauge, then 'no' should default to be interpreted as 
an alias for 'nb' - thus bokmål dictionaries should be picked.

The users will then have to accept that they cannot expect to have 
full control over the interface language of applications tagged as 
'no'. And this is not difficult. Users accept this easily. As long 
as you do not use 'no' but translate it in the user interface as 
'Nynorsk' or 'Bokmål'. Same for zh/Chinese, if it in some language 
is translated as 'Mandarin', then you will get user reactions if 
you use it for any thing else but Mandarin. Hence, such use should 
be avoided.

> What is not permissible is to dismiss someone else's Cantonese
> content tagged as 'zh' as wrong.
> 
> A corollary example might help:
> 
> It is always permissible to tag US English as 'en'. It is also
> permissible, within one's own application, to require that
> people who want something other than US English to us a
> different tag from 'en'. For example, they can be required to
> use the tag 'en-GB'.
> 
> What is not permissible is to dismiss someone else's UK English
> content tagged as 'en' as wrong.

Let me reuse your example:

  In Mac OS X I can select UK English as preferred language. 
Unless 'en_UK' localisations are available, then the 'en' tagged 
localisations with 'en-US' content will be served. However, there 
will be one important difference: UK dictioanaries will be 
preferred over US ones. And and certain other things will shift to 
its British values.

Just like the "color" of the "en" tag shifts based on whether the 
user prefers en-US, en-UK, en-Ca etc, the same way the 
Macrolanguage tag should shift according to which variety of the 
Chinese/Norwegian/Arabic language one is preferring.

Btw, since I have been critical about Apple, I think they do the 
right thing when they use 'en' for US English *while still* 
translating its meaning as "English" and not as "US English". It 
is *this* which is permissible. And if this is what you mean, 
Addision, then I agree with you. But if you mean that one can use 
"en" but put a "US English" on it as a label, then I disagree.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru