Dear readers,
For a while now I have been thinking how we can make life easier for those who use our products in West Africa with either qwerty or azerty keyboards. In the multi-lingual context of West-Africa it is often needed to switch between typing a regional language like Wolof, Bambara, Jula, Fulani and French for instance. Luckily, the keyboards developed for the West African languages make that possible. But do they really?
For instance, the SIL Mali keyboard can produce an é by typing e and /. In MS Word however, a French word with any kind of accented vowel produced by keyman this way is not recognised. To type French correctly with a qwerty keyboard and it to be recognised by the MS Word spell check, one has to use the EuroLatin (SIL) keyboard. (i.e. This also applies for the Cameroun keyboard, and probably others.)
However, the difficulty with the Eurolatin keyboard is that the typing sequence is counter- intuitive (i.e. the other way around). One first types the special character, followed by the vowel. In this case ’ followed by e -› to get é. The advantage is that the word élève (on the right in the image) is recognised by MS Word, and no further spell check is needed. The disadvantage is that the typing is counter intuitive for a user working with the Mali Keyboard, (or most West African keyboards) and thus it is difficult to learn.
So my question is, how could the (West-)African keyboards be improved so that the French accents are seen as valid by spell checkers like MS Word?
I agree with you; it is counter intuitive to type the diacritic before the base letter. That is just like dotting the “i” before writing the body of the “i”.
I have also noticed a similar problem relating to spell-checking in Keyman: When I type in the local language, each keystroke is taken to mean a word, so that if you decide to undo typing a word, you can’t; you can only undo typing a letter. It makes the undo/redo function in MS Word to be less useful.
I think the Microsoft Word spellchecker would work better with French if the text was composed. So if the keyboard normalised all typing to NFC (which I think I will happen in the future with Keyman) the spellchecker would work.
The é from the SIL Mali keyboard is actually two characters
U+0065 LATIN SMALL LETTER E
U+0301 COMBINING ACUTE ACCENT
The EuroLatin (SIL) keyboard is generating
U+00E9 LATIN SMALL LETTER E WITH ACUTE
You can see this difference yourself by copying the text into UniView and pressing the down arrow button on the screen.
I was able to see the difference in spellchecking in Word from Microsoft 365 by entering the codepoints into a text file and then opening that text file in Word. That is, I did not use any Keyman keyboards (as I don’t have Keyman installed at the moment), the text came from the codepoints I entered.
So the issue, as far as I can tell, is if the text is composed or decomposed. Not primarily what order someone types in.
Granted, with the SIL Mali keyboard using a modifier key (/) after the vowel, generating decomposed text probably makes for a much simpler keyboard definition than generating composed text.
Likewise, with the EuroLatin (SIL) keyboard using a deadkey (') before the vowel, generating composed text (a single codepoint in this case) probably makes for a much simpler keyboard definition than generating decomposed text.
But with a more complicated Keyman keyboard definition, you can generate composed or decomposed text with either typing order.
It is easy in Keyman to finish with a pass that does NFC. But, we leave that up to the keyboard author to decide if they want to implement it. This one Eastern Congo keyboard does nfc, but it also uses a modifier key to access almost any special character so that doesn’t look like what you are looking for.
With Keyman, you can setup the typing order to be whichever works better for your users. If your users prefer to type diacritics afterwards, they can do so, and you can use a post-processing group as @Lorna suggested to normalize any combining marks into a composed form. It’s a little more complex than an NFD keyboard, but it’s worth the effort. We can help you with this if you need. (Note, you also need to make sure your rule contexts cater to both NFD and NFC content.)
For Word, text needs to be tagged to the target language in order for content to be spell checked properly. So you need to (a) normalize your output, and (b) ensure that the keyboard is associated with French language. (You can add the same keyboard to multiple languages in Keyman Configuration.)
Spell checker and Undo that @katelem noted – this could probably be helpfully discussed as a separate topic, if it is of concern.
Thank you again for your contributions. As it turns out, the keyboard is producing composed french very well indeed ! However, the keyboard was not linked to the french language (as a tag) in keyman .
After correcting that we now have one kmx file linked to three languages in the keyman configuration settings. This works very well, with an added difficulty.
For each of these 3 languages the same icon is displayed by keyman. So the unaware user may think he or she is ok, but in MSWord one may find this:
So indeed it is very helpfull that one can add the same keyboard to multiple languages in Keyman Configuration, but the question is how to make that visible for the user? When MSWord is launched it will switch to the current language that is active in Keyman. As far as I am aware, the user will then have to manually change the language of the new document via the language settings menu:
Is there a solution to display a different icon for each language selected within one kmx file? If not, what help could we offer the user to make him or her aware which keyboard is selected?
Thanks for considering this Marc. One workaround could be to use the same kmx file, but rename it for multiple languages, thus allowing a different icon for each language. Would that have any disadvantages?
Yes, you could do that, and it would work at a local level.
I guess It’s not a solution I’d want to propagate onto the Keyman Cloud or into the keyboards repository, because the duplication of identical keyboards would be hard to maintain and confusing for users searching.
.
