Re: [Ltru] Consensus call: extlang

[Leif Halvard Silli <[e-mail]>]

Mark Davis 2008-05-29 06.14:

> [...] The string "zh-yue" is really a different semantic; it is
>  not just Cantonese, it is "Cantonese-but-fall-back-to- 
> ambiguously-Chinese-of-indeterminate-script" in lookup (but not
> some other operations like RFC 4646 filtering). [...]


If the focus is identification, then the fallback and filtering 
doesn't matter (or must be defined subsequently).  Certainly, 
however, it is because 'zh-yue' can be identified with 'zh' that 
it can default/fall back to 'zh'.  By saying 'zh-yue' we are also 
identifying 'zh' - as a wide tag.

Extlang makes identifying/finding *all* Chinese languages simple, 
for those that need to do find them all. It would only require 
that you ask for 'zh'. Thus with extlang one could start tagging 
resources spesificly *immediatly*, because it should be highly 
compatible with existing application behaviour.

(Btw, this approach strikes me as higly compatible with another 
popular slogan: Don't break the Web.)

Whether 'zh' or any other Macrolanguage tag would be recommended 
  - alone or together with more spesific tags - as "preferred 
language tag" in Web browsers etc, is a question that must be 
determined by examining the situation for each language and 
localisation.  And it must determined separately from the question 
of how to tag the resources to be consumed (text/audio/video) by 
that program.

(I personally have a hard time thinking that it will *ever* happen 
that e.g. a Chinese user will *not* need to ask for 'zh' 
regardless what we do.)

> On Wed, May 28, 2008 at 7:26 PM, Broome, Karen: 
>> I thought the primary goal was identification, not fallback.
>> Without extlang, we lose some information the ISO standards
>> otherwise contain.  I think we may be losing an oppportunity
>> to clean up some historically muddy tags. I raise questions
>> about identification and I am answered with arguments about
>> fallback. I honestly fear this draft may not be an 
>> improvement for me


What I have understood lately, because I've understood better how 
fallback works, is that extlang WRT fallback is closer to the 
no-extlang solution than I thought. This fact ought to be a reason 
to  focus more on the identifaction issue. The identification 
issue is also more related to tagging *resources* than to saying 
how *applications* should find those resources. At the same time, 
it is of course good to have a compatible model.

I think that deprecating the 'zh' or any of the other 
macrolanguage tags must be out of question. If the purpose of the 
RFC is to deal especially with the Macrolanguages, then it would 
be a strange thing to deprecate those tags. ISO has defined them. 
They must be accepted. Instead  one could focus on saying hat 
macrolanguage tags and extlang tags are good for different 
purposes. One should generally advice strongly against using the 
macrolanguage subtags alone, for tagging, for the identication 
reasons you mention. While at the same time doing a much more 
careful evaluation about what to do inside Web browsers and other 
applications that can be used to find those resources.

This thing with "historically muddy tags" is important. The 
identification argument *is* connected to those Macrolanguage tags 
which are allready in use, and especially to those Macrolanguage 
tags which have been the sole tag for an entire Macrolanguage.

Btw, for those macrolanguages which will not get extlang, we 
should get into the RFC, that to use the Macrolanguage subtag in 
e.g. a Web browser will lead to all encompassed languages being 
included. (With the exception for Swahili, Uzbek etc.) That way, 
for those Macrolanguges which are covering closely related 
encompassed languages, the users and implementors will only need 
to include two tags in order to cover the entire Macrolanguage 
*and* to specify one's preferred encompassed language. I.e. the 
same number of tags that those *with* encompassed languages 
generally will need to include .
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ltru