bugmldonkey, a multi-networks file-sharing client - Bugs: bug #9101, [CJK] Search with CJK characters


You are not allowed to post comments on this tracker with your current authentication level.

bug #9101: [CJK] Search with CJK characters

Submitted by:  None
Submitted on:  Wed 26 May 2004 02:27:18 AM UTC  
Category:  Core Severity:  3 - Normal
Item Group:  i18n issues Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  Release:  2-5-16
Operating System:  Mac OS X 10.3 Binaries Origin:  Downloaded from third-party page
CPU type:  PowerPC

( Jump to the original submission)

Thu 26 May 2005 09:33:52 AM UTC, comment #23: 

I tested Sancho on Gentoo, GTK2 version with the Google search result:


I copied the string via clipboard from Firefox to Sanchos search field and it works.

@Rolf: As I don´t have experience with other input methods (Input Method Editor) I can´t test it here.

spiralvoice <spiralvoice>
Project Administrator
Tue 24 May 2005 08:43:13 AM UTC, comment #22: 

Sancho has been fixed in 0.9.4-43

spiralvoice <spiralvoice>
Project Administrator
Sat 21 May 2005 12:06:31 AM UTC, comment #21: 
spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 10:00:42 PM UTC, comment #20: 

Actually, results appear to be fine when using Firefox from Debian.  So I guess, this bug is indeed a goner.

Rolf Leggewie <leggewie>
Fri 20 May 2005 05:02:27 PM UTC, comment #19: 

spiralvoice, the screenshot you attached indeed shows valid results only.  Did you scroll further down, though?  I used to have stretches of good mixed with bad results.

I attach a screenshot I just took five minutes ago with core 2.5-30.15.  There clearly are results in there that do not fit.  Browser is kmeleon.sf.net on Win98 SE.  I think this behaviour was the same with Firefox on Debian as well, though.  I will test that again.

Rolf Leggewie <leggewie>
Fri 20 May 2005 12:30:18 PM UTC, comment #18: 

Did the same search with Firefox 1.0.4 on Gentoo Linux with Unicode enabled, it worked well.
GTK2 GUI compiled on Gentoo Linux also has correct results.

Sancho GTK returned no results, Sancho FOX seems to lack Unicode
according to Sancho homepage:
"sancho patiently waits for:
- fox: to get utf8 & theming support"

On Linux Sancho GTK can display CJK characters of running downloads well,
Sancho FOX as expected not.

spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 10:06:36 AM UTC, comment #17: 
spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 09:51:41 AM UTC, comment #16: 

Sancho has weired search results though on W2K, but that maybe
a Sancho thing. Which program did you try for searching?

spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 09:43:24 AM UTC, comment #15: 

Hi, I did just that. Attached to this bugreport you will find
my search results. In the commandline I copied the search string.
Although I am by no means an expert in CJK characters after two
minutes of comparing I think there are no results which do not fit.

Maybe you can yourself post a screenshot with the wrong results.

spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 01:23:34 AM UTC, comment #14: 

spiralvoice, try http://www.google.co.jp/search?hl=ja&q=%E3%82%B1%E3%83%84%E3%83%A1%E3%82%A4%E3%82%B7&btnG=Google+%E6%A4%9C%E7%B4%A2&lr= If that looks OK try and copy the text from the search box.  That is the search term I used.

Rolf Leggewie <leggewie>
Fri 20 May 2005 01:14:42 AM UTC, comment #13: 

how to display japanese characters in my browser (Firefox, W2K)?

spiralvoice <spiralvoice>
Project Administrator
Fri 20 May 2005 12:28:14 AM UTC, comment #12: 

If I understand the intent of this bug report correctly, I'd say it is not yet solved.  If I search for &#12465;&#12484;&#12513;&#12452;&#12471; (the name of a Japanese hiphop group) there are a bunch of results which certainly have no relation to that term.

Request reopening.

Rolf Leggewie <leggewie>
Thu 19 May 2005 03:21:04 PM UTC, comment #11: 


cf.bug #9102

JongAm Park <JongAm>
Fri 31 Dec 2004 09:54:19 PM UTC, comment #10: 

I couldn't

JongAm Park <JongAm>
Sat 30 Oct 2004 05:43:45 PM UTC, comment #9: 

Yes... By the way, do you know how to do it with NSString or any other Cocoa/Core Foundation functions?

JongAm Park <JongAm>
Fri 29 Oct 2004 12:18:55 PM UTC, comment #8: 

"The second screen capture, search_result1_mldonkey1.jpg.jpg, shows that how the hash numbers are used instead of the file name."
I don´t think that the filename is built with the hash value of that file, instead the ascii numbers are used.
To have UTF8 conversion have a look at this patch for the GTK2 GUI:

