Re: Japanese "onyomi" versus "kunyomi" sort

[Ryan Thompson]

I work at a Japanese software development house, and this is a very common problem which unfortunately cannot be solved programmatically, as kunyomi is inconsistent, with specialized readings for various words and names which use identical kanji.

Generally, the solution I see followed is that a second "kana" field is added to the database, into which the reading (読み方) of the content is entered directly.

Although this often means double the entry keystrokes, this is very common for Japanese applications. For instance, most web site registration or purchasing systems require that users enter their name both in kanji for display, and again in katakana or romaji (latin characters) for sorting or interfacing to non-Japanese systems such as credit card processors or airline reservation systems.

For instance, an application I am currently developing always contains the following columns for all objects which have a name:

name VARCHAR(200) NOT NULL,
name_kana VARCHAR(200) NOT NULL

Order-by statements ignore the name, using name_kana instead. For all other purposes, name_kana is ignored (never displayed) and name column is use instead.

Now, some Japanese data entry systems (notably FileMaker) are intelligent enough to update a kana field from the kanji field interactively, while the user is entering. This saves many keystrokes for the data entry user.