This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
localedata/locales/iso14651_t1 problem?
- To: libc-alpha at sourceware dot cygnus dot com
- Subject: localedata/locales/iso14651_t1 problem?
- From: GOTO Masanori <gotom at debian dot org>
- Date: Sat, 05 May 2001 06:26:40 +0900
- Cc: gotom at debian dot org
Hi,
Some localedata/locales/* includes iso14651_t1 as LC_COLLATE definition.
But I recently looked at debian lists, someone complain such locales
including iso14651_t1 leads non-user-oriented behavior like:
> % LANG=en_US ls -a
> . file2vZuoT filevijr0k ssh-XXOKiPLN texMSudLt .X11-unix
> .. filennXKNi .font-unix texaZj9oc .X0-lock .xf86config20364
(This version of "ls" is locale sensitive)
Above is correct behavior. But, users want below behavior like:
> % LANG=en_US ls -a
> . .X0-lock .font-unix file2vZuoT filevijr0k texMSudLt
> .. .X11-unix .xf86config20364 filennXKNi ssh-XXOKiPLN texaZj9oc
This is traditional one.
ISO/IEC 14651:2000 and ISO14651_2000_TABLE1 follow ordering results
as Canadian standard CAN/CSZ Z243.4.1-1998, but this behavior is
not useful for who want tranditional locale behavior...
Is introducing into locale data with iso14651_t1 premature...?
Or should we get ready for 2 data including iso14651_t1 and not one...?
Or is it ok...?
IMHO, using iso14651_t1 causes some back compatibility problems.
So, we make 2 data, one for Unicode (i.e. includes iso14651_t1),
another for ISO-8859-* (i.e. it does not include iso14651_t1),
for all localedatas having iso14651_t1 entry.
In addition, I'm not ISO-8859-* native, so I may have wrong point of view.
If so, I apologize my mistake.
Regards,
-- GOTO Masanori