bugmldonkey, a multi-networks file-sharing client - Bugs: bug #9102, [CJK] File names in Downloads and...


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

bug #9102: [CJK] File names in Downloads and search results Web UI page

Submitted by:  None
Submitted on:  Wed 26 May 2004 02:31:07 AM UTC  
Category:  Core Severity:  3 - Normal
Item Group:  i18n issues Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  Release:
Operating System:  None Binaries Origin:  Downloaded from third-party page
CPU type:  PowerPC

( Jump to the original submission)

Fri 20 May 2005 12:31:55 AM UTC, comment #32: 

There are still some files displayed incorrectly but I assume that is an artifact of encoding problems on the other side.  My vote goes for "close the bug".

Rolf Leggewie <leggewie>
Thu 19 May 2005 03:12:49 PM UTC, comment #31: 

Yes. I think this bug is solved.

However I need to submit another bug.
File names for committed files are ------.blah..
The CJK characters are written as ----.

JongAm Park <JongAm>
Thu 19 May 2005 02:02:11 PM UTC, comment #30: 

"However, from 2.5.30, UTF-8 also seems to return good result."

Can I consider this bug solved and close it?

spiralvoice <spiralvoice>
Project Administrator
Tue 17 May 2005 09:02:15 AM UTC, comment #29: 

AFAIK while receiving a paste signal, the GTK2 entry widget make a string conversion to get an UTF-8 encoded string from the clipboard.
they use a "gdk_atom_intern ("UTF8_STRING", FALSE)" as the target to put the content of the clipboard.
Attached is an another screenshot of the GTK2 GUI with the entry field font forced to "sans" (hardcoded by me for test - currently not available in the CVS version).
The result shown is done copying the word below (EUC-KR encoded) and pasting directly in the entry box (conversion to UTF-8 string is properly done by the GTK2 entry widget).
Immediate consequence, the search results are UTF-8 strings, of course.
With a web interface, it is more flexible... You may search with a string encoded EUC-KR, but to view the results I think you have to switch back to the encoding UTF-8 to have properly displayed names. except if our conversion is badly implemented. but I try it and it seems ok.

Tue 17 May 2005 04:45:29 AM UTC, comment #28: 

Su_Blanc's description is quite accurate.

If you have a Korean/Japanese/Chinese fonts, you can search files with respective name correctly.

Well, if you copy text in EUC-KR, and paste it on a UTF-8 text field, it may make the text corrupted. is the screenshot for that case?

If you search in EUC-KR, it can show more result than you do in UTF-8, also.
However, from 2.5.30, UTF-8 also seems to return good result.

JongAm Park <JongAm>
Tue 17 May 2005 02:46:20 AM UTC, comment #27: 

the core sends UTF-8 encoded strings to the GUI.
But the GUI can send whatever to the core. no check/conversion implemented on this side of the protocol.
Nevertheless the GTK2 GUI sends only UTF-8 encoded strings because all GTK2 "text" widgets (entry, ...) use UTF-8 encoded strings.
In mozilla I put the character encoding "EUC-KR", copy and paste the text ÇؽŠindicated below in the keyword box of the search tab of the GTK2 GUI.
Attached a screenshot from a WIN XP OS with the GTK2 GUI. I had to choose the font "sans" to display properly the korean character in the search tab.
Make sure that the font, you use, can display the range of korean characters... on WIN XP you get nice square when the character cannot be displayed by the font selected.

su_blanc <su_blanc>
Project Member
Sun 08 May 2005 04:16:09 PM UTC, comment #26: 

the gui protocol is now supposed to use uft-8 exclusively.

to comment #20 :
we should try to exclusively use utf-8 for network output, too. in the case where the network or the client/server we just connected to doesn't support it, we should try to use it's encoding to get the best possible compatibility.

Amorphous <amorphous>
Sun 08 May 2005 02:15:54 AM UTC, comment #25: 

Hello, su_blanc. Can I ask you a question?

From 2.5.30, does the mlnet core uses UTF-8 as its default encoding method for all string, ie. search, file names in transfer page, search result, and so on?

I would like to make the mlMac, which is an mlnet GUI on Mac, display file names correctly. So....

I tested with the latest mlMac, but it couldn't display the file names correctly.


