** Observed with 4/26/99 Win32 build ** Hopefully this problem has been filed already but it shows up also in composing new mail messages. 1. Using Windows-Japanese IME (Input Method module), input Japanese into a composer window (mail or general editor). 2. Commit the first input strings by pressing "Enter" key. 3. Now start the new set of input using a Japanese IME. 4. Note that the 2nd set of strings are now replacing the 1st set of string instead of being appended to the 1st string. Given this behavior, there is no way to retain anything other than the current input string set. It seems that the insertion point cursor gets reset to the beginning every time the Japanese IME input string is committed instead of retaining the last character position so that the next input set can be added after that position.
IME is not really ready yet for IQA. This is an architectural problem that kin and tague are trying to resolve by M5.
I take bobj's comment to mean that we won't be committing to Japanese mail-send feature for M5 except in a very primitive way. Currently, copy/paste doesn't seem to be working into mail body for Japanese strings, header cannot take IME input, and so they and this bug leave only one kind of input possible, i.e. a few words which can be entered via IME in the first set of input. I guess we are now looking at very scaled-down enabling of Japanese mail-send for M5? There is also a blocking bug 5525 for Japanese mail-send.
Tague: please determine if anything else is required on the part of the editor team.
Adding to QA Blocker radar.
I looked at Japanese mail today -- finishing up the enabling work is only going to allow you to type in the mail textbody, you won't be able to type in the headers or subject line. all of the non body fields are implemented with native text widgets and don't have IME support.
Momoi, can you please assign yourself as the qa_contact? I won't be able to regress this type of bug...thanks!
Changed QA contact to firstname.lastname@example.org
Non-body text fields are using HTML forms. HTML forms have not yet switched to Ender and will not be I18N enabled until they're Ender-based. That part is M6, but the body part is M5.
checked in a fix today with chofmann's approval.
I verified this in 6-17-08 build.