Review period; Nepali and Oriya

[Peter Constable]

The 639-3 RA faces a bit of a conundrum in certain cases. (It's not clear to me if this really applies to the Oriya and Nepali cases or not; I talking in general terms.) There will be situations in which an existing entry, A, is determined to encompass multiple distinct languages, B and C. (For sake of discussion, I'll assume that B is the more well-known / developed of the two languages.) Now in principle, there are three strategies that can be taken:

i) deprecate the identifier for A and create new identifiers for B and C
ii) create new identifiers for B and C, change the scope of A to macrolanguage, and have A encompass B and C
iii) redefine A to denote B but not C, and create a new identifier for C

There's a general problem with option (iii) that existing records tagged with A may actually be in C, and so those records have suddenly become incorrectly tagged. That problem doesn't occur for either (i) or (ii). To avoid this problem, the text of 639-3 stipulates that, in maintaining the code table, strategy (iii) could not be employed.

Now, it's become clear since the approval of 639-3 that, while the above is strictly speaking true, that hypothetical impact on existing records is not the only type of negative business impact that may arise from the need to accommodate the B/C distinction, and that strategies (i) and (ii) can also have negative business impacts, and potentially moreso than strategy (iii). But strictly speaking, the text of 639-3 doesn't permit that. (That hasn't stopped the RA and JAC from doing something in the vein of (iii) in some cases, but with a hand-wave of assuming that A was really never meant to denote C.)

Even if the text of 639-3 did permit strategy (iii), it won't always be clear how the strategies compare in terms of their real-world business impacts.



Peter

-----Original Message-----
From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Doug Ewell
Sent: Monday, August 20, 2012 11:25 AM
To: ietf-languages at iana.org
Subject: Re: Review period; Nepali and Oriya

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

> Now, that being said, if this group wants to have Nepali and Oriya be 
> macro languages, it is not really a problem for CLDR; simply more 
> entries in the tables. It will cause migration hassles for other 
> implementations that use BCP47, but that is not an issue with CLDR.
> The more common the language, the worse the hassles. For example, 
> consider what would happen were ISO to decide that 'en' really was a 
> macrolanguage with 'ens' being Standard English, and 'enz' being New 
> Zealand English—how much software would hiccough when it hit 
> 'enz-GB'...

I don't think this is an argument for or against creating extlangs. It's more an argument that ISO 639-3/RA should stop converting individual language code elements into macrolanguages. This group didn't decide to have Nepali and Oriya be macrolanguages, of course; that was the RA's decision.

If the RA did what you posit with English, and ietf-languages followed this by creating extlangs, then the theoretical "New Zealand English as used in the United Kingdom" could be tagged, using extlang form, as "en-enz-GB". Existing software might have an easier time with this than with "enz-GB". Of course, in order to assign extlangs under English, this group would have to buy the notion that there is a "specific dominant variety" of English (§4.1.2), and that seems improbable.

--
Doug Ewell | Thornton, Colorado, USA
http://www.ewellic.org | @DougEwell ­

_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages