Talk:OLPC Amharic Keyboard

There has been some questions as to why the typing in the Amharic XO keyboard is reverse of normal. I sent a mail on this, which should explain the issue:

Hi,
I thought I would explain the issues we are having with the Amharic
keyboard in details, so that interested people in the techteam are
aware of what is happening. (please note that the design and the
decisions with respect to the Ethiopian keyboard was taken much before
I came into the scene, and there might be even better reasons for
going with the current system, which I am not aware of)

Each symbol in the Amharic script is a consonant vowel combination.
For example, the Amharic equivalent of 'r' has nine forms, depending
on the vowel that combines with it. The table below shows the various
forms, and the first row has the vowel modifier which is applied to
get the corresponding form. In case you are wondering, 'ə' represents
the reduced vowel 'a' (as in 'above'), and ɨ represents the reduced
vowel 'e' (as in 'business')

ə     u         i       a       e      ɨ       o        wa   jə
ረ       ሩ       ሪ       ራ       ሬ       ር       ሮ       ሯ       ፘ

Now let us try to figure out how we can get this written on a normal
qwerty keyboard with our existing XKB based keyboard input framework.

Option 1: Use of the "Multi Key"
This lets us write in the requisite order: The user has to press
something called a "multi key" (which can be, and is usually mapped to
the right Alt key), then press the sequence r, u to get the character
on the second column (ሩ). However, in that case, almost each and every
character will have to be written using the Multi key being pressed.
This means the user will have to type in a really awkward way (imagine
having no caps lock and trying to type a whole school assignment in
all caps). Not a nice option.

Option 2: Using the correct phonetic way
This is the ideal solution. The compose tables are created such that r
followed by u will give ሩ. However, in our current input method, the
first item in a compose table entry is  automatically treated as a
dead character or a modifier (which means it cannot have an
independent existence). However, the problem in such a situation, that
according to our keyboard, 'r' is already mapped to ረ. Which means as
a result, ረ becomes a dead character abd ceases to have an independent
existence, and you cannot type it in unless a vowel follows it. So
doing this is not possible.

Option 3: Reversing the order
If you look at the Ethiopian keyboard layout at
http://wiki.laptop.org/images/8/8f/Ethiopic-B3.png, you will notice
that the vowels (and a few others) are left blank in the Ethiopian
mode. This means that we do not need them to produce anything useful
(as standalone keys) while in Ethiopian mode. So, the solution that
was adopted involved treating the vowels as modifiers [1], and hence
we have the compose mapping where the vowels come first. Thus the
reverse order. In fact, this is how it is done in upstream Xorg as
well.


So, how does SCIM become useful here ? Among various other things,
SCIM has the ability to look at the characters surrounding a
particular character to decide the ultimate form of a character. So if
ረ is followed by u, it will replace ረ by ሩ. However, if ረ is followed
by ለ (the equivalent of 'l+ə'), ረ is kept unchanged.

Hopefully I managed to explain the situation without too much
confusion ;-). This also underlines the fact why we should really move
to SCIM in 9.1. As I have said before we hit almost the limits of what
we can achieve with XKB with Amharic, and it would be impossible to
handle even more complicated scripts unless we shift to SCIM (or any
equivalent).

Thanks,
Sayamindu


[1] This messed up our English keyboard (as Compose tables are loaded
on the basis of locales), and vowels on the English keyboard stopped
working. As a result, we have had to do even more hacks to get the
keyboard working properly, and I'm currently interacting with the
upstream Xorg developers on how to handle this properly.