Closed mcdurdin closed 5 years ago
For Android, 1 set of keyboard files gets installed in packages/packageID/
All the associated languages in the keyboard get added
It's good to know the files aren't duplicated, but is this intended operation to show several language instances of the same keyboard? At the least, it is inconsistent with Desktop. Would presenting a chooser/checkbox interface of languages in the package be reasonable?
The intent is to install for use only the first language in the package. Others will be available in the Add Keyboard languages menu for addition if needed.
This matches Keyman Desktop behaviour.
This use-case is for installing keyboards from a local package.
If we have this issue change iOS / Android to only use the first listed language in the package, we'd still need a new UI to follow Desktop's "Add Keyboard languages" menu.
Can’t we just merge the entries from a kmp with the existing list sourced from cloud?
If you show the whole list (cloud+package), won't the user get lost in a sea of languages when they just installed a few in a package. It seems best to only show the package's languages at install time.
If you show the whole list (cloud+package), won't the user get lost in a sea of languages when they just installed a few in a package. It seems best to only show the package's languages at install time.
Yes, I agree long term we need to improve the keyboard and language management on mobile devices (and on desktop devices also). However, the status quo is a long list of (or, sea of) languages, and most people seem to be working with that. For version 11, we won't be able to add the UI to split out the language management per-package.
We need to do a proper design round on this rather than patching, taking into account the various methods of keyboard distribution, etc. The addition of predictive text in v12 will add another variable which needs to be managed.
So for now, to at least make sure that the keyboard is available to be installed against any language in the package by merging the package language list with the cloud language list, at least we have a pathway, even if it isn't ideal.
For the scope of 11.0 we'll change local kmp installation:
Splitting this issue into a separate one for Android.
@darcywong00 Thanks, that sounds consistent with Desktop.
Note: the best way to undo this test is to uninstall Keyman! (warning before doing the below)
To reproduce (I'm sure you know this already, but it's for my benefit):
For the scope of 11.0 we'll change local kmp installation:
- Install the first listed language for each keyboard in the package.
- Merge the language/keyboard info with the cloud catalog so the user can select a different language for the keyboard.
The second part of the issue will be tracked in #1613
I believe that installing a multilingual keyboard on iOS from a local package installs a copy of the keyboard for every language. I don't know if this is true for Android.
Originally posted by @erros84 in https://github.com/keymanapp/keyman/issues/1456#issuecomment-449023757