[Non-ASCII-capable layouts](https://invent.kde.org/plasma/plasma-setup/-/issues/52) aren't the only non-obvious complex case for a tool determined to offer input configuration. Another is input methods. Some scripts have huge numbers of characters, far more than you can simply map one-character-to-one-key. For these scripts we have 'input methods'. These days on Linux I think pretty much everyone uses the [ibus](https://github.com/ibus/ibus) framework. The KDE Control Center is already capable of configuring these, so the code's around, but plasma-setup does not appear to do so yet. A Chinese or Japanese or Korean (etc.) person encountering such a tool probably expects to be able to configure their input method through it. Also, following https://invent.kde.org/plasma/plasma-setup/-/issues/53 , if the user selects Chinese, Japanese, Korean etc. as their language, we should guess a sensible default input method - plus an ASCII-capable keyboard layout for entering Latin characters, of course - as the default configuration (I believe GNOME initial setup does this). [langtable](https://github.com/mike-fabian/langtable) has data on this, just as it does for keyboard layouts associated with languages. For instance, in `langtable/data/languages.xml`, the entry for Japanese includes: ``` <keyboards> <keyboard><keyboardId>jp</keyboardId><rank>1000</rank></keyboard> </keyboards> <inputmethods> <inputmethod><inputmethodId>ibus/anthy</inputmethodId><rank>900</rank></inputmethod> <inputmethod><inputmethodId>ibus/kkc</inputmethodId><rank>100</rank></inputmethod> </inputmethods> ``` which you can read as recommending the default setup of `ibus/anthy` input method (for typing Japanese) and `ja` keyboard layout (for typing ASCII characters; it's almost identical to the `us` layout).