spiralvoice <spiralvoice>
Project Administrator
Mon 04 Oct 2004 01:05:45 AM UTC, comment #7: 

If you scroll down a little, you can see like the one attached as

What it shows is that the result contains files which are not related to the search keyword.

FYI, before searching, you should set the encoding method "euc-kr" with the Firefox or Korean( Windows, DOS ) with the Safari. Because most of the users are Windows users you should use the encoding method they use.

The mldonkey versions, a year ago probably, doesn't have the problem the serach_result_mldonkey2.jpg shows.
is it due to the object-caml language? I don't think you intentionally change the behaviour.

If you don't think that this issue is important, think about this. Most of the overnet users are Koreans. The eDonkey network is quite popular in Korea.
I think the most of population which use P2P could be Koreans among other people.

JongAm Park <JongAm>
Mon 04 Oct 2004 12:56:50 AM UTC, comment #6: 

The second screen capture, search_result1_mldonkey1.jpg.jpg, shows that how the hash numbers are used instead of the file name.

FYI, the mldonkey finds and displays files with Korean names correctly with some files, but you have bunch of files like the one you can see in the search_result1_mldonkey1.jpg.jpg.

JongAm Park <JongAm>
Mon 04 Oct 2004 12:52:57 AM UTC, comment #5: 

I think you don't understand this.

So, here I attach 3 files with which you can compare and understand what I mean.

First one is result with the eMule plus.
What you should look at is what it found, not whether the files found by the emule and the mldonkey are different.

Search result can be different from trial to trial.

JongAm Park <JongAm>
Mon 13 Sep 2004 12:21:30 AM UTC, comment #4: 

Yes. it still has the bug.

JongAm Park <JongAm>
Thu 19 Aug 2004 12:57:34 PM UTC, comment #3: 

Pre-compiled Mac cores are available here: http://mlnet.macbay.de/mlnet/

spiralvoice <spiralvoice>
Project Administrator
Mon 16 Aug 2004 03:30:21 AM UTC, comment #2: 

Hello, sprialvoice.

I can't check the CVS version, because I can't compile the mldonkey on my MacOS X machine. The configure script throws "can't compile with gcc-something" error. Although I can compile C/C++/Java with the Xcode and with the gcc.


JongAm Park <JongAm>
Sun 15 Aug 2004 03:52:47 PM UTC, comment #1: 

Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/

spiralvoice <spiralvoice>
Project Administrator
Wed 26 May 2004 02:27:18 AM UTC, original submission:  

You know, eDonkey network is the most popular in Korea, and there are many files with Korean file names.

I know that search results can be different from trial to trial and from server to server. However the results are too different if it is compared to other programs like eMule. So, at least, wouldn't it be neccessary if the mldonkey searches files well?

Second problem is that the mldonkey doesn't seem to find files with CJK names well. For example, if you find files with CJK string, uh.. let's say it is "XAC", then the results should be something that contains XAC, but sometimes it is not. Some file names doesn't contain "XAC" at all.

So, could programmers or code examiners check if the search feature of the mldonkey treats CJK characters or other code set correctly? Or does it search files with CJK characters coincidently well? :)



Attached Files
file #2997:  cjk_search.png added by leggewie (19KiB - image/png - Irrelevant search result mixed with good results)
file #2994:  japan_hip_hop.jpg added by spiralvoice (62KiB - image/jpeg)
file #1831:  mldonkey2.jpg added by JongAm (241KiB - image/jpeg - this is search_result1_mldonkey2.jpg, size reduced)
file #1827:  mldonkey1.jpg added by JongAm (262KiB - image/jpeg - this is search_result1_mldonkey1.jpg.jpg. size reduced)
file #1825:  search_result_emule_plus.jpg added by JongAm (210KiB - image/jpeg)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




Follow 12 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-05-21 spiralvoice Open/ClosedOpen => Closed
2005-05-20 leggewie Attached File- => Added cjk_search.png, #2522
2005-05-20 spiralvoice Attached File- => Added japan_hip_hop.jpg, #2519
2005-05-20 spiralvoice Open/ClosedClosed => Open
2005-05-19 spiralvoice StatusNone => Fixed
    Open/ClosedOpen => Closed
2005-05-18 leggewie Carbon-Copy- => Added mld-bug9101@rolf.leggewie.biz
2005-03-16 amorphous Item GroupNone => i18n issues
2004-10-04 JongAm Attached File- => Added mldonkey2.jpg, #1732
2004-10-04 JongAm Attached File- => Added mldonkey1.jpg, #1731
2004-10-04 JongAm Attached File- => Added search_result_emule_plus.jpg, #1730
2004-05-26 JongAm Carbon-Copy- => Added jongam --AT-- myrealbox --DOT-- com

Back to the top

Powered by Savane 3.5