I finally managed one critical simplification that enabled me to complete the database model. Today, I released a new version of my kanji quiz program that used a database instead of flat files, resulting in a huge speed improvement and increased flexibility.
So, what was my simplification? Avoiding radicals altogether.
Well, okay, I didn’t go quite that far. What I did was ignored any kanji composition information that didn’t consist only of other kanji. So the kanji for “time” still shows, when you run the program, that it’s made up of “sun” and “temple”. But anything with the “grass radical” doesn’t have composition information any more.
An unfortunate simplification, to be sure, but one that I think was necessary for me to get a release finished in any reasonable time period. In the near future, I hope to revisit that decision and figure out some way of enabling non-kanji radical information to be present and displayed. First, though, I think I’ll write a tool that allows editing and revising of that information—already I’ve noticed some inaccuracies in the current kanji-only data that I have.
To make up for this reduction in information, however, I’ve added a new feature: kanji compound words. Now, when viewing kanji information, you can click a button and get a list of all “edict” words that contain that particular kanji. This really helps memorization—more so, I think, even than the radical information.
For example, the word for photograph—”sha-shi-n”—is made up of two characters that I didn’t know before. The characters themselves are not used very often in isolation, so it’s difficult to remember their basic meaning. But when I remember that they’re part of “photograph”, I easily recall the readings and a basic idea of what each means.
So, what’s next on my plate? Enabling the user to select different kanji lists, rather than being stuck on the two hard-coded JLPT lists. Maybe after that I’ll get bored and move on to the next project …
Entries (RSS)