Re: [Ltru] Consensus call: extlang

Here is a brief description:

   - Map deprecated codes to the canonical codes*. Thus "zh-yue" maps to
   "yue", and identifies Cantonese, "zh-hakka" maps to "hak", and so on.
      - * There are a few exceptions to this where we use the deprecated
      form as the canonical form, for backwards compatibility, eg "iw" for "he".
      - We have yet to decide what to do with codes that are illegal in
      4646, but where the intent is clear, like "zh-yue-Hant-HK"; I
suspect that
      we'll also remap those also, eg "zh-yue-Hant-HK".
      - We don't want to deal with irregular codes, so any that can't be
   resolved by this mapping are disallowed (there is a separate thread on
   that). Luckily in draft 14 there are only a small handful of those.
   - For lookup, use the kind of fallback that Addison outlined, taking into
   account backward compatibility considerations like the fact that "zh-TW" was
   used to represent "zh-Hant".
   - cmn-Hant-TW
      - zh-Hant-TW
      - cmn-Hant
      - zh-Hant
      - cmn-TW
      - zh-TW
      - cmn
      - zh
   - We have fallbacks that are unrelated to macro/micro, like
   Romanian-Moldavian, Filipino-Tagalog, and I'd expect to add to that list
   over time as we support additional languages. Mandarin might be a good
   fallback for, say, Gan; but Spanish might be a better fallback for
   various Quechua encompassed languages. Each case has to be decided on its
   own merits as it comes up: we've found that macrolanguage is not very useful
   for the goal to "give the user what s/he wants/needs".
   - Because extlang brings no benefit and only complications, if BCP 47
   were to adopt it, I suspect we would cease trying to be conformant to BCP 47
   internally.

Mark

On Thu, May 29, 2008 at 9:42 AM, Broome, Karen <Karen_Broome@spe.sony.com>
wrote:

> Mark writes:
>
> >If identification is what you want, then "cmn" IS unambigously
> >Mandarin (indeterminate script);
>
> But is "cmn" the tag you will use, Mark?
>
> >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).
>
> The fallback is *NOT*, I repeat *NOT*, part of the semantic of that tag.
> ISO defines the semantics of the tags and fallback has nothing to do with
> identifying languages.
>
> My issue is this: If I look at my real-world language list and the codes
> I've assigned, I think everyone on this list would agree that the codes I've
> chosen based on the IANA registry and RFC 4646 are the best tags for that
> content. I have codes for everything I need today, thanks to the patient
> guidance of everyone on this list.
>
> However, when RFC 4646bis is released, it seems like I will be using
> different tags than everyone else on this list and we will no longer agree
> on what the best tag is. I fear the subtleties in the rules may prove
> tougher to explain than today's rules which already cause some eyerolling.
> Considering this, I start to wonder if the release of RFC 4646bis is a step
> backward or forward. While I'm happy there's a tag for Broome Pearling
> Lugger Pidgin in ISO 639-3, I don't have any personal need for it.
>
> Regards,
>
> Karen Broome
>

-- 
Mark