Category: Kotoba

Well, I think we can safely say we have reached our first milestone with Kotoba: importation of JMDict.  Yeah!  We now have over 130,000 Japanese words with some 220,000 definitions for English alone, not to mention French, German, and Russian definitions.  We have not even begun to really delve into what Kotoba is all about, though: learning a new language!  Stay tuned as we bring on phase II, III, and more!

What is a dictionary if you cannot discover relationships between words?  Well, not much in my opinion.  In order to better let to find related words, Kotoba now supports cross-references between words.  Ultimately, this allows you to better discover relationships (e.g. antonyms, synonyms, et cetera) between words which better help to delve into the nuances of words.

A natural consequence of managing many-to-many relationships is the need to provide usable controls to select items.  With the JMdict alone we will have 130,000 Japanese entries that can be added to any number of vocabulary lists.  While Rails provides a drop-down list, having all 130,000 is not only usable, it will more than likely crash your web browser the moment you click on it: not the user-experience we are seeking.

Our solution is this problem is to leverage Lance Levy‘s excellcent RecordSelect.  This project provides a fully AJAX’d solution to showing any number of entries in a searchable way.  While the current RecordSelect is not out-of-the-box suitable for use with ActiveScaffold, a little of tender love eventually got the two working together.  At this point, integration is nominally complete albeit there is still room for greater usability.  However, I believe we have a great start to ensuring that you can manage your vocabulary lists easily.

For those not familiar with the term CRUD, it stands for “create”, “retrieve” “update” and “delete”.  Basically, these are the four (4) basic operations you ever need to do to maintain information.

After a bit of struggling to understand Rails support of many-to-many relationships, whether it is with HABTM (Has And Belongs to Many) or HMT (Has Many Through) as they intersect with ActiveScaffold, I finally was able to determine a reasonable approach to supporting editable many-to-many relationships.

For those interested, HABTM supports only weak entities.  This can be, in the majority of cases, all that you really need when tracking a many-to-many relationship; however, there appears to be some consensus that HABTM and weak entities are a Bad Thing.  Frankly, while I think some people’s positions are over-stated on the matter of HABTM, it is true that there is some niceness when using with HMT over HABTM.  As previously stated, HABTM are weak which means they have no state of their own.  The use of HTM (strong entity vis-a-vis join table) allows you to track not just the relationship, but the state of the relationship between the two entities; itself a good thing if you need this.

Ultimately I decided that I wanted to use HTM throughout Kotoba to keep things consistent and provide insurance against future growth.  Unfortunately, ActiveScaffold’s support for HTM is only read-only while HABTM is fully editable right out of the box.  And unfortunate in that I really want to be able to add words to vocabulary lists, and vocabulary lists to words in a manner that is intuitive and usable.   That said, I needed a means of updating the vocabulary_lists_words join directly from either vocabulary lists or words.  Luckily the wonderful developers of ActiveScaffold include some necessary call-backs (e.g. before_update_save) at the controller level very similar in vein to ActiveRecord’s before_ methods.  

What does this mean to you?  You can now manage your vocabulary list’s words directly from the vocabulary list.  And equally cool, you can just add a word to your vocabulary list as you find them.

Internationalization, aka I18n for those l33t (elite) readers out there, is the process of removing any specific language references from your application.  Typically this is accomplished in its simplest form with a simple map of key, value pairs for each target language and/or region.  

Once this step is complete, the next phase is to localize (L10n) the application.  While internationalizing an application removes all assumptions about a human language, localizing an application is ironically enough the opposite; namely, re-inserting human language and/or region specific requirements back into application albeit in a extensible fashion.

Why all this rather esoteric dribble about I18n and L10n?  As of Rails 2.2.2, internationalization is a part of the base configuration.  While you can still use such gems as gettext either directly or as the backend to Rails implementation, using Rails implementation is a great way to get started immediately.  Which means it is possible to more easily add any number of languages to your Rails application.

Which is a lot of write up to say this: as of today I have included a first pass at internationalizing Kotoba.  I still have work to do with messages, some less-used views, and emails; however, at present the application supports both English and 日本語.  You can change your preferred language under Preferences.  Give it a shot and tell me what you think.