localedata/locales/iso14651_t1 problem?

localedata/locales/iso14651_t1 problem?

[GOTO Masanori]

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

Re: localedata/locales/iso14651_t1 problem?

[Ulrich Drepper]

GOTO Masanori <gotom@debian.org> writes:

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

Then let those people use LC_ALL=C.  You have to learn to
differentiate between the assumptions made by people who used
non-i18n-ized systems and the assumptions a neutral (or new) user has.
The first output is what everybody in the second camp expects since
this is how a dictionary is ordered.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: localedata/locales/iso14651_t1 problem?

[GOTO Masanori]

At 05 May 2001 23:18:11 -0700,
Ulrich Drepper wrote:
> > > % 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
> 
> Then let those people use LC_ALL=C.  You have to learn to
> differentiate between the assumptions made by people who used
> non-i18n-ized systems and the assumptions a neutral (or new) user has.
> The first output is what everybody in the second camp expects since
> this is how a dictionary is ordered.

Do you think iso14651_t1 reached to use?
It has been approved and is under publication,
so it's only in beta stage, IMHO.

-- GOTO Masanori

Re: localedata/locales/iso14651_t1 problem?

[Ulrich Drepper]

GOTO Masanori <gotom@debian.org> writes:

> Do you think iso14651_t1 reached to use?
> It has been approved and is under publication,
> so it's only in beta stage, IMHO.

14651 is already approved but this is beside the point.  This sorting
is done for centuries.  It's nothing which is invented for this
standard.  It's just a codification.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------