Comment 2 by mdcurran on 2012-10-31 04:44
I think some research will need to be undertaken to find out exactly how all affected asian input methods should handle this. There are major differences between the languages. Also the implementation of speak typed words was not designed to handle this, so it will have to be rethought based on the new asian input support.
Changes:
Milestone changed from None to near-term

Comment 3 by blindbhavya on 2014-09-07 08:20
Hi.
A similar issue was reported and fixed for v 2014.3
If this issue is the same one, and is fixed in 2014.3, then this should be marked as duplicate and closed.
I don't exactly remember the other ticket number that I said was fixed.

The InputComposition NVDAObject intentionally treats characters as words. This is correct for Chinese (where every character is a word), but it isn't correct for other languages. We should determine where this doesn't apply and find a way to exclude these cases (e.g. Unicode ranges).

CC @josephsl, @nishimotz.

In my opinion, 'speak typed words' option is not relevant for input composition.
Japanese language users, in general, do not use 'speak typed words' during input composition.

The conversion operation of Japanese IME is usually assigned to space key, so the announcement of candidates is something similar to the typed words during the Japanese input composition.
If the candidate contains several words, reviewing for each word is possible within the composition session.
(actually the composition unit is not equal to the Japanese word, in terms of linguistics.)

Although it is not common, skilled Japanese users just disable 'Speak typed characters' and 'Report changes to the reading string' and only enable the report of selected composition string.
It is something similar to the latin character input, with only enabling 'Speak typed words'.

For Chinese language, word segmentation is mentioned in #4075.
Word segmentation of Japanese language is not trivial as well.

As far as I have tested few years ago, Windows Uniscribe API cannot handle Japanese correctly.
Microsoft Word seems to have own text analysis system for Japanese word segmentation.
Mozilla Firefox uses full-shape punctuation characters for psudo-word segmentation.
Internet Explorer and WordPad treats successive Katakana phonetic characters as a psudo-word.

I'll ask Korean users if they'd like to offer some additional info on this.
For Hangul input, it is like entering Latin characters in that space and other whitespace chars are used to separate words. For Korean, after entering some characters, Korean IME is smart enough to move to the next character (hence, certain Unicode char range is devoted to storing all possible consonant/vowel combinations for Hangul chars).
For Hanja input, the setting that's useful is announce short descriptions. Because the same char (not the letter, but the pictorial shown) could have differing meanings, it is always helpful for people to know the short description/possibilities. These days, Hanja (Chinese characters) are used in Korean text to clarify meanings of words (often found inside parentheses as part of Hangul text).
For Korean users, the important thing is for NVDA to support entry of Hangul better. Thanks.

I'm a korean.
In korean language, Chinese characters are basicly used as characters, not as words. Some cases, a chinese character can be used as a word, but it's not general.
So, as a korean NVDA user, I think Notepad and such a edit control are really inconvenient to korean users.
I hope that NVDA has a option which can select whether inputconposition object treats characters as characters or as words.
This problem will be a critical obstacle for more korean blinds to use NVDA.

@josephsl: Do you think #8110 can solve or improve this somehow? Pretty curious what its impact on the behavior for input composition is anyway.

@josephsl could you please thest with last NVDA alpha if this is still an issue? Or could you ask on the translations list for someone to test if this has been improved now? Thanks.

cc: @khsbory, @ungjinPark, @dnz3d4c, @larry801 maybe this could be a good point to start a team work in asian communities to develop sollutions for such issues and similar problems in IME window regarding compound characters.