Most people in the UK and Ireland use the UK English layout, which is marginally different from US English. This is a market of ~65m people and therefore not to be dismissed lightly.
This would require the following five alternative keycaps to be manufactured:
[2"] [3£] [’@] [`¬¦] [#~]
These would replace the US-ascii 2, 3, apostrophe, backtick and backslash keys respectively. This is dependent on an “international key” scancode for the backslash keycap, which doesn’t appear on the proposed default Model 01 layout. We may also then require a sixth alternative keycap [|], depending on the position chosen for the international key (which will determine whether we can reuse the us-ascii backslash keycap).
I think if we start down the path of internationalization it would probably make sense to make one set with all the commonly used Latin-1 charsets (Nordic/French/German/Spanish/etc), the alternative being to go with an entirely new layout that addresses all languages that use Latin based character sets.
That’s a lot of glyphs, the majority of which will never be used (how many people type in more than two languages?). And such a layout would require yet another bespoke OS keymap to go with it.
People who want a non-US keyboard generally do so because their localized variant is more familiar. There are extended keyboard layouts (dead keys etc) that can be selected in your favourite OS if you want extra functionality. And there’s always compose-key.
Yup, I created one such layout (see the Colemak layout chat) and I realize that probably nobody except me will ever use it even though it’s faster/better for any given language than the current layouts. On the flip side we need a lot of internationalization kits and I think UK English is probably at the back of the list.
Most people in the UK know how to use a US keyboard and the changes are minimal, it’s probably more urgent to get a Spanish/German layout.
I would have been crazy had I thought the layout would gain significant adoption, people are already far to invested in QWERTY and local customization dating back to typewriters. The world is full of local minimas and getting the people to crawl out of this one is about as hard as changing to decimal time, global GMT, the US adopting the metric system, standardizing voltage/freq of electrical supply and a host of other things.
That may be a pro, rather than a con. It means you only need to make five or six extra keycaps. Other languages may have more need for a localized layout, but also require more keycaps (not only for the extra letters, but the AltGr keycaps for the displaced symbols), which raise manufacturing costs.
Most manufacturers make the key caps as one mold for the whole keyboard (or in this case at least one half), I think Signature Plastics is the exception but typically this would be the difference between a $30 set or a $130 set (assuming doubleshot PBT). I think the Model 01 does the whole half at a time but @jesse can probably answer that better.
@antevens is correct - our keycaps are being manufactured as a single injection mold per 64 key keyset.
We’re still hopeful that we’ll be able to find a vendor to help us do small-batch customization, but it’s not something we’ll offer for first shipment.
on a pragmatic note, for those of us set in our ways with qwerty/uk layout I came up with a (hopefully) minimum-mental-overhead layout to switch to keyboardio from standard UK without going totally crazy.
So here is the layout diagram showing my changes from stock (without my own idiosyncratic thumb remapping):
Getting that working in Keyboardio firmware is a bit fiddly. To get orphaned symbols into the function layer when using a UK software mapping these are the code snippets for Model01-Firmware.ino:
My primary machines are Chromebooks which are set to UK Dvorak in software. Using a Model01 with stock firmware in that configuration, I have a bunch of keys not accessible. Most notably:
and ~
/ and ?
\ and |
I’m trying to work out if that will give me full access to all the keys that I need to use on a day to day basis.
I seem to recall seeing a blank layout too, but I don’t have the link handy at the moment. The Share your layout topic has a few other layouts of various kinds, and some links to KLE too.
Apologies for the delayed response, I’ve been busy for the past month.
Having a look at the source code, it seems like the merlin2 layer is compiled into the firmware, but it’s not obvious to me how to select the merlin2 layer as the base/default layer used by my keyboard.
To enable mixing and matching of different layers, I split out the layout logic from the main .ino file into the keymaps.h file, which I then heavily modified.
If you look at keymaps.h you will see a series of #include directives. Commenting these in and out changes what layout options get compiled into the firmware. The default branch has aliases-abg-orphans-merlin2.h enabled, so this is used by the parameterised base layer.
The base layer is defined in layer-std-qwerty-parameterized.h - you can see this #included into the const Key keymaps[] definition at the bottom of keymaps.h. This is a special layout file that relies on macros defined in the aliases-* files. The other two default layers are #included in a similar way, but they don’t use the macros.
So in short, merlin2 is enabled out of the box. If you want to try one of the other options, edit keymaps.h and rebuild.
Hmm. Managed to flash merlin firmware, have UK Dvorak in software on my Chromebook. Still can’t get access to NON_US_\ or whatever it’s called (\ unshifted, | shifted, on an ISO 105 key keyboard). Is there a PDF/SVG of the merlin layout which I can look at?
