Looking for testers: keyboard search refresh

Introducing the refreshed keyboard search

With the next version of Keyman, we are rebuilding the keyboard search to make it hopefully simpler and smoother to use! We’ve just finished the first iteration of the changes and are looking from feedback from you, our users, on the usability of the search.

At present, the search is available on our staging website. The exact same search will be embedded in all the Keyman apps on all platforms, replacing the existing long scrolling lists on mobile platforms and Windows, and upgrading the experience on macOS and Linux. (KeymanWeb will be handled separately.)

Test the Keyboard Search Online

You can test the search at: https://keyman-staging.com/keyboards

Try searching for keyboards, languages, countries, scripts, other things. What do you naturally search for when looking for a keyboard? (Try searching for a language’s localised name – not just in English?)


We’re looking for feedback on:

  • Relevance of search results
  • Erroneous results
  • Ease of searching
  • Potential confusion or pain points
  • Presentation of results – clarity, missing information, too much information?
  • If you see something else, don’t hold back :wink:


  • This new search returns only keyboard results – there is no longer any drilling down through languages or regions. We believe this is simpler to understand, more like a Google search; what do you think?
  • You can search for keyboard names and identifiers, languages, scripts, countries and even text from the description of the keyboard.
  • The list of popular keyboards is buried under a link at present but may be added to the starting page if we all think that’s a good idea.
  • Monthly download numbers are only partial – they only include some downloads at present, but do give an indication of relative popularity.
  • This search does not yet link to the custom home pages (e.g. https://keyman.com/amharic)
  • The keyboard detail pages are still undergoing development to support deep links for simpler installation of Keyman + keyboard.
  • The staging site may occasionally be unavailable when we are doing updates.

Advanced searches

These are fun for techy types.

  • k:<name> will search only against keyboard data and not language, country or script.
  • k:id:<keyboard_id> will search for only keyboards with identifiers that start with <keyboard_id>.
  • legacy:<id> will return the keyboard with the matching legacy integer identifier (this is used for forwarded links from the old tavultesoft site).
  • l:<name> will search for keyboards that support language <name>.
  • l:id:<bcp47> will search for keyboards that support language with that BCP 47 tag (normalization of tags is performed, so similar tags will match).
  • s:<name> will search for keyboards that support script <name>.
  • s:id:<code> will search for keyboards that support script with ISO 15924 code <code>.
  • c:<name> will search for keyboards that support languages used in countries starting with <name>.
  • c:id:<code> will search for keyboards that support languages used in country with ISO 3166 code <code>.

Searching for “Greek” brings up 4 pages of keyboard entries, with the final 2+ pages being obsolete ones. Would you consider making the default to suppress obsolete keyboards? Perhaps with a “Show obsolete keyboards” link at the end of the non-obsolete ones?

@drowe, that’s a good idea. I am considering removing obsolete (i.e. deprecated) keyboards from the default search altogether – they’d be listed as a separate search under the ‘Older Versions’ link in Downloads. Behind the scenes, it would just load the same search page with an “obsolete” flag set for searching.

I can’t see a reason for the obsolete keyboards to be visible by default – the reason they are obsolete is that they have been replaced with a newer keyboard. We keep them really only for very special cases!

FWIW, the reason they are visible now is that the old mechanism of hiding/showing as part of the default search doesn’t work well with paged results; removing them altogether from the default search avoids this issue.

There’s another category that’s even worse than the deprecated ones.

We put “(obsolete non-Unicode)” in the title of the keyboard_info file

    "name": "Tepehuan (obsolete non-Unicode)",
    "description": "For historical research. This is a non-Unicode compliant keyboard. (Keyboard and font package for entering the Tepehuan language of Mexico \nin modified roman or phonetic script.)",

I think those could be weeded out of the search too.

Tepehuan (obsolete non-Unicode)

1 Like

Yep. I think non-Unicode keyboards can be placed in the same category as deprecated keyboards. This is now on the list to address before release.

It’s great that one can search for the keyboard using their language, but can one search for country name in in their language. As of now, searching for “កម្ពុជា/ប្រទេស​កម្ពុជា” (Cambodia/Cambodia country) does not return anything.

Some users may naturally add a word or two after the language name when looking for a keyboard of their choosing, i.e. language or keyboard. Right now, when searching for “Khmer language” and “Khmer keyboard” does not return anything.

Pagination is interesting because it shows this when the result is null:

1 Like

Thanks for the feedback @makara. We’ll add localised country names in a future update (we’d need a new data source for it, potentially CLDR, which is a significant effort).

On your second and third points:

  • I have added a note to strip out generic words such as “language” and “keyboard”.
  • I’ll skip the “page 1 of 0” when there are no results!
  • The search currently only finds languages that start with the search term. Previously it also listed languages that contained that term. Searching for “German” now shows all keyboards for the German language, but not “German, Pennsylvania” that it showed previously. Searching for “Pennsylvania Dutch” shows the expected results, but searching just for “Dutch” shows only keyboards for Dutch, but not Pennsylvania Dutch.

  • if search finds a match I can’t extend the search to include a space - the space at the end gets removed. I can paste from the clipboard, then it searches with space (e.g. “german pe”) and finds “EuroLatin (SIL) (German, Pennsylvania language)”, but I can’t type it.

  • Searching for “Amish” (that previously showed language “German, Pennsylvania (Amish Pennsylvania German)”) has 0 results.

  • It’s not possible to search for language code (unless you use l:id:code)

  • Searching for “usa” shows keyboards for Usakade language, but not keyboards used in the USA.

  • Searching for “c:id:usa” has 0 results (don’t they use keyboards anymore? :slight_smile: ). Ah, I see. It expects the two-letter codes from ISO 3166-2, not the three letter codes: “c:id:us”

  • Searching for “c:usa” has 0 results. Has to use “c:united states” (and if I’m slower to type than the search to find results then I can’t type that because it strips the space)

  • Searching for “swa” shows keyboards for several languages that start with “swa”. However, it doesn’t show “EuroLatin (SIL)” for Swabian; Swabian keyboards appear under obsolete keyboards. Searching for “swab” shows the EuroLatin one as well.

  • The display of results when searching for localized language name is awkward: “EuroLatin (SIL)(Deutsch language)”. Putting the language first would be better: “EuroLatin (SIL)(language: Deutsch)”

  • Searching for “l:id:ydd” shows results for BCP 47 tag ‘yi’ - which might be correct but is a bit surprising. “l:id:yi” shows same results (old search didn’t find anything for l:id:yi). Searching for “l:id:yih” shows results for BCP tag ‘yih’.

  • Searching for “yiddis” shows “Yiddish Pasekh”. Searching for “yiddish” shows “Yiddish Pasekh (Yiddish language)”. Searching for “yiddish p” shows “Yiddish Pasekh” again.

  • The old search listed languages and countries related to the search term which I find helpful.

1 Like

Just found a bug:

Searching for “German” shows “EuroLatin (SIL) (German language)” as expected. However, the bcp47 tag in the link is wrong: pdt instead of de (https://staging-keyman-com.azurewebsites.net/keyboards/sil_euro_latin?bcp47=pdt)

When searching for ipa, why does IPATotal show up first (with 82 monthly downloads) and IPA (SIL) only second? Especially since I did the search on Linux where IPATotal is not supported. I would have expected IPA (SIL) to show up first.

Also, why does “Tepehuan (obsolete non-Unicode)” show up third instead of under “Obsolete keyboards”?

That was discussed earlier in the thread :slight_smile:

I’ve now added your comments, @EberhardBeilharz, to the tracking issue (#87).

I was trying to query for a recently added sil_nko keyboard for the N’Ko language

My query l:n’ko gives a list of 7 Keyboards for languages matching ‘n’ko’ but sil_nko isn’t one of them.

The keyboard page

does list N’Ko (l:id:nqo) as one of the supported languages

Sorry if this is resurrecting a dead thread. I’m interested in searching for a particular character/unicode value. With some minority languages, it’s not always clear which keyboard will best support the characters that they need.

Alternatively, a way to bulk download all of the keyboards so that I can search the ldml files locally would be great.

Hi @JDWood, welcome to the community!

Currently, we don’t have a way of searching the keyboards by character repertoire. We do have some internal tooling that can identify the full repertoire but we haven’t yet integrated that into the search.

You can download the source for the keyboards by cloning the source repository at GitHub - keymanapp/keyboards: Open Source Keyman keyboards. Note that the keyboards are not in LDML format – they use the Keyman .kmn keyboard format.

And, also sometimes the keyboard source uses the glyph itself and sometimes USV (U+00xx) format so you have to be able to search both forms.