Keyman 10 keyboard and Windows 10 awkwardness

Not sure if this is a Keyman issue or a Windows issue. I’m continuing to test making packages and install them on Windows and on mobile devices; and just had a surprising result installing a test keyboard on Windows 10.

I followed the new model of adding a BCP 47 tag to the keyboard in the package, I used the tag fuh-Latn.
This installed fine into Keyman on Windows but I couldn’t figure out how to activate it. Selecting the keyboard in Keyman desktop did not activate it. I looked more closely at my language settings, and saw that Windows had installed the test keyboard under a new language string, QAA. I had to switch from EN to QAA before I could activate the keyboard.

I discovered if I added English (US) to the keyboard in the language list in Keyman configuration, I could then activate the keyboard in Keyman desktop like I was expecting to be able to do, without needing to switch from EN to QAA.

My Keyman developer build is 10.0.1056 and my Windows 10 version is Pro 1709.

I suspect the problem here is that you need to include a script tag before the qaa tag will ‘take’, e.g. qaa-latn. See https://github.com/keymanapp/keyman/issues/731 for work we are doing on this.

It’s also possible that it’s a side-effect from the installation process. Keyboards in Windows 10 are installed asynchronously by a scheduled task. If your system is busy, then it can take several seconds or sometimes even longer to run the keyboard install; Keyman is not aware of exactly when the keyboard installation finishes. If this happens, then opening Keyman Configuration and clicking OK is usually enough to refresh Keyman.

I didn’t put the qaa tag in the keyboard package, I put in a fuh-Latn tag. Windows decided it didn’t know what to do with that and assigned the keyboard to the qaa language.

My laptop, with WIndows 10 Home, behaves more intelligently. It creates a language “western Niger Fulfulde” for the keyboard to match the tag I put in the keyboard package. Also Windows 10 build 1709, but Home rather than Pro.

Sorry I misread your original message. That is curious. I tried adding fuh-Latn to a keyboard and it installed fine on my machine when I tried it. Can you try opening Keyman Configuration, clicking Add Language for your keyboard, typing fuh-Latn and clicking OK? Let me know what the outcome is. Home vs Pro shouldn’t make an impact on this.

I think the key factor with my office desktop is not Pro vs Home, but that my user login is not an administrator account. The network admins do not want us to use administrative accounts for day to day use, we are provided with an administrative account to authenticate when we need to install something.

I uninstalled and tried again with that keyboard set to fuh-Latn. Today, when I installed with my non-administrative account, giving the administrative login when asked, the keyboard got listed as an option for English. But if I deleted it again, then logged into my administrative account and installed it there, it did create the Niger Fulfulde language and put it there. So it seems this issue of accounts has some effect.

Thanks, that’s helpful feedback. We’ll do some testing here on cross-account installation. Are the two accounts on the same domain or different domains?

Good question! Actually they are not. And I think this is by design. The network admins want to give average users access to network resources, so we have logins on the network domain. But the local computer admin account I use to permit installing software is only on my computer’s “domain.”

Thanks Steve; we’ll feed knowledge that into the research here.

More information on this process – installing a Keyman keyboard in WIndows 10 when you are not an administrator on the computer but have a different admin account to log into for installing software.

It seems when the install process asks me to give the administrator username and password, it installs the keyboard, but the language tag information is written to the administrator account user profile, and the user account profile does not see it.

I did another test just now, about the issue with the SIL Hebrew keyboard. I downloaded the SIL Hebrew .kmn file from Github, renamed it “SIL-test Hebrew”, compiled it and built a test package. In the test package, I put in the BCP 47 tag “hbo-Hebr”. When I install this, the hbo-Hebr tag is not visible in my language bar nor in the main Keyman desktop window. In the Language bar, Windows added a new locale ‘qad-Latn’ for the Hebrew keyboard, and in Keyman desktop, it is listed under “English US”. In Keyman desktop configuration, the keyboard is tagged with the hbo language.

If I log out and log into the administrator account, then the keyboard appears like it should in both the language bar and Keyman desktop, under “hbo-Hebr”.

Can the keyboard install process be rewritten so the language tag info is installed for all users and not just the administrative user?

Thanks Steve, this is on my agenda to address this sprint. Your additional research is also really helpful.

fuh-Latn is working for me on Win 10 pro. Likewise ff-Latn-XX pattern is working.

This conversation has been resolved.