ISO 639-3 changes

Phillips, Addison addison at lab126.com
Mon Jan 19 23:29:54 CET 2015


Thanks Doug for taking on this annual task!

> There are a couple of new issues this year. One involves the use of "click"
> letters ǀ, ǁ, ǂ, and ǃ for certain African languages instead of ASCII fallbacks.
> The RA has added a code element for ǂUngkue, using the real letter ǂ
> instead of a fallback like =/Ungkue, because the database used by the RA
> now supports them. The RA is not changing the spelling of any existing
> names for now. We have always used the ASCII fallbacks in the Registry
> because they were what the RA used; now may be the time to reopen the
> question of whether to use the real letters uniformly, use ASCII fallbacks
> uniformly, or include both.
> 

I tend to favor the use of the real letters, with my second choice being including both.

> A greater problem is that the 639-3 data files, for the first time, include the
> alpha-2 code element 'zg' for Standard Moroccan Tamazight, which already
> has the alpha-3 code element and BCP 47 subtag 'zgh'.
> According to the 639-3 Registrar, 'zg' was approved at the same time as 'zgh'
> (November 2012) but was not listed in the 639-3 data files or website due to
> a clerical error. However, it is also not listed on the
> 639-2 site or data files, which are the official online resources for 639-1.

Amazing and seriously unhelpful.

It would be useful to include a comments field in the 'zgh' record spelling out the situation.

Do you think the communications you've established with the RA will avoid this occurring again? Is there any way to verify if other subtags are lurking "in the dark" like this?

> 
> RFC 5646, Section 2.2.1 says clearly that if 639-1 adds an alpha-2 code element
> to a language that already has an alpha-3, the 2-letter subtag will not be
> added to the Registry. It doesn't specify what happens if the alpha-2 has
> supposedly been assigned for years but was not published on freely available
> resources (I haven't purchased updates of any of the
> 639 standards, and wasn't supposed to need them).

Operating on the theory for the moment that the omission of 'zg' was a mistake, one supposes that 'zgh' could be deprecated (it cannot be removed). But I tend to think it would be better to follow the course you suggest.

> 
> This will surprise some users
> who still think the ISO websites and data files are the source for BCP 47
> subtags at the user level, but for the rest of us, it will serve to remind us why
> they aren't.

+1

Addison


More information about the Ietf-languages mailing list