On 06/13/2002 03:42:31 AM Keld Jørn Simonsen wrote:

This is an old thread I have only now been able to come back to.

>> I am
>> wondering, though, what the long-term expectations are with regard to
>> two-letter identifiers. [snip]   E.g. they are used in the
>> internationalisation infrastructure of Java and at least some Unix
>> implementations for "locale" identification (identification of anything
>> culture-related, which would include multilingual text), but two-letter
>> codes are not adequate for such uses since the number of languages 
>> will eventually want supported by those infrastructures goes well 
>> 676.
>for unix/posix/c/c++ yes we use the 2-letter code, and that has till now
>proven to be quite productive. It is an established and well known
>practice, and also standardized in ISO/IEC 15897 on locale names.
>We have plans to enhance this use to also use 3-letter 639-2 codes
>when needed.
>For current C/C++ software it is in practise needed to have support
>for a language that there be a 2-letter code.

I'm curious to know when that might occur, and what it would take for a 
need to be perceived. For instance, there was a recent request for a 
2-letter code for Hawaiian, and if I understood the background correctly, 
the main reason behind this request was that someone wanted a unix 
implementation to be created, and was told that a 2-letter identifier was 
needed. There's circular argumentation going on there, it seems to me: 
unix implementations will be enhanced to used 3-letter identifiers if 
there is a need; but faced with an existing 3-letter identifier for which 
there is no 2-letter counterpart, one is told that current implementations 
only work with 2-letter identifiers and so a 2-letter identifier must be 
requested. Nowhere in that equation is there consideration that the 
language in question may not be a candidate for a 2-letter identifier 
according to the criteria of ISO 639-1 (remember that standard?).

I realise that immediate needs can only be dealt with in terms of 
currently-existing implementations, but it seems to me that the signs of 
the times are clear: the number of language communities wishing to have 
software implementations for their languages and writing systems is 
growing quicker than ever before, and thus the time for that promised 
enhancement is at hand. But is it forthcoming?

>I think we should follow the rules laid down in the standard and
>our procedures, when a request is presented to us. It seems like the
>locales are a major usage area of our standard, I believe that the 
>request also came out of a need for a locale name.

The criteria for ISO 639-1 say nothing whatsoever about locales, and that 
standard was not developed primarily to service the needs of software 
localisation and language-enablement. The needs of software localisation 
and enablement are, in fact, rather more extensive that the 2-letter code 
can accommodate, and potentially involve very many languages that do 
satisfy the criteria for ISO 639-1. The request for Walloon may have been 
related to the need for a locale name, though I have reason to question it 
(there had been requests from the community for Walloon to be recognised 
as a distinct language in the Ethnologue as well as in ISO 639, and that 
clearly had nothing to do with locale identification). But what of 
Neapolitan, Asturian, the various Saami languages and other recent 
additions to ISO 639-2? Are they any less valid candidates for 
identification of resources in unix/posix/c/c++/java than Walloon? By no 

- Peter

Peter Constable

Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <[log in to unmask]>