Subject: Re: [Ietf-languages] Montenegrin has been given an ISO 639-3 code

From: "Doug Ewell" <[email-masked]>
Date: Wed, 15 Nov 2017 14:02:42 -0700

Michael Everson wrote:

> The code is “cnr”.

Is this request, let alone its approval status, listed anywhere on the
639-3 site? Or was it approved in a separate, non-public process?

> This may have implications for us; we use sr-ME, do we not?

People tagging and searching for content do, yes.

Addison noted in response to this:

> "sr-ME" means Serbian as used in Montenegro. "cnr-ME" would mean
> Montenegrin as used in Montenegro.

Which, of course, are essentially the same language. The proponents of
the new code element, along with everyone else who deals with content in
this language, will have to live with the ramifications of requesting
this code. Content tagged "sr-ME" will not disappear or be retagged
overnight. Searching on one tag or the other will return only some of
the desired results, unless search providers add custom code to handle
this case.

Peter Constable wrote:

> Yes, sh/hbs is the macrolanguage encompassing cnr. That macrolanguage
> also encompasses bs/bos, hr/hrv and sr/srp.

We will certainly need to take that into account when the 639-3 data
files are updated and we add this to the Registry.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Peter Constable <[email-masked]>
Date: Wed, 15 Nov 2017 21:42:36 +0000

This is not coming into 639-3 by typical 639-3 process, but rather via 639-2 process. Since the 639-3 RA updates on a regular cycle while the 639-2 RA does so irregularly, since changes to part 2 are infrequent, I expect this might show up in code tables for 639-2 before 639-3.

> Which, of course, are essentially the same language.

Yes, "sr-ME" and "cnr" are effectively synonymous.

> The proponents of the new code element, along with everyone else who deals with content in this language, will have to live with the ramifications of requesting this code...

The request for this new code element came from the National Library of Montenegro. They might not have difficulties if the only thing used within their system is "cnr". But lots of others will have to deal with ramifications. This issue was brought up in the ISO 639-RA/JAC discussion, but most members (those not involved in IT) did not see that as a concern that drove their decision.

Peter

-----Original Message-----
From: Ietf-languages [mailto:[email-masked]] On Behalf Of Doug Ewell
Sent: Wednesday, November 15, 2017 1:03 PM
To: Michael Everson <[email-masked]>; IETF Languages Discussion <[email-masked]>
Cc: ISO639-3 <[email-masked]>
Subject: Re: [Ietf-languages] Montenegrin has been given an ISO 639-3 code

> Montenegrin as used in Montenegro.

Which, of course, are essentially the same language. The proponents of the new code element, along with everyone else who deals with content in this language, will have to live with the ramifications of requesting this code. Content tagged "sr-ME" will not disappear or be retagged overnight. Searching on one tag or the other will return only some of the desired results, unless search providers add custom code to handle this case.

> also encompasses bs/bos, hr/hrv and sr/srp.

We will certainly need to take that into account when the 639-3 data files are updated and we add this to the Registry.

--

_______________________________________________

Ietf-languages mailing list

[email-masked]<mailto:[email-masked]>

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-languages&data=02%7C01%7Cpetercon%40microsoft.com%7C5606d4ad6596488dd33608d52c6d47d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463770227302100&sdata=xiNuDGf8Cd0vZo6DRVEhO2zD2fmYGEUIazl6prKBJ8Q%3D&reserved=0

---

From: John Cowan <[email-masked]>
Date: Wed, 15 Nov 2017 17:27:43 -0500

On Wed, Nov 15, 2017 at 4:42 PM, Peter Constable <[email-masked]>
wrote:

> This is not coming into 639-3 by typical 639-3 process, but rather via
> 639-2 process.
>
I was going to ask if the new code would be added to the "hbs" (aka "sh")
macrolanguage, but I see that macrolanguage is no longer on the 639-2 page,
though it is still in the 639-3 system.  Does that mean that 639-2 has
removed it?

-- 
John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
No,  John.  I want formats that are actually useful, rather than over-
featured megaliths that address all questions by piling on ridiculous
internal links in forms which are hideously over-complex.
        --Simon St. Laurent on xml-dev

---

From: Peter Constable <[email-masked]>
Date: Thu, 16 Nov 2017 05:56:11 +0000

639-2 never included “hbs” or any equivalent to “sh”. I created “hbs” in the draft code table of ISO DIS 639-3 so that part 3 would not have the anomaly of not including an entry for something defined in part 1.

Peter

From: John Cowan [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 2:28 PM
To: Peter Constable <[email-masked]>
Cc: Doug Ewell <[email-masked]>; Michael Everson <[email-masked]>; IETF Languages Discussion <[email-masked]>; ISO639-3 <[email-masked]>
Subject: Re: [Ietf-languages] Montenegrin has been given an ISO 639-3 code

On Wed, Nov 15, 2017 at 4:42 PM, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:

This is not coming into 639-3 by typical 639-3 process, but rather via 639-2 process.
I was going to ask if the new code would be added to the "hbs" (aka "sh") macrolanguage, but I see that macrolanguage is no longer on the 639-2 page, though it is still in the 639-3 system.  Does that mean that 639-2 has removed it?

--
John Cowan          http://vrici.lojban.org/~cowan<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fvrici.lojban.org%2F~cowan&data=02%7C01%7Cpetercon%40microsoft.com%7C5267551f55984676217f08d52c7823e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463816861118741&sdata=H0p8uj2BDzyBXnm%2Fuc%2Bpf6OrxR7KXNFpVTTY8z7s71c%3D&reserved=0>        [email-masked]<mailto:[email-masked]>

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Nov 2017 10:03:01 -0700

When [cnr] does appear on the ISO 639-2 and/or 639-3 code tables, which 
will trigger its addition to the Registry, I will propose including this 
field in the new 'cnr' record:

Comments: see sr

and adding this field to the existing 'sr' record:

Comments: see cnr

and probably also updating the Comments field in the existing 'sh' 
record:

Comments: sr, hr, bs, cnr are preferred for most modern uses

---

From: John Cowan <[email-masked]>
Date: Sat, 18 Nov 2017 13:08:37 -0500

On Sat, Nov 18, 2017 at 12:03 PM, Doug Ewell <[email-masked]> wrote

> Comments: see cnr

I would change the latter to "see cnr for Montenegrin", since few will know
what the code means.

I wish there were some way to enter "sr-ME" as a "redundant" entry, but we
are not allowed to create them de novo.

-- 
John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
To say that Bilbo's breath was taken away is no description at all.  There
are
no words left to express his staggerment, since Men changed the language
that
they learned of elves in the days when all the world was wonderful. --The
Hobbit

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Nov 2017 12:09:36 -0700

John Cowan wrote:

>> Comments: see cnr
>
> I would change the latter to "see cnr for Montenegrin", since few will
> know what the code means.

That seems reasonable.

> I wish there were some way to enter "sr-ME" as a "redundant" entry,
> but we are not allowed to create them de novo.

I guess I don't understand what the goal of that would be. "Redundant" 
doesn't carry any connotation of deprecation or supersession.

---

From: Mark Davis ☕️ <[email-masked]>
Date: Sat, 18 Nov 2017 21:58:45 +0100

> Comments: sr, hr, bs, cnr are preferred for most modern uses

That is going a bit too far: sr, hr, bs, are more customary, but cnr is a
long way from being so, and may never be. We haven't decided what to do in
CLDR, for example, but for stability we might stick with sr-ME until
(/unless) cnr becomes more common. Probably aliasing cnr, like we do with
'mo'.

Mark <https://twitter.com/mark_e_davis>

On Sat, Nov 18, 2017 at 6:03 PM, Doug Ewell <[email-masked]> wrote:

> and probably also updating the Comments field in the existing 'sh' record:
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-languages
>

---

From: John Cowan <[email-masked]>
Date: Sat, 18 Nov 2017 19:05:34 -0500

On Sat, Nov 18, 2017 at 2:09 PM, Doug Ewell <[email-masked]> wrote:

> doesn't carry any connotation of deprecation or supersession.

I was thinking of "grandfathered", but creating a de novo grandfathered
entry is not only disallowed but rather weird.

-- 
John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Nov 2017 17:30:58 -0700

John Cowan wrote:

>> I guess I don't understand what the goal of that would be.
> "Redundant" doesn't carry any connotation of deprecation or
> supersession.
>
> I was thinking of "grandfathered", but creating a de novo
> grandfathered entry is not only disallowed but rather weird.

Not to mention that "sr-ME" is regular. Grandfathered tags are defined 
as being irregular, i.e. not following the BCP 47 syntax.

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Nov 2017 21:17:46 -0700

I wrote, off the top of my head:

> Grandfathered tags are defined as being irregular, i.e. not following
> the BCP 47 syntax.

which is not entirely correct.

Grandfathered tags were in the pre-4646 tag registry and fall into two 
categories:

(1) those that are irregular according to the BCP 47 syntax (e.g. 
"sgn-BE-FR")

(2) those that are syntactically regular, but cannot be broken down 
semantically into a series of BCP 47 subtags, either because the 
"extlangs" aren't registered as extlangs (e.g. "no-bok") or the 
"variant" isn't registered as a variant (e.g. "zh-guoyu"), or if they 
are, the tag doesn't mean what the subtags individually mean.

"sr-ME" doesn't fall into any of these categories: it wasn't in the old 
tag registry (which is what John means by "de novo"); it does follow the 
modern syntax (of course); all of its individual subtags are registered; 
and it does mean what the individual subtags imply.

---

From: Michael Everson <[email-masked]>
Date: Sun, 19 Nov 2017 09:25:56 +0100

On 18 Nov 2017, at 18:03, Doug Ewell <[email-masked]> wrote:
> 
> When [cnr] does appear on the ISO 639-2 and/or 639-3 code tables, which will trigger its addition to the Registry, I will propose including this field in the new 'cnr' record:
> 
> Comments: see sr
> 

Those are a little terse.

Michael

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 19 Nov 2017 08:11:12 -0700

> Those are a little terse.

They are what we have used for years. Only a very few Comments fields 
for language and extlang subtags are longer than "see A, B, C".

I am fine with "see sr for Serbian" and "see cnr for Montenegrin" in 
this case.

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 19 Nov 2017 23:17:07 +0000

> "sr-ME" doesn't fall into any of these categories: it wasn't in the old tag
> registry (which is what John means by "de novo"); it does follow the modern
> syntax (of course); all of its individual subtags are registered; and it does
> mean what the individual subtags imply.

More important: it should not be deprecated. It is a valid and well-formed tag. It has rather more sense than some other valid and well-formed tags (tlh-Cyrl-AQ), even if some users or applications will prefer to use the new ISO 639-3-based subtag. If that subtag is, over time, preferred by users and applications for Montenegrin, then "sr-ME" will be irrelevant. If it isn't, then the subtag will be no more problematic than 'arq' (Algerian Arabic) is to the tag "ar-DZ" (Arabic as used in Algeria). 

To John's point, the Serbo-Croatian complex of languages/dialects is probably more complex than is accounted for by the generative scheme and currently registered subtags in BCP47 anyway. But a deep breath and studiedly ignoring the problem is probably the best course :-).

Addison

> Sent: Saturday, November 18, 2017 8:18 PM
> To: John Cowan <[email-masked]>
> Cc: IETF Languages Discussion <[email-masked]>
> semantically into a series of BCP 47 subtags, either because the "extlangs"
> aren't registered as extlangs (e.g. "no-bok") or the "variant" isn't registered
> as a variant (e.g. "zh-guoyu"), or if they are, the tag doesn't mean what the
> subtags individually mean.
> 
> "sr-ME" doesn't fall into any of these categories: it wasn't in the old tag
> registry (which is what John means by "de novo"); it does follow the modern
> syntax (of course); all of its individual subtags are registered; and it does
> mean what the individual subtags imply.
> 
> --

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 20 Nov 2017 10:55:31 -0700

Phillips, Addison wrote:

> More important: it should not be deprecated.

Then it's probably a good thing it can't be.