[v5.2.0 now out] Conkey keyboard layout

[bradrn]

For about two weeks now I’ve been working on this project. It’s a keyboard layout specifically aimed at conlangers, with all the special letters, diacritics and symbols we love to use. Here’s a sample of what you can type, copied from the linked GitHub page:

Nuu-Chah-Nulth (source):
ʔUyaaƛaḥ hawiiʔaƛii maapt̓ał c̓išaaʔatḥ ʔuukʷił yuułuʔiłʔatḥ ʔaḥʔaaʔaƛsi n̓ačuʔałʔaƛsi hiikʷis.

Khoekhoe (source):
ǂKam !ũi-aob gye ǁẽib di gūna ǃhomi ǃna gye ǃũi hã i.

Azerbaijani 1922 alphabet (source):
Butun insanlar ləƶaqət və huqyqlarьna gɵrə azad və bərabər doƣylyrlar.

Zhuang 1957 alphabet (source):
Bouч bouч ma dəŋƨ laзƃɯn couƅ miƨ cɯyouƨ, cinƅyenƨ cəuƽ genƨli bouчbouч giŋƨdəŋз.

Polish (source):
Mag skłonił się. […]
— Jak siē nazywa ta wieś, panie? — zapytał przybysz. Kowal wzruszył ramionami.
— Głupi Osioł.

Various typographical marks (source: various Wikipedia articles)
„Hast du den Artiken ‚EU-Erweiterung‛ gelesen?‟
« Voulez‐vous un sandwich, Henri ? »
What are those‽

Mathematics:
∀ a,b,c,x ∈ ℂ. (ax² + bx + c = 0) ⇒ (x = (−b ± √(b² - 4ac)) ÷ 2a)

Haskell:

Code: Select all

(∘) ∷ ∀ α β γ. (β → γ) → (α → β) → (α → γ)
g ∘ f = \x → g (f x)

(Yes, I know those last two aren’t strictly languages, but they’re good as a demonstration…)

And another sample which I forgot to include above — some of the language names from Akana, which have weird characters galore:

Aθáta, Kuyʔūn, Ishoʻu ʻOhu, Iŋomœ́, Kibülʌiṅ, Ree Rɛɛ Kıbyaa, A-Rox Ŋʷoskʷuɣmʲa, Potɑnsʉti (I think), Tkeḏ, ǃHuwan

I would welcome any questions/comments/critiques/criticisms/compliments! If you find an issue, please submit it in this thread or on the issue tracker.

(Note that this project obsolesces my earlier half-baked attempt at a multilingual keyboard. This one is much easier to use, as it’s designed from scratch. This one also has a lot more symbols.)

[k1234567890y]

