RE: [Ltru] extlang (was: Punjabi)

"Don Osborn" <dzo@bisharat.net> Sun, 18 March 2007 04:16 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSmoW-0000YN-Bt; Sun, 18 Mar 2007 00:16:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSmoV-0000YI-1Z for ltru@ietf.org; Sun, 18 Mar 2007 00:16:11 -0400
Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSmoS-0007wN-JB for ltru@ietf.org; Sun, 18 Mar 2007 00:16:11 -0400
Received: (qmail 23024 invoked from network); 17 Mar 2007 23:15:52 -0500
Received: from pool-71-252-39-214.washdc.east.verizon.net (HELO IBM92AA25595C4) (71.252.39.214) by 72.32.229.137 with SMTP; 17 Mar 2007 23:15:51 -0500
From: Don Osborn <dzo@bisharat.net>
To: 'Doug Ewell' <dewell@adelphia.net>, 'LTRU Working Group' <ltru@ietf.org>
References: <E1HRsNL-0001ob-5h@megatron.ietf.org> <003501c76756$f2213760$6401a8c0@DGBP7M81> <30b660a20703161305h1f007acalb7ecf2c45224b4da@mail.gmail.com> <20070316210509.GF17950@mercury.ccil.org> <30b660a20703161537q77fcf86y9c6488e0eb0603b@mail.gmail.com> <45FB2259.7050202@yahoo-inc.com> <30b660a20703161617u85dbfe1r44ddc29fcfcf1a6d@mail.gmail.com> <45FB2C4E.9090303@yahoo-inc.com> <006e01c7682b$f0687b10$d1397130$@net> <004501c768bb$3bc185e0$6401a8c0@DGBP7M81>
In-Reply-To: <004501c768bb$3bc185e0$6401a8c0@DGBP7M81>
Subject: RE: [Ltru] extlang (was: Punjabi)
Date: Sun, 18 Mar 2007 00:15:42 -0400
Message-ID: <00fd01c76914$18377ae0$48a670a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcdouzwcOUt5bKNkQv6bxLwNt4+GawAH81Yw
Content-Language: en-us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc:
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

Thanks Doug for the clarifications. 

Your statement "This type of person will also invent their own subtags, switch the order of subtags from what the ABNF specifies, and so forth" had me thinking more about user behavior and actually about an analogy with the "diffusion of innovation" model. (Bear with me...)

Briefly, at the lead end of the bell-curve you have the folks who really get it and go with, no matter how complicated it (in fact, maybe invent it). At the other end of course are those who totally don't get it or don't want to, or worse. In the middle are various shades of understanding and motivation, and I'm suspecting that in there, the well meaning folks who kind of get it may use the codes in a seemingly sensible but not strictly proper way. Like cmn instead of zh-cmn (and so on). There already is the notion out there that ISO-639-3 supersedes 1&2 (in some contexts it may, but the real overall relationship - let alone the intricacies of some specific languages - does not seem to lend itself to a quick and clear explanation). That alone could lead to honest errors in choice.

I guess there is a problem, though, if it turns out that the system is complex enough that human errors are likely and technofixes are hard to devise. It may not be possible to cover for all the possible misuses of tags, but maybe one can cover for the smarter mistakes?

On the other hand, what is the actual number of (macro)languages where extlang issues arise?

This may rate as another non-sequiteur message, but I'm trying to think of end users and scenarios. Have a good rest-of-the-weekend.

Don

PS- I take it then that "new" macrolanguages can be defined in the future, under some circumstances?


> -----Original Message-----
> From: Doug Ewell [mailto:dewell@adelphia.net]
> Sent: Saturday, March 17, 2007 1:40 PM
> To: LTRU Working Group
> Cc: Don Osborn
> Subject: Re: [Ltru] Re: Punjabi
> 
> Don Osborn <dzo at bisharat dot net> wrote:
> 
> > I also concur with Mark's unease with "baking" in a certain approach,
> > given the potential alternative needs. I would say "flexibility" here
> > but that got me into trouble before.
> 
> If the proposal is to allow both "zh-cmn" and "cmn" as synonyms, with
> neither deprecated in favor of the other, then I will indeed object to
> that kind of "flexibility."  The current thinking seems to be that
> matching algorithms will be too dumb to perform anything but basic
> remove-from-right truncation, which would fail dismally under such a
> plan.
> 
> > In effect cmn would "map" to zh?
> 
> Yes, via the Prefix field.
> 
> > I wonder if the existence of the codes doesn't pretty much guarantee
> > that some people will, for whatever reason, use the language code
> > without attention to the macrolanguage code. One would have to
> > consider this possibility and provide for it.
> 
> "cmn" would be listed as "Type: extlang".  If people misuse the
> protocol
> to the point of using extended language subtags alone, without their
> prefix, there is probably nothing we can do about it.  This type of
> person will also invent their own subtags, switch the order of subtags
> from what the ABNF specifies, and so forth.
> 
> >> My surmise is that macro-languages are a one-time event: "discovery"
> >> of future macro-languages will mostly be prohibited by rule (since
> >> most of the languages will already have codes in the "primary"
> >> position when they become part of a macro-language collection). If
> my
> >> surmise is correct, we could ban future extlang additions and use
> the
> >> remainder of that namespace for (well) nefarious purposes.
> >
> > Don't agree here. I think there are de facto macrolanguages out there
> > without the title that may need new codes and the extlang
> > relationships with other 639-3 or even 639-1/2 coded (sub)languages
> > that those would imply (Runyakitara, Oshiwambo, and Beti are examples
> > of possibilities, from my understanding of descriptions). At the very
> > least, the door should not be closed.
> 
> I think Addison was talking about the combination of (a) ISO 639-3
> adding new macrolanguage relationships with languages that are not
> currently encoded, and (b) our group sticking to its rule about adding
> extlangs.  If we change our rules and allow extlangs to mean something
> other than what they mean in draft-4646bis-02, then anything can
> happen.
> 
> --
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
> http://users.adelphia.net/~dewell/
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages




_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru