Print

Print


On Tue, Sep 03, 2002 at 11:40:15PM -0500, Peter Constable wrote:
> 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
> users
> >> will eventually want supported by those infrastructures goes well
> beyond
> >> 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.

I can't tell about that. One thing is what we stipulate in standards,
another whein it is supported. It may be supported already now, I have
not checked the GNU glibc code on this.

> 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 see what you mean. But I think it is recognised in the community
that 3-letter language codes are a need.

> 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?

At least we are doing it in IS 15897. But standards take time. I think
that standard will materialise maybe 2 years from now.
>
>
>
> >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
> Walloon
> >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
> means.

Agree


keld