New item in ISO 639-2 - Zaza

Mark Davis mark.davis at icu-project.org
Thu Aug 24 02:15:34 CEST 2006


This is still an open issue. John discussed the choices in
http://www.alvestrand.no/pipermail/ietf-languages/2004-August/002214.html

To add examples and some pros & cons to his list:

   1. Allow the individual language codes
      - cmn-CN is valid
      - zh-cmn-CN is not
      - + Simplest approach, no new structure.
      - - fallback requires extra information.
   2. Allow the higher-order code extended by an individual language code
      - cmn-CN is not valid
      - zh-cmn-CN is valid
      - - means adding more structure (which we have allowed for).
      - + automatic fallback
      - - testing for validity is slightly more complicated (need to
      check that the combination of lang + extlang is valid)
   3. Allow both 1 and 2 as synonyms.
      - zh-cmn-CN and cmn-CN are both valid and synonymous.
      - - means adding more structure (which we have allowed for).
      - ± automatic fallback (if we canonicalize to the longer form)
      - - testing for validity is slightly more complicated (need to
      check that the combination of lang + extlang for the long form is valid)

A big question in my mind is the stability of the macro language inclusion
relationship. If there is the remotest chance that they will change, eg that
someday de becomes a macro language that includes de, sli, sxu, ltz, vmf,
etc. (http://www.ethnologue.com/show_family.asp?subid=90073) then the only
choice we have is #1.

The more I think about it, the more I like #1. We already have to do fallback
between language subtags (think no, nb, nn), and this recasts the issue into
providing additional data so that if I don't find language subtag X, I can
what is the next best choice Y.

Also see http://www.sil.org/iso639-3/macrolanguages.asp,
http://www.sil.org/iso639-3/scope.asp#M

Mark

On 8/23/06, Addison Phillips <addison at yahoo-inc.com> wrote:
>
> >
> > But the macrolanguage in 639-3 doesn't just create itself, does it?
> > Suppose -- this is my whole point really -- suppose this happened in the
> > 3066ter era.  The Registry would contain primary language subtags "diq"
> > and "kiu".  Now suppose 639-2 adds "zza" and we need to add it as well.
> > We would have to reclassify "diq" and "kiu" from primary to extended,
> > right?
>
> Stability rules prevent this from happening: a subtag cannot change its
> stripes, or the whole meaning of the term "stability" goes out the
> window. In that case, users would need to decide if 'zza' or 'diq'/'kiu'
> were more appropriate for their content. Another potential solution
> would be that language subtag 'diq' might be deprecated in favor of the
> prefix "zza-diq" (using a new extlang 'diq').
>
> Addison
>
> --
> Addison Phillips
> Globalization Architect -- Yahoo! Inc.
>
> Internationalization is an architecture.
> It is not a feature.
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20060823/34586fec/attachment-0001.html


More information about the Ietf-languages mailing list