aMule Forum
English => en_Bugs => Topic started by: ycjhi on November 26, 2007, 10:02:46 AM
-
OS: MacOS X 10.5 Leopard
CVS: 20071126
Problem:
1. aMule does not correctly display names of local files that have UTF-8 (Korean) filenames.
- When I share a file that has UTF-8 filename, aMule doesn't read the filename correctly. Log (when hashing) also shows broken characters for the filename.
2. aMule does not correctly store filenames of downloaded files that have UTF-8 (Korean) filenames.
- UTF-8 filenames of the files being downloaded are displayed correctly in aMule's transfer screen. But, when they are being stored in local file system, aMule stores filenames in a wrong way. For example, it stores a filename in Korean to be (literally) "%BA%ED%B8%AEġ 300ȭ - Curse named Love.zip"
Note:
- UTF-8 queries in search screen work fine. Also, search results are displayed correctly.
- Log displays UTF-8 filenames correctly when aMule starts downloading.
- aMule 2.1.3 doesn't have this problem. Since I haven't recognized this problem before, aMule-CVS-20071115 seems not to have this problem either.
-
Hi ycjhi,
Nothing has changed recently in unicode handling. There are some problems with filename handling, but not for UTF-8. I personally tested some files with japonese and korean characters and they seem to work fine.
Is your system LANG environment variable set to a UTF-8 language? Here I have
$ env | grep LANG
LANG=en_US.UTF-8
If you have UTF-8 set, things should work, no matter which language you use. If you don't want to change the system default, you can try to run amule like:
$ LANG=ko_KR.UTF-8 /path/to/amule
Cheers!
-
Hi ycjhi,
Nothing has changed recently in unicode handling. There are some problems with filename handling, but not for UTF-8. I personally tested some files with japonese and korean characters and they seem to work fine.
Is your system LANG environment variable set to a UTF-8 language? Here I have
$ env | grep LANG
LANG=en_US.UTF-8
If you have UTF-8 set, things should work, no matter which language you use. If you don't want to change the system default, you can try to run amule like:
$ LANG=ko_KR.UTF-8 /path/to/amule
Cheers!
hi phoenix,
That's strange... ??? my LANG environment variable is always set to en_US.UTF-8 or ko_KR.UTF-8 (as the default in MacOS X is *.UTF-8). I'll try some previous CVS versions and report again.
Thank you,
-
wuischke,
What are you doing to perform the language switch to test translations? I did a test here and aMule only uses the korean character set for the ok button in the about dialog, but not for the rest of the GUI. Filenames are displayed ok in the "shared" tab.
Cheers!
-
Hi phoenix,
There are no problems here, besides a little visual glitch in the sharedlistctrl with korean, Some messages are not translated (e.g. debug, connection notices) at all, but everything else is displayed fine.
I enabled the locales in /etc/locale.gen and ran locale-gen to create them (the Arch way) and then I simply selected the language in the preferences and restarted aMule.
Software I use: glibc 2.7, wxgtk 2.8.4, gtk 2.12.1, aMule r7675 (i.e. last updated today 3:30am UTC+1)
-
Hi wuischke,
I enabled the locales in /etc/locale.gen and ran locale-gen to create them (the Arch way) and then I simply selected the language in the preferences and restarted aMule.
Strange, I never had to do anything in my system to enable other languages. I am using Suse now, but I used to run Fedora Core. Maybe there is a difference, but still sounds strange. I don't have /etc/locale.gen here, I'll see what I can do.
BTW, I get the message:
(amule:3939): Gtk-CRITICAL **: gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
also, locale -a shows me tons of locales.
-
Ok, I configured aMule with --prefix=/home/myuser/usr/local and did a "make install". When I run amule from the installed directory, translations work fine as they should.
Something must have changed ( wx? ), aMule is probably not finding the translations when not installed, and I know that it used to find them.
Back to the topic, ycjhi, Kry is looking at the filename issue.
Cheers!
-
aMule finds the translations only if they are installed. In addition, you have to have the locale for the translation to be generated or you wouldn't have much fun with it.
-
Hello phoenix,
this way is unique to is how it's done with Archlinux (it's a rather small distro, comparable to Slackware or binary-Gentoo with a great package manager), you're supposed to only enable those locales you actually need (opt-in) opposed to the policy of including everything by default.
Furthermore I have no such messages at all, can't help you with this.
Edit: I stand corrected.
-
wuischke, that's the way debian does it as well.
-
For debian I prefer "dpkg-reconfigure locales"
-
sure. but both are valid. you can also install locales-all and be done with it.
-
Hi ycjhi,
Nothing has changed recently in unicode handling. There are some problems with filename handling, but not for UTF-8. I personally tested some files with japonese and korean characters and they seem to work fine.
Is your system LANG environment variable set to a UTF-8 language? Here I have
$ env | grep LANG
LANG=en_US.UTF-8
If you have UTF-8 set, things should work, no matter which language you use. If you don't want to change the system default, you can try to run amule like:
$ LANG=ko_KR.UTF-8 /path/to/amule
Cheers!
Do you convert encodings before storing downloaded file to local file system? I'm concerning because Mac OS uses filenames in UTF-8 encoding for local file system. I don't know what other operating systems use though.
I'm sorry for not being able to post further test results. Apple Service Center took my MacBook yesterday due to a fan problem which caused frequent 'sudden death'. So sad.
-
aMule finds the translations only if they are installed. In addition, you have to have the locale for the translation to be generated or you wouldn't have much fun with it.
Ok, but I am surely missing something. What is that the instalation process do to aMule so that it finds the files? The executable file is exactly the same, so? Sorry if this is a dumb question. :/
Do you convert encodings before storing downloaded file to local file system? I'm concerning because Mac OS uses filenames in UTF-8 encoding for local file system. I don't know what other operating systems use though.
This is the problem. If we use a conversion that uses the default system conversion, and this default is not UTF-8, say ISO-8859-1, it will fail on characters that are not from this charset. And all the network filename traffic is in UNICODE, so if the file system is not UNICODE or UTF-8, the conversion will sometimes fail. We currently try to do the best job, first we try to convert UNICODE to ISO-8859-1. If this fails, then we convert it to UTF-8, which should never fail.
The right solution, in my opinion, would be to use UTF-8 always, even though non-UNICODE systems would display the name incorrectly.
-
phoenix,
as far as I know, wx will assume /usr/local as prefix as long as the binary is not installed to /usr, even if it is in my compile path $HOME/devel/amule-dev/src and the Makefiles set a prefix of /usr. I ran into similar problems with skin support and I think this was what happened.
I personally don't see any downside to using only unicode, every major operating system supports unicode for years now (even windows 98 supports it with an add-on) and we require wx-builds with unicode anyway, so I don't see why not.
-
aMule finds the translations only if they are installed. In addition, you have to have the locale for the translation to be generated or you wouldn't have much fun with it.
As wuischke already said, you have to do a make install to get it to work. Beside that the locale you want to use has to be generated, say it is in the list of "locale -a". Beside that you need the amule.mo for the locale (should be installed, I'm just working on a possibillity to choose which to generate and install). If this is done, open the prefs, choose the lang, restart and it should work.
-
as far as I know, wx will assume /usr/local as prefix as long as the binary is not installed to /usr, even if it is in my compile path $HOME/devel/amule-dev/src and the Makefiles set a prefix of /usr. I ran into similar problems with skin support and I think this was what happened.
The strange thing is that it works when I "make install" with a crazy prefix, I used "/home/myuser/usr/local/amule".
As wuischke already said, you have to do a make install to get it to work. Beside that the locale you want to use has to be generated, say it is in the list of "locale -a". Beside that you need the amule.mo for the locale (should be installed, I'm just working on a possibillity to choose which to generate and install). If this is done, open the prefs, choose the lang, restart and it should work.
You are missing my point, I have it working now, what I want to know is _how_ it is done. Why do I need "make install" to make it work, even if I install it in such an odd path as I did.
Cheers!
-
Just a guess, but at compiletime you choose the path where it is installed and with that the path where it should look for his files. If you don't install, the files are not where it expects them. It seems that in this case a fallback to /usr/local happens. It doesn't matter where you install, installed is installed and all files are in place.
-
Yeah, you are probably right, configure is passing some information to wxWidgets then.
Thanks!
-
I don't think the already compiled wxWidgets get's modified by amule's configure. Is is more like "searchpath=<something_from_configure_call>/amule" in the sourcecode.
-
Do you convert encodings before storing downloaded file to local file system? I'm concerning because Mac OS uses filenames in UTF-8 encoding for local file system. I don't know what other operating systems use though.
This is the problem. If we use a conversion that uses the default system conversion, and this default is not UTF-8, say ISO-8859-1, it will fail on characters that are not from this charset. And all the network filename traffic is in UNICODE, so if the file system is not UNICODE or UTF-8, the conversion will sometimes fail. We currently try to do the best job, first we try to convert UNICODE to ISO-8859-1. If this fails, then we convert it to UTF-8, which should never fail.
The right solution, in my opinion, would be to use UTF-8 always, even though non-UNICODE systems would display the name incorrectly.
What about letting users to set an option such as "Local filesystem name encoding" in aMule configuration dialog box?
-
ycjhi,
This solution has the same "short blanket" effect too.
Imagine that the user sets the local file system character set to ISO-8859-1. Then we have exactly the same problem we have today. The user may be downloading files that cannot be saved in its file system encoding.
Cheers!
-
ycjhi,
This solution has the same "short blanket" effect too.
Imagine that the user sets the local file system character set to ISO-8859-1. Then we have exactly the same problem we have today. The user may be downloading files that cannot be saved in its file system encoding.
Cheers!
That was a stupid question. I should have read your post carefully. Sorry :-[
-
Hey, nevermind! Your doubt is also someone else's doubt (if not my doubt :D ) The debate is good.
Cheers!