nice (:

maybe you can also aim at peoples who want to revive dying or lost language, not just conlangers I guess.

also is it possible to type non-Latin characters with this?

[bradrn]

nice (:

Thank you!

maybe you can also aim at peoples who want to revive dying or lost language, not just conlangers I guess.

Maybe… I haven’t thought about that as a goal yet. On the other hand, there’s already a sub‐keyboard for Haskell programmers, so this is certainly possible.

also is it possible to type non-Latin characters with this?

From the README:

• Conkey supports only Latin scripts (not including the IPA). Characters from other scripts should only be added if they have been used at some point in a Latin-based script.

So you can already type ьЬαβγΓδΔλƛ, but only because those letters are often used in a Latin‐script context. On the other hand, if you want to use a non-Latin letter in a conlang, I would consider that to be enough justification to include that letter…

[cedh]

From the README:

• Conkey supports only Latin scripts (not including the IPA).

If it's aimed at conlangers, why is the IPA not included? That seems like a strange design decision to me...

(In my own custom keyboard layout, I am using the Caps Lock key to switch from Latin mode to IPA mode, with the IPA mode layout roughly based on X-SAMPA.)

[akam chinjir]

From the README:

• Conkey supports only Latin scripts (not including the IPA).

If it's aimed at conlangers, why is the IPA not included? That seems like a strange design decision to me...

(In my own custom keyboard layout, I am using the Caps Lock key to switch from Latin mode to IPA mode, with the IPA mode layout roughly based on X-SAMPA.)

I feel sure that was supposed to mean "the IPA is the only non-Latin script that's supported."

I wonder how many such things there are amongst all of us. (I've got a gradually expanding descendent of ipa-praat.el for use within emacs.)

[bradrn]

If it's aimed at conlangers, why is the IPA not included? That seems like a strange design decision to me...

Good question, and one I didn’t think about in detail! However, the answer is that the IPA requires a very large range of symbols which are almost never used outside the IPA, and including all those symbols would use up a lot of space on the keyboard layout which could be used for other more useful letters. I felt that it would be better design to let this keyboard be more ‘general-purpose’, and leave IPA support to a dedicated keyboard layout.

(In my own custom keyboard layout, I am using the Caps Lock key to switch from Latin mode to IPA mode, with the IPA mode layout roughly based on X-SAMPA.)

Clever design! To me that feels a lot like including ‘two keyboard layouts in one’ in some way. This is of course another way to do what I mentioned above, about a split between a ‘general-purpose’/IPA keyboard.

Also, is your keyboard publicly accessible? It sounds like something I’d love to try out!

• Conkey supports only Latin scripts (not including the IPA).

I feel sure that was supposed to mean "the IPA is the only non-Latin script that's supported."

Almost the opposite: it was meant to mean “the IPA is the only Latin-based script that isn’t supported”. But I appreciate that the wording is a bit ambiguous; do you have a better suggestion which I could use?

I wonder how many such things there are amongst all of us. (I've got a gradually expanding descendent of ipa-praat.el for use within emacs.)

I do wonder… it might be nice to have a collection of such layouts, so we could each find one which suits us best.

(This actually reminds me of sound change appliers. I am sure that every conlanger who can program eventually develops their own SCA, as per the xkcd. I know of at least 6 SCAs off the top of my head, and there’s probably many more which I don’t know.)

[mèþru]

There should be an equivalent Cyrillic keyboard
I'm tired of having to use special characters to type in all my obscure Cyrillic letters or to combine them with (additional) diacritics

[bradrn]

There should be an equivalent Cyrillic keyboard
I'm tired of having to use special characters to type in all my obscure Cyrillic letters or to combine them with (additional) diacritics

I’ve never needed to type Cyrillic, so I don’t have any plans for a keyboard like that. I do believe that people have already made keyboards like that though.

[bradrn]

If anyone’s interested, I’ve just released a new version of Conkey! Here’s the changelog, copied from GitHub:

• Add chevron symbols ⟨ and ⟩.
• Add more superscripts: ᴬᴮᴰᴱᴳᴴᴵᴶᴷᴸᴹᴺᴼᴾᴿᵀᵁⱽᵂᵃᵇᶜᵈᵉᶠᵍʰⁱʲᵏˡᵐⁿᵒᵖʳˢᵗᵘᵛʷˣʸᶻ¹²³⁴⁵⁶⁷⁸⁹⁰⁺⁻.
• Add ∅ symbol for the null set.
• Fix issues with the dead keys for superscripts, arrows, Haskell, interrobang and blackboard bold.

[Xwtek]

Can anyone port it to Linux?

[bradrn]

Can anyone port it to Linux?

I would love to make Conkey available on other platforms as well! The problem is that currently Conkey is built using the Microsoft Keyboard Layout Creater (MSKLC), which only supports Windows. On the other hand, some preliminary research seems to suggest that a Linux keyboard layout is just a text file, and MSKLC files are fairly human-readable as well, so it may be possible to make a conversion script… I have a lot of free time in the next few days, so I’ll definitely look into this.

[bradrn]

There should be an equivalent Cyrillic keyboard
I'm tired of having to use special characters to type in all my obscure Cyrillic letters or to combine them with (additional) diacritics

It’s probably far, far too late to respond to this, but if you’re still interested, I just discovered this site, which contains at least two comprehensive Cyrillic keyboards (‘Slavonic’ and an unnamed one), plus lots for individual languages. Also from the same site, this ‘Russian (International) Keyboard Layout, which may or may not be the same thing, but certainly looks very comprehensive.

[Kuchigakatai]

Do MSKLC layouts work on Windows 10? I remember hearing something about MSKLC keyboards failing to install or work properly in the new OS, and Microsoft being uninterested in updating MSKLC to get them to work.

And yeah, it should be fairly easy to translate Conkey to a Linux keyboard layout file.

[alice]

Can anyone port it to Linux?

On the other hand, some preliminary research seems to suggest that a Linux keyboard layout is just a text file,

All you have to do is copy one of the files in /usr/share/X11/xkb/symbols/ and edit it appropriately. Here's one I knocked up earlier:

Code: Select all

    key <AD01> { [ q, U0252, U0291, U02A5 ] };
    key <AD02> { [ w, U026F, U02B7, U0270 ] };
    key <AD03> { [ e, U025B, U0259, U025C ] };
    key <AD04> { [ r, U0280, U0279, U027D ] };
    key <AD05> { [ t, U03B8, U02A7, U0288 ] };
    key <AD06> { [ y, U028F, U0264        ] };
    key <AD07> { [ u, U028A, U0289, U1D7F ] };
    key <AD08> { [ i, U026A, U0268        ] };
    key <AD09> { [ o, U0254, U00F8, U0153 ] };
    key <AD10> { [ p, U028B               ] };

    key <AC01> { [ a, U0251, U00E6, U0251 ] };
    key <AC02> { [ s, U0283, U02A6, U0282 ] };
    key <AC03> { [ d, U00F0, U02A4, U0256 ] };
    key <AC04> { [ f, U0278, U025F        ] };
    key <AC05> { [ g, U0263, U02E0, U0262 ] };
    key <AC06> { [ h, U0266, U02B0, U0265 ] };
    key <AC07> { [ j, U029D, U02B2        ] };
    key <AC08> { [ k, U026C               ] };
    key <AC09> { [ l, U029F, U028E, U026D ] };
    key <AC10> { [ semicolon, U02D0 ] };
    key <AC11> { [apostrophe, U0259, dead_circumflex, dead_parrot] };

    key <AB01> { [ z, U0292, U02A3, U0290 ] };
    key <AB02> { [ x, U03C7, U0281        ] };
    key <AB03> { [ c, U00E7, U0255, U02A8 ] };
    key <AB04> { [ v, U028C               ] };
    key <AB05> { [ b, U03B2               ] };
    key <AB06> { [ n, U014B, U0272, U0273 ] };
    key <AB07> { [ m, U0271, U0274        ] };
    key <AB10> { [ slash, U0294 ] };

This file should then be picked up by the keyboard manager as a new layout with the name of the file.

[Richard W]

All you have to do is copy one of the files in /usr/share/X11/xkb/symbols/ and edit it appropriately. Here's one I knocked up earlier:

If only! AltGr and dead keys don't mix well on Linux. The method I'm currently using on Ubuntu is to define the keyboard in M17n and load it via fcitx. It may be possible to use 'super' instead of 'altGr', but I have the conceptual problem that I don't see 'super' on my keyboard. To make fcitx work with AltGr, I had to patch the code, and my browser won't let me access the fcitx site to report the problem and fix. (I have other issues with fcitx, but not bad enough to make me investigate.) I haven't found a solution for emacs, which works best for me if the system keyboard if an ASCII extension and I use quail for the exotic keyboards. Instead, I have to make an ordinary key into an undead dead key. Thus, my Lanna keyboard ends up using AltGr for an X11 keyboard, '!' as an undead key for emacs, and allows either for repaired fcitx. (KMfL + ibus uses the undead key.)

The X11 keyboard suffers from the problem that one can't use it readily to bring up sequences of character at a single keystroke, e.g. the IPA for a voiceless nasal.

I work with lists of special sequences of characters to input a character - that transfers easily between emacs and M17n. I don't see any advantage with actual dead keys, and they are a problem with longer sequences, such as one would naturally use for big* character sets, like Cuneiform or Middle Egyptian. (Middle Egyptian is working nicely on Andrew Glass's laptop, but as of last month had yet to be published to Windows 10. He apparently felt that Unicode should handle real Egyptian - his demonstration goes right to left, the default for real Egyptian.) Micha Kaplan reported a mechanism for using string to character lists for post-MSKLC Windows, and I will have to look that up to port back to MSKLC. For example, in my XSAMPA-based phonetic keyboard, I use 'underscore', 'F', 'backslash', to enter COMBINING ACUTE-MACRON.

*About a 1000 or so characters. These compress quite nicely with SCSU**, with under 2 bytes per character.
**Well, with my encoder, which works with a one-character lookahead and no statistical record.

[bradrn]

Do MSKLC layouts work on Windows 10? I remember hearing something about MSKLC keyboards failing to install or work properly in the new OS, and Microsoft being uninterested in updating MSKLC to get them to work.

And yeah, it should be fairly easy to translate Conkey to a Linux keyboard layout file.

I’m using Windows 10. They work just fine, for the most part. It’s certainly become less smooth — I have to restart after installation to get Windows to see the new keyboard, and I have to make sure the keyboard is removed from my list of keyboards before uninstalling — but overall it works fine.

Can anyone port it to Linux?

On the other hand, some preliminary research seems to suggest that a Linux keyboard layout is just a text file,

All you have to do is copy one of the files in /usr/share/X11/xkb/symbols/ and edit it appropriately.

That’s what I surmised based on what I read. But it’s nice having confirmation!

(But do you know if this works on all Linux distros? Or just one or two?)

[Kuchigakatai]

If only! AltGr and dead keys don't mix well on Linux.

Dang. And here I was assuming it was straightforward to define AltGr deadkeys on Linux...

I work with lists of special sequences of characters to input a character - that transfers easily between emacs and M17n. I don't see any advantage with actual dead keys, and they are a problem with longer sequences, such as one would naturally use for big* character sets, like Cuneiform or Middle Egyptian. (Middle Egyptian is working nicely on Andrew Glass's laptop, but as of last month had yet to be published to Windows 10. He apparently felt that Unicode should handle real Egyptian - his demonstration goes right to left, the default for real Egyptian.) Micha Kaplan reported a mechanism for using string to character lists for post-MSKLC Windows, and I will have to look that up to port back to MSKLC.

I don't quite understand what you're going on about. Cuneiform and Egyptian are logographies, wouldn't the obvious way to go be full-blown input method editors, i.e. what Chinese and Japanese do? Type "inanna", type a number to chose from a small pop-up list, and get 𒈹.

[bradrn]

I finally managed to create a keyboard layout on Ubuntu! Just a very simple one (remapping q ↔ Q), but now that I know what I’m doing I can start working on Conkey proper.

For future reference, I’ll write down the steps I used (largely based on http://people.uleth.ca/~daniel.odonnell ... n-linuxx11), so I don’t forget them:

1. Define the keyboard layout in /usr/share/X11/xkb/symbols/<keyboard-filename>.
2. Add the following in /usr/share/X11/xkb/evdev.xml:

   Code: Select all

          <layout>
            <configItem>
              <name>keyboard-filename</name>
              <shortDescription>Description 1</shortDescription>
              <description>Description 2</description>
              <languageList>
                 <iso639Id>art</iso639Id>
              </languageList>
            </configItem>
            <variantList/>
          </layout>
   

   It must be added within the <layoutList> section.
3. Run sudo dpkg-reconfigure xkb-data.
4. Log out then back in. The new keyboard should now be available.

[bradrn]

Does anyone have any idea how to get dead keys in a Linux keyboard layout? As mentioned above, I’ve figured out the basics, but there doesn’t seem to be any documentation on how to make dead keys. All I know so far is that one can use dead_acute, dead_grave etc., but I need a little bit more control if I want to port Conkey over.

[Richard W]

Does anyone have any idea how to get dead keys in a Linux keyboard layout? As mentioned above, I’ve figured out the basics, but there doesn’t seem to be any documentation on how to make dead keys. All I know so far is that one can use dead_acute, dead_grave etc., but I need a little bit more control if I want to port Conkey over.

First, let me point out that you are currently talking about X, rather than Linux. There are other schemes in Linux, with frameworks like scim (abandoned?), ibus and fcitx, and interfacing keyboard definitions defined by, amongst others, KMfL and M17n, as well as input methods that include their own interfacing with these frameworks. KMfL relies on the characters formed by a US keyboard, which is rather limiting.

X has explicit dead key characters, but formally it is the responsibility of the application to combine dead kay and following key to make the required character. The combination that should be supported is language-dependent, but fortunately, many applications support them all regardless.

There is also a 'compose' mechanism available for X applications, which seems to require the use of a 'compose' key. I haven't investigated this one, and I don't know how widespread support is amongst applications.