From keld@dkuug.dk Thu Dec 27 19:23:53 1990
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
	id AA01416; Thu, 27 Dec 90 19:23:53 +0100
Date: Thu, 27 Dec 90 19:23:53 +0100
From: Keld J|rn Simonsen <keld@dkuug.dk>
Message-Id: <9012271823.AA01416@dkuug.dk>
To: i18n@dkuug.dk
Subject: specific locales
X-Charset: ASCII
X-Char-Esc: 29

There has been a discussion on the uniforum-intl list about locales,
which I now am continuing on the i18n list, as it is very relevant to
the work of WG15 RIN.

The original statement as I understood it was that we should not
standardize locales, that is the data in locales, but it was OK to
standardize the language for it.

I am active in three aspects here.

1. I am collecting example locales and making them available by anon ftp
   and email. I have to date clooected locales for X/Open, Greger
   Leijonhufvud and myself/DS. They are available from the site dkuug.dk
   129.142.96.41 in the directory i18n. Examples of email access:

     mail uunet!dkuug.dk!archive
     Subject: dir i18n

     mail uunet!dkuug.dk!archive
     Subject: files i18n
     Names: da_DK ja_JP,XO

   This is in accordance with an item of the approved programme of
   work for WG15 RIN.

2. I have been involved in producing the example Danish National 
   profile and locale on behalf of the Danish member body of ISO (DS).
   This is available as noted above, files da_DK ISO_10646 ISO_8859-1
   ISO_646 (the last three are charmaps for the da_DK locale).
   The da_DK locale is just an example, and has no formal status
   in Denmark or in the POSIX standard (or in CEN). Work is of cause
   done on turning this locale into a formal Danish standard.

3. I am a member of ISO/IEC JTC1/SC22/WG14 for the C language,
   and WG14 has asked me to propose a "C" locale which is more
   intelligent than the current C locale. I have done some work on this.

I am not sure if the original poster was hinting at some of this work,
and which he thought should not be carried out. I see that there
might be problems with the "enhanced C locale" - defining concrete
data for that, but that has already been done with the C and POSIX
locales. 

I think the enhanced C locale is very convenient to fulfill the project
that WG14 has been mandated to do by SC22 on solving "character set issues".

I would like comments on how this could be carried out most conveniently.

Keld Simonsen
