Keyboard per Language or per Country ? - the pros and cons

Having just done the feb. 2020 Keyman developer course (thank you for recording that) and created a touch-keyboard with success :slightly_smiling_face:, I am left with a question. Clearly the course seems to promote a keyboard that is as simple as possible and avoid long-press keys with a whole lot of possibilities etc. And that is just what you get, in most cases, when creating a keyboard for a whole country. And so at the moment, “our” keyboards, like the one for Cameroon and Mali that I know a bit, are like that. “Big” keyboards that “have it all”.

From the point of view of the user though, according to what the course (SIL?) is advocating, the user is best served with a simple keyboard, just for one language. Just as I would be hard sold on a european keyboard showing me all the scandinavian and southern european characters. This is not difficult to understand.

So do you agree, should we move away from country-keyboards (=many language keyboards) to more simples one-language keyboards ?

What advantages do you see, and what disadvantages ?

Full Disclosure: I maintain the Cameroon Keyboard (QWERTY and AZERTY versions that include full ASCII and special characters). The country keyboard can provide for English, French, and any Cameroon language following the standard orthography. I’m also working on some monolingual keyboards for a few communities that have requested them.

Multilingual Keyboards are (at least) a stepping stone, with their primary advantage being on physical keyboards where you are “typing blind”. You learn the few special combos you need for your language, and ignore the rest. They enable access to write languages even as the orthographies are still being tested and formalized and ISO codes are being negotiated. They enable researchers or multilinguals to work with several languages without learning or switching to new layouts. The disadvantage is that it can be hard to place all of those characters on a single keyboard. AZERTY is nearly full before you start to add special characters.

When you get to Mobile keyboards, simpler seems to be easier to learn, and you are no longer “typing blind” so learning a new keyboard is easier. The separation of language models and keyboards allow you to choose the language and keyboard separately, a huge advantage. It makes sense from a training standpoint that a naive user might be better served for writing their own language by a keyboard that only includes their own alphabet and nothing else, but then they have to learn to switch keyboards [very] often. It’s hard to type if y is not in on the keyboard, and who wants to switch keyboards to type a web or email address? (Of course, I work in primarily Roman script. Those who use languages with different scripts are presumably more used to switching keyboards. Switching keyboards when switching scripts seems easier (if not necessary), while switching languages within the same script could be accomplished on the same keyboard. I use QWERTY on GBoard on my phone with both English and French auto-completion, but switch to the Cameroon keyboard for Cameroon languages.)

Maybe a minority language keyboard should be “pure”. Maybe it should have the capability of producing the national languages as well, but some may see that as “corrupt”. Maybe a National keyboard is “good enough” for a time.

Keyboarding is ALWAYS influenced by history and what the user has used before. I think of a national keyboard as analogous to a transition primer, and a monolingual keyboard as analagous to a “start-from-scratch” literacy primer. Each has a different audience. The bottom line, as with any linguistic issue, is that it should be determined what the community wants. If some want a country keyboard (convenience, adaptability) and some want a language keyboard (prestige, simplicity), go for it! In my experience, both is the best option, even if it is a lot of work.

Matthew Lee
SIL Cameroon

Thanks for replying Matthew. I agree that a purist keyboard may often not be practical, but a one-size-fits-all multi-lingual keyboard is not practiced anywhere except in African countries like Mali, Burkina Faso and Cameroon (not being critical here, just stating the facts as I know them). For instance, I would be surprised if a Thailand keyboard would exist. From what I know there is Thai, khmer, ect ect, one keyboard per language. In that line of though it is easy to understand why a European keyboard does not exist. Or can one ever imagine a Nigerian keyboard (200 languages in one keyboard?). From what I know, Yoruba, Twi etc etc all have their own keyboards. . Now I am exaggerating of course, but I do think up until now keyboard design has been in the hands of technological experts like you and me, trying to limit maintenance, and be as efficient as possible. But if we really want to put the user first, we should listen to the communities and see what they want. And indeed, most of the android users in West Africa will have been using the french azerty to type their texts, so a combination of that and one local language with the french seems like the way to go I think.
I am curious what Doug Higby and Ron Lockwood would have to say on the subject.

Thailand? I was advocating both country and language-specific if possible. :stuck_out_tongue:

Let me clarify, the critical issue for feasibility of a multilingual keyboard is not the number of languages, but the number of possible characters in the combined orthographies, and it’s usually not such a stretch to add a few similar languages in the same script if that’s what the users want. Switzerland has a national keyboard that covers French, English, German (probably Romansh), and Italian without a problem. Canada has national bilingual keyboard(s). US International is quite close to being a pan-European-capable keyboard for roman scripts. They exist for convenience, even if one language is so strong that a monolingual keyboard is most common. There is little reason for majority monolinguals to make sure that their keyboard works for other languages, but the minority language groups that have to work with content in the national language seem to appreciate a keyboard that can do both.

As you say (and I didn’t take it as a criticism), massively multilingual keyboards and hacked fonts were created just before the Unicode boom in developing nations with lots of languages (Most West and Central African countries, PNG, etc.), because keyboard development and font hacking were a specialist process and we HAD to have a workable keyboard and font in the meantime (even if it was awkward). As Unicode rose, the necessity for keyboard developers to be font hackers was dropped, but the Unicode versions of the keyboards became de facto standards because people knew and used them.

I mentioned that I was in the land of Roman script with a relatively small number of characters. Cameroon has only 41 letters plus extras and decomposed diacritics in the GALC ( that the language groups can choose from, and theoretically that could work for any of Cameroon’s 280 languages if they follow the national orthography. I don’t doubt that languages like Yoruba have their own keyboard(s), but it seems that they have a general orthography as well (smaller than Cameroon) and I’m pretty sure that some working in Nigeria have a country keyboard that covers most of the 400+ languages using Roman script, even if it isn’t “official”. Some groups in Cameroon have their own specific keyboards as well, but that doesn’t fully negate the utility of a national keyboard or a quasi-national keyboard. On the more extreme side, Pan-African Roman keyboards exist as well, but they get more complex and efficiency compromises are made.

West and Central Africa are admittedly a perfect storm for country keyboards. We had one or two keyboard developers per country during the rise of Unicode, we’re mostly in roman script (plus a few IPA characters), characters can [usually] stay decomposed, many of our countries have centrally-managed national orthographies, and it is [just] possible to include everything, even on AZERTY, without resorting to awkward combinations like [ALT]+[SHIFT]+[Lick your Elbow].

@dhigby used to be a developer of country keyboards, but he keeps asking us in the domain how we are progressing on language-keyboards, especially with the auto-complete features available. I’ve seen Doug gradually guiding a shifting in emphasis towards language keyboards. We’ve also had an emphasis in Francophone Africa on making keyboards more discoverable.

Nevertheless, country keyboards are a done deal for us requiring minimal continual maintenance, and cross-language workers would be sad to see them go (Some translation consultants even have their own hyper-custom keyboards to type well-enough in the countries that they work with). There’s no need for us to stop maintaining and kill existing country keyboards, but we (or better yet, “they”) can and should gradually add new language keyboards as individual orthographies get solidified.

One script per keyboard seems to be an emphasis I’ve heard from @drowe and @Ron_Lockwood, and that makes perfect sense to me. Within the same script, I’d love to hear more discussion on multilingual and monolingual keyboards for a non-Francophone Africa context.

Thank you Matthew, the use of a country keyboard of course is very usefull for more advanced users. If we never add discoverability features in those keyboards they may become less liked over time.
I would be interested to find out how these cameroonian communities you described earlier made their request? Were they approached? Why would they want a separate keyboard for their language from the Cameroon Country keyboard?

The question is, if the tech people (=SIL) decide to “just” maintain the country keyboards, who will do the language keyboards ? Who is going to do the tech-advocacy for these groups? Do you see this as your responsability Matthew?

Thanks for contributing to an interesting exchange and hoping @dhigby and other will contribute as well.

Thanks @Matthew_Lee for your perspective – I would agree with you write. From my perspective, at the end of the day, it’s really up to the user communities! However, one thing to consider also is that a keyboard optimized for a given language may have greater success because users can see it as a solution specially created for them. I believe this sense of ownership can be important for language vitality.

Multi-language keyboards also suffer a little around documentation. It is difficult to provide documentation (at least within Keyman’s current design) that supports many languages within a single package.

Simply put, any character that requires 3 keystrokes to access, or a frequently used character that requires 2 keystrokes to access, is going to result in inefficient typing. Country keyboards do have it all, but have to be evaluated for every language as to whether the inefficiencies outweigh the convenience.

Thanks for contributing Doug. Would you be willing to share your finalised Fulfulde Language keyboard with the lexical model to help see where you have applied these efficiency measures ? I would be very interested.

Hi Matthew

Country-general (regional) and language-specific keyboard each layouts have their place. Although size of character repetoire is a trade-off with complexity of layout and ease of input.

I have created both language specific and regional layouts. Regional layouts are easier to work with if there is a shared approach to orthographies and a more concise repetoire of characters.

Language specific keyboard layouts lend themselves to implenting text predition/suggestions. They also lend themselves to what I refer to as orthographically responsive layouts where input can be optimised for a specific language.

For instance in Dinka long vowels are indicated by doubling a vowel . Breathy vowels are indicated by a diearesis. A long breathy vowel would be a doubled vowel with diearesis. E.g long breathy a would be ää . Typing would be a +diearesis +a + diearesis four keystrokes … with analysis of language and vowel combinations possible it is possible to also ok mplement a rule as three keystrokes a+a+diearesis also giving ää since in this language the combination aä isn’t possible.