Andrew Benton wrote:
Another application I'm keen on is the file sharing application
gtk-gnutella. Filenames are an issue there as people on the network
could be in any locale. There was a long thread on the
gtk-gnutella-devel mailing list about language issues. I read it, but I
don't pretend to understand it all. If you have time, could you have a
look and see what you think?
http://sourceforge.net/mailarchive/forum.php?thread_id=8318817&forum_id=5942
Exactly the same issue/bug. The only known working eDonkey client is
Windows-based crapware running under Wine (and I don't use any other
filesharing networks).
They should have looked how SAMBA solves this, when talking with
WinNT/2K/XP clients. UNICODE is used on the wire. Two configurations are
possible, depending on the "unix charset" parameter in the config file:
unix charset = (locale encoding): filenames are shown correctly by "ls",
in Midnight Commander, Mutt and all other console programs. But invalid
characters are being replaced with underscores, so after storing a file
a client can receive it with a changed name. But that's extremely rare
as Windows users can't type such characters anyway if they configured
the same default regional settings.
unix charset = utf-8: filenames on disk are garbage from the viewpoint
of console apps. But no riund-trip loss occurs.
Admins generally prefer either the first variant or (if the distro is
RedHat or SuSE) use UTF-8 locales where this problem doesn't exist. But
in UTF-8 locales the maximum path length in characters is too short for
Russians.
Also, the following words are 100% correct for ru_RU.KOI8-R if one
replaces "file manager" with "ls command":
So russian filenames will be more important to them than
german filenames. What would be more convenient for them? Store all
names in koi8-r, losing one foreign "รค", but still be able to correctly
see all their downloaded russian files in their file manager? Or store
all names in utf-8, technically not losing any information but losing
the ability to read these filenames, especially their preferred russian
filenames? I bet they won't choose the latter. Why not at least give
the option?
That's why we set G_FILENAME_ENCODING="@locale" in BLFS. Not obeying to
this variable in a glib2-based app is a bug.
Of course the problem doesn't exist in ru_RU.UTF-8, but other problems
appear in that locale.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
