Version: 1.4.3 (using KDE KDE 3.5.5) Installed from: Fedora RPMs OS: Linux The items displayed in the collection panel are sorted without respect to locales. This not the case for the playlist.
Can you please be more specific and provide an example
In a locale where 'ö' is equivalent to 'o' (regarding collating), A song such as "Tö" will appear after "Tu" in the collection panel (assuming the artist is the same). In the playlist, the songs will appear in the correct order.
Are you refering to Tree, Ipod, or Flat view?
I'm referring to Tree view
Okay, and which enconding are you using? What's the value of the LANG, LC_ALL, and LC_COLLATE environment variables?
LANG = fr_FR LC_ALL and LC_COLLATE are not set.
Well, it works for me with every encoding I try, provided that I have the files for the specific encoding. What's the output of the locale command? All I can think is that your files are somehow messed up. We use QString::localAwareCompare for sorting collection, just like we do on playlist.
I'm quite sure there is a bug in Amarok, since the song titles are sorted in the wrong order only when the collection is ordered by artist. For a given artist, the accented characters in song titles are not equivalent to the non accented ones, as they normally are. On the contrary, Artist names with accented characters are correctly sorted when the collection is ordered by artist. In addition, the playlist is always correctly sorted. In conclusion, it works in some cases, and it fails other cases. If I type the following command : echo -e "td\nté\ntf" | sort on the command line, I get : td té tf which is correct The output of the locale command is : LANG=fr_FR LC_CTYPE="fr_FR" LC_NUMERIC="fr_FR" LC_TIME="fr_FR" LC_COLLATE="fr_FR" LC_MONETARY="fr_FR" LC_MESSAGES="fr_FR" LC_PAPER="fr_FR" LC_NAME="fr_FR" LC_ADDRESS="fr_FR" LC_TELEPHONE="fr_FR" LC_MEASUREMENT="fr_FR" LC_IDENTIFICATION="fr_FR" LC_ALL=
Ah, song titles! somehow I missed this before! Well, I'll see what can be done about it, but probably only for 1.5, when we'll hopefully refactor some of collection browser code. Anyway, for tracks, sorting comes directly from the database, and it means that it will work if you set the encoding and collate correctly in the database.
I don't use an external database, but only the built-in one.
*** Bug 138242 has been marked as a duplicate of this bug. ***
*** Bug 142507 has been marked as a duplicate of this bug. ***
bug 132721 looks like a dup of this one, too
*** Bug 132721 has been marked as a duplicate of this bug. ***
Still present in current Amarok 2.
If this is still an issue, it's an issue in QSortFilterProxyModel. The logic currently with reguards to our sorting is: Check disc number, sort by that. If disc number is =, sort by track number. If track number is equal, or if there is no track number, ask QSortFilterProxyModel to handle the sorting for us. The only resolution I can give is WONTFIX, according to bugzie. It should really be CANTFIX though. Sorry :(