JongAm Park <JongAm>
Thu 05 May 2005 04:27:51 AM UTC, comment #24: 

Hello, su_blanc.

I tested the 2.5.30.

It works fine.
Amazingly it can search files well. Additionally, the search result looks quite good now. Thanks for the hard work!

 However I didn't compare it with the result of eMule plus. I know that the result can be different. However it should be similar.

I would like to submit a screenshot, but this system doesn't allow it.
I'm sorry about it.

JongAm Park <JongAm>
Tue 03 May 2005 10:05:54 AM UTC, comment #23: 

@JongAm Park:
Could you use a 2.5.30-15 version? iconv is not implemented in your core. It is also working for all platforms that have iconv (windows is included).
For Mozilla, I have 2 comments:
- we parse short strings, different from sentences, and thus lexical analysis is very difficult
- we have to treat a lot of strings in a very shorter time as a p2p application.

su_blanc <su_blanc>
Project Member
Tue 03 May 2005 06:58:33 AM UTC, comment #22: 

Actually, I tried to build the Mozilla's chardet as a separated library, but I couldn't. I would like to know what functions and data structures are for internal use, and what are for public use.

Well, I can find out about it for myself, but I had no enough time.
I sent email to Tang, who were involved in making the detector, but after a few email between he and I, he didn't reply any more.
So, I was stucked.

Actually, I was trying to make the mlMac, the mldonkey GUI for Mac OS X, use CJK strings in search/search result/download/upload.
However the same thing can be done on the mldonkey level, it is far better approach.

JongAm Park <JongAm>
Tue 03 May 2005 06:54:37 AM UTC, comment #21: 

to su_blanc..

Well, my startup screen doesn't show the locale information.
Anyway, I believe my locale is US / EN.
It is good idea to determine encoding method using locales being used.
However, can it be applied to the Windows case also?
On Windows, which I believe most of eDonkey, gnutella users use, we have many version. First Korean Windows. I think it will use a kind of locale. However, nowadays even on English Windows, you can forcefully set its default language.
There is an option like, "If it is not Unicode program, then use this encoding method.". It can be found at "Regional and Language Options" control panel. Try clicking the 'Advanced' tab.

However if there is a way to determine using the transmitted text string, the file name, I mean, it could be better.

If you search the Mozilla web site, they posted their own encoding detector.
I think their method is better than Apple's TecSniffer.
However, because they are based on probability, and file names are not that long usually, the possibility of accurate detection can be low. So, in addition to the automatic detection, if you provide "encoding menu" just like that of Mozilla web browser, it could be easier way, and it may be sufficient for most users, I think.

For mozilla's implementation, please confer :



JongAm-Parks-Computer:~ jongampark$ cd /Applications/Network/Mldk2.5.16v/
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.16v jongampark$ ./mlnet
Resolving [JongAm-Parks-Computer.local] ...done
Network Global Shares registered
Network Gnutella registered
Network G2 registered
Network Fasttrack registered
Network FileTP registered
Network BitTorrent registered
Network Donkey registered
Network Soulseek registered
IP blacklist: 52946 ranges loaded
Updating options to level 3
Network.load_complex_options not implemented by Soulseek
Network.load_complex_options not implemented by FileTP
Network.load_complex_options not implemented by Fasttrack
Network Soulseek enabled
Network Donkey enabled
Network BitTorrent disabled
Network FileTP enabled
Network Fasttrack enabled
Network G2 disabled
Network Gnutella disabled
Network.recover_temp not implemented by Soulseek
Error loading ./comments.met: Sys_error("./comments.met: No such file or directory")
Network.recover_temp not implemented by FileTP
cipher_packet_set s = "\250\000\182+\007[\205\021n\233\135\187"
apply_cipher s = "\016\210\245\241\144Ug\028Z\229\1928\176\167\192\008\139\019\018Z\1937\226\250i"
Network.recover_temp not implemented by Fasttrack
QUERY URL http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-best.met
QUERY URL http://members.lycos.co.uk/appbyhp2/FlockHelpApp/contact-files/contact.ocl
QUERY URL http://www.bluetack.co.uk/config/antip2p.txt

