WIP Add Chinese keyboards

[kevinlin18]

Original discussion: #798

Support Chinese keyboards by integrate Rime Input Method Engine
Features:

• UI translation: Chinese Traditional
• Quick switch between Chinese/English keyboards, can specific dictionary (Canada/UK/US)
• Split UI, Keyboard language list in management
• Supported input methods(keyboard) list:
  • Bopomofo
  • Cangjie
  • Luna Pinyin
  • Terra Pinyin

TODO
support stroke keyboard https://github.com/rime/rime-stroke

Known issues
'rimePreedit' not reset when leave a keyboard

Library:
librime 1.7.3

[kmcnaught]

@JuliusSweetland

I've asked a chinese friend to clarify some things for me, but in the meantime these are the existing issues I think are present:

• "Clear" sometimes clears the RIME input (i.e. removes suggestions) without clearing the scratchpad. It needs to clear both
• I don't think "Back Word" works
  • I need to ask for clarification on how it would be expected to work
• When switching between Chinese and English or vice versa, the prediction still contains part of what was already typed leading to various strange behaviours. Something needs to change here but I've asked for clarification on what would be reasonable, for example:
  • auto-add a space when switching from chinese to english? Should it take the current top prediction, or clear the current input?
  • clear any un-used input when switching from english to chinese?
• When switching from Chinese to english, sometimes the predictions bar misbehaves, with the wrong term highlighted due to the shift from 4 -> 6 suggestions giving a weird scaling bug. This might disappear if we are clearing suggestions when switching.

[JuliusSweetland]

Great to have some clear guidance. Thank you

…

On Thu, 29 Jun 2023, 14:18 kmcnaught, ***@***.***> wrote: @JuliusSweetland <https://github.com/JuliusSweetland> I've asked a chinese friend to clarify some things for me, but in the meantime these are the existing issues I think are present: - "Clear" sometimes clears the RIME input (i.e. removes suggestions) without clearing the scratchpad. It needs to clear both - I don't think "Back Word" works - I need to ask for clarification on how it would be expected to work - When switching between Chinese and English or vice versa, the prediction still contains part of what was already typed leading to various strange behaviours. Something needs to change here but I've asked for clarification on what would be reasonable, for example: - auto-add a space when switching from chinese to english? Should it take the current top prediction, or clear the current input? - clear any un-used input when switching from english to chinese? - When switching from Chinese to english, sometimes the predictions bar misbehaves, with the wrong term highlighted due to the shift from 4 -> 6 suggestions giving a weird scaling bug. This might disappear if we are clearing suggestions when switching. — Reply to this email directly, view it on GitHub <#876 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEA7ANR7M63QPPVSJYC72LXNV6AXANCNFSM6AAAAAASTIR5LY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kmcnaught]

I've been reviewing how the language is set in the installer, which needed some minor changes. Note that the Languages enum has been slightly overloaded - there is a single Languages enum whose constants describe either UI Language (all the previous ones, plus ChineseTraditionalTaiwan, and/or Keyboard Langauge + input methods (all the previous ones, plus 10 new ones like ChineseSimplifiedBopomofo, ChineseTaiwanTraditionalLunaPinyin, ChineseTraditionalTerraPinyin. So we have one enum list, but some enum constants don't correspond to a UI language, and some enum constants don't correspond to a keyboard language. This logic is mainly handled by presenting two different list of values to the user depending on the context. It feels like something that should be split out if we ever add another language that has more than one input keyboard available - the language and the input method should be nested. In fact, this would also suit the Simplified keyboards which are currently handled by a different boolean flag.

I'm not proposing this refactoring is essential now, but flagging it as something that should be considered next time we poke the nest. And it's important context for the following remarks.

In the installer, we allow people to choose a language, and (until now) use it for both the UI language and keyboard language. This can be separated in the management console if people want them to be different. This doesn't work for chinese though, because the list of available Chinese UI languages and Chinese keyboard languages are disjoint.

We also have a bunch of preexisting logic which tries to be smart about defaulting to the local culture if possible (e.g. if Windows is in French, you have "French" preselected in the languages dropdown but can choose another).

What I've done, which I think is reasonable given the current constraints, is this:

• in the installer, the user is given the list of keyboard languages to choose from, e.g. all the input methods like ChineseSimplifiedBopomofo, ChineseTaiwanTraditionalLunaPinyin, ChineseTraditionalTerraPinyin.
• This is used as the default keyboard language for Optikey
• If a "Chinese" option is chosen then the UI language is automatically set to ChineseTraditionalTaiwan which is the only translation we have available.
• If the system language is "zh-CH" (China) or "zh-TW" (Taiwan) then the dropdown should default to one of the options that supports Simplified (for China) or Traditional (for Taiwan). I think this is an okay heuristic, I don't actually know which it will pick (probably the first or last in the list). I haven't tested this as changing my PC to Chinese is scary, but I don't think it's critical as it's just a nice-to-have hint. It would also be okay if it failed and the dropdown defaulted to English.

[kmcnaught]

General update - this is ready for testing.

To Do:

• Need a translation for "English dictionary for Rime" which I think should just be "English dictionary" in the following screenshot
• Need to work out what to do with Symbols keyboard (based on testing)

[kmcnaught]

@JuliusSweetland this branch is now ready for testing both Chinese + touch input. You should be able to make an installer fine if required, or just share the bin directory for testing.