Support 2byte language
 

With my thought, Limewire most stable then anyother gnutella client. But... I disappoint with one problem.

Limewire doesn't support my native language. I'm using Korean. This problem might caused from JAVA's.

Is there any solution?

I can't search with Korean. And file name changed without my will.

And i happen do be dutch .
What If I change all my filenames to MY native language ?
Then you don't understand jack sh!t anymore of them .
It won't even match your searches because I'm using keywords in Dutch .

Same problem other way around , I can't read korean !

For everybody's sake , keep the network in a language everybody can easily understand ; for now that means English .
I would like to name my files in dutch too because that handles easier for me to work with .
But i don't , because I know that people in Bagdad , France , germany , US , Venezulea , Spain , Korea , ... then won't understand what the filename says .
This goes for any language other then English .
If everything would suddenly become in German or french , would you be happy ?

BTW , why do I see so manny people showing up from Korea , are they modernizing bigtime or something ?

Native language support is a good reason to have specialized horizons/a Community tab. Also, there would be less Internet backbone traffic from files traveling long distances, similar to the mirror concept.

With that I can agree .
But he was talking about filenames with non-international/english caracters .
For everybody's benefit , let's keep the filenames in english .

I didn't want to change all the file name to native language. And I know what u say. So, I intended to attach Native language commets to end of file name if that file originated from KOREA.

Comments on the end of the file name ...
Good idea , but keep the first and important parts in English .
Thatway when somebody doesn't speak that particular (Korean in this case) language they can still understand what the file contains .

About using non-english caractars :
I don't think LW can do anything about it .
The Java runtime is to blame for that .

Put it in the ideas forum and I'm sure they will read it sooner or later .

LimeWire is working to create internationalized versions, and we should have this released for several languagues quite soon. This is separate from the problem of not allowing 2 byte (Unicode) searches. The real catch there is that we'd have to get consensus from all of the Gnutella developers to implement it, and that's not an easy task.

In terms of having versions of LimeWire for all languages, though, I strongly encourage anyone interested to join the mailing lists at www.limewire.org and get involved. We have a working Dutch translation that could definitely use a second look, and we are still lacking a Korean translation.

Skip localized versions and go for full UNICODE! This is a world wide web after all. I'm located in Germany but I want files in Japanese. Understandably I normally don't get access to a Japanese language OS, and if I do then I get problems with non-UNICODE aware programs with German characters.

If you do localized versions using the country specific encodings, how would you solve the compatibility problems when going beyond one country border? You need UNICODE, it doesn't work otherwise.

Java has an internationalized version of the runtime environment, which is able to e.g. display Japanese characters on a German Windows (settings have to be modified, though). Java itself is UNICODE based, but still there might be some methods that request a string in the system default locale from the hosting OS. If that happens, then for example Japanese will be turned to ?'s on an English OS. This might be a problem, but Java itself is not.

If you use UTF-8 as the UNICODE transformation format for the search traffic then the protocol will stay compatible with current versions. Old clients will see funny characters, but that they do even now. New clients would recognize UTF-8 and read it as UNICODE.

Please do skip versions with country specific encodings! It would make it nearly impossible to go for a world wide reach later!

Implement UNICODE using UTF-8!
 

Please see my post in the 0.7-proposal <a href=http://www.gnutellaforums.com/showthread.php?s=&threadid=6920&perpage=20&pagenum ber=2>threat</a>!

registration coming soon
 

This is why GNUTELLA clients should become smarter.

If I'm searching 2byte, then find other servers with 2byte filenames. If I'm searching cryllic then give me cryllic servers.

Spanish, etc. Use past search words or keys such as Æ or ô .... duh.....

The problem is solved - half of it, that is. UTF-8 has been accepted for the 0.7 proposal. Any language can be described by it. Now you just need a client that fully implements this proposal, and a computer with your desired default system locale, or a smart client that accepts any character in the UNICODE range.

Just returning specific language servers for a specific language query isn't very desirable and anyway impossible to implement: You would need to explicitly specify the language of a file. This is bothersome, unnecessarily restrictive (think of a word which is written with the same Chinese characters in Korean, Chinese and Japanese) and much too complicated to implement. Also, what would you do with servers which offer mixed language files?

The problem is solved, with the 0.7 proposal. Now it depends on the clients.

mutibyte emulation option
 

convert multibyte (utf-8) to non-lossy-ascii and search.
convert non-lossy-ascii to utf-8 (alphabet would be passed)
and display search result.

is it effective?

i have created utf-8 text by TextEdit OSX.
and save as non-lossy-ascii.
and open saved text with iso-latin-1 encoding
fellow text was displayed.

€u3053€u306e

and copy and paste it to limewire search field,
and push query button.
it has passed.

Another solution
 

Being thought as evasion step the character string which is converted
as the ISO-8856-1 code prepare the function which is converted to the
correct character string.
this is sample code.

public static String raw2String(String raw, String encoding)
throws UnsupportedEncodingException {

return (new String(raw.getBytes("8859_1"), encoding));
}

It is the processing where the program below at a time one character
fetches character from String and transfers to doSomething method.
this is sample.
For support Limewire to UNICODE dynamic composition.

public static void doSomethingPerCharacter(String string) {
BreakIterator boundary = BreakIterator.getCharacterInstance();
boundary.setText(string);
int start = boundary.first();
for (int end = boundary.next(); end != BreakIterator.DONE;
start = end, end = boundary.next()) {
String c = String.substring(start, end);
doSomething(c);
}
}