šŸ—ŗ Keyman Roadmap - March 2020

My Bad!
I am hope I can assist with some simple tasks.

1 Like

We are having a team meeting in October where we will be discussing our roadmap. I will make sure we talk about how we can highlight issues that would be good for anyone outside the core team to tackle :slight_smile:

1 Like

We are starting to identify issues where other developers could help with the ā€œhelp wantedā€ tag in the source repository.

1 Like

We are delivering a fully-internationalized Keyman across Windows, macOS, Android and iOS in version 14.

Is support for external keyboards on iOS in the works or planned? Given the nacent pervasiveness of physical keyboards with iPads these feels essential.

@tgerdin, currently Apple do not make it possible for 3rd party system keyboards such as Keyman to interface with external keyboards on iOS. If and when they do make this possible, weā€™re ready to implement (as we have done on Android, already, several years ago).

Oh, that is indeed a pity! I would expect this to become possible, but where on Appleā€™s roadmap this lies is a different question. The nuisance of a closed platformā€¦

@tgerdin Indeed. Iā€™d encourage you to let Apple know that you want this via feedbackassistant.apple.com. The more users who flag this with Apple, the better.

My comment on the predictive text part of the roadmap which includes improved corrections and common optimisations is this:

For many languages and our language it doesnā€™t make sense to have the option on the left side to select what you have already typed as the word. It wastes space which could have another suggestion. Spacebar should in most languages at least perform that function.

Being able to identify in the tsv file what types of words can take what types of prefixes and in our languageā€™s case clitic pronouns would allow for prediction of at least suffixes, but also better predictions on verbs, nouns, or whatever should follow.

Maybe a long press on a word suggest or on a root suggestion that could bring up derivations of words and let the user choose the word they want could speed up typing of languages where there is quite a bit of affixation. When all your verbs start with a few prefixes, but the middle of the word is what makes the difference, it will be hard for prediction software to be useful until after 3 or 4 letters are already typed.

Maybe even a prefix picker menu could speed things up.

Hunspell has at least been barking up this tree for more than a decade and Fieldworks grammar data can be used to help with word prediction.

Many languages will require specific greetings to be the way you open up a text message. Having those float to the top of suggestions for a new text would be useful. Things like Hola, Assalam Alaykum, Good Evening. These type of message openers could be designated in a TSV file.

Thanks @Luke ā€“ those are good thoughts around optimisations. I think most of the more interactive ones will probably have to wait until v15 but weā€™ll definitely be referring to your suggestions when we do the improvements we have scheduled for v14 as well.

Keyman Messenger
I was considering how Android mobile phone vendors like Samsung make it next to impossible to install your own fonts. Then how fortunate it is that the Keyman editor app can work with a bundled font, and wouldnā€™t it be great if the app had a ā€œSendā€ button? :grinning:

So, a wish list item for the next Roadmap would be to launch a ā€œKeyman Messengerā€ companion application. Thereā€™s likely a cross platform OpenSource messenger app out there that could be built upon to get started.

Weā€™d love to do something like this but itā€™s outside the capacity of the Keyman team to take it on. The good news is that with Keyman Engine for Android, any Android developer should be able to integrate Keyman into a messenger-style app, if you can find someone whoā€™d be interested in putting it together!

Thanks @Marc , I may suggest it for a senior project or perhaps to someone looking for a Google Summer of Code project. If this actually happens and a volunteer makes an initial version, could the Keyman team maintain it?

Iā€™d like to be able to say ā€˜yesā€™, but I donā€™t think we can commit to that. Maintenance of projects is expensive and we are already stretched too thin maintaining Keyman as it is :frowning:

Good information thanks for sharing

Keyman 14 will be released in a few weeks with full localization (except macOS which we were unable to finish this release, sadly). You can localize now at https://translate.keyman.com/ and if you get the translation in soon, it will make it into the release.

A consideration for the roadmap -KeymanTV! One of the few remaining places where I cannot yet use keyman is when I try to search on my television for a video. Iā€™m thinking here of most any modern TV in the last decade that is network enabled and supports apps for YouTube and the like where the user must resort back to English based searches.

Samsung and LG are big vendors that have TV operating systems based on Android. Similarly, Amazonā€™s Firestick, and Roku are Android based (guessing a bit) and Apple TV is probably iOS or macOS based, which are already supported by Keyman.

A difficulty here is of course installation. Some of these platforms also will have app stores for distribution. The Keyman team would have to work with these vendors in any event, possibly this opens a door for a commercial licensing opportunity with these vendors that may also be in want of a multilingual typing solution.

Thanks for the suggestion @dyacob! I think this is a good candidate for our LDML keyboard project. If we are generating keyboards that match an open standard there is a bigger incentive for TV developers to use them.

1 Like

To quote Dire Straits (featuring Sting): ā€œI want my, I want my, KMTVā€¦ā€

(my whole life has been leading to this moment :slight_smile: )

1 Like

:laughing: :laughing: