Mutliple unicodes in shift layer

Apologies for the double post,

I am working on creating an android keyboard for the Laz language. While I am able to create an uppercase letter consisting two unicodes in the default layer, when I try creating it in the shift layer, no letter appears upon testing it.
I found out you can create new ids based on two unicodes by writing them this way:

Since most uppercase letters seem to work when I use an U_xxxx id, I figured I use the same system for this letter: Ç̆ (shift layer, longpress-key tied to Ç):
unicode: U+00C7 U+0306
id: U_00C7_0306

When I try compiling the keyboard I get the following error message:
laz_android.kmn: Error: 405A Key “U_00C7_0306” on “phone”, layer “shift” has a multi-part identifier which requires version 15.0 or newer.
laz_android.kmn: Failure: ‘…\laz_android.kmn’ was not compiled successfully for Web, iPhone, iPad, Android phone, Android tablet, Mobile devices, Tablet devices.

Please note, I am using Keyman Developer Version 16, so I am not sure why I’m getting this error message.

Thank you for taking the time reading my post!

Best wishes,

Hi Okan,

No worries – this message is coming up because your keyboard is currently “targeting” an older version of Keyman, even though it is build with Keyman Developer 16. To target Keyman 15, you need to add or edit the store(&version) line in your .kmn:

store(&version) "15.0"
1 Like

Thank you so much, I should have looked at the very first line! :smiley:

1 Like

There’s a header statement with the minimum Keyman version required for your keyboard. It probably says 9.0 or 10.0. Change that to 15.0

I want to add one more element to this story.

You’ve solved the problem in Developer, but using this feature (U_00C7_0306) means that your users will need at least Keyman 15 (from 2022) to use your keyboard. This may not be a problem since the Keyman can be updated online, but that depends on your users and how often they are connected to the internet or update their apps.

The alternative (supported since version 9) is to create a recognizable name for the key and write a rule in your layout tab. If you named the key T_CCARCED, the rule would be + [T_CCARCED] > "Ç̆".

Using a rule in the keyboard layout (.kmn) file is certainly a possibility. And considering your users is very important!

My understanding is that the U_xxxx_yyyy syntax needs Keyman Developer 15 or later to compile the keyboard, but that the compiled result does not require the later version of Keyman on the mobile device. @Marc Can you comment? Are there any disadvantages to using the U_xxxx_yyyy syntax?

Thank you for the concern, but I’d rather have clearly defined characters than the patchwork alphabet we’ve been using as community. I’m currently working on replacing a lot of texts issued by the Laz institute using my keyboard.

That being said, I made my cousin test the keyboard in iOS (using the project folder similar to the way I’ve been testing it), but the longpress keys do not work properly.
He just downloaded Keyman today. What might be the issue? Do I have to add a separate code for iOS?

He just had to restart his phone but it works! That being said, unfortunately the letter t‌̌ isn’t correctly displayed on his screen - but I doubt this can be fixed here, I suspect it’s a system wide issue.

Thanks again!

Best wishes,


The U_xxxx_yyyy syntax does require Keyman 15 or later to use the keyboard, due to changes in the compiled file to support this syntax. The vast majority of users on mobile devices are on 15 or later (because generally, they get updates automatically).