Welcome to MLdonkey client
Check the forums at http://www.mldonkey.org/ for updates
as long as http://www.mldonkey.org/ is not maintained
To command: telnet 4000
Or with browser:
Welcome to MLdonkey

 2/ 5, 23:18:53: Saving shared files and sources
Server.server_to_option not implemented by Soulseek
 2/ 5, 23:18:53: Options correctly saved
 2/ 5, 23:18:54: Core started
Disabling output to console, to enable: stdout true

JongAm Park <JongAm>
Tue 03 May 2005 06:15:39 AM UTC, comment #20: 

To Amorphous..

Your ideas :

-everything internal to mldonkey should use UTF-8
-add an option character_encoding_default with default UTF-8
-when a peer connects try to determine what encoding he uses and convert it to/from UTF-8, if we can't determine it use character_encoding_default
-when searching use the option character_encoding_default to determine the encoding we use (i assume here that the servers don't care about encoding)

are very good. However, we should be aware of this.
Although the eDonkey project itself is moving to Unicode based approach nowadays, there are many eDonkey servers and clients which don't use Unicodes. I believe that if eDonkey itself moves to the Unicode, then most users will switch to the newer approach whether they like or not.
However there can be some servers/clients which don't use unicode in future. We may be able to disregard those safely. Because it is an open source project, and thus it is not as risky as commercial programs.
However, whatever you take, I think this should be discussed with guys at eDonkey network people.
Actually, mldonkey is not only for eDonkey. You may need to discuss about this issue with Kazza, Soulseek, and gnutella.(and so on. )
Nowadays there are Unicode gnutella clients. So, I think they are also moving to the Unicode base.

Or it may be better to add "encoder specifier for each file name" to the protocol itself. Because different servers and clients may have different encoding scheme.
Or.. better approach, IMHO, is that the encoding method for the network itself should be standardized on the Unicode.

What do you think about this?

JongAm Park <JongAm>
Tue 03 May 2005 06:15:26 AM UTC, comment #19: 

right now, the filename_conversions option is a bit tricky, doesn't it?

a- What does prevent the user to put a pair (97, ">") in filename_conversions? The consequences are huge if I'm a windows user, because your loop will never fallback to the safe replacement of chars for windows .... and I won't be able to commit any file if the file name contains 'a'.

b- Shouldn't we rename "The conversions to apply on characters depending on their ASCII code" to "The conversions to apply on characters to fallback to an ASCII string".
Even this option is too dangerous as it is coded because there no check that the replacement string consists strictly in ASCII chars and there is no check that the char I want to replace is included in the range 0x00 to 0xFF (OCaml char is 8 bits and Ocaml int is 31 bits!). So anyway we are able to convert only chars that are in the 0x00 to 0xFF range, which is very limited in comparison with UTF-8 characters.

c- Another example, if I am Arabic and I use the filename_conversions option as is, I will get some issue to understand why the arabic letter LAM (in ISO-8859-6: 0xe4 == 228) is replaced by "ae" in my filename.

I think you should change as follows:

1) create conversions functions for safe checking:
let safe_int8 i =
  if i > 255
    then failwith (Printf.sprintf "Cannot convert character if higher than 255 [%i].\n" i)
    else i

let safe_ascii s =
  for i = 0 to String.length s - 1 do
    if int_of_char s.[i] > 127
      then failwith (Printf.sprintf "%c is not an ASCII character.\n" s.[i])

let value_to_int8 v =
  let i = Options.value_to_int v in
  safe_int8 i

let int8_to_value i =
  let i = safe_int8 i in
  Options.int_to_value i

let value_to_ascii v =
  let s = Options.value_to_string v in
  safe_ascii s

let ascii_to_value s =
  let s = safe_ascii s in
  Options.string_to_value s

let ascii_option =
    define_option_class "Ascii"
    value_to_ascii ascii_to_value

let int8_option =
    define_option_class "Int8"
    value_to_int8 int8_to_value

2) define option filename_conversions:

let filename_conversions = define_expert_option current_section
    "The conversions to apply on characters to fallback to an ASCII string"
    (list_option (tuple2_option (int8_option, ascii_option))) []

3) make sure the default value is []. the user has to choose.

