Re: Feedback: Six Nautilus annoyances

[Owen Taylor <otaylor redhat com>]

On Wed, 2004-02-11 at 16:43, Patrick J. Volkerding wrote:
> On Wed, 11 Feb 2004, Alexander Larsson wrote:
> > I can see Slackware going with C, since its a very traditional "old
> > unix" style distro, and its users might not like it when ls starts
> > sorting like normal humans (without them telling it to).
> 
> Now that you mention it, that is *exactly* the reason that Slackware has
> stuck with C as the default -- the sort order in ls.  Of course, if it's
> now breaking all kinds of things then I might be forced to switch to
> setting an en_US as the default, but would rather not.

The sort order used by ls can certainly be set indepenently of
most of the other characteristics of locale.

LANG=en_US LC_COLLATE=C        # better than LANG=C
LANG=en_US.UTF-8 LC_COLLATE=C  # even better

> As far as I can tell, breakage with C is limited to GTK things.  Could
> this be fixed, or does something about the C locale make that not
> feasible?

Well, as far as I can see this "breakage" here can't be fixed; if the 
C library thinks the right way to sort things is the old-school
ls sort order, then that's how Nautilus, etc, are going to sort
them. The only way to fix that sort order but leave ls sorting
the old way is to patch or wrap ls so that it uses strcmp
or sees LC_COLLATE=C.

But the extremely serious breakage with using LANG=C is that
you are leaving characters with codes greater than 127 without
any interpretation, so a system set up this way is only ever
usable for the most basic ways to write English.

I don't think GTK+ is more broken by LANG=C than other apps, but
it is certainly by far happiest if the system locale is UTF-8,
the same encoding as it uses internally. If you are going to
switch the default encoding of Slackware, I'd really advise
switching it to en_US.UTF-8 so you don't have to switch it 
again later. 

Regards,
					Owen