GNOME Bugzilla – Bug 118923
Wrong locale handling
Last modified: 2004-12-22 21:47:04 UTC
I use a iso-8859-15 locale. Every time a gtk2 program tries to browse a directory with a name containing a non ascii character I get error messages Gtk-Message: The filename "s\351curoute.rtf" couldn't be converted to UTF-8 (try setting the environment variable G_BROKEN_FILENAMES): Invalid byte sequence in conversion input Gtk-Message: The filename "Localit\351.zip" couldn't be converted to UTF-8 (try setting the environment variable G_BROKEN_FILENAMES): Invalid byte sequence in conversion input 1) my filenames are *NOT* broken 2) the locale is NOT utf-8, so trying to interpret as UTF-8 is wrong.
Unix file systems have no encoding field for filenames, filenames that depend on the locale, *are* in our opinion broken. Because: A) You can have multiple users on a system using different encodings B) Users do change the encoding they are running in. But anyways, it's just a name 'G_BROKEN_FILENAMES' means use the current locale for the filenames.
It's not just our opinion for at least the most common Linux filesystem, ext2/ext3 filenames officially are encoded in UTF-8, this just isn't enforced in the kernel because POSIX doesn't allow it. Ask the ext2/ext3 filesystem authors...
1) UTF-8 does not work with other programms and I cannot recode all my disks, so GTK2 is broken by lack of backward compatibility 2) my filenames are *NOT* broken, gtk2 is. So I do *not* accept to add googles of environment variables just to tell buggy programzs that my environment does not fit in tyhe straight undocumented limitations of those programs. If gtk2 is uynable to deal with non utf-8 FS then it must be documented and *all* gtk2 programs are buggy.
So rename the environment variable on your local source code tree to "GTK_WORKING_FILENAMES" if the naming of it is your issue. The fact remains that filenames aren't encoding-tagged and therefore have to be in UTF-8 to allow users speaking two different languages to use the same system. There's a conversion utility in perl called "convmv" or something you may want to check out, and also one in C at ftp://people.redhat.com/hp/recode-files.c
I am a *user*, I do not compile. What you say me is that *you* put the code to handle the situation but prefer to insult users that do not fit in your limited scheme rather than activating it automaticaly. It *is* a bug
As for recoding : wshy should the USER make this effort ? Who are you to decide that the only acceptable encoding under Unix is utf-8 ? My xterm, my ssh client do they handle it ? I do not know and will not tryt beca&use a bunch of peopple think they can decide what is good for me.
A) Renaming the environment variable would be an incompatible change, that would require some better reason than people finding it insulting. B) Setting G_BROKEN_FILENAMES is a perfectly valid thing to do in some cases; we do that for Red Hat linux; (though we default to UTF-8 locales where it doesn't matter) There is no reason not to set it if you are on a single user system and all your filenames are encoded in one locale and you always use that locale. C) But thing really will never work properly for non ASCII filenames - they will be "broken" until everybody switches to UTF-8 locales. Resolving as WONTFIX, since we aren't going to make a change here. Thanks.
The fact is that 1) there is code to handle this 2) pressure is put on iuser to change to a configuration which will break many thing 3) gtk2 team finds it perfectly normal Let me conclude that gtk team does not give a damn about users.
Could you not have delayed this kind of things until UTF-8 is more usable ? Or else say it clearly and push for having UTF-8 everywhere ? This kind of behavior discriminates against every non US or UTF-8 user. Friendly, Sven Luther