Why is this important? Because for some complex scripts it doesn’t work to have a few extra buttons for special characters. We need the clever keyboard logic to handle reordering or context-sensitive choices. And for Apps that use different scripts, we need to be able to specify a different keyboard for each of those scripts (but SAB currently only offers 1 place to add language specific “keys”).
Of course, there will be people who say,“Just get them to install Keyman and download the appropriate keyboard from there!” - and I would agree that that is the ideal situation; but for users who haven’t even managed to get through secondary school, I think we might be expecting too much. The more we can automate this for them, the more likely it will be used.
SAB 5.1 was just released. Here’s the blurb from the release notes concerning Keyman:
In-app Keyman keyboards (for beta testing)
- You can now integrate Keyman keyboards within your app for use on the Search screen.
- Select a keyboard to use on the book collection > Styles tab.
- Current limitations: choosing a mix of Keyman and system keyboards will not work well. Add Note screen keyboard not supported yet.
Thanks to the developers for adding this functionality. I’ve tried it out, but unsuccessfully so far:
I’ve only managed to make an App that crashes on startup.
I am guessing that I’ve picked up the wrong file. Can someone tell me WHICH file I need to add from the Keyman Developer’s build folder?
The .js file contains code like this:
Also, I’m curious to find out how SAB ties each (different) keyboard to the right Book Collection - especially when there are multiple Book Collections - each one requiring a different keyboard. It isn’t clear in this dialogue which one of these fields will make that connection:
Aha - I can now see where to “connect” these. BUT it still isn’t working for me.
Some might reply: surely the user already has a keyboard installed for their language, but …
Many of the languages we’re publishing Scripture in do not exist as interface languages for Android (or iOS). So the user will have their Android set to display in an LWC (language of wider communication), and only be using their mother tongue in the SAB app.
Maybe this is obvious, since SAB is so popular for minority languages, but I thought I’d state it clearly anyway.
Actually, where I work, we have an intermediate situation: the Android interface is available in Tajik, but even those who don’t know the LWC – Russian – all that well, still prefer to have their Android OS in Russian. I haven’t seen a single person who uses the Tajik interface! The reason for this is always stated thus: “I can’t understand the technical terms in Tajik.”
Tajik has not had, until recently, any technical terms of its own, and has simply used Russian loanwords. But official Tajik translations are these days expected (by the government and by academics) to be “pure”, basically meaning free from Russian loanwords. In practice, that means that the technical terms are just replaced by Arabic loanwords (the irony!), and few people understand these. To see the Russian technical terms that they’re familiar with, their only option is to have everything in Russian.
This also means that the Russian interface has huge inertia: if you chose the Tajik interface, and asked your friend for help in, say, changing a mobile network setting, the friend’s first action would be to change the interface to Russian. So you’re out on a limb if you try to use Tajik Android.
It has been quite a while since I asked this question, and I haven’t heard back from anyone who has managed to use this relatively new feature. I have just tried again and almost gave up when I realized what was wrong… I was trying to build the app “offline” and SAB/Gradle needed to download some other libraries to make this feature work. On the 3rd attempt, and after all the extra bits were downloaded, I was finally able to get the test app (with a .js Keyman keyboard) built and installed.
So, now, when a user hits the search button, they get a fully functional Keyman keyboard instead of some oddly arrange “buttons” as well as the system keyboard. Yay! @richard - It would be nice to be able to have this keyboard appear when the user adds a Note as well. Maybe that’s still in the pipeline.
or in portrait mode, like this:
For anyone who wants the details of what needs to be in place, here are a couple of screenshots:
And then link it to a collection like this:
The beauty of this set-up is that you can include MULTIPLE keyboards in the same app - so that each Book Collection (in a different script) gets its own appropriate keyboard. Very nice!