Thanks all for the replies on this matter. Concerning the keyboard side
of the issue, there has been a lot of discussion about unified standards
over the years, but what we end up with is maybe another case of "The
nice thing about standards is that there are so many to choose from."
Within that, there seem to be two main questions addressed by keyboard
creation: production and popular use. It Many keyboards are made with
production in one or maybe a couple of languages in mind - this is in
line with the thinking behind creation of old 8-bit modified fonts. On
the other hand, is the need for keyboard layouts that can be accessed
broadly without the users having to learn new key assignments at each
new device. In terms of philosophy, I'd see common keyboards as more in
line with the intent of Unicode.
In the ideal world, there would be no distinction between keyboards
created with limited/focused production in mind (limited in the sense of
one language in a multilingual society and/or focused on a particular
production need), and keyboards intended to facilitate broad usage. Like
a QWERTY+ or AZERTY+ perhaps? That has not been easy - kind of another
theory of everything problem.
The flexibility of touchpad keyboards in theory gets beyond the
limitations of the physical keyboards - has anyone tried adding a row to
say a QWERY layout, which includes additional characters, rather than
sweating the issues about shoehorning them in other levels or key
sequences? Is that even possible? Still would be helpful to have
standards, but where something is visible, it is easy to use.
On the font side, my impression (a bit dated) is that there is/was a
policy dimension or gap. Back when Unicode was becoming more widely
adopted, there were new computers marketed in Africa without the then
limited repertoire of fonts with extended Latin. Even when these were
included, there are some instances where it is possible that 8-bit fonts
with extended characters were created on machines that already had one
or two Unicode fonts - evidently unbeknownst to the user. So there was,
and always has been, a public education side to this that none of us in
position or interest to do so have been able to address.
In the background one should bring in the issue of whether computer
science students and IT experts in Africa had any introduction to
Unicode. That could be a big missing piece in the equation.
The case of the Chinese publications using modified 8-bit fonts for both
Hausa boko and Chinese pinyin is a specialized one. Given the small
number of people working on both those languages it may be just the
chance outcome of their not being aware that Unicode already had their
needs covered. A specialized keyboard for production of text including
hooked consonants and tone-marked vowels, plus awareness of Unicode
would probably set them on a new course.
Marcel, I would be very interested to know more about what you are
working on wrt Bambara - perhaps offline.
Don
On 5/5/2016 10:35 PM, Marcel Schneider wrote:
On Sat, 30 Apr 2016 13:27:02 -0400, Don Osborn wrote:
If the latter be the case, that would seem to have implications
regarding dissemination of information about Unicode. "If you
standardize it, they will adopt" certainly holds for industry and
well-informed user communities (such as in open source software), but
not necessarily for more localized initiatives. This is not to seek to
assign blame in any way, but rather to point out what seems to be a
persistent issue with long term costs in terms of usability of text in
writing systems as diverse as Bambara, Hausa boko, and Chinese pinyin.
The situation Don describes is challenging the work that is already done and
on-going in Mali, with several keyboard layouts at hand. If widening the range
is really suitable, one might wish to test a couple of other solutions than
already mentioned, that roughly fall into two subsets:
1) Letters on the digits row. Thanks to a kindly shared resource, Iʼm able to
tell that over one dozen Windows layouts—mainly French, as used in Mali, but
also Lithuanian, Czech, Slovak, and Vietnamese, have the digits in the Shift or
AltGr shift states. The latter is the only useful way of mapping letters on
digit keys and becomes handy if the Kana toggle is added, either alone or in
synergy with the Kana modifier instead of AltGr. With all bracketing characters
in group 2 level 1 on the home row and so on, there is enough place to have all
characters for Bambara and French directly accessed.
2) Letters through dead keys. This is the ISO/IEC 9995 way of making more
characters available in additional groups with dead key group selectors
(referred to as remnant modifiers but actually implemented as dead keys). This
is also one way SIL/Tavultesoftʼs layouts work for African and notably for
Malian languages. IME-based keyboarding software may additionally offer a
transparent input experience.
On Mon, 2 May 2016 12:03:58 -0400, Ed Trager wrote:
Also with web applications the "software installation" issue is eliminated.
Remember that while it is easy for technologically savvy folks like members
of this mailing list to install keyboard drivers on any platform we like,
this process is somewhat beyond the reach of many people I know, even when
they are otherwise fairly comfortable using computers.
I canʼt easily believe that people who are comfortable with computers may have
trouble using the widely automatted keyboard layout installation feature,
because Iʼve as well experienced myself as got the opportunity to observe on
other persons I know, that in fact there is some kind of reluctance based on
the belief—call it a myth or an urban legend—that Windows plus preinstalled
software plus MS Office come along with everything any user may need until the
next update. Though informing about Microsoftʼs help to customize the keyboard
is more complicated in that the display is part of the hardware, and the
functioning behind has more of a blackbox.
Being actually working on such a project for the fr-FR locale, Iʼve already got
some ideas for Bambara. I hope it can soon be on-line.
Kind regards,
Marcel
