Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Japanese input method is not reported correctly #2730

Open
nvaccessAuto opened this issue Oct 19, 2012 · 7 comments
Open

Japanese input method is not reported correctly #2730

nvaccessAuto opened this issue Oct 19, 2012 · 7 comments
Assignees

Comments

@nvaccessAuto
Copy link

@nvaccessAuto nvaccessAuto commented Oct 19, 2012

Reported by nishimotz on 2012-10-19 07:24
Japanese input method is reported as follows:

Example:
Three syllabic (kana) characters (transliterated from Latin 'k a w a n o')

'ka' (0x304B)
'wa' (0x308F)
'no' (0x306E)

are translated into three (ideographic and syllabic) characters:

'kawa (river)' (0x5DDD)
'no' (0x306E)
typed character: reported message

k: k
a: ka
w: w
a: wa
n: n
o: no
space: ka wa

When the space is pressed, first candidate 'kawa no' is shown (without opening candidate window), so it should be reported using character descriptions.

It also should include the last (syllabic) character 'no'.

  • operating system: Windows 7 SP1 Japanese
  • input method: Microsoft IME (Roman input mode)
  • application: Notepad
@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Feb 23, 2013

Comment 1 by nishimotz on 2013-02-23 07:45
Japanese IME works better if NVDAObjects/inputComposition.py is modified as follows:

def calculateInsertedChars(oldComp,newComp):

(omitted)

    #return newComp[newComp[diffStart:](diffStart:diffEnd]
    return)

Regarding Japanese IME, diffEnd is not necessary as far as I know.

@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Jan 8, 2015

Comment 2 by mdcurran on 2015-01-08 06:15
I assume this is still an issue?
If so, is the reason you don't want to use diffEnd because it is invalid (less or equal to diffStart), or because its more pleasing in Japanese to always read to the end, even if only the middle changed? Could you provide an example?

@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Jan 8, 2015

Comment 3 by nishimotz on 2015-01-08 09:18
At the time of previous writing, I didn't explain the consecutive clause conversion of Japanese input method.

Technically, we should obtain information regarding TF_DA_ATTR_INFO (for TSF) or GCS_COMPATTR (for IMM32) from Japanese input method editor.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms629063%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/cc195099.aspx

Just after pressing space key and first candidate appears, the results may differ depending on the configurations or previous usage of the system.

If all the characters are 'target_converted' characters (we also say that characters are converted as single clause), the user want to hear the explanations for all of the characters as the feedback of conversion.

If some characters are 'target_converted' and other characters are just 'converted' (we say that characters are converted as multiple clauses), the user should know what portion is 'target' (or 'selected'), because we must use left/right arrow keys to choose the 'target' portion and press space key to select alternatives for the target portion.

In Japan, implementations regarding this differs among screen readers:

  • type A: For the first time of pressing space key, all (including both target and non-target) characters are explained. For second time and later (i.e. choosing alternatives for the target portion), only the target characters are explained.
  • type B: Always only the target characters are explained.

Anyway, it is not just the matter of string comparisons.
If the last portion of characters are omitted just because they are same as input characters, the user may misunderstand as the result is separated into multiple clauses and only the first portion is marked as 'target clause'.

NVDA-JP has been worked around GCS_COMPATTR and we added TF_DA_ATTR_INFO support since 2014.3jp, so we should contribute regarding this.

@bhavyashah
Copy link

@bhavyashah bhavyashah commented Aug 13, 2017

@michaelDCurran Since you were assessing the reported issue earlier, could you please share any thoughts/inputs you may have in response to @nishimotz's #2730 (comment)?

@nishimotz
Copy link
Contributor

@nishimotz nishimotz commented Aug 15, 2018

Let me continue the discussion of #8621 regarding Japanese IME here.

The first candidate issue is still open for Japanese as well, however, it is different from Chinese.
Candidates window of Japanese IME is not shown during the type of Latin characters.
Windows 10 can show the prediction window during the type, but usually it is not expected to be announced.

When the space key is pressed, first candidate is shown, without candidate window.
At the second press of space key, candidate window pops up and the second candidate is focused.
As the result, first candidate is not announced as character description.

@larry801
Copy link
Contributor

@larry801 larry801 commented Aug 15, 2018

Auto focus means announce the prediction window under Windows 10. Am I right?
@nishimotz

@larry801
Copy link
Contributor

@larry801 larry801 commented Aug 22, 2018

As far as I have seen, the first candidate in Japanese IME shown after pressing space is treated as a reading string. That is why the first candidate is not announced as character description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.