Bug 84611

Sorry, but internally Qt uses the libc call strcoll for sorting (which is absolutely reasonable because reinventing locale-aware sorting would be nuts). So you'll have to complain to the people who are responsible for l10n in GNU libc.

> Sorry, but internally Qt uses the libc call strcoll for sorting (which
> is absolutely reasonable because reinventing locale-aware sorting would
> be nuts). So you'll have to complain to the people who are responsible
> for l10n in GNU libc.

I would think this would be the reasonable approach, indeed, to use the
locale-dependant collation function. But how do you explain the fact
that the collation of the drop-down folder list in the "Move to folder..."
menu is sorted as expected, yet the one in the folder pane isn't?
I don't see the reason why the lists should be sorted differently,
other than a bug on kmail's side.

see my last comment

Recent update of my Debian kmail package to version 4:3.2.2-2 has resolved it.
Thanks a bunch, folks!

Sorry, the retest happened under a different locale. It still doesn't work in 4:3.2.2-2

Does this problem still occur for you in the latest KMail?

> Does this problem still occur for you in the latest KMail?


The very latest kmail (from debian testing and from gentoo stable) just 
crashes on startup for me (I have a 2-account    IMAP setup, and there 
have been other bugs reporting crashes similar to mine, so I didn't 
METOO these). The latest kmail I was able to use is the one currently in 
debian stable (sorry I am away from a debian box at this moment, so I 
don't have a version # at hand), and it still does have the bug 
manifested. As a result, I've switched to mozilla-thunderbird for now.

I believe it's pretty straightforward to recreate - create, say, 3 
folders, !admin !block abuse  and see how kmail behaves within the 
standard and a RU locale - the correct order for these should be
!admin !block abuse and not abuse !admin !block.

V

Was LC_COLLATE set correctly?

> Was LC_COLLATE set correctly?

I only set LANG in the env, but, when I do a locale(1),
it certainly outputs all the LC_... variables to be the same:


$ locale
LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES="ru_RU.KOI8-R"
LC_PAPER="ru_RU.KOI8-R"
LC_NAME="ru_RU.KOI8-R"
LC_ADDRESS="ru_RU.KOI8-R"
LC_TELEPHONE="ru_RU.KOI8-R"
LC_MEASUREMENT="ru_RU.KOI8-R"
LC_IDENTIFICATION="ru_RU.KOI8-R"
LC_ALL=

FWIW, the Russian collation rules shouldn't according to my 
(Russian-born) common sense cause the bug behaviour to happen.

V.

> FWIW, the Russian collation rules shouldn't according to my 
> (Russian-born) common sense cause the bug behaviour to happen.
> 


OTOH, it seems to me that indeed there is a problem with the collation 
order in the locale (either I misunderstand what should be happening or 
the locale has a bug), because I am observing the very same problem in 
the mozilla-thunderbird version 1.5.0.7 (20060927). Unless it and kmail 
use some common library above the locale stuff of libc, it should be 
something to do with the locale.

What is the way to see what the OFFICIAL collation rules of the KOI8-R 
locale are, to check whether the locale is implemented correctly?

V

Vassilii, thanks for investigating. I'm afraid I don't know where to find the locale files (and I guess it's specific to your distro), but I'll close this bug since it seems to not be a kde problem. Please reopen it if you find any evidence that it *is* a KDE problem. Thanks!

I've reassigned the debian twin of this bug to libc, retitled and amended it accordingly. Hopefully it'll get eventually resolved.