RightBracket and Backslash on LEFT_OF_Q, LEFT_OF_A. This is a straight hand-swap on the same rows and prioritises ease of finding the keys in the japanese layer.
Minus and Equals onto LED/Any as per (1)
LeftBracket and Quote on RIGHT_OF_P, RIGHT_OF_SEMICOLON as per (1)
Backtick is used as a nonprinting mode switcher, so it might be safe to go on Prog, otherwise Fn-Prog
And the three other special keys (Kana, Henkan, Muhenkan) can fit onto the thumbs, at the price of having only one each of control, shift and alt.
I decided against pairing the japanese bracket keys on LED/Any because they sit above and below each other on a standard keyboard, so having them side-by-side is less critical than it would be for languages where the brackets normally are side-by-side. Whereas hand-swapping the kana (letters) seemed to be more touch-typing friendly.
The same argument also works for pt_BR (class 4), which would then become:
Bracket pair on Key_RightBracket and Key_Backslash (pt_BR): Key_RightBracket ([) and Key_Backslash (]) on LEFT_OF_Q, LEFT_OF_A, Key_Backtick on RIGHT_OF_5 and Key_Minus, Key_Equals on RIGHT_OF_SLASH, LEFT_OF_6 respectively
This keeps Equals on the right hand, which might be more intuitive than sending it to LEFT_OF_A.
Interesting thing about Brazilian keyboards is that they commonly have an extra key in the same place as Japanese Key_Ro (I don’t know if it uses the same scancode) - but there are AltGr alternatives so that the same OS layout can be used on a standard keyboard. I think we should take advantage of the latter, as we have enough trouble fitting the standard keys in…
At this point I’m not sure we can go much farther without a survey of native speakers.
I use a parameterized sketch which can be modified by commenting in and out various #include directives. To enable the various options above, edit keymaps.h and change aliases-abg-orphans-merlin2.h (under “Choose the arrangement of the orphan keys”) to one of the following:
For class1 (dvorak, azerty, qwertz, scandi, canada) leave it as is
For class 2 (en_qwerty, dutch) use aliases-abg-orphans-ngetal2.h
For class 3 (es_latam) use aliases-abg-orphans-latam.h
For class 4 (brazil) use aliases-abg-orphans-brazil.h
For class 5 (es_es) use aliases-abg-orphans-merlin3.h
For japanese, use aliases-abg-orphans-japan.h and also change aliases-abg-modifiers-thumb-enter.h (under “Choose modifier key layout”) to aliases-abg-modifiers-japan.h to get the Henkan, Muhenkan and Kana keys on the thumbs.
If you don’t like my weird thumb modifiers, change aliases-abg-modifiers-thumb-enter.h to aliases-std-modifiers.h.
This looks like a wonderful package you have put together, and I think it will be invaluable particularly when Chrysalis comes on line. Thank you for the thought and effort that has gone into this.
In the meantime for less technical users I would like to have resources available on the wiki to easily customize their layouts. If I want to generate keymaps analogous to the Dvorak and Colemak maps for these definitions, how would I do that?
I would like to add an “International support” page to the wiki where the alternate layouts are covered, and I would prefer simple cut & paste keymaps and a description or image of the layout. (from a description I can edit the existing image file and create the corresponding layout.)
Thanks again for all the thought and effort this represents. I know I’m asking you to dumb this down a lot for the purposes of easy onboarding right now for the folks who aren’t going to easily be able to update their firmware to add your libraries, and I am sorry for that. I know that this will turn into something that’s part of core and will give international users the equivalent of a switch they can flip to get the layer zero they want, and when we get to that point I will gleefully pull the keymaps out of the docs and give the correct configuration parameters instead. I’m just trying to make sure we have at least rudimentary support for other language groups asap.
It should be possible to knock up a make rule that would preprocess the layer files with each variant enabled in turn and produce an output keymap definition that would be cut and pasteable. Let me work on that this weekend.
This is turning out to be harder than I thought. If I could source or generate a definition file for all known keymaps in the form (Key = Symbol) I could in principle use this to generate mappings from symbol to symbol for pairs of keymaps, and by extension a mapping from the US_ASCII based aliases to aliases defined WRT any given language (what we want). But getting that definition file for a large number of keymaps is proving difficult.
xmodmap does what I want: it outputs the current keymap as a straightforward mapping “KEY = SYMBOL” for each key (it’s a bit more complicated than that, but not much). Unfortunately xmodmap only does this for the currently active keymap, meaning I would have to reconfigure my local machine’s live settings for every language. This strikes me as error-prone and could potentially leave me with an unusable computer.
xkbprint will draw me a pretty picture of an arbitrary keymap (that’s what I use to make my keyboard diagrams), but it apparently won’t give me a machine parseable list of pairs like xmodmap does. And the XKB source files are full of multilevel include indirection, meaning that there is no one file that holds a complete set of definitions, except for US_ASCII.
I’m sure such a set of mappings must exist in parseable form. But the documentation is telling me to look at files that don’t exist, and my google-fu is failing me. And I don’t want to reverse-engineer an XKB source file parser…
In the meantime, I’ve updated GitHub - andrewgdotcom/keyboardio-xkb: Some XKB files for use with the Keyboardio Model 01 to include the latest set of keymaps above. It is still lacking the ability to print the AltGr layers automatically, unfortunately. And I can’t get Japanese keymaps to print. But it will give you a nice picture of an arbitrary European language keymap.