4) in CommonInteractive.canonize_basename, make sure that the characters '/', '\\' are replaced (as well as for windows ':', '*', '?', '"', '<', '>', '|', '%'). That's not case now.

But no, CommonInteractive.canonize_basename, option filename_conversion and Charset.to_locale may be complementary. Despite they fallback to '_', they don't do it for the same purpose.
Charset.to_locale make sure we have a string that is as per LOCALE in any case (even if the final string is not 'human' readable), but filename_conversions option doesn't.

Another solution (less elegant than Charset.to_locale + filename_conversions option) would have been to convert any string going through CommonInteractive.canonize_basename in ASCII string:

| for i = 0 to String.length s - 1 do                 |
|   s.[i] <- char_of_int (int_of_char s.[i] land 127) |
| done                                                |

the result may be unreadable but it's working anywhere.

yes ANSI_X3.4-1968 is an alias of ASCII (range is 0x00 to 0x7F - 128 chars). very limited to convert strings ...

su_blanc <su_blanc>
Project Member
Tue 03 May 2005 06:05:58 AM UTC, comment #18: 

OK. I'm back home.

To spiralvoice..
Please try ÇؽÅ
The Korean character is written in EUC-KR here.
So, please change your Web browser's encoding method to EUC-KR¿¡ try copy & past. It is very popular mini series nowadays. So, you can find bunch of files with the search string.
Well.. is the html file itself saved in UTF-8? Or is it saved as US-ASCII and its meta tag is just UTF-8?
Depending on it, the correctness of the display will be determined.
Anyway, you can override encoding method using a web browser's encoding menu.

JongAm Park <JongAm>
Mon 02 May 2005 03:18:32 PM UTC, comment #17: 

OK. I will read this thread carefully and post my reply when I go back home. :)

I'm sorry that I didn't reply quickly.

JongAm Park <JongAm>
Mon 02 May 2005 01:22:31 PM UTC, comment #16: 

@spiralvoice: does it work then?
i would guess ANSI_X2.4-1968 is an alias to ASCII...

Amorphous <amorphous>
Mon 02 May 2005 12:16:49 PM UTC, comment #15: 

"2) if we fail doing so, we try to convert the complete string char by char to UFT-8 from 'locale'. If the char is not convertible we replace it by a '_'."

Please see bug #12910. also I think you don´t take into account
that we have commonInteractive.canonize_basename for that which uses filename_conversions option in downloads.ini.

My MLDonkey machine is a router with minimal software (kernel 2.2.x, libc5) and so on. Non-ASCII characters are not well
supported so I am using this table to convert the german
umlauts to their two-character equivalent.

router:/mlnet # ./mlnet
Current locale of the target machine is ANSI_X3.4-1968
Current language of the target machine is EN
List of charmap used to convert the strings:
  Use encoding CP1252
  Use encoding ISO-8859-15
  Use encoding 850
  Use encoding CP819
  Use encoding MAC
  Use encoding 437
  Use encoding 860
  Use encoding 863
  Use encoding ANSI_X3.4-1968
  Use encoding C99
  Use encoding ISO-10646-UCS-2
  Use encoding UCS-2BE
  Use encoding UCS-2LE
  Use encoding ISO-10646-UCS-4
  Use encoding UCS-4BE
  Use encoding UCS-4LE
  Use encoding UTF-16
  Use encoding UTF-16BE
  Use encoding UTF-16LE
  Use encoding UTF-32
  Use encoding UTF-32BE
  Use encoding UTF-32LE
  Use encoding UNICODE-1-1-UTF-7
  Use encoding UCS-2-INTERNAL
  Use encoding UCS-2-SWAPPED
  Use encoding UCS-4-INTERNAL
  Use encoding UCS-4-SWAPPED

spiralvoice <spiralvoice>
Project Administrator
Mon 02 May 2005 08:43:47 AM UTC, comment #14: 

Are you sure that it is not possible to guess the encoding of a peer? For example one could do that by checking the emule version. I think there is something like that for edonkey servers in the emule souce. Newer edonkey servers do some character encoding changes to UTF-8 for incoming shares.

Perhaps we should fall back to charset guessing when character_encoding_default is not set and for sending to UTF-8, then it is just for the corner cases where we can't be sure but the user is sure. (If he isn't then he shouldn't set it.)

