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.)
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?)
Feedback
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
Notes
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.
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.
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:
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? ). 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.
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”?
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.
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.
). Ah, I see. It expects the two-letter codes from ISO 3166-2, not the three letter codes: “c:id:us”