Print

Print


Dear All,

 

In the light of the discussions in the JAC over the last 15 or more years and in agreement with Håvard’s explanations, I tend to say that the concept of “reserved identifier” proved to be inappropriate. This definitely needs rewording (or deletion) in the new ISO 639. In addition, at least one identifier was changed because of a mistake, another one because of a country’s request etc. (see explanations below)

I  agree with Håvard that we must be grateful to Gérard for raising the issue so that we can avoid some of the sub-optimal decisions in the past and find the right formulations in the new ISO 639.

 

It seems to me that “reservation of identifiers” as raised by Gérard – if at all – only refers to “spa” (for which “esp” was reserved for 639-2/T use). Several cases referred to corrections, most of them after a few months, or to the normal process of dealing with changes/modifications in the JAC. (see explanations below)

 

I hope that we can settle all cases raised by Gérard within the JAC – whose role it is to deal with change requests – and not raise them again in the planned TC 37/SC 2-TC 46/SC 4 JWG 639 whose role it is to develop the rules of the new 639. The cases Gérard raises and probably many more will be good examples from practice to be considered in the course of wordings of the stipulations of the new 639.

 

Best regards

Christian

 

 

We have different types of modifications! Let me take Gerard’s examples one by one:

1/ Concerning ISO 639-1 alpha-2 code elements/identifiers/symbols:

(i) "ji" (Yiddish) published in ISO 639 (1988) replaced by "yi" on 11-03-1989;

[CG] "Yiddish" in its orignial name of languge "Jiddisch" (יידיש or אידיש, literally "jüdisch", short for "jiddisch-daitsch"= jüdisch-deutsch) is a language largely developed out of Middle High German. Therefore, "ji" was correct under the 1980s philosophy of the 639 experts. I do not recall the reasons, why we changed to "yi" – maybe because of the huge costs involved in re-indexing material in major libraries in the world. It may well be that also the French experts insisted on "yi" because:  "Le yiddish (ייִדיש (API: [ˈjɪdɪʃ] ou [ˈjiːdɪʃ]) en yiddish; également orthographié en français yidish, jiddisch, jidisch ainsi que, selon les rectifications orthographiques du français, yidich, idiche ou yidiche)

The question for JAC is: shall we keep "ji" being a sort of correction as blocked (although it was only used for a few months) or could we release it out of the block? (of course after thorough investigation)

 

(ii) in" (Indonesian) published in ISO 639 (1988) replaced by "id" on 11-03-1989;

[CG] I think it was treated as a correction, but again I do not recall for what reasons.

Same question to JAC as under 1(i)

 

(iii) "iw" (Hebrew/ Iwrith) published in ISO 639 (1988) replaced by "he" on 11-03-1989;

[CG] "iw" was definitely corrected upon the request of Israeli authorities.

Same question to JAC as under 1(i)

 

(iv) "sh" (Serbo-Croatian published in ISO 639 (1988) 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; from a linguistic point of view Serbo-Croatian has been a human-made construct. However, there are huge amounts of documents (i.e. bibliographic data) indexed with "sh".

[CG] If I recall well, "sh" was deprecated as of 2005 (or any other year?). Deprecated does not mean open to re-use after a certain time (as in the beginnings of 639), the symbol "sh" remains, but is blocked for further use.

I think there is no need for the JAC to discuss this again.

 

(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;

[CG] this definitely was a correction of a mistake, which was corrected first in the form of a hardcopy circular to a mailing list, which does not exist any longer.

But as it had been there for several years (not months), I wonder whether it can be considered by JAC like 1(i)

 

(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".

[CG] From a linguistic point of view, Moldovan is a variety of "Romanian". JAC decided not to consider the official status of this variety in Moldavia, because there are lots of other aimilar or not so similar cases (e.g. Valencian), where we would run into great difficulties. It is also a good case where a more "neutral" identifier/symbol (less near to an "abbreviation") would have solved an array of problems.

 

2/ Concerning ISO 639-2 alpha-3 code elements/identifiers/symbols:

[CG] All of the language identifiers/symbols mentioned by Gerard namely

(i) "jav" (Javanese), (ii) "spa" (Spanish), (iii) "srp" (Serbian), (iv) "hrv" (Croation), (v) "rum/ron" (Romanian)

were decided by the JAC after intensive discussions and thorough investigations including the members delegated by TC 46 (to which one could also count LoC)

Therefore, from the JAC’s point of view I would have problems to see the need to discuss them again.

 

3/ Moreover, concening ISO 639-3 alpha-3 code elements, we have the ugly case of "eur".

[CG] This and other code elements (comprising the name/s of the respective language and its identifiers/symbols) are good examples, where the difference can be made clear between

- ISO 639-1 and ISO 639-2, whose code elements have a high "authoritative" nature and

- ISO 639-3 which is a good resource for further harmonization of identifiers/symbols for language names

(not to mention ISO 639-6)

The JAC agreed to consider first of all 639-3 code elements whenever there is a need for coding further languages.

 

 

Von: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] Im Auftrag von Håvard Hjulstad
Gesendet: Mittwoch, 11. September 2013 16:34
An: [log in to unmask]
Betreff: SV: 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

 

Dear all,

 

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.

 

Best regards,
Håvard

 

--------------------
Håvard Hjulstad

  prosjektleder / Project Manager

  Standard Norge / Standards Norway
  [log in to unmask]

  http://www.standard.no/
--------------------
P Tenk på miljøet før du skriver ut denne e-posten. / Please consider the environment before printing this e-mail.

 

Fra: Gérard Lang-Marconnet [mailto:[log in to unmask]]
Sendt: 11. september 2013 14:22
Til: ISO 639 Joint Advisory Committee; Galinski Christian; Håvard Hjulstad
Emne: Re: SV: 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

 

Dear Havard,

Dear Christian,

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".

 

Bien amicalement.

Gérard Lang

 

 

 

 

Le 11 sept. 2013 à 05:38, Håvard Hjulstad a écrit

 

Hi,

 

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)”.

 

Best regards,
Håvard

 

--------------------
Håvard Hjulstad

  prosjektleder / Project Manager

  Standard Norge / Standards Norway
  [log in to unmask]

  http://www.standard.no/
--------------------
P Tenk på miljøet før du skriver ut denne e-posten. / Please consider the environment before printing this e-mail.

 

Fra: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] På vegne av Christian Galinski
Sendt: 10. september 2013 22:58
Til: [log in to unmask]
Emne: WG: 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

 

Dear Colleagues,

 

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)

 

Best regards

Christian

 

 

-----Ursprüngliche Nachricht-----
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

 

Dear All,

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.

 

Bien amicalement.

Gérard Lang=