This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

localedata/locales/iso14651_t1 problem?


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.

-- GOTO Masanori

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]