Review period; Nepali and Oriya

[Broome, Karen]

I used the term language a bit loosely in the last paragraph and it doesn't help me here. I perhaps should have said "linguistic entity" or even "audience". Content creators tend to think strongly in terms of the audience even if that's not precisely what's being specified here. 

Regards,

Karen

(It's been awhile, but I still monitor the list!)

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

I would also add that the extlang coding seemed helpful to me in a digital world where audiovisual content is combined with its data and that data is frequently in mostly written Mandarin for the Cantonese speaker (language used in a video in spoken form). Precise tagging is still good on both the data and the video, but the structure of the tag indicated the relationship of spoken and written forms better, and didn't invalidate any past documents in written Cantonese coded as "zh."

For me, it made a connection in a language that has less written diversity than spoken diversity in commercial use today. For what it's worth. I know others felt differently and still do.

Regards,

Karen Broome
Sony Electronics

-----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
_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages