AKKHARA: A Generalized Rewrite-based Input Method Editor
for Writing Systems with Medium Complexity
Chenchen Ding, Masao Utiyama, Eiichiro Sumita
Advanced Translation Technology Laboratory,
Advanced Speech Translation Research and Development Promotion Center,
National Institute of Information and Communications Technology
3-5 Hikaridai, Seika-cho, Soraku-gun, Kyoto 619-0289, Japan{chenchen.ding, mutiyama, eiichiro.sumita}@nict.go.jp
Abstract
This paper describes the input method editor
AKKHARA, which has been developed to accommodate writing systems comprising several tens to hundreds of symbols. In particular, it is designed as a general solution for theefficient input of various abugida writing systems used in South and Southeast Asia. As
an engineering realization, AKKHARA accepts
and applies a set of rewrite rules with priorities,
so that alternation, substitution, and normalization of character strings are applied alongside
the keystrokes. Compared with key-character
editors, AKKHARA provides greater flexibility
for Romanization-based rule edition. Compared with input methods developed for Chinese and Japanese, AKKHARA is lightweightand easy to maintain. A version of AKKHARA
for Microsoft Windows has been released1 that
supports Unicode characters with customizable functions for rewrite rule edition.

1

Introduction

Various alphabet writing systems are used to record
a large number of languages around the world.
These alphabet systems use tens of distinguishable
symbols to transcribe phonemes.2 At the other extreme, languages such as Chinese and Japanese
apply logogram systems totally or partially in theirorthographies, whereby thousands of symbols areused to represent morphemes.
This work focuses on a group of syllabic systems
that lies somewhere between the abovementioned
extremes. They are referred to as having medium
complexity in this paper. Compared with logogramsystems, they are still phonetic-based, although acertain redundancy in spelling may be retained to
distinguish morphemes; compared with an alphabet
system, they assign symbols based on syllables
1
https://www2.nict.go.jp/astrec-att/
member/ding/my-akkhara.html
2
Of course, the orthography is affected by many historicalfactors.

rather than on phonemes, and may apply nonlinear
combination schemes to basic/diacritic characters.
Traditionally, these syllabic systems are input by
direct keystrokes treated as common alphabets. Because of the larger symbol set, the keyboard layout
is crowded and one or more alternation keys are
required. However, these systems are not as complex as those used in Chinese or Japanese, wherelanguage-dependent input methods are indispensable. The AKKHARA system developed in this work
provides a general solution for the input of writing
systems having medium complexity.
AKKHARA repeatedly applies rewrite operations
to convert keystrokes into specific character strings.
Therefore, compared with a keyboard layout editor, AKKHARA has more capacity and flexibility inapplying string operations than simply appending
new characters by keystrokes. This is especially
important for writing systems having certain redundancies in their encoding systems, as some complex
combined glyphs can be realized in more than one
way. Thus, rewrite operations can normalize theinput to generate consistently encoded textual data.
The temporary input methods for Chinese andJapanese are generally based on common Romanization systems such as Pinyin and Rōmaji. However, in many languages that do not use the Latin alphabet, there is no consistent Romanization system.
In AKKHARA, the set of rewrite rules is organizedin an editable textual file with a structured format,
enabling users to customize the input method according to their preferences.
In Sec. 2, the linguistic background of writing
systems is introduced. Related work and applications are reviewed in Sec. 3. Section 4 provides
an overview of AKKHARA and Sec. 5 describes therewrite rule edition. Section 6 provides a real example of defining a minimal input method for the
Myanmar script with 133 rules. Section 7 summarizes the conclusions to this study and presents
ideas for future work.

Linguistic Background

Table 1 lists the main types of writing systems usedin the world, with a comparison of the numberof symbols applied. Generally, an analytic phonetic writing system, e.g., a typical alphabet or
abjad system, usually contains around 30 (≈ 101.5 )symbols. This is because the average phonetic inventory among natural languages contains 22 ± 3
consonants (Maddieson, 2013a) and five or six vowels (Maddieson, 2013b). At the other extreme, alogogram system may contain thousands of symbols for daily use. For example, the Table of General Standard Chinese Characters3 contains 8, 105
characters for Chinese, and the List of jōyō kanji4
contains 2,136 characters for Japanese.
Figure 1 compares the character distribution
across different writing systems. The parallel datafrom the Asian Language Treebank (Riza et al.,2016)5 was used. The differences between an alphabet system (English), a mixed syllabic and logogram system (Japanese), and four abugida systems (Myanmar, Khmer, Thai, and Lao) are presented. Clearly, the four abugida systems withmedium complexity share similar features, but differ from the alphabet/logogram systems. Generally,in these medium complexity systems, there are
more commonly used symbols and a longer tailof obscure characters than in a general alphabet
system. However, the complexity is still far fromthat of a logogram system.

3

Related Work and Applications

Popular operating systems (OS) such as Microsoft
Windows (Win) and Macintosh provide keyboard
layouts for various writing systems. Several keyboard layout editors, such as Keyman,6 have beendeveloped for more sophisticated functions on layout editions. These input methods/editors basicallyfocus on the key-character mapping, with extensions to handle contextually dependent keystrokes.
For writing systems using Chinese characters,
the RIME7 input engine has customization functions that allow users to design their own input
3
http://www.gov.cn/gzdt/att/att/site1/
20130819/tygfhzb.pdf
4
https://www.bunka.go.jp/kokugo_
nihongo/sisaku/joho/joho/kijun/naikaku/
pdf/joyokanjihyo_20101130.pdf
5
https://www2.nict.go.jp/astrec-att/
member/mutiyama/ALT/
6
https://keyman.com/
7
https://github.com/rimeTypelogogramphonogram– syllabic– abugida– alphabet– abjad# Symbol> 103

ExampleChinese character

101.5 – 103
101.5 – 103≈ 101.5≈ 101.5

Japanese kana
Devanagari script
Latin script
Arabic script

Table 1: Types of writing systems and the scale of symbols used in them. The abugida/syllabic systems arereferred to as having medium complexity in this paper.
0.0

1.5

3.0

0.0

frequency (logarithmic)

2

-1.0

Japanese(Kana + Kanji)

-2.0
-3.0
-4.0
-5.0
-6.0
-7.0

English(Latin letters)
Lao
Khmer
Thai

Myanmarrank (logarithmic)

Figure 1: Character distribution on Latin letters in English, the kana and kanji in Japanese, and the four
abugida systems of Myanmar, Khmer, Thai, and Lao.

schemes. In particular, this project supports obscure ancient fonts and dialect-based input methods. Regarding the medium complexity scripts ofinterest in this study, the configuration of RIME isexcessively complex.
Ding et al. (2019) proposed an input method
for the Myanmar script that can be formulated by
a complex automaton. Rather than key-charactermapping, the basic idea is the conversion of strings
so that operations such as looped alternation, substitution for combined glyphs, and normalization
for ambiguities and redundancies in the Unicode
can be modeled in a uniform framework. However,this method is only applicable to the specific writing system and the overall automaton is hard-coded.
Essentially, AKKHARA is a generalized extensionof this previous approach.
Prediction based on words, phrases, or even sentences supported by large-scale data is a common
function provided by many Chinese and Japanese
input methods. Ding et al. (2018) investigated anauto-complete method for several abugida systems
that can achieve high accuracy, even with limited
training data. This is a direction for the future development of AKKHARA because it provides a more
extensible platform than a key-character mapper.

4

Overview of AKKHARAAKKHARA can be installed and used as a common
input method editor under Win. It supports multiple input methods, which can be selected from alist. Figure 2 shows the launch screen of AKKHARA,
while Fig. 3 shows an image of the typed and converted strings. For a selected input method, thedetails can be customized and viewed in the interface shown in Fig. 4.
In the background, an input method is organized
in a text file named *.akkhara, where * is thelisted name of the input method. Each line of thefile is organized in the following format.
input ||| output ||| priority ||| status (1)Here, input and output are Unicode strings before and after a rewriting operation. The priority
is generally a non-negative integer, and rules withsmaller values are always applied before rules withlarger values. The priority can also take a valueof −1 for final normalization after all other operations have been conducted. The status takes avalue of 0, 1, or −1. Values of 1 and −1 are flags
for the rules that have been enabled and disabledby the customization, and 0 denotes the basic keycharacter mappings that are always applied. Therefore, the customization label (left of Fig. 4)
lists all the non-zero flagged rules with their status,
and the application label (right of Fig. 4) lists
all the non-negative flagged rules that are used.
As a generalization ofrg
the hard-coded automaton_ 3C 02
in Ding et al. (2019), a set
3C 1B
of rules in the abovemen1B
4D
tioned format actually defines the state transitions in an automaton by the
input and output fields.8 The table here provides
an example of the state-transition from parts ofFigs. 8 and 9 in the appendix of Ding et al. (2019).
Thus, this table can be described by the following rules: r ||| 3C , g ||| 02 , 3C r ||| 1B , and
1B g ||| 4D . The following section provides a brief
overview of rule edition.

5

Rule Edition

5.1

General Issues

Figure 2: Interface to launch AKKHARA. Four scripts
are listed: Khmer, Laos, Myanmar (selected), and Thai.

Figure 3: Input interface. Pressing the Space bar will
input the lower converted Myanmar script. Pressing theEnter key will input the upper original string.

Figure 4: Interface showing details of the selected input method. The left screen shows a customizationin which specific rules are enabled/disabled, while theright screen lists all of the enabled rules.

For the input and output files in a rule, ASCII
characters9 can be directly used; other charactersshould be represented by hexadecimal Unicode.
The rules should be integrated on the basis of increasing values of priority from 0, ending withthose that have a priority of −1. A reboot isrequired to reload an akkhara file after modified.
In the following subsections, typical rule patterns are described. The examples are taken from
Ding et al. (2019). The status of the rules isomitted as this depends on user preference.
5.2

For basic key–character mappings, simple rules canbe described in the following form.

An akkhara file can be created and edited by ageneral text editor such as Notepad under Win.
8

Strictly, priorities are unnecessary if the rules are deliberately edited. As described later, priorities can grouprules that are useful for edition.

Simple Mapping9

k ||| 1000 ||| 0 |||(2)

h ||| 103E ||| 0 |||(3)

K ||| 1001 ||| 0 |||(4)

AKKHARA use the US keyboard layout under Win bydefault. The ASCII characters mean those letters and marks
can be input by direct keystrokes on such a keyboard.

One-to-many mappings can also be assigned.
x ||| 1004 103A ||| 0 |||(5)

Combined with the case of Sec. 5.3, a key forconversion can be used multiple times to input obscure symbols, as shown by the following rules.

For these basic mappings that directly use ASCII
characters, the priority is set to 0, as no otherprior rules will be applied.
5.3

Simple Conversion

Given Rules (2) – (4), adding Rule (6) allows the
input of the character 1001 by two keystrokes, kand h, as well as by the uppercase K.
1000 103E ||| 1001 ||| 1 |||(6)This type of rule is suitable for some characterswith stable digraph Latin transcriptions, such as theuse of the letter h for aspiration in many languages.
In cases where a digraph may cause ambiguities orusers may intentionally disable the conversion, thefollowing rules can be added as a solution.

n ||| 1014 ||| 0 |||(11)

g ||| 1002 ||| 0 |||(12)1014 1002 ||| 1004 ||| 1 |||(13)1004 1002 ||| 100F ||| 1 |||(14)

100F 1002 ||| 104C ||| 1 |||(15)

From Rules (11) – (15), a keystroke of n inputs
1014, and then multiple keystrokes of g successively convert 1004, 100F, and 104C. Note that thepriority values of Rules (13) – (15) can be all
set to 1. Because the rewrite is implemented after
each keystroke, there is no need to distinguish theorder of these rules. When one of them is applied,the previous rewrite has already been completed.
Similar to Rule (8), Rules (16) and (7) preventa keystroke of q from being converted if the very
character 1002 input by g is expected.
200B 1002 ||| 1002 ||| − 1 |||q ||| 200B ||| 0 |||(7)200B 103E ||| 103E ||| − 1 |||(8)Here, q is set as an invisible separator by Rule (7)and the zero width space 200B is deleted byRule (8) as a final normalization with a priorityof −1. The keystrokes k q h then forcibly input
the sequence 1000 103E.10 Section 5.7 discusses
further details about the normalization processing.
5.4

5.5

(9)

103E 103E ||| 101F ||| 1 |||(10)This is similar to the case of Sec. 5.3, but theconversion is implemented by tapping an identical
key. This is suitable for symbols with identical
Latin transcriptions in which one of them is overwhelmingly used in the orthography.

(17)

I ||| 102E ||| 0 |||(18)

102D 102D ||| 102E ||| 1 |||(19)

102E 102D ||| 102D ||| 1 |||(20)

Normalization of Variants

Context-dependent variants of specific symbols areused in some writing systems.11 The following
rules provide a relatively complex example.
p ||| 1015 ||| 1 |||(21)

v ||| 102C ||| 1 |||(22)1015 102C ||| 1015 102B ||| 2 |||(23)1015 1039 1015 102B |||10

The sequence 1000 103E violates the common orthography of Myanmar, which states that it should not appear innormal texts. It is only mentioned here as an example.

i ||| 102D ||| 0 |||Rules (17) – (20) input the two symbols by
keystrokes of i, where 102D is input by an odd
number of times and 102E is input by an even number of times. As a shortcut, 102E can also be input
by an uppercase I.
5.6

H ||| 101F ||| 0 |||Looped Conversion

This kind of conversion is applied to groups of
diacritic symbols. Here, the characters 102D and
102E in Myanmar script are taken as examples.
The two diacritic symbols are generally Romanized
as i, but with different tones.

Conversion by Multiple Keystrokes

In many abugida systems, symbols have dependentand independent forms. For example, the 103E
given by Rule (3) is a dependent form — the corresponding independent form is 101F. By adding
the following rules, a double stroke of h will input
the independent form as well as an uppercase H.

(16)1015 1039 1015 102C ||| 3 |||11

Such as the abandoned Latin letter long s.

(24)

The characters 102B (tall aa) and 102C (aa) arevariants of one diacritic mark. Typically, 102C isused by default, while the tall variant 102B is easierto read in specific combinations. Rule (23) alternates the tall variant after the character 1015 input
by p. However, in the geminated case whereby two
1015 inputs are stacked by the operator character
1039, the default variant will be used, which is realized by Rule (24). Consequently, the priority ofRule (24) must be greater than that of Rule (23).12
In orthographies that preserve historical features,certain obscure variants may only appear in a few
specific words, and these can be organized in therules. As in Rules (23) and (24), specific conversions requiring longer contexts should have a larger
priority value than those general ones requiring
less contextual information.
5.7

Normalization of Encoding

Rules (8) and (16) have been introduced in previous
subsections to avoid potential ambiguities. Moregenerally, rules with a priority of −1 are designed for some non-intuitive combinations/orders
in the encoding system (i.e., Unicode here). Unlike
Sec. 5.6, the normalization in this subsection may
be unnoticed by users.
A crucial case is to use the Backspace key
for deletion during inputting. Because the appending and converting operations are uniform
in AKKHARA, a keystroke of Backspace actually cancels the previous rule application, regardless of the specific operation. Figures 5 (a) and5 (b) provide examples on the deletion of appending and converting operations, respectively. As
an example of this kind of normalization, the order of Myanmar characters 103A and 1037 is notstrictly determined. They are usually normalized
into 1037 103A by an increasing order of the code,
although intuitively, 103A is considered to be partof the preceding character. By Rule (5) and thefollowing Rule (25), the input can be realized asin Fig. 5 (c), which is in accord with our intuition.
Rule (26) performs the final normalization whenescaping the input mode.
J ||| 1037 ||| 0 |||103A 1037 ||| 1037 103A ||| − 1 |||

(25)
(26)

12
For clarity, the priority of Rule (23) is set to 2 here toemphasize that it will be conducted after all common rewrites.

(a)

(b)

(c)

Figure 5: (a) Using k and K to input 1000 and 1001,
with a Backspace keystroke deleting the character
1001. (b) Using k and kh to input two characters andthe Backspace keystroke to cancel the conversion
caused by h. (c) During the input process, 1037 (thelower circle) and 103A (the upper arc) are not normalized, so that a Backspace keystroke deletes the 1037.

6

ExampleIn this section, we provide an example of anakkhara file that realizes the function describedby Ding et al. (2019). For a clear presentation,
the rules are organized in Tables 2, 3, 4, 5, and6, according to their priority of 0, 1, 2, 3, and−1, respectively. By organizing all the rules in theformat of Rule (1) and placing them sequentiallyline-by-line in an akkhara file, the input method
is defined and facilitated by AKKHARA.
Table 2 includes the basic mapping described inSec. 5.2 for two punctuation marks, 10 digits,13
and the 26 lower/uppercase Latin letters. The threeletters a, o, and x have a one-to-many mapping.
Table 3 includes further conversions. The table is divided into three blocks from top to bottom and from left to right. The first block contains simple conversions (mainly by 103E and1002, and also by 103B and 103C), as described inSec. 5.3; the second block contains five conversions
implemented by double keystrokes, as describedin Sec. 5.4; the third group contains looped conversions for five pairs (102D/102E, 102F/1030,
1031/1032, 1038/1037, and 103A/1039), as described in Sec. 5.5. Tables 2 and 3 cover the scheme
proposed in Fig. 4 of Ding et al. (2019).
Tables 4 and 5 are related to normalization forvariants of 102C/102B. Character sequences requiring alternation are listed. This issue was not
explicitly mentioned by Ding et al. (2019); in thispaper, it has been discussed in Sec. 5.6.
Table 6 contains the final normalization rules.
The upper two rules related to 200B have been
mentioned in Sec. 5.3 in terms of cleaning up theinvisible separator to avoid ambiguities. The lower
three rules are related to the Unicode scheme forgenerating the recommended encoding manner.
13

They were not included in Ding et al. (2019).

in.
,
.
0
1
2
3
4
5
6
7
8
9

out.
104A
104B
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049

b
c
d
e
f
g
h
i
in.
a
o
x

1017
1005
1012
1031
103A
1002
103E
102D

in.
j
k
l
m
n
p
q
r
s
t
u
v
w
y
z
A
B
C
D
E

out.
1038
1000
101C
1019
1014
1015
200B
103C
101E
1010
102F
102C
103D
103B
1007

in.
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z

104F
1018
1006
1013
1032
out.
1031 102C
102D 102F
1004 103A

out.
1039
1003
101F
102E
1037
1001
1020
1036
100A
1029
1016
1002
100B
1026
1011
1030
1021
101D
1004
101A
1008

in.
1000 103E
1002 103E
1005 103E
1007 103E
1010 103E
1012 103E
1015 103E
1017 103E
1004 1002
100A 1002
100F 1002
1010 1002
1011 1002
1012 1002
1013 1002
1014 1002
1019 1002
101B 1002
101C 1002
101E 1002
1020 1002
1027 1002
1029 1002
102C 1002

out.
1001
1003
1006
1008
1011
1013
1016
1018
100F
1009
104C
100B
100C
100D
100E
1004
1036
104D
1020
103F
104E
104F
102A
102B

7

Conclusion and Future Work

This paper has described the AKKHARA, a general
input method editor that can accommodate writing
systems of medium complexity. AKKHARA is more
powerful than a key-character mapper, but is simpler than input methods for Chinese and Japanese.
Therefore, AKKHARA is easy to maintain and suitable for realizing customized input methods.
Future developments include: 1) developing
AKKHARA for other OSs besides Win, 2) improving the interface of rule edition, and 3) integrating
corpora for prediction functions.
14
From 1000 to 104F, without 1022, 1028, 1033, 1034,
and 1035.

out.
1023
1024
1025
1026
1027
100A
1029

102C 102C
103B 103B
103C 103C
103D 103D
103E 103E

1021
101A
101B
101D
101F

102D 102D
102E 102D
102F 102F
1030 102F
1031 1031
1032 1031
1038 1038
1037 1038
103A 103A
1039 103A

102E
102D
1030
102F
1032
1031
1037
1038
1039
103A

Table 3: 46 rules of in. ||| out. ||| 1 ||| 0 .

Table 2: 64 rules of in. ||| out. ||| 0 ||| 0 .

In this example, an input method for 75 Unicodecharacters14 are defined by 133 rules. More rules
can be added to accommodate users’ preferences.
Generally, the number of rules can be two or threetimes the number of symbols. In practice, a scaleof 102 – 103 rules is suggested for an akkhara
file to ensure easy edition and maintenance.

in.
102D 1002
102E 1002
102F 1002
1030 1002
1031 1002
1014 103B
101E 103C*
1001 1001 1031
1004 1004 1031
1015 1015 1031
1002 103D
1012 103D

1002 1002 1031
1012 1012 1031
101D 101D 1031
1002 103D 1031
1012 103D 1031

Table 4: 16 rules of ∗ 102C ||| ∗ 102B ||| 2 ||| 1 .

*1015 1039 1015 1015 1039 1015 1031
Table 5: Two rules of ∗ 102B ||| ∗ 102C ||| 3 ||| 1 .

in.
out.
in.
out.
200B 103E 103E 200B 1002 1002
in.
out.
1025 102E
1026
1029 1031 102C 103A
102A
103A 1037
1037 103A
Table 6: Five rules of in. ||| out. ||| − 1 ||| 0 .

References
Chenchen Ding, Masao Utiyama, and Eiichiro Sumita.
2018. Simplified abugidas. In Proceedings of the56th Annual Meeting of the Association for Computational Linguistics (Volume 2: Short Papers),
pages 491–495, Melbourne, Australia. Association
for Computational Linguistics.
Chenchen Ding, Masao Utiyama, and Eiichiro Sumita.
2019. MY-AKKHARA: A Romanization-based
Burmese (Myanmar) input method. In Proceedingsof the 2019 Conference on Empirical Methods in
Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP): System Demonstrations,pages 157–162, Hong Kong, China. Association for
Computational Linguistics.
Ian Maddieson. 2013a. Consonant inventories. In
Matthew S. Dryer and Martin Haspelmath, editors,
The World Atlas of Language Structures Online.
Max Planck Institute for Evolutionary Anthropology, Leipzig.
Ian Maddieson. 2013b. Vowel quality inventories.
In Matthew S. Dryer and Martin Haspelmath, editors, The World Atlas of Language Structures Online. Max Planck Institute for Evolutionary Anthropology, Leipzig.
Hammam Riza, Michael Purwoadi, Teduh Uliniansyah,
Aw Ai Ti, Sharifah Mahani Aljunied, Luong Chi
Mai, Vu Tat Thang, Nguyen Phuong Thai, Rapid
Sun, Vichet Chea, Khin Mar Soe, Khin Thandar
Nwet, Masao Utiyama, and Chenchen Ding. 2016.
Introduction of the asian language treebank. In Proc.
of O-COCOSDA, pages 1–6.