Amorphous <amorphous>
Mon 02 May 2005 03:56:06 AM UTC, comment #13: 

Let me explain how the things work.
At mlnet startup, the core try to determine how the strings will be  converted and this based on the target machine settings.
We read 2 values :
- 'locale' of the target machine
- 'language' of the target machine
The most important to understand is that the variable 'language' does build a list of char mappings that will be used further to convert the strings to UTF-8 or to LOCALE. Maybe this part is not properly implemented.
in the [CJK] case, mlnet will use the following char mapping :
   [CP949; UHC];
   [CP1361; JOHAB];
   [ISO_2022_KR; CSISO2022KR];
   [ISO_IR_149; KOREAN; KSC_5601; KS_C_5601_1987; KS_C_5601_1989; CSKSC56011987];

only if the variable 'language' is "KO".
Yes the Core consider that if your machine language is "EN" (English), you will not use CP949 strings. Nevertheless the Core allows you to use Unicode char mappings independently of the language of the target machine.
There is no facilities to override this mechanism at the moment (option parameter), and I think it is the weakest point...

Side note: If you search for a file from any interface that is UTF-8 encoded (web, GTK2 ...), the results returned are UTF-8 encoded (bitwise comparaison!).

when mlnet converts the string to LOCALE, first we convert it to UTF-8 using the list of char mappings.
1) for each list included in the char mapping list, we take the first element of the list (ex: [CP949; UHC] we take CP949 because UHC is an alias of CP949) and we try to convert the complete string to LOCALE from the current char mapping (CP949, CP1361, EUC_KR, ISO_2022_KR, ISO_IR_149).
2) if we fail doing so, we try to convert the complete string char by char to UFT-8 from 'locale'. If the char is not convertible we replace it by a '_'.
3) then we convert the newly created UTF-8 string to 'locale'.

As a consequence, if the 'language' and 'locale' variables are set properly on the target machine, there should'nt be any issue (ideal setting would be KO_UTF-8).

@JongAm Park:
Can you put here what is printed by the core at startup.
Because I'm surprised by the behaviour of your Core.
something like :
Current locale of the target machine is UTF-8
Current language of the target machine is DE
List of charmap used to convert the strings:
Use encoding CP1252
Use encoding ISO-8859-15

you can't determine what string encoding is using a peer. The only thing you can do is to iter through the complete list of char mapping until the core finds one from which you are able to convert the complete string.
1) you have no guarantee that this the good char mapping because several use the same ranges to encode strings
2) you create a load of the core (a lot of strings to parse) for a purpose which IMHO is not legitimate.
Thus IMHO it has to be considered as useless.

the idea of "character_encoding_default" looks good for searches because everybody knows that windows users are still a majority and thus can allow any user (CP1252 versus ISO-8859-15, ...) to 'compete' equally. But will all mldonkey users understand how to use this feature?

su_blanc <su_blanc>
Project Member
Fri 15 Apr 2005 01:10:52 PM UTC, comment #12: 

