GNOME Bugzilla – Bug 612803
Date widget input problem in Japanese
Last modified: 2018-06-29 22:36:49 UTC
Created attachment 156063 [details] Account period problem in Japanese This problem affects at least Japanese locale. Situation: Set the end of accounting period Mar 31, 2011 in Japanese locale When we input the date Mar 31, 2011 in Japanese, at first, we have to press keys "2011nenn03gatsu31niti" continuously, then we convert them into numbers and Han ideographs using input method. So input method must receive all the keys in order to convert them properly. But GnuCash consume the key press "t" before input method receive it and input method can receive only "2011nen03gasu31nii" (without "t"). So we can't convert them properly. This problem don't occur on Windows because Windows input method consume key press events at the top-level window.
I guess this means the date widget has to be changed so that the keyboard shortcuts are switched off in locales where one of the input methods are being used?
Many Latin languages use simple input methods in order to input diacritical marks. They are simpler than Asian languages' one. But some unexpected problems occur when key presses are consumed *BEFORE* the input methods use them. For example, when you input a ý (U+00FD), you will press ` and y. But if y is consumed before Latin input method use, you can't use ý (U+00FD) character. Fortunately, GnuCash shortcut keys don't conflict input characters into date fields until now. I accidentally discover GnuCash short keys conflict Japanese date. I think there are two solutions and two workarounds. Solution 1: Process shortcut keys *AFTER* input methods use them. This is ordinary way to handle input methods and I use it to implement IMContext into GnuCashSheet. Date field of accounting period window use GtkEntry widget internally. So you can use "insert-text" signal instead of "key_press" signal. But they are incompatible with current implementation and may introduce some bug like Bug#605802 Comment 27 2). Solution 2: Make shortcut keys of date fields customizable. Workaround 1: Suggest Japanese users to use ISO date format instead of locale. Japanese people prefer to use yyyy/mm/dd or yyyy-mm-dd formats. Workaround 2: Suggest Japanese users not to delete preexisting Han Ideographs and only edit numbers.
FYI, with IBus, there is another workaround: IBUS_SNOOPER_APPS=gnucash gnucash
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=612803. Please continue processing the bug there and please update any external references or bookmarks.