Wednesday, 5 January, 2005, 9:44:37, you wrote:
> TS> * Implemented read support for .m3u and .pls
> TS> playlist formats. This new functionality is
> TS> largely untested at the moment, so reports
> TS> of it working or not are welcome.
> Yesterday I have checked with m3u playlist, that was created with
> XMMS. So, I can see metadata in playlist, this work, and I can play
> files from playlist, but again... My m3u playlist was saved in koi8-u
> encoding, so when I try to start playing cyr named file, I see in
> console "unable open file: path/to/file", but file exist, and in
> console I see proper path to it... And if file not exist, aqualung say
> that file not found, or somthing like this (cannot remember now).
I always knew internationalization's gonna cost me a few headaches :)
OK, let's sort this out. I'll describe the issue from a perspective. GTK+ and libXML all use
utf8 internally, so there are no problems when strings like track names, file names etc.
travel from one point to another in the program, get displayed, etc. Everything is fine
throughout the program, regardless of the characters the user types/sees (since utf8
contains everything, that's the whole point).
The problem arises when something needs to be input (from the command line or playlists) or
output (to system calls) to/from the program. Then we need to convert between the external
encoding and utf8. That's not a problem in itself, GLib has functions for this task.
As long as command line parsing goes (which is where you entered cyrillic characters until
now) the external encoding has always been the locale encoding, i.e. the one that is used by
the filesystem to encode your cyrillic file names.
The .m3u playlist import function src/playlist.c/load_m3u() also uses locale->utf8 encoding
on all strings (track titles and file names) parsed from the .m3u file, before they are
added to the playlist (which needs to receive text in utf8).
And here's the (possible) problem. From where could the program possibly know the encoding
XMMS (or whatever else) used when writing the .m3u playlist? Is it always identical to the
locale encoding? Or is it always koi8-u (user defined)?
If your locale encoding is also koi8-u, it should work. But it does not, so we'll need to
tackle upon this a little. I would ask you to do a simple experiment. In src/playlist.c
at about line 1171 at the end of the function load_m3u() there you find a call like this:
0, g_locale_to_utf8(name, -1, NULL, NULL, NULL),
1, g_locale_to_utf8(path, -1, NULL, NULL, NULL),
2, pl_color_inactive, -1);
This call adds a line to the Aqualung playlist. The two strings 'name' and 'path' are
copied directly from the .m3u file, so they are koi8-u or whatever encoding it is.
The g_locale_to_utf8() should make proper utf8 strings from them, if their original encoding
is the locale encoding. Change these calls to
g_convert(name, -1, "utf8", "koi8-u", NULL, NULL, NULL)
g_convert(path, -1, "utf8", "koi8-u", NULL, NULL, NULL)
If that works, then the locale encoding is not koi8-u.
The specification I found regarding .m3u files only said that the file is 'ASCII',
nothing more specific. :)
I don't have any other idea right now.
Please send me your playlist, so I can try to reproduce (or correct) the problem.