Tomohiro Kubota writes:
> I think it is not a good idea to use Japanese filename, even if it
> is encoded by EUC-JP. Do you use filenames in ISO-8859-1?
Sure I did. Being able to save a file under the real name of a friend
without transliteration, say "Mail-von-Jörg", not "Mail-von-Joerg", is
an important feature for users.
Robert Brady writes:
> GTK+ 2.0 will be taking the policy, that all filenames are in UTF-8
This is a mistake. Users use terminals and 'ls' to see and manipulate
their files. The file name, as passed from/to the kernel, must be in
the user's locale encoding.
Mozilla 0.18 assumes the user's filenames are all in ISO-8859-1.
That's broken. Assuming they are all in UTF-8 is just as broken.
The meaning of the G_BROKEN_FILENAMES environment variable ought to be
reversed.
Tomohiro Kubota writes:
> I think it is not a good idea, too. You will have trouble when you
> use other locales (for example, UTF-8 locales).
When a user switches locales, it's easy to rename all files, using a
combination of 'find', 'ls', 'iconv', 'mv'. This is much easier than
converting the contents of the files.
> And more, the advantage of ISO-2022 which I wrote above would be
> lost if ISO-2022 is used only under ISO-2022 locale. (The point
> of this idea is that ISO-2022 can co-exist with any other encodings.
> Thus, terminals can [theoretically] support both locale encoding
> and ISO-2022 at the same time.
You mean, adding ISO-2022 escape sequence interpretation to all
locales, from UTF-8 to ISO-8859-15, would be an advantage? Adding
complexity and unreliability of stateful encodings to all locales?
Oh no. It is not a feature if users can screw up their terminal by
accidentally outputting an escape sequence. It is a bug.
Bruno
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
