As for Limewire 2 characters or less cannot be searched, it is
probably will be?

Should I be typing in Japanese? Hey I could be wrong. The error message that comes up is that 2 characters will congest the network, as it will seek out/search thru more items than it could possibly need & without necessarily finding all possible desired sources before the search is exhausted. In other words, a lot of search energy would simply be wasted searching thru unnecessary & unwanted files. One thing the p2p & particularly LW designers try to do is limit unnecessary traffic along the Gnutella network so it doesn't work at snail's pace. Which would you prefer, LW to work as the tortoise or the hare? lol

If you're refering to Asian characters such as used in Chinese or Japanese then perhaps you should put a request in for a new feature in LW. Post here: New Feature Requests And explain your reasons in detail. I can see how it would be a nuisance. Particularly for some names or even simple/short titles.

To the question before answering, thank you for! By any means, unless
search can be written in 2 characters, there are also some which do
not come out it is, but in that case it probably is how it should have
done?

The way Limewire is set up at present, you will need to think very carefully how you can search using more than 2 characters to find what you want to find. Because you can search using different types of criteria, you can try to find a way of expressing it using 3 or more characters.

As far as results go, showing results with only 2 characters I don't know. I would need to change my set-up & experiment to find this out. Or perhaps you could tell us.

Thank you for bringing this to our attention & I'll try to leave a note for the developers (not that they ever listen to me anyway, lol )

I see that you are in fact using a Japanese ip. Out of curiousity which city are you from?

The limit on 3 characters was designed at a time when only ASCII searches were reliable.
But since we now support Unicode for handling any language, this rule should be rewritten so that it will require a minimum 3 UTF-8 encoded bytes for a search.

This won't change anything for ASCII searches: it will still be 3 characters.

But for geenral European Latin/Greek searches it will mean that 2 characters will be enough if at least one is not ASCII (note however that searches ignores and drop accents, even if combining accents are still returned in the results)

For Asian languages, 3 UTF-8 bytes will code 1 ideograph or 1 Hiragana or Katakana. May be this limit of 3 bytes is too little.

So as a prudent alternative, I would say that 3 ASCII-only characters or 4 bytes of UTF-8 encoding will be needed to perform a search (For European languages, this is 3 ASCII, or 2 ASCII and 1 extended character, or 2 extended characters; for Asian texts, this means a minimum of 2 ideographs or 2 hiragana/katakana, ignoring the combining voice or tone marks)

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Nihon-go desu ka.
Warui kedo ore-tachi no nihon-go wa mada mada desu
(I still can't read, not to mention write, kanji)
It is really funny to see how those translator applications work (or don't work).

__________________
iMac G4 OSX 10.3.9
RAM 256MB
LW 4.10.5 Basic
ADSL anything from 3 to 8Mbps/around 1024kbps

"Raise your can of Beer on high
And seal your fate forever
Our best years have passed us by
The Golden Age Of Leather"
-Blue Öyster Cult-

Although I can't read Japanese other than Hiragana and Katakana characters for which an approximative phonetic translitteration to the Latin script is easy to perform (like you did), I can still recognize that "nihon-go" means "Japanese" (the language name).

So I won't be helpful unless there's a translator for support questions in Japanese (even more difficult when Japanese users send us a question in Japanese using in their email some unknown variant of EUC/ISO-2022-JP, instead of the more widely portable Shift-JIS, or even Unicode UTF-8)...

So I have a small support question in Japanese for which I can't reply. Here it is (sorry this forum does not support Unicode characters other than in a UTF-8 form , so characters are shown incorrectly; you need to explicitly select UTF-8 in your browser...):

æ–‡å_—ã?®éƒ¨åˆ†ã?Œâ–¡â–¡â–¡ã?«ã?ªã‚Šã?¾ã?™
����ょ��?

The question comes with a screen snapshot of Limewire in Japanese, where the title shown at the top of the search box is shown only as a string of square boxes. Apparently that user seems to have problems in his configuration of fonts to display Japanese, but I'm not sure how I can help, given that his display is not the one I get when testing LimeWire in Japanese, where I don't see these square boxes (which mean missing glyphs in the selected font).

So if there are inaccuracies in the encoding of the Japanese translation of LimeWire, there's little I can do. (Some months ago, a Japanese student was working in LimeWire offices in New York, and helped improving this translation, and creating the complete translation of the LimeWire web site in Japanese; he also worked with me to define the rules allowing better handling of Japanese in keyword searches).

Can someone come to the rescue? Aren't there any experimented Japanese user out there?

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

How about Chinese characters. 榆

Chinese characters, more exactly Han ideographs, are used in Chinese most often to write one syllable, not to write words or concepts as the term "ideograph" would imply. Linguists prefer the term "sinograph" to designate these characters.

What makes the Han script complex is the number of syllables that the script allow to encode, and the fact that the set of syllables in Chinese is extremely rich, with distinctive diphtongs, stress, tones, and multiple consonnants... When you compare it to other syllabaries (like Hiragana or Katakana used also in Japanese), the individual "letters" of that script becomes as much expressive as 1 or 2 syllables in a Latin-based language. That's why most Chinese words are written with no more than 2 sinographs. This is why Han is not considered as a syllabary, although it should (with the exception of some historic and rarely used sinographs used to represent concepts, or some tradtional sinographs which are widely used and frequent in Chinese texts, and represent a complete word or concept).

The size of the extended Han syllabary is not a problem for LimeWire, which inherits simply from the encoding efforts for Han performed in Unicode. In Unicode the most frenquent sinographs are encoded in the "BMP" after the U+03FF code point limit, meaning that they are represented with 3 bytes in a UTF-8 encoding scheme. A search for these characters will be selective if there is a bit more than 1 common sinograph in the search string.

The rule for allowing searches with:
- at least 3 ASCII-only chars,
- or at least 2 chars if at least one is not ASCII,
- or at least 4 bytes in the UTF-8 representation
would work for Chinese, as well as other languages.

Many more rare Han sinographs are encoded out of the BMP in a supplementary "ideographic" plane (SIP). Within Java and in LimeWire, all Unicode characters in strings are encoded internally with UTF-16 as a pair of "surrogates". But in UTF-8 they will become 4 bytes. If those characters were present in a search string, each of them would highly selective for searches. So a single character would be enough.

So the proposed rule to allow searches would also work well for these extended sinographs in the SIP...

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

That's very impressive about 中文 use in LW! I guess it depends upon which Japanese text you use. But their very roughly equivalent of Han might achieve in finding some items in searches (depending on labelling & source, etc.) I don't know japanese as is obvious 石灰ワイヤー So it's a difficult task.