Print

Print


Dear All,

 

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?

 

Best regards

Christian

 

 

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

 

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
   <blocked::mailto:[log in to unmask]> [log in to unmask]
   <blocked::http://www.standard.no/> 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