[Ltru] Collection tags considered problematic (was: "mis" update review request)

Mark Davis mark.davis at icu-project.org
Sat Apr 14 02:33:01 CEST 2007


What is truly unfortunate is that ISO defined these (Other) items by
exclusion. If they had defined the tag "ger" to simply meant Germanic, it
would remain valid indefinitely. They would then behave like macrolanguages.

In LTRU what we need to decide is whether we bail on stability, or we impose
stability. We can do the latter by deciding, like we do with other unstable
ISO codes, that the meaning of the tag "ger" is set at the time we add it to
the registry, and can only be narrowed, not broadened. Then if ISO decides
to add a new code for a Germanic language "gxx", it then simply overlaps
with "ger". It is then a strong SHOULD to use "gxx" in preference to "ger"
where it applies, but it doesn't invalidate previous usage.

Mark

> Randy Presuhn scripsit:
>
> > The thing that bothers me about the comment "A collection of languages
> > which don't belong to any other collection" is that it isn't compatible
> > with the possibility that one or more of those languages might
> > eventually be included in another (possibly new) collection.  If that
> > langauage were left in the mis collection as well, the comment would
> > be incorrect.  If the language were removed from the mis collection,
> > stability goes out the window.  Either way, changing the comment
> > wouldn't help the situation.
>
> That's true, but it's also true of all other collection subtags.  "Mis"
> is a particularly bad case, but it's not hard to devise other problematic
> situations; I've changed the Subject: line accordingly.
>
> For example, today Slobbovian (hypothetical) might be considered a Slavic
> language with a heavy Germanic substrate, but tomorrow Thingummy might
> be able to show conclusively that it was really a Germanic language
> with a heavy Slavic superstrate.  That would invalidate the old "sla"
> tag for the Slobbovian Declaration of Independence in favor of a "ger"
> one, but since collections are not and cannot in practice be defined by
> enumeration, such things can't be avoided.
>
> I think we must accept that there is some risk of instability when
> language collection subtags are used; that's a tradeoff against their
> convenience.
>
> Bullet point 3 of section 4.1 of rfc-4646-04 currently says:
>
>         Use specific language subtags or subtag sequences in preference
>         to subtags for language collections. A "language collection"
>         is a subtag derived from one of the ISO 639-2 codes that
>         represents multiple related languages. For example, the code 'cmc'
>         represents "Chamic languages". The registry contains values for
>         each of the approximately ten individual languages represented
>         by this collective code. For example 'jra' (Jarai) and 'cja'
>         (Western Cham).
>
> I suggest adding the following additional text:
>
>         Using a collective language code may often be convenient or
>         necessary when detailed information is not available.  However,
>         collections are defined not by enumerating specific languages,
>         but by genetic or other criteria, and so a specific language may
>         be moved out of a given collection if further information about
>         the language becomes available.  Thus collective language codes
>         are inherently more unstable.
>
> For guidance in interpreting these suggestions, I think we now
> need to include the 639-3 scope information in language subtags:
> "individual language", "macrolanguage", "collective" or "private use".
>
>
> --
> John Cowan                              <cowan at ccil.org>
>             http://www.ccil.org/~cowan
>                 .e'osai ko sarji la lojban.
>                 Please support Lojban!          http://www.lojban.org
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20070413/377c3fbe/attachment.html


More information about the Ietf-languages mailing list