Subject: [Ltru] The true meaning of "macrolanguage" (was: Re: John Cowan...)

From: "Doug Ewell" <[email-masked]>
Date: Fri, 30 Nov 2007 21:02:07 -0800

Peter Constable <petercon at microsoft dot com> wrote:

> If Kwanyama and Ndonga are distinct languages and if "Oshiwambo" can 
> refer to either and is in some contexts used as though it were a 
> single language rather than a collection, then it can be considered a 
> macrolanguage. But if Oshiwambo refers to a distinct variety that is 
> not the same as either Kwanyama or Ndonga but is used or coming into 
> use by speakers of both Kwanyama and Ndonga communities, then it might 
> make more sense to consider Oshiwambo an individual language.

Peter has always been very clear and consistent in his explanation of 
the term "macrolanguage," and the paragraph above is no exception. 
However, I fear there is still a great deal of misunderstanding 
surrounding this term, and I hope Peter and the ISO 639-3/RA are bold in 
explaining and promoting the correct use of this term, which is not 
synonymous with "language family," "language collection," "dominant 
language," or any other term.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://home.roadrunner.com/~dewell
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Fri, 30 Nov 2007 23:01:18 -0800

> From: Doug Ewell [mailto:[email-masked]]

> However, I strongly oppose any efforts to add our own, non-ISO 639
> mappings to the Registry, even seemingly obvious ones like Breton ->
> French.

I agree. Users should choose their own language fallbacks. A an appropriate fallback for Oriya might as readily be Bengali or Hindi or Kannada, depending on the user. That in addition to the issues Doug mentions.

>  That way lies complete madness.  We will never come anywhere
> close to getting all of them, and we will be reviled for "ignoring" the
> ones we miss, and every decision to either include or not include some
> mapping will be viewed by someone as an intentional slight or attempted
> subjugation of one of the languages involved.  Please, let's leave this
> kind of mapping up to each application.

Peter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 1 Dec 2007 14:25:44 +0100

On Fri, Nov 30, 2007 at 08:38:58PM -0800,
 Doug Ewell <[email-masked]> wrote 

> mappings to the Registry, even seemingly obvious ones like Breton ->

Like many people here, I agree. (One of the reasons being that such
mappings would not be very stable.)

> Please, let's leave this kind of mapping up to each application.

But I don't think we should add this solution. I understand the need
for user-specific mappings but I do not see why an
application-specific mapping could be useful.

An "official" "fallback mapping" somewhere (ISO 639-something?) would
be very useful. But I agree that it is not our job.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 14:37:51 +0100

Doug Ewell wrote on the LTRU list:
 
> Cross-references like that are generally considered a good thing,
> aren't they?  They reduce the chances of introducing a typo that
> changes the ABNF, and serve to discourage each application from
> adopting their own, slightly different syntax.

Depends.  For 2616bis they could use a simplified syntax in the
direction of  tag = primary *( "-" auxiliary )  directly expanded
in  tag = 1*8( ALPHA / DIGIT ) *( "-" 1*8( ALPHA / DIGIT ))  with
a note in prose that tags are actually supposed to be BCP 47 tags.

> "Self-sufficiency" should be a complete non-goal.

As proposed above, where is the problem ?  I guess 2616bis needs
also ranges (with "*" stars) based on RFC 4617 somewhere, that is
also covered by BCP 47, but references in RFCs to BCPs, STDs, etc.
are typically given by their RFC number (at least for documents
created with xml2rfc).

> How many modern RFCs seek to define MUST and SHOULD independently
> of RFC 2119

RFC 2821 and I-D.klensin-2821bis come to mind.  It's a royal pain
to check that these definitions are verbatim copies not citing the
source for a very esoteric reason (arguably 2821bis doesn't follow
the one and only MUST in chapter 6 of 2119).

> or the format of a mail message independently of RFC (2)822?

Well, HTTP does some things with MIME you won't find in RFC 2045 ;-)

 Frank (cc hhtpbis)

---

From: Peter Constable <[email-masked]>
Date: Sat, 1 Dec 2007 07:19:02 -0800

> From: Stephane Bortzmeyer [mailto:[email-masked]]

> be very useful.

I disagree. A user with a system set for Breton as the preferred UI language might want to fallback to French or Japanese or Swahili -- it all depends on the user. Perhaps French is a reasonable default that could be assumed in that case in the absence of other information, but that's just one case. What is the fallback for German in Switzerland? What is the fallback for Hindi in India? What is the fallback for Inuktitut, or Filipino?

Peter

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 1 Dec 2007 09:07:50 -0800

> application-specific mapping could be useful.

Sorry, I meant "application" not only in the sense of a program, but 
also a human user or another standard or specification that uses BCP 47. 
I tried to use "application" in the sense it is often used in IETF 
documents.

> be very useful. But I agree that it is not our job.

As Peter said, I don't think anyone else could make these generalized 
pronouncements any better than we could.  It's an individual choice.

---

From: Addison Phillips <[email-masked]>
Date: Sat, 01 Dec 2007 10:40:38 -0800

Peter Constable wrote:
> I disagree. A user with a system set for Breton as the 
 > preferred UI language might want to fallback to French or
 > Japanese or Swahili -- it all depends on the user. Perhaps
 > French is a reasonable default that could be assumed in
 > that case in the absence of other information, but that's
 > just one case. What is the fallback for German in Switzerland?
 > What is the fallback for Hindi in India? What is the
 > fallback for Inuktitut, or Filipino?
> 
> 

+1

I think the Breton example has been beaten to pieces. If my application 
wishes to associate French as the fallback for Breton when Breton is not 
available, that's my application's business. Your application may do 
otherwise. At the BCP 47 level we should avoid making any attempt at 
making mappings like this at all normative.

More to the point: mappings of this nature are someone's guess as to 
what an appropriate fallback would be absent further information from 
the user. It would be unsurprising if, for a Web application, other 
information would also applied in that case. All of this is outside the 
realm of RFC 4647's algorithms (except to say they are examples of 
'implementation defined defaults' in the Lookup algorithm).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.