IME mode changed at startup in Google Japanese Input #14407
Comments
kzrnm
added
Issue-Bug
|
Hmm. linking threads: |
|
Not only Japanese, but also Chinese.
|
lhecker
added
Product-Terminal
|
Same issue is reported at Gborad Help. Expert says that Microsft IME has one state "半角英数字/直接入力" (direct input) but Google Japanese Input and Legacy Microsoft IME has "半角英数" (English input) and "直接入力" (direct input) as separated state.
I think Windows Terminal incorrectly specifies input method at startup. |
|
I have same issue, and v1.14.186 reproduces the issue but v1.13.1143 doesn't. |
carlos-zamora
added
Issue-Feature
ghost
added
the
|
Marking this as a feature. We've had reports in the past of users wanting this kind of behavior. Sounds like the right path forward is to make this a configurable setting. |
|
@carlos-zamora If there are some usecases that users want to switch to that mode, I think it is the right way to make it configurable too. |
|
The cause appears to be #13028. In this PR, it is declared that
and
However, as this issue shows, this feature can have extremely unpleasant side effects depending on the environment. As @carlos-zamora suggests, I strongly agree that there is a need to add settings that allow users to easily switch this feature ON/OFF. |
|
Original issue #12731 says:
So the author expected that users could immediately start typing commands at startup, but this is hampered by this issue. |
I add two keyboard layout, one is english, another one is chinese. If I need to input english / chinese, I use |
|
I now think this can be considered as Google IME's issue. In Microsoft IME, CoreTextInputScope::AlphanumericHalfWidth is mapped to Direct Input mode, so it is okay for us. But in Google IME or Mozc, the scope is mapped to Alphanumeric mode with IME on, causing this issue. It is documented in Mozc repository: Quote:
As described above, Google IME and Mozc consider IME should be turned on in text inputs with AlphanumericHalfWidth scope. I am not familier with UWP, but isn't there a way to turn IME off without depending on the InputScope? |
Mozc for Windows has been mapping IS_ALPHANUMERIC_HALFWIDTH InputScope to "Halfwidth Alphanumeric Mode (IME On)" to be compatible with Microsoft IME 2012. However, recent versions of MS-IME map it to "Direct Mode", probably to make it more consistent with their default settings of "Don't use direct input mode" [1]. This discrepancy can result in unexpected user experiences when app developers assume IS_ALPHANUMERIC_HALFWIDTH is a way to turn off IME based on recent MS-IME's behavior [2]. Anyway, Mozc's design philosophy has been to emulate MS-IME's behavior whenever possible. Let's just update InputScope mapping to be compatible with the latest version of MS-IME. Closes #818. [1]: #817 [2]: microsoft/terminal#14407 PiperOrigin-RevId: 573458610
[IME mode changed at startup in Google Japanese Input · microsoft/terminal](microsoft/terminal#14407) という問題が存在しており、 [ターミナルとIMEについてのログ · cumet04/dotfiles](cumet04/dotfiles#17) を参考にひらがな切り替えのショートカットを追加することで誤魔化しを考える。
Mozc for Windows has been mapping IS_ALPHANUMERIC_HALFWIDTH InputScope to "Halfwidth Alphanumeric Mode (IME On)" to be compatible with Microsoft IME 2012. However, recent versions of MS-IME map it to "Direct Mode", probably to make it more consistent with their default settings of "Don't use direct input mode" [1]. This discrepancy can result in unexpected user experiences when app developers assume IS_ALPHANUMERIC_HALFWIDTH is a way to turn off IME based on recent MS-IME's behavior [2]. Anyway, Mozc's design philosophy has been to emulate MS-IME's behavior whenever possible. Let's just update InputScope mapping to be compatible with the latest version of MS-IME. Closes google#818. [1]: google#817 [2]: microsoft/terminal#14407 PiperOrigin-RevId: 573458610
|
I tested the built-in CJK IMEs in Windows XP, 7, and 11. Chinese IMEWindows XP's version: "IME off" and "IME on, but English mode" are different states. When the IME is on, you can switch between Chinese/English with Shift keys, but when the IME is off you can't. Other than that, those two modes are similar: both modes just pass the English key input without interception, similar to "direct input". Windows 7's version: those two modes are merged. "Turning off IME" is interpreted as "switching to English mode". And when the IME is in English mode, it will report that it is off. Windows 11's version: "Turning off IME" is interpreted as "switching to English mode". However, the IME always reports that it is on. Some third-party Chinese IMEs follow the XP's behavior. If they are turned off, they behave as if they are "disabled": the IME bar is hidden, and you cannot use Shift keys or other hot keys to bring them back, until you switch to another IME then switch back. Japanese IMEWindows XP's version: "IME off" and "IME on, but half-width alphanumeric mode" are different states. "IME off" is also known as the "direct input" mode. In half-width alphanumeric mode, English input is not converted, but is still intercepted. Windows 7/11's version: those two modes are merged. There's no "direct input" mode anymore, only "half-width alphanumeric" mode. When in this mode, the IME reports that it is off. Korean IMEWindows XP's version: reports that it is on or off depending on whether it's in Korean mode, but you cannot turn it on or off. You have to change the conversion mode. Windows 7's version: reports that it is on or off depending on whether it's in Korean mode. Turning it on or off appears to change its state, but in fact the mode is not changed. Windows 11's version: reports that it is on or off depending on whether it's in Korean mode. You can turn the IME on or off to switch between Korean/English mode. (But sometimes it doesn't work) ConclusionIf the user is using Chinese or Korean IME, the conversion mode should be changed. This can be done via ImmSetConversionStatus, or sending a WM_IME_CONTROL with wParam = If the user is using Japanese IME, the IME should be turned off. This can be done via ImmSetOpenStatus, or sending a WM_IME_CONTROL with wParam = It seems that there isn't a corresponding InputScope value for the "IME off" state, though. |
|
A Google Japanese Input / Mozc maintainer here. If you are/were using Google Japanese Input for Windows and had been affected by this particular issue, it should no longer happen with Google Japanese Input version As far as Google Japanese Input is concerned, I believe no further change in the Windows Terminal side is needed. Just for your reference, here are currently released versions as of writing.
|
|
The latest update seems to have fixed the issue for me, however the "About Google Japanese Input" page is blank, so I'm not sure what version I'm on... (Edit: Using the method below, I see it's 2.29.5370) I was on 2.28 previously which I downloaded about 2 weeks ago. Thank you for the heads up! |
Me too, it's probably because your (and my) system is using Dark Mode. The dialog uses system-default text color (white in Dark Mode) with custom background, I guess. |
|
You can verify the version by converting the word "ばーじょん" on Google Japanese Input. |
Sorry about the trouble. I've filed the following issue to keep track of the above issue. Thanks! |
Next in the popular series of minor refactorings: Out with the old, in with the new! This PR removes all of the existing TSF code, both for conhost and Windows Terminal. conhost's TSF implementation was awful: It allocated an entire text buffer _per line_ of input. Additionally, its implementation spanned a whopping 40 files and almost 5000 lines of code. Windows Terminal's implementation was absolutely fine in comparison, but it was user unfriendly due to two reasons: Its usage of the `CoreTextServices` WinRT API indirectly meant that it used a non-transitory TSF document, which is not the right choice for a terminal. A `TF_SS_TRANSITORY` document (-context) indicates to TSF that it cannot undo a previously completed composition which is exactly what we need: Once composition has completed we send the result to the shell and we cannot undo this later on. The WinRT API does not allow us to use `TF_SS_TRANSITORY` and so it's unsuitable for our application. Additionally, the implementation used XAML to render the composition instead of being part of our text renderer, which resulted in the text looking weird and hard to read. The new implementation spans just 8 files and is ~1000 lines which should make it significantly easier to maintain. The architecture is not particularly great, but it's certainly better than what we had. The implementation is almost entirely identical between both conhost and Windows Terminal and thus they both also behave identical. It fixes an uncountable number of subtle bugs in the conhost TSF implementation, as it failed to check for status codes after calls. It also adds several new features, like support for wavy underlines (as used by the Japanese IME), dashed underlines (the default for various languages now, like Vietnamese), colored underlines, colored foreground/background controlled by the IME, and more! I have tried to replicate the following issues and have a high confidence that they're resolved now: Closes #1304 Closes #3730 Closes #4052 Closes #5007 (as it is not applicable anymore) Closes #5110 Closes #6186 Closes #6192 Closes #13805 Closes #14349 Closes #14407 Closes #16180 For the following issues I'm not entirely sure if it'll fix it, but I suspect it's somewhat likely: #13681 #16305 #16817 Lastly, there's one remaining bug that I don't know how to resolve. However, that issue also plagues conhost and Windows Terminal right now, so it's at least not a regression: * Press Win+. (emoji picker) and close it * Move the window around * Press Win+. This will open the emoji picker at the old window location. It also occurs when the cursor moves within the window. While this is super annoying, I could not find a way to fix it. ## Validation Steps Performed * See the above closed issues * Use Vietnamese Telex and type "xin choaf" Results in "xin chào" ✅ * Use the MS Japanese IME and press Alt+` Toggles between the last 2 modes ✅ * Use the MS Japanese IME, type "kyouhaishaheiku", and press Space * The text is converted, underlined and the first part is doubly underlined ✅ * Left/Right moves between the 3 segments ✅ * Home/End moves between start/end ✅ * Esc puts a wavy line under the current segment ✅ * Use the Korean IME, type "gksgks" This results in "한한" ✅ * Use the Korean IME, type "gks", and press Right Ctrl Opens a popup which allows you to navigate with Arrow/Tab keys ✅
|
We just published a major update to our IME implementation in the nightly Canary branch. It was rewritten from the ground up and has tons of improvements! If you're interested in trying it out, you can get it here: https://aka.ms/terminal-canary-installer If you encounter any issues or have any suggestions, or if you simply like/dislike the changes, please let us know! Thank you for bearing with us. 😊 |
Windows Terminal version
1.15.2874.0
Windows build number
10.0.19045.0
Other Software
Google 日本語入力 (2.28.4650.0)
Steps to reproduce
Start Windows Terminal with Japanese IME.
Expected Behavior
Google IME selects
直接入力(Direct input) mode.MS IME selects
半角英数字/直接入力(Direct input) mode.Actual Behavior
Google IME selects
半角英数(English input with IME) mode.MS IME selects
半角英数字/直接入力(Direct input) mode.The text was updated successfully, but these errors were encountered: