Thank you Håvard for the swift and clear reply.
I vaguely remember that there was such a request probably in the 1980s, when experts were not yet aware of many issues in language coding.
According to Håvard’s reply such a case – if it existed – was not recorded and in practice not enforced. So what could be the conclusions?
(1) Today, we should not do something line “reserving a symbol” for a potential future change (except maybe for a new symbol, which is under discussion for inclusion in the 639 codes by JAC).
- in any case not for 2-letter symbols, where the possible combinations are so limited anyhow
- in fact also not for 3-letter symbols
From a practical point of view, such a decision could also be an internal temporary decision by the JAC, which does not need codification in the future ISO 639.
(2) JAC – out of its experience – could formulate a recommendation to that extent to the present 639 AHG and future ISO 639 JWG for modifying that clause in the future ISO 639.
Would that be agreeable?
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
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.
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)