When a japanese user using IME input method try to enter the captcha challenge string, the input is not recognized unless the IME input is set to Direct Input.
I assume this problem persist with all asian languages e.g. chinese when using the Windows IME input method.
Set to major because japanese users get frustrated after several attempts and leave the site.
Solution:
IME input other then Direct Input e.g. hiragana, should be recognized when romanji characthers are used.
Thanks for the great module!
...and good luck with the renovation! ;-)
univac
Comments
Comment #1
soxofaan commentedI'm not familiar with Chinese, Japanese or other Asian languages, let alone all their different writing systems, transformations and IME systems. For example, I don't completely understand the original description of the problem. Could you elaborate a bit more on it?
Anyway, I don't feel in the right position to dive into/solve this problem and I hope someone with more practical knowledge about Asian/non latin languages/scripts tackles this one.
Also: I wouldn't consider this a bug, but more a feature request.
Comment #2
univac commentedDear soxofaan,
thanks for the replay. Yes, it might not be trivial if you are new in asian input system.
The IME is the Microsoft version of the Input Method used to write asian characters in a computer. It's a sort of T9 which semplfy the writing in the mobile devices, but developed to overcome the limitation of the alphanumeric keyboard in writing kanji and other asian characters.
You can download the package for free for any Windows version by Microsoft. Also other OS support similar input methods.
Now, with IME you can select different input forms for different writing modes. I am not an expert either, but in some of these modes you can still write alphanumeric characters "ABCD1234 etc..." only that they are eventually encoded with different character set, so thay are not recognized by CAPTCHA during comparison.
Perhaps a solution could be appling a transliteration of these characters to reformat them into latin one. Could you please make a try to apply such transliteration. Then I can volunteer for testing having the IME installed here.
Please consider that all the other half of the world is awaiting for that! ;-)
Thanks by now,
univac
Comment #3
soxofaan commentedThanks univac for this clarification, but there are still things unclear to me:
- What kind of keyboard (layout) is the user using? One with Latin keys ("US" keyboard style, qwerty, azerty, ...) or one with non-Latin script keys?
- What characters set is used for the challenge, e.g. image CAPTCHA: basic Latin A-Z or non-Latin characters?
If you enable "Log wrong responses" the "wrong" responses are logged to the watchdog log. Could you give some examples of these log entries?
Comment #4
univac commentedHi soxofaan,
thanks for your quick reply. I will try to answer your legitimate questions starting from the log:
On my experiments I get
feedback_form post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "gw44lz", but the solution was "GW44LZ".
or
feedback_form post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "mm6pけ", but the solution was "MM6PKE".
Of course I use the "case insensitive option" in the CAPTHA configuration. If you cut&paste the above log in MS Wordpad you can see different encoding (for some unknown reasons in the first example I see CHINESE but in the second example Japanese as expected - just move the cursor over the answered word). In the second example the last two characters have been translated into a Katakana character, so you might question whether the rejection was correct or not, but the user just typed the corrected keys on the keyboard.
Some other logs report:
user_register post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "" class=", but the solution was "XEY63C".
but I cannot say it was a spider...
About the keyboard, this can be any (QWERTY, QZERTY, etc...) no matter. With the IME system you type (spell) the kanji character in phonetics and the program present to yuo possible kanji that can fit with that spelling. You select from the scroll list with the mouse / arrows; then the spelling is removed and the kanji is inserted insteand in the text. Conceptually it is like the T9 in the mobile phones.
Hope this helps, just let me know.
Thanks again,
univac
Comment #5
miurahr commentedI've also got similar situation in my site. Some user claims to enter same character but answer was an error, because of a same case with univac's first example.
There is a CSS2 style 'ime-mode' that controls input method active/inactive, which helps users input with a correct character set. In this case, we can use 'ime-mode: disabled'
https://developer.mozilla.org/en-US/docs/CSS/ime-mode
When we use xhtml for the page for mobile devices, WAP foundation defined WAP CSS for input mode - '-wap-input-format'
http://www.developershome.com/wap/wcss/wcss_tutorial.asp?page=inputExten...
When we use html for (japanese) feature phones, it may be needed to insert argument such as ' input istyle="3" format=*m mode="alphabet" '. These three unofficial tags are for each NTT-DoCoMo, KDDI and Softbank to control ime mode.
I hope it helps you.
Comment #6
wundo commented