Problem With Caps Lock Output

We have two layout here in Keyman for this language (Obolo): The CHWERTY and QWERTY layout



The CHWERTY layout produces “Ch Sh Ọ N̄” with SHIFT but produces “ch sh ọ n̄” when capslock is on. This means that many keystrokes will have to go into typing this diagraphs in all caps, and right now, this keyboard cannot type those diagraphs in all all caps unless each letter is taken singly.

Using the QWERTY layout helps, but will only solve the problem of CH and SH since one key outputs one letter, but “ọ n̄” will still be in lower case with CAPS LOCK on.

Also, in the language, the QWERTY layout overloads ones right hand and makes it do more work while the left does less. That makes one tired typing long articles (because the most frequently occurring letters are all on the right).

Since you (Keyman) would like us (keyboard authors) to minimise keystrokes (and we know that all keys are useful), is there no way for you to instruct the Keyman app to “output every letter in the upper case equivalent when CAPS LOCK is on”? I think that will really help to reduce multiple keystrokes and speed up writing.

Or, is there something I’m not doing right? Any workarounds?

IN SUMMARY: I want to be able to use this keyboard with “caps lock on” to type those diagraphs etc. in upper case when writing titles, etc.

P.S. I’ve checked all the topics relating to caps lock in this forum.

First, just for clarity on our end, what platform are you using Keyman on? Based on your description and the screenshots above, I’m guessing Android, but it’d help us if you could include those details.

Since you (Keyman) would like us (keyboard authors) to minimise keystrokes (and we know that all keys are useful), is there no way for you to instruct the Keyman app to “output every letter in the upper case equivalent when CAPS LOCK is on”? I think that will really help to reduce multiple keystrokes and speed up writing.

On this point, there’s a little problem that makes this… less simple than it seems. Many languages of the world don’t have upper-case vs lower-case. Long story short, this has led to documentation of this issue:

Every now and again, we internally have a discussion regarding potential designs to address this, but sadly this keeps falling further and further behind on our roadmap.

So… it’s something that everyone would like, but it simply isn’t something that KeymanEngine does on behalf of keyboard designers… at least not yet.

If you want a keyboard to provide this behavior, there is a way to do it, though it does mean adding a lot of extra detail to your keyboard. This post describes the general approach you’d need.

ch and sh have three cases:

lowercase: ch and sh

uppercase: CH and SH

titlecase: Ch and Sh

so in theory you need to support ch, Ch and CH as well as sh, Sh and SH

there are a few different strategies that could work:

  1. avoid using digraphs on keys, use separate s, c and h keys to type digraphs, or

  2. on mobile devices have separate layouts for lower, upper and titlecase, with buttons to switch between them as required, or

  3. on mobile devices have two layers: lowercase and titlecase and add CH and SH to longpress of Ch and Sh respectively

there are also many other ways of handling it as well, by writing more complex contextual rules and constraints to guess whether uppercase or titecase should be used.

This issue affects the desktop app, but I’m posting from Android that’s why the picture is Android screenshot.

I have read that post before publishing the last update to the keyboard. But that did not address my CAPS LOCK issue. At the end of that post you see this:
“This could be done, but @Marc may suggest that we wait for Caps to be truly added as a feature.”
Again that post is about switching layer, whereas this one is about CAPS LOCK producing lower case letters.

I have already done that in the QWERTY layout. But the problem with that layout, as I stated, is that it overloads ones right hand. Note that it’s the only available keyboard for writing this language. So we use this keyboard to type long articles in the language. If you have to type that long, then both hands will need to share in the work. Thus, the CHWERTY layout does it better in this language. But then, this CAPS LOCK issue is affecting this CHWERTY layout.
Even if I avoid using diagraphs, the ọ and n̄ will still appear in lower case with CAPS LOCK on.

That’s exactly what I’ve done. But it doesn’t solve the CAPS LOCK issue. If you need to try out the keyboard, I can send you the link or the .kmp file.

How about enabling it for languages that do? I think (though not very sure) that many languages using Latin script will have uppercase.

@joshua_horton and @Andrew_Cunningham
I really appreciate the work that you and the Keyman team are doing. It’s highly appreciated. For this language Keyman is a life saver. I just wanted you to know that fixing this issue will really help.

For desktop layouts other strategies are needed.

I assume that Ch and Sh are more often needed to be typed than CH and SH in which case one possibility is to have Ch and Sh generated on the shift state and move CH and SH to AltGr sequences for instance.

Rules tailored for CAPS and NCAPS states should allow you to control the desired behaviour.

For a couple of keyboard layouts I developed I was in the position to have to type long documents in them. In one case a minimum of 80 pages in a single document.

After analysing the orthography in more detail a number of optimisations suggested themselves.

Extensive typing in a language is a good way to stress test a layout .

I am not part of the keyman team. I am a keyboard dev much like yourself.

I see two main approaches:

  1. Normal state is lowercase, shift state is title case and AltGr is uppercase and disable caps lock.

  2. Normal state is lowercase. Shift state is title case. Caps lock becomes a toggle making keyboard give lowercase and uppercase.

There are other options. But really comes down to how users want it to behave. The more you move from the default behaviour of a keyboard, the more complex the rules become, especially if the touch and physical keyboard paradigms differ.

Keyman can be quite powerful and quite sophisticated keyboard layouts are possible.

If it’s the desktop app, then using virtual keys with [CAPS K_X] and [NCAPS K_X] should cover all your requirements. See

On mobile platforms, we are hoping to improve Caps Lock support for this release, actually in just a few weeks:

  • double-tap shift to “shift-lock” the layer
  • also optimizations for lexical models
  • start-of-sentence auto caps
  • Title Case mode

See for more details

When I use the [CAPS K_X] suggestion, it refuses to compile, and shows this:

I really need to know how those rules work. Please look at the screenshot I’ve posted above and let me know where I got it wrong.

Very nice. I’m keeping my fingers crossed. More grace to the Keyman team.

1 Like

This looks like you need to update the target version for your keyboard (Caps Lock support was added in KeymanWeb 10):

store(&version) '10.0'

Thanks. I’ve updated the version but this shows up:

But line 159 is important. It is intended to help check wrong placement of accent, and other things which are not acceptable in the orthography, which will also help users to write well. Any workaround for “notany” please.

Yes, notany is something that we really want to support in KeymanWeb better. We have a plan for it but have not had the capacity to resolve it yet. I am going to try and shuffle some priorities around and get this resolved in 14.0. See for details and some partial workarounds.

1 Like

Please see our specification for Caps Lock support on touch layouts at