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
- 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.
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
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
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
s:id:<code> will search for keyboards that support script with ISO 15924 code
c:<name> will search for keyboards that support languages used in countries starting with
c:id:<code> will search for keyboards that support languages used in country with ISO 3166 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)
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:
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!
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
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.