cannot sort playlist after changing language

[François Févotte]

This is a bug report from a Debian user:

> After changing my LANG from en_GB.UTF-8 to es_AR.UTF-8, I cannot
> sort my playlist by title or artist. It seems, that the
> translated string (e.g. "titulo" for title and "artista" for
> artist) are used as internal Python dictionary key. I can still
> sort by album - it's the same word in English and Spanish. One
> should probably always use the original English string in the
> internals and only use translated strings for display, right?
>
> Traceback (most recent call last):
> File "/usr/share/exaile/xl/trackslist.py", line 592, in set_sort_by
> self.reorder_songs()
> File "/usr/share/exaile/xl/trackslist.py", line 598, in reorder_songs
> attr, reverse = self.get_sort_by()
> File "/usr/share/exaile/xl/trackslist.py", line 618, in get_sort_by
> return (self.col_map[col.get_title()],
> KeyError: 'Artista'

I can confirm that I get the same kind of error when I localize exaile in french (for example). I can only agree with the bug reporter's diagnosis, which seems to be correct. As for fixing the bug, I don't know what would be the best solution:

1- a redesign of the code so that columns titles are shown localized, but are internally kept as uninternationalized strings (which can be used as keys in the sorting requests). This is probably the best way to solve the problem, but it involves much work.

2- a quick fix could probably be implemented by aliasing the different field names in the SQL requests by their localized versions. This is probably more dirty, but would be much easier to implement.

What do you think?

[Johannes Sasongko (sjohannes)]

I'm working on this, but it won't be in 0.2.11 due to the high risk of (1) me running out of time, or (2) the fix being buggy.

It will also break existing settings unless we have a settings upgrade mechanism, just like we have with the db.

[François Févotte (francois-fevotte)]

Hello Johannes,

On 9/25/07, Johannes Sasongko <email address hidden> wrote:
> I'm working on this, but it won't be in 0.2.11 due to the high risk of
> (1) me running out of time, or (2) the fix being buggy.

Yes, such things tend to be very destabilizing, so that might be a
good idea to wait for 0.2.11 to be released before working on it.

> It will also break existing settings unless we have a settings upgrade
> mechanism, just like we have with the db.

I'm not sure how you could do such an upgrade regarding localized
column names. First, I fail to see how such a conversion could be done
without building a "reverse mapping" indicating the English
translation of a localized term (which would not be very easy to
build).
Second, the upgrade mechanism would then have to be locale-dependent,
so that you would have to make sure that the settings upgrade is done
using the same locale as was previously used for saving the settings.

So I would say that the quickest way to do things would be to:
1- check if column names were stored in English in the settings.ini file
2- if that was not the case, drop all "col_order" and "trackcol_*"
settings altogether.

This is very easy to implement, and would guarantee that nothing
breaks, and few informations are lost.

Cheers,
   François

[Johannes Sasongko (sjohannes)]

The fix is working (the code is in the linked branch), but it simply skips column IDs that it doesn't recognises, which means that with an old settings.ini there is no column at all.

I can change it to reset to the default if the IDs are not recognised, but I prefer to have that sort of code in an upgrade script (bug #137126).

[Johannes Sasongko (sjohannes)]

I bit the bullet and merged the changes. What this means is that, if the settings are already wrong, there will be no columns at all. They can be re-enabled from View->Columns.

[Johannes Sasongko (sjohannes)]

Actually, the problem might also show up even when the settings are not invalid. Oh well, at least people will test it.