Keyboard layout screen should show hints in the current settings language

The UI for adding a new keyboard layout assumes that the user knows the native spelling of the language and that the user has the apropriate keyboard to type those characters. This is not always the case, especially for those who want to learn a new language (or test pull requests like #1681)

I’m not sure what’s the correct solution here, but one approach could be to add translations for the layout languages in the various languages used by the keyboard settings application. And then we could have some sort of hint for each option or use the translation as default and have the hint show the native name of the language.

I saw #1681 and I wanted to validate the changes, just to make sure that it’s not a node-ipc-style vandalism. And while trying to validate the changes I had to use a translation service and send the native language names via an instant messaging application. And at that point I realized that I’ve ran into the samne issue some time ago, when I was trying to add a new keyboard layout for my language learning app.

[patrickgold]

Regarding the CLDR layouts: During the development of emojicon I discovered that the CLDR had a ton of keyboard layouts for varying sizes, and it may be worth checking out if the default layouts should inherit from these or not. The most interesting thing is that the CLDR combines the symbol layouts to the character layouts, whereas FlorisBoard has completely decoupled them. Tbh I don’t want to ever take away that freedom of combining anything you want. We could add the CLDR layouts as suggested subtype presets though.

I think though before we address the CLDR layouts we should focus on the subtype management process and the layout extension metadata.

[SchnWalter]

It might not be needed, especially if you have only one layout per language or it’s obvious what you have. But there are situations where it makes sense to add that extra information. For canadian_french you might want to show the layout, because the fr_CA layout is QWERTY and the fr_FR layout is AZERTY.

Currently we have layouts and they have no relation to languages, maybe in the long run, it would be worth looking into what the Unicode CLDR (Common Locale Data Repository) is doing. They group the layouts by language, and they even provide “names” for all these layouts. Here are 3 layouts for small screens (768dpi), it seems that they only add the “layout design” info if it’s not the default: French Canada and not French Canada (QWERTY)

More info:

• https://cldr.unicode.org/index/charts/keyboards
• https://unicode-org.github.io/cldr-staging/charts/latest/keyboards/layouts/index.html

If @patrickgold approves, I could create a python script to extract that “CLDR Layouts” data, similar to the florisboard/emojicon repo for extracting CLDR emoji data. And in the long run, we could have “Standard Layouts” and “Custom Layouts”. Note that this repository seems to lack various layouts available on modern systems.