Subject: Re: [Ltru] rechartering to handle 639-6

From: "Doug Ewell" <[email-masked]>
Date: Wed, 15 Jul 2009 22:00:28 -0600

Mark Davis ? <mark at macchiato dot com> wrote:

> Most of the rest are associated with geographic designations. Rather 
> than have a hit&miss approach to those that seem important to the 
> designers of 639-6, we'd be better off having some variant convention 
> like the following.
>
>  - unlXXXXX is a UN/LOCODE minus the country designator (see for this
>  case, http://www.unece.org/cefact/locode/gb.htm)
>  - isoXXXXX is an ISO 3166-2 code (as regularized and stabilized by
>  CLDR). See for this case, http://en.wikipedia.org/wiki/ISO_3166-2:GB,
>
> So toss out all those that could be expressed in this way (using case 
> just to make the derivation clear):
>
> en-GB-unlHMA for Helmsdale
> en-GB-unlNCS for Newcastle
> en-GB-isoSCT for Scots
> en-GB-isoZET for Shetlandic
> ...

There's nothing wrong with suggesting alternatives to ISO 639-6, but 
let's steer clear of the completely unworkable ones.

UN/LOCODE makes no promises of stability, and has not been updated for 
16 months (the "2007" version having been released in March 2008). 
UN/LOCODE has also declined to respond when informed of duplicates or 
errors in their coding or in their data files (i.e. the "plain ASCII" 
file contains garbage for some entries, perhaps owing to their stated 
belief that CP437 is "the standard United States character set" and that 
it "conforms to [ISO 8859-1 and ISO 10646]").  I seriously question 
whether this standard is being active maintained.

ISO 3166-2 is well known to have two major flaws for our purposes: any 
or all of the code elements for a given country can be, and have been, 
changed completely at any time, and some of them have restrictions 
against free availability.  I understand that the core standards 
themselves do not have to be freely available, but the code lists must 
be.

Any proposal to assign variants on a systematic, formulaic basis -- not 
three or four, but dozens or hundreds or thousands -- ought to make us 
stop and wonder why we don't establish an extension for the purpose 
instead:

* not en-GB-unlHMA, but en-GB-u-HMA
* not en-GB-isoSCT, but en-GB-i-SCT
* not en-GB-6grdi, but en-GB-6-grdi

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Mark Davis ⌛ <[email-masked]>
Date: Wed, 15 Jul 2009 21:21:31 -0700

I'm only saying that for associations with regions, both of those are as
better than -6. And I would far rather see something like that than new
atomic codes in primary position - for variants that just doesn't work. You
are right about the stability issue: that's why I remarked about CLDR -
since we impose stability. So I'm making no proposal; just comparing
hypotheticals.

Mark

On Wed, Jul 15, 2009 at 21:00, Doug Ewell <[email-masked]> wrote:

>  Most of the rest are associated with geographic designations. Rather than
>> have a hit&miss approach to those that seem important to the designers of
>> 639-6, we'd be better off having some variant convention like the following.
>>
>> So toss out all those that could be expressed in this way (using case just
>> to make the derivation clear):
>>
> There's nothing wrong with suggesting alternatives to ISO 639-6, but let's
> steer clear of the completely unworkable ones.
>
> UN/LOCODE makes no promises of stability, and has not been updated for 16
> months (the "2007" version having been released in March 2008). UN/LOCODE
> has also declined to respond when informed of duplicates or errors in their
> coding or in their data files (i.e. the "plain ASCII" file contains garbage
> for some entries, perhaps owing to their stated belief that CP437 is "the
> standard United States character set" and that it "conforms to [ISO 8859-1
> and ISO 10646]").  I seriously question whether this standard is being
> active maintained.
>
> ISO 3166-2 is well known to have two major flaws for our purposes: any or
> all of the code elements for a given country can be, and have been, changed
> completely at any time, and some of them have restrictions against free
> availability.  I understand that the core standards themselves do not have
> to be freely available, but the code lists must be.
>
> three or four, but dozens or hundreds or thousands -- ought to make us stop
> and wonder why we don't establish an extension for the purpose instead:
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>

---

From: John Cowan <[email-masked]>
Date: Thu, 16 Jul 2009 00:29:06 -0400

> let's steer clear of the completely unworkable ones.

[viz. UN/LOCODE and ISO 3166-2]

+1

> stop and wonder why we don't establish an extension for the purpose 

The point of creating an extension is to provide additional orthogonal
information that is packaged up with the language tag.  (IMHO this is
rather silly, as few databases allow only one field, but who knows.)
They aren't meant to be used for specification that of language variant
information; that is semantically part of the language tag and belongs
in the variant field.

-- 
Mos Eisley spaceport.  You will never           John Cowan
see a more wretched hive of scum and            [email-masked]
villainy --unless you watch the                http://www.ccil.org/~cowan
Jerry Springer Show.   --georgettesworld.com

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 15 Jul 2009 22:06:55 -0700

> information; that is semantically part of the language tag and

Well, that isn't necessarily so. I know that the RFC-to-be says that extensions are "orthogonal". But an extension could be created that wasn’t entirely orthogonal to language identification. It might provide finer-grained identification (such as 639-6 is purported to provide) than variants might provide. I think that having an extension proposal would actually be the test of whether it were an appropriate use or not. Just as having 639-6 in a relatively mature state is an important pre-condition to its potential incorporation into the corpus of BCP 47.

Addison