Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ycjhi]

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.

[phoenix]

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!

[ycjhi]

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,

[phoenix]

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!

[wuischke]

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)

[phoenix]

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.

[phoenix]

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!

[Vollstrecker]

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.

[wuischke]

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.

[Kry]

wuischke, that's the way debian does it as well.

[Vollstrecker]

For debian I prefer "dpkg-reconfigure locales"

[Kry]

sure. but both are valid. you can also install locales-all and be done with it.

[ycjhi]

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.

[phoenix]

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.

[wuischke]

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.