On Tue, 2005-06-21 at 17:54 +0100, Simos Xenitellis wrote: > Though you must agree that this does not follow the principle of "Just > works"; the GUI tool will not be able to do the work for them. Most > end-users will be in a "Am stuck&give up" situation. :( > > If we cannot solve it in a gracefull way, we might be able to put this > whole issue under the carpet if we identify that a very limited number > of end-users are really affected. Can we say that? People from distros, > do you have feedback on this?
I'd say, for normal chinese user in hong kong, they use chinese filename quite frequently, especial home user. But I think another sensible behaviour is, to kindly inform the user about corrupted filename, and return them with some replaced characters, not just using '?', but may be a randome string. As a filename full of '?' or '_' will scare user, that's just abnormal situation !! While replace the filename with some random string is not satisfactory, but people will still able to open the file and 'save as' new file name in the application, etc. Another way to go is leaving a config (gconf key) to set the 'default' legacy encoding, which will used to decode the archieve contents. Looking from another point, I think a more 'global' mechansim like env var or gnome wide gconf key (or equal thing in KDE) to set a default legacy encoding, this is currently often causing problems on linux user in Hong Kong (who use UTF8 as default). People need to exchange files with others, or need to open his/her old files, this files are still using legacy encoding like big5 / gb2312, etc The following is a short list of common problem and should be fixed by a global config mechanism: - Filename in Legazy encoding in zip archieve - Old vfat volume (mount with iocharset should do, but for inside hal, the similar issue happens again) - MP3 tag issue (using big5 instead of plain ascii) (Though id3v2 specify, ascii or Unicode is allowed, but the fact is lots of user's MP3 tag data is big5 (or other legacy enc) and the header is indicating the tag data is ascii. There is some workaround available, for gstreamer, it use an env var 'GST_ID3_TAG_ENCODING' to set the default legacy encoding for reading tag data.) - I believe, similar problem should arise on old .doc/.xls format file also. If this kind of workaround doesn't exist, ppl will forced to use legacy encoding as default, as pure UTF-8 env. is just doesn't practical, considering those old files made in the old days! Regards, Zarick Lau -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