i guess that is not realy needed. the problem i guess is, that there are peers on the donkey network with different character-encodings. but currently the donkey-implementation (as all other networks) does not care about the encoding. i don't know  exactly how the donkey-network handles this, but i guess the following should be done
-everything internal to mldonkey should use UTF-8
-add an option character_encoding_default with default UTF-8
-when a peer connects try to determine what encoding he uses and convert it to/from UTF-8, if we can't determine it use character_encoding_default
-when searching use the option character_encoding_default to determine the encoding we use (i assume here that the servers don't care about encoding)

anyone who want's to do this :) ? you are welcome.

Amorphous <amorphous>
Thu 14 Apr 2005 10:59:07 PM UTC, comment #11: 

The problem for most of us coders is that we can´t speak nor write korean. Could you please post some examples of what to search for in korean so we have a clue what to paste?
The encoding of MLDonkey html pages has been changed to utf-8,
should this be an option so you can set it to EUC-KR?
Could you also provide some ed2k links for korean files which
are GPL?

spiralvoice <spiralvoice>
Project Administrator
Thu 14 Apr 2005 07:42:45 PM UTC, comment #10: 

Hello. This is not solved still.

The testing can be a little weird.
Did you test with UTF-8 only?

I think you should also check EUC-KR.
If you set your web browser's encoding method to UTF-8, the search result may be less than what you get when you set it to EUC-kR.
However for search result, nowadays most of them are in UTF-8.
So, I think it should handle this.

Search           | Result
EUC-KR, CP0949   | Unicode, EUC-KR, CP-949
Unicode          | Unicode

If the result file names are in Unicode, your web browser may display them correctly, but with EUC-KR or CP-949, they are not.

Even when downloading is completed, files with EUC-KR,CP949 file names can't be move to incoming directory automatically.

So, to solve this problem, all of the cases should be considered.

JongAm Park <JongAm>
Mon 11 Apr 2005 06:24:55 PM UTC, comment #9: 

i can reproduce this with the german non-ascii characters called "umlaut" but the filename is displayed right in the details of the file (works for japanese, too).

Amorphous <amorphous>
Sat 02 Apr 2005 09:51:33 AM UTC, comment #8: 

a real feature would be if the webui were encoded in utf8...

Amorphous <amorphous>
Fri 01 Apr 2005 09:46:45 PM UTC, comment #7: 

It´s not a bug, it´s a feature;-)

spiralvoice <spiralvoice>
Project Administrator
Fri 28 Jan 2005 09:26:43 PM UTC, comment #6: 

Please try again compiling 2-5-28p, there were patches for configuring MLDonkey on MacOS

spiralvoice <spiralvoice>
Project Administrator
Fri 31 Dec 2004 09:53:31 PM UTC, comment #5: 

I couldn't compile it.

JongAm Park <JongAm>
Sat 30 Oct 2004 05:40:10 PM UTC, comment #4: 

FYI, i can't compile it on my MacOS X machine.
Because the configure script complaints.

As far as the 2-5-25 version is concerned, I think I downloaded it from MacOS X forum. It didn't work for me.

JongAm Park <JongAm>
Fri 29 Oct 2004 12:19:32 PM UTC, comment #3: 

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
Tue 10 Aug 2004 06:47:33 PM UTC, comment #2: 

Changing severity to 1 because this bug might be solved in current CVS release.

spiralvoice <spiralvoice>
Project Administrator
Mon 09 Aug 2004 06:29:55 PM UTC, comment #1: 

Please test CVS 2-5-25 and report if the bugs is still present.

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

About 6 months ago, before the mldonkey development looks stalled and multinet feature was being implemented, mldonkey WEB UI displays CJK file names on its Downloads page well.
However, with recents builds, it is not.

For example, it displays [SBS]???.?03??.SDTVrip.[2004-05-24].avi file like this.


On the bottom size,where downloaded files are displayed, it also displays files with CJK file names as its unique numbers rather than file names.



Attached Files
file #2977:  font_entry_box_forced-EUC-KR.PNG added by None (141KiB - image/png - GTK2 GUI with keyword field font forced)
file #2974:  Mozilla-EUC-KR.PNG added by su_blanc (115KiB - image/png - Mozilla UTF-8 encoded strings)
file #2969:  EUC-KR.PNG added by su_blanc (148KiB - image/png - WIN XP GTK2 GUI Screenshot)


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-19 spiralvoice StatusNone => Fixed
    Open/ClosedOpen => Closed
2005-05-18 leggewie Carbon-Copy- => Added mld-bug9102@rolf.leggewie.biz
2005-05-17 None Attached File- => Added font_entry_box_forced-EUC-KR.PNG, #2505
2005-05-17 su_blanc Attached File- => Added Mozilla-EUC-KR.PNG, #2502
2005-05-17 su_blanc Attached File- => Added EUC-KR.PNG, #2501
2005-04-14 spiralvoice Severity1 - Wish => 3 - Normal
    Release2-5-16 =>
    Operating SystemMac OS X 10.3 => None
2005-04-11 amorphous Summary[CJK] File names in Downloads Web UI page => [CJK] File names in Downloads and search results Web UI page
2004-08-10 spiralvoice Severity3 - Normal => 1 - Wish
2004-05-26 JongAm Carbon-Copy- => Added jongam --AT-- myrealbox --DOT-- com

Back to the top

Powered by Savane 3.5