FYI: ISO 639-5 reconfirmation ballot

[Mark Davis ☕️]

I disagree. If it is withdrawn, and replaced by something else, it still
orphans the codes in the language registry. And if it is replaced by
something that doesn't use the same namespace (a statement like "why use
alpha-3 codes which look identical to language codes?" is worrisome) it
will cause no end of confusion in implementations.

> And it is nowhere near complete enough to be useful.

It should be fleshed out, in that case. Clearly linguists may also need a
more elaborate structure, with more information that would be of little
interest to lay people. And for that it could be useful to have an
*additional* part.

But there would be value value to providing standard 3-letter code to
complete the common groupings like those under "Language Family" on the
right page of https://en.wikipedia.org/wiki/Swahili_language, even when the
categorization changes over time.

Mark

On Sat, Jul 16, 2016 at 6:23 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Peter Constable scripsit:
>
> > So, if nothing else, I think 639-5 should not be withdrawn. Because my
> > main concern is BCP 47, I would have no qualms if 639-5 and its code
> > table remain unchanged.
>
> I disagree.
>
> If it were withdrawn, our Registry would remain unchanged.  Our only
> obligation with respect to ISO 639-5 is to add any subtags that the RA
> (the Library of Congress) should decide to add.  If the RA ceases to
> exist, we don't have to do anything.  Certainly we wouldn't remove any
> of the codes from the former standard.
>
> So I think we should be neutral on the subject, rather than insisting
> that ISO 639-5 must be kept because *in the past* we made a copy of its
> code elements.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Let's face it: software is crap. Feature-laden and bloated, written under
> tremendous time-pressure, often by incapable coders, using dangerous
> languages and inadequate tools, trying to connect to heaps of broken or
> obsolete protocols, implemented equally insufficiently, running on
> unpredictable hardware -- we are all more than used to brokenness.
>                    --Felix Winkelmann
> _______________________________________________
> 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/20160716/cda68d6d/attachment.html>