Subject: [Ietf-languages] deprecation of "bh"

From: Peter Constable <[email-masked]>
Date: Thu, 13 May 2021 22:31:00 +0000

This is a request for input regarding a change being considered by the ISO 639/RA Joint Advisory Committee.

The two-letter language identifiers in ISO 639-1 all represent individual languages, with one exception: "bh" = Bihari languages (a language group that includes Bhojpuri, Caribbean Hindustani, Maithili and other languages). ISO is in the process of revising the ISO 639 standards, and the drafters wanted to characterize Part 1 as coding only individual languages, but I pointed out this exception.

Because it is an anomaly in Part 1, a proposal has been submitted to the ISO 639/RA Joint Advisory Committee by the Part 1 registrar to deprecate "bh". The identifier "bh" would remain in 639 Part 1 with the same meaning, but usage would be strongly discouraged.

I was wondering what the impact might be for BCP 47 if that change in ISO 639 were approved. The possibility exists to update the Language Subtag Registry record for "bh" to indicate it is deprecated, and there are already other records for alpha-2 identifiers from 639-1 that are marked as deprecated: "in" (Indonesian), "iw" (Hebrew), "ji" (Yiddish), "jw" (Javanese), and "mo" (Moldovan). However, those cases are a little different from this case. In those cases, the languages had duplicate encoding with two alpha-2 identifiers, and the LSR records indicate the other identifier in the preferred-value field. In the case of "bh", though, there isn't a duplicate alpha-2 encoding. There is an alpha-3 identifier from 639-2 and 639-5, "bih", but its use is not permitted in BCP 47 because the language in question has a shorter identifier, "bh". So, in the LSR, there two options would be

  *   Add a Deprecated field to "bh" without any preferred-value field.
  *   Don't deprecate "bh" for use in BCP 47, even though it is deprecated in ISO 639-1.

So, what are people's thoughts about these two options?

Thanks
Peter Constable

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 13 May 2021 23:12:47 +0000

Hi Peter,

Note that 'bh' is unique in being a 639-1 derived subtag with a Scope field of 'collection'. So there is already a kind of suggestion in the registry of not using the subtag. Since it is unique, we could add deprecated and a note explaining that individual language subtags are preferred to this collection code without necessarily specifying the list of them?

%%
Type: language
Subtag: bh
Description: Bihari languages
Added: 2005-10-16
Scope: collection
%%

Addison

Addison Phillips
Sr. Principal SDE - I18N (Amazon)
Chair I18N WG, Amazon ACRep (W3C)

Internationalization is not a feature.
It is an architecture.

From: Ietf-languages <[email-masked]> On Behalf Of Peter Constable
Sent: Thursday, May 13, 2021 3:31 PM
To: IETF Languages Discussion <[email-masked]>
Subject: [EXTERNAL] [Ietf-languages] deprecation of "bh"

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Thanks
Peter Constable

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 13 May 2021 17:41:43 -0600

What makes this case tricky is that [bih] would not be withdrawn from ISO 639-2 or 639-5.

So if 'bh' were deprecated in the Registry with no other action, we would have a unique and problematic situation: the only non-withdrawn code element in any part of ISO 639 not represented as a non-deprecated subtag in the Registry, either directly or via its two-letter equivalent.

I don't think we can justify that by noting that 'bh' has a Scope value of "collection" and is thus discouraged in some vague way.

RFC 5646, Section 4.1, bullet point 4 is the relevant passage here. That paragraph talks about exercising caution when using subtags for language collections -- for example, matching algorithms can't match them to individual languages, because there is no definitive list -- but it says nothing about discouraging their use outright. In fact, it states that such subtags are "always preferred to less specific alternatives such as 'mul' and 'und'," and even those two very generic subtags, which /are/ discouraged in the text, are not excluded from the Registry.

Any course we take feels like a greater or lesser deviation from the "letter of the law." I believe the path of least deviation, the decision we should make, is to deprecate 'bh', and add 'bih' and make it the Preferred-Value of 'bh'.

--
Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 13 May 2021 17:54:52 -0600

Upon re-reading what Peter wrote:

> Because it is an anomaly in Part 1, a proposal has been submitted to
> the ISO 639/RA Joint Advisory Committee by the Part 1 registrar to
> deprecate “bh”. The identifier “bh” would remain in 639 Part 1 with
> the same meaning, but usage would be strongly discouraged.

So, just to clarify, the code element [bh] would not be formally withdrawn from 639-1, but would merely be (uniquely) identified with an annotation that says "don't use this"?

This would be a unique situation for 639, which normally withdraws code elements rather than deprecating them.

In that case, we would have two appropriate options for the Registry: do nothing, which was Peter's second option, or deprecate 'bh' and add 'bih' as its P-V, which I proposed in my other message.