Thank you, Gérard, for a good overview of changes in language identifiers through the history of ISO 639 (many of which happened before my time as responsible for the maintenance). This overview is very useful, and it reflects changing “639 thinking” over time.
However, it doesn’t relate to the issue that was raised: “A.3.4 Reservation of identifiers”. On the other hand it relates to the issue of code table stability and backwards compatibility, which has become increasingly important through the lifetime of ISO 639.
One also weren’t so concerned with “space” in the early days of ISO 639. Even the mere 676 possible identifiers in the alpha-2 code seemed like a lot in those days. I am quite certain that neither Yiddish, Indonesian or Hebrew would have had their identifiers change if the issue came up today. These three languages occupy six spaces in the code table, three of which are deprecated (but none of which are “reserved”).
But Gérard’s historical overview should obviously be kept in mind.
prosjektleder / Project Manager
Standard Norge / Standards Norway
[log in to unmask]
P Tenk på miljøet før du skriver ut denne e-posten. / Please consider the environment before printing this e-mail.
In my personal opinion, the situation is not so evident.
I will give some examples of code elements that have a quasi-reserved status.
1/ Concerning ISO 639-1 alpha-2 code elements:
(i) "ji" (Yiddish) that was published in ISO 639 (1988), was replaced by "yi" on 11-03-1989;
(ii) in" (Indonesian) that was published in ISO 639 (1988), was replaced by "in" on 11-03-1989;[HHJ] A small typo here: «id» is the new identifier.
(iii) "iw" (Hebrew/ Iwrith) that was published in ISO 639 (1988), was replaced by "he" on 11-03-1989;
(iv) sh" (Serbo-Croatian that was published in ISO 639 (1988) and was deprecated on 18-02-2000. The same code element was further reinstalled with the publication of ISO 639-1 (2002) and one more time deprecated in 2005;
(v) "jw" (Javanese) was published in table 1 of ISO 639 (1988), but was in fact a double with "jv" that was given in tables 2 and 3 of ISO 639 (1988), so that "jw" and has been deleted on 13-08-2001;
(vi) "mo" (Moldovan) that had been created in ISO 639-1 on 26-06-2008 was rapidly (only after 5 months) deprecated on 03-11-2008 and replaced by "ro"; the corresponding change notice states that this identifier will not be assigned to different items, and recordings using these identifiers will not be invalid, so that the ISO 3166 uses "mo" to represent the name of language "Moldovan" following the fact that article 13 of the Moldovan Constitution writes " (1) The national language of the Republic of Moldova is Moldovan, and its writing is based on the Latin alphabet".
2/ Concerning ISO 639-2 alpha-3 code elements
(i) "jaw"(Javanese) that was published as ISO 639-2/T code element, with "jav" as corresponding ISO 639-2/B code element, in ISO 639-2(1998) was replaced by "jav"on 13-08-2001;
(ii) esp" (Spanish) was not initially published as an official code element in ISO 639-2 (1998); in fact spa" was published as initial ISO 639-2:B and T code element. But the following note was written in the three published tables "After a period of five years from the publication of this standard, "esp" may be used as the ISO 639-2/T (terminology) code for Spanish". So that, because ISO 3166 uses the T version of ISO 639-2, "esp" was published in ISO 3166-1 (2006) and in ISO 3166-2 (2007). It seems that the JAC decided in 2004 not to replace "spa" by "esp" as the ISO 639-2/T code element for Spanish. I never saw this decision, that is not to be found in the ISO 639-2 change notice list. Anyway, as no revision of the text of ISO 639-2 has been made from 1998 on to act this, it remains possible to challenge the legitimity of such a JAC decision
(iii) "scc" (Serbian) that was published as ISO 639-2/B code element, with "srp" as corresponding ISO 639-2/T code element in ISO 639-2 (1998)was replaced by "srp" on 28-08-2008;
(iv)"scr" (Croation) that was published as ISO 639-2/B code element , with "hrv" as corresponding ISO 639-2/T code element in ISO 639-2 (1998 ) was replaced by "hrv" on 28-06-2008
(v) "mol" (Moldovan) that had been created in ISO 639-2 on 26-06-2008 was rapidly (only after 5 months) deprecated on 03-11-2008 and replaced by "ron"(B) and "rum" (T); the corresponding change notice states that this identifier will not be assigned to different items, and recordings using these identifiers will not be invalid, so that ISO 3166 uses "mol" to represent the name of language "Moldovan", following the Constitution of the Republic of Moldova.
As everybody seems to be OK that no ISO 639 code element having represented a name of language in the past from the beginning should be reused to represent another name of language, it seems that my examples concerning ISO 639-1 and ISO 639-2 must be considered as reserved code elements. Moreover, in the case of "mo" and "mol" we are practically vey near of the case of immediate rejection of a new proposed code element. Let me also add that the normative clause A.3.4 "Reservation of codes" of ISO 639-2 (for example) is still explicitely in force today and that this cannot be changed by a vote of the JAC; only a revision of the text of ISO 639-2 could achieive this.
3/ Moreover, concening ISO 639-3 alpha-3 code elements, we have the ugly case of "eur".
"eur" was on the initial list of the ISO 639-3/RA published after the adoption of the ISO 639-3 standard (2007).
The definition of the considered language name was "Europanto: this is the name of the language commonly used by the bureaucrats of the European Communities in their headquarter in Brüssels".
I rapidly asked the ISO 639/RA to suppress from their list this code element, considering that the alleged "name of language" did not correspond to anything existing and was using a very useful alpha-3 code element.. It was answered that "eur" was certainly interesting, at least as a good joke, and that no reason for the requested suppression was found. So, I made a very official request for the creation of the new alpha-3 ISO 639-3 code element "neg" to represent the name of language defined as "Neglish: this is the name of the language commonly used by the bureaucrats of NATO in their headquarter near Brüssels". ISO 639-3 refused to register this very official request, but miraculously decided soon after that to suppress the code element "eur".
I do not find it intelligent to block the use of such an useful and meaningful code element like "eur". So that I propose, as an exceptional and elegant reestablishment for this case to slightly change the interpretation of "eur" from an indistinct and not-existing combination between all official languages of the European Community to the very list of the (currently) 24 official languages of the European Community. We would then create the first example of an alpha-3 ISO 639-5 code element to represent a language group (defined by clause 3.6 of ISO 639-5 as "two or more individual languages that, for some purpose, may suitably be treated as a unit") by definig "eur" as the code element representing the name of the group of languages "Official languages of the European Union".
Le 11 sept. 2013 à 05:38, Håvard Hjulstad a écrit
Just a quick response to “1 a”: I have never had to process any requests for “reserved identifier”. The way I interpreted the rule is: (1) request for identifier; (2) JAC processing results in “no”; (3) request to “at least reserve an identifier”, in case things change; (4) new JAC processing of that request. There never were any “(3)” during my time, and consequently no “(4)”.
prosjektleder / Project Manager
we will have to deal with the official request of ISO/TC 46 concerning 2- and 3-letter symbols for 11 languages. Before starting the process I would like to suggest that we clarify 2 issues:
(1) concerning ISO 639-1:2002 clause A.3.4 “Reservation of identifiers":
"When a request for inclusion of a new entity has been rejected, ISO 639-1/RA may reserve the requested identifier for the use of the applicant and others possible users. ISO 639-1 will keep a record of such reservations and will inform the ISO 639-2/RA of such."
In this connection I would like to ask
a) Håvard whether he has a record on such reservations (because such cases were long in the past),
b) all of you, whether we have considered this clause in our discussions after the problem with the reuse of an outdated country symbol to another country by ISO 3166/MA – in fact, whether this clause is still necessary or will need rewording in future ISO 639.
(2) concerning the assignment of language symbols based on mnemotechnic principles (whether based on the English name of a language or the original name of it):
In this connection I would like to ask you to consider a slight modification of the rules – or rather our practice to apply the rules –:
a) we will run for sure into more problematic cases the more language names are coded, and our argument that the language symbol is merely a code and not an abbreviation is weak.
(in this connection the alignment with country names is probably not really helpful either)
b) our colleague Marion Kresse suggested to select new language symbols from a table showing available letter combinations (as we do) – but choosing the second and/or third letter in such a way that they do not look too much like an abbreviation of the language name in question. In several cases we had to do this anyhow – either due to the lack of letter combinations to choose for the language symbol or because of two or more different languages had similar names.
c) we had internally agreed to reserve as much as possible the letters x, y and z for difficult cases in the future (see for instance airport codes, such as YMX for Montreal International or YND for Ottawa or XRH for Richmond in AUS /=Australia, not AUT=Austria/ - similar problems in different coding systems)
Von: Gérard Lang-Marconnet [mailto:[log in to unmask]]
Gesendet: Mittwoch, 26. Juni 2013 12:10
An: Galinski Christian; Zagas John; ISO639-3 Melinda; Constable Peter; Drude Sebastian; Kresse Maren; Hakala Juha; Porteneuve Elisabeth; Demay François; Patton Glenn; Le Feuvre Pierrick; Lang Gérard; Ferres Mercé; Pelaprat Mary-Lou; Warburton Kara; Warburton Kara 2; Pelle Françoise
Betreff: Request from the ISO/TC 46 to the ISO 639/RA-JAC for the creation of 11 alpha-2 ISO 639-1 code elements concerning the name of administrative languages
In my capacity of liaison officer from ISO/TC 46 to ISO/TC 37, let me inform you that during the plenary session of its 2013 annual meeting in Paris, ISO/TC 46 (Information and Documentation) adopted on Friday 2013-06-07 the following resolution 2013-01:
ISO/TC 46 asks the Joint Advisory Committee on Registration authorities for ISO 639 "Codes for the representation of names of languages" to consider attributing alpha-2 code elements for the languages listed in Document N490, that are administrative languages for ISO 3166-1 countries and need to be referenced to in ISO 3166 "Codes for the representation of names of countries and their subdivisions".
The corresponding list of the 11 alpha-2 ISO 639-1 requested code elements, as proposed by the ISO 3166/MA, follows. Each line gives the proposed/requested alpha-2 code element, the name of the language to be represented (in english and in french), the corresponding alpha-3 ISO 639-2 (or ISO 639-3, if necessary, followed by *) corresponding code element and (the list of) the alpha-2 ISO 3166-1 code element(s) representing the interessed country.
1/ cm; Shikomor/ comorien; ---; KM;
2/ gi; Gilbertese/ kiribati; gil; KI
3/ me; Montenegrin /monténegrin;---; ,ME; 4/ ni; Niuean/ niué; niu; NU; 5/ ns; Soto, Northern/ sotho du nord; nso; ZA; (Remark: among the 11administrative languages of South Afrika, whose names all have an alpha-3 ISO 639-2 code element this is the only one case
not to have an alpha-2 ISO 639-1 code element) 6/ pp; Papiamento/ papiamento; pap; BQ, CW; 7/ pw; Paluan/ palau; pau; PW; 8/ sy; Seselwa Creole French/ seychellois; crs*; SC;
9: tm; Tetum/ tetum; tet; TL;
10/ tp; Tok pisin/ tok pisin; tpi; PG;
11: tv; Tuvalu/ tuvalu; tvl; TV
In the case that some of these 11 requested code elements would not be accepted, ISO/TC 46 would, as I explained at the ISO 639/RA-JAC meeting in Paris on 2013-06-04, ask for the application of the normative clause" A.3.4 Reservation of identifiers" of ISO 639-1:2002 (further consolidated in clause A.5 of ISO 639-4:2010), that writes;
"When a request for inclusion of a new entity has been rejected, ISO 639-1/RA may reserve the requested identifier for the use of the applicant and others possible users. ISO 639-1 will keep a record of such reservations and will inform the ISO 639-2/RA of such.",
so as to be able to use all 11 requested code elements for ISO 3166.
We would like the ISO 639/RA-JAC to consider these requests as soon as possible, because the votes on the three parts of the new edition 2013 of ISO 3166 closed very recently on 2013-06-19 with positive results (for example ISO 3166-1:2013 was unanimously approved, with 29 yes and 6 abstentions on 35 voting P-members), so that it would be nice to be able to insert the requested code elements in the publication of the new edition of ISO 3166.