Errors in Registry
"Doug Ewell" <[email protected]> Tue, 08 Jan 2019 16:57:41 -0700
| Newsgroups | gmane.ietf.languages |
|---|---|
| Message-ID | <20190108165741.665a7a7059d7ee80bb4d670165c8327d.f9c23f4dc6.wbe@email03.godaddy.com> |
I've done some experimenting recently with an XML version of the Language Subtag Registry, which allowed me to build an XSD schema and check the Registry much more robustly than would otherwise be possible with the record-jar format. In the process, I've discovered a few cases where the current Registry is not compliant with the RFC 5646 definition. We need to examine these cases and decide what to do about them. The issues are as follows: 1. Extlangs 'lsg', 'rsi', 'yds' have no Preferred-Value Section 2.2.2 says: "3. Extended language subtag records MUST include a 'Preferred-Value'. The 'Preferred-Value' and 'Subtag' fields MUST be identical." Section 3.1.7 goes on to say: "Changes to one subtag can affect other subtags as well: when proposing changes to the registry, the Language Subtag Reviewer MUST review the registry for such effects and propose the necessary changes using the process in Section 3.5, although anyone MAY request such changes. For example: Suppose that subtag 'XX' has a 'Preferred-Value' of 'YY'. If 'YY' later changes to have a 'Preferred-Value' of 'ZZ', then the 'Preferred-Value' for 'XX' MUST also change to be 'ZZ'." This was clearly written with the use case in mind of a subtag whose Preferred-Value changes from something to something else. The intent was to prevent "chaining" of Preferred-Values, such that 'xxx' has a P-V of 'yyy', which has a P-V of 'zzz', and so forth. However, a subtag can be deprecated with no Preferred-Value. This occurs frequently when ISO 639-3 withdraws a language code element and the decision doesn't provide a single replacement element. In BCP 47, subtags for individual languages that are encompassed by an ISO 639-3 macrolanguage have corresponding extlang subtags, with a Preferred-Value of the language subtag (per 2.2.2). An important extension to this scenario is that sign languages are considered to be encompassed by [sgn], and also get extlangs. Three sign languages have been withdrawn by ISO 639-3, all as "nonexistent": [lsg] for Lyons Sign Language, [rsi] for Rennellese Sign Language, and [yds] for Yiddish Sign Language. In an attempt to follow Section 3.1.7, we removed the Preferred-Value from the extlang records for 'lsg', 'rsi', and 'yds'. But this breaks the requirement in 2.2.2 that all extlangs must have a P-V which matches the subtag value. Proposed action: Restore the P-V for these three deprecated extlang subtags. They will point to deprecated language subtags, which is the "chaining" we were trying to prevent, but that is less of a problem IMHO than the violation of 2.2.2. 2. Variants 'arevela' and 'arevmda' have language subtags as their P-V Section 3.1.2 says: "Preferred-Value's field-body contains a canonical mapping from this record's value to a modern equivalent that is preferred in its place. Depending on the value of the 'Type' field, this value can take different forms: [...] For fields of type 'script', 'region', or 'variant', 'Preferred-Value' contains the subtag of the same type that is preferred for forming the language tag." We deprecated variant subtags 'arevela' for Eastern Armenian and 'arevmda' for Western Armenian when ISO 639-3 added language code element [hyw], because now subtag 'hy' could refer specifically to Eastern Armenian and 'hyw' would refer to Western Armenian, making the variants unnecessary. But this is a violation of 3.1.2: the P-V is not of the same type as the subtag. Proposed action: Remove the P-V for each of these variant subtags, and add a Comments field along the lines of "Preferred tag is hy", analogous to 'heploc'. If there is general agreement to make these changes, I'll post forms. I do feel it's important to bring the Registry in line with its specification. -- Doug Ewell | Thornton, CO, US | ewellic.org