Mobile phone dictionaries

I am down in Adelaide at the moment delivering the Kaurna electronic dictionaries we’ve been working on to the Kaurna Warra Pintyandi group. We’ve produced a Kirrkirr Kaurna dictionary and a mobile phone Kaurna dictionary, based on the work of the 19th century German missionaries Christian Teichelmann and Clamor Schürmann. Both dictionaries were well received. The mobile phone dictionary seemed to be particularly well received by the young people, but I guess we can really appreciate these things. I’ve put up a demonstration version of the dictionary for download so that a wider audience can try it out. I’ve also put up information about how the dictionary works and provided the source code and instructions on how to port other dictionaries into the program.

Mobile phones that can run third-party application software are very common today and people who have these phones carry them almost everywhere they go. In Aboriginal families in particular mobile phones are probably more common than computers. With the recent closure of the CDMA network in Australia, people living in remote areas have had to upgrade to 3G phones, which definitely have the features and capacity required for the mobile phone dictionary software. Speakers with the dictionary on their mobile phones can use it for tasks such as checking the spelling of words when they’re texting. The inclusion of sound means that they can check their understanding of the orthography by comparing the sound they hear with the spelling provided in the dictionary.
The work of many people has gone in getting the electronic dictionaries ready. The work of course started way back in the early 19th century with the efforts of Teichelmann and Schürmann. The team who worked on the most recent project (funded by the former DCITA) was made up of Jane Simpson, Aidan Wilson, Fiona Blake and James McElvenny in Sydney and Jack Buckskin and Rob Amery in Adelaide. The Sydney team did the work of preparing the written dictionary content and the Adelaide team made the sound recordings for the dictionary. Aidan Wilson will be giving a presentation on the work on the Kaurna dictionary at AUSTRALEX in Wellington this November (if our abstract is accepted).
Work continues on the mobile phone dictionary software. We are currently working with the Dharug language revitalisation group to port their electronic dictionary with sounds into mobile phone format. We’re keen to help anyone else out with porting their dictionary to mobile phones. The information below should be enough to get more tech-savvy people going. I do realise, though, that the information will not be enough for many people who are interested. If you have a marked-up electronic dictionary that you want to port, contact me at james.mcelvenny followed by the at sign and then gmail.com and I’ll see if I can do the conversion for you.

How the mobile phone dictionary works

The software that we’ve developed for the Kaurna electronic dictionary is written in Java ME (Micro Edition), a version of the Java platform that runs on devices with low levels of computing power, such as mobile phones. The application consists of a very small Java program and text and audio resource files that store the dictionary content. The text files describe the menu structure for navigating around the dictionary and the written content of entries. The sound files contain sounds associated with entries that can be played back on the phone.
The menus for navigating around the dictionary are set out in the menu files in the ‘res/dic’ directory (the file format for menus and entries is described below). The Kaurna dictionary is set up with a menu system that first asks the user whether they want to search the dictionary by Kaurna headword or by English gloss. It then presents an intermediate menu where the user selects the first two letters of the word they are looking for. Finally, they are given a list of words that begin with those two letters. Selecting an item on this menu takes them to the actual entry. If the entry has sound, it can be played by pressing the play button. The user can navigate back up through the menu structure using the back button. We decided to put in the intermediate menu to divide the entries in the dictionary into smaller groups. If the entries weren’t divided into smaller groups, the user would have to scroll through a very long list to find entries in the middle of the dictionary.
The current user interface for the dictionary MIDlet is not particularly attractive, unless you have a love for phone settings menus. The current interface does have a few advantages, though. It is built solely on the interface classes provided in the standard MIDP library. This means that the dictionary MIDlet should run on any phone that supports Java ME. The MIDlet itself does not need to contain complex code for creating the user interface, which makes it more compact. The menu interfaces should also appear like the other menu interfaces on the phone and so their operation should be familiar to the user. Nonetheless, designing a better user interface should be one of the top priorities for the next version of the dictionary application.
The content of the dictionary is stored on the phone rather than being delivered online through WAP or some other protocol. Storing the content on the phone means that users do not have to pay fees to a carrier to access content over a network and that the content of the dictionary is available even when the phone is out of range of a network signal. A problem with storing the content on the phone is that the amount that can be stored is limited by the size of the phone’s memory. Some phones also have arbitrary restrictions on the size of jar files. My phone, a Nokia 6150, cannot run jar files over 1MB in size. The complete Kaurna dictionary, with 2085 entries plus index files and 281 unique sounds, comes in at 1.9 MB when compressed into a jar. This will run on most phones that I have tested it on. Only my phone and one other fairly old Nokia refused to run it. The problems with size restrictions should fall away as phones become exponentially super-duper.
Another possible problem with storing the content in the phone is that to upgrade the content a new version of the dictionary jar file must be downloaded to the phone. I don’t think this is really a major problem, though.

How to install the mobile phone dictionary

The following instructions describe how to install the Kaurna mobile phone dictionary on a mobile phone.

1. Download the zip archive containing the files for the dictionary by clicking on this link. This is a demonstration version of the Kaurna dictionary. It contains the complete application but only a small part of the content of the full Kaurna dictionary. The Kaurna Warra Pintyandi group has given permission for me to release the content of this demonstration version of the dictionary to the public.
2. Unzip the archive. It should expand into the files DictionaryMIDlet.jar and DictionaryMIDlet.jad. The DictionaryMIDlet.jar contains the actual application and dictionary content. The DictionaryMIDlet.jad file contains a description of the jar file. It is required to install the jar file on some mobile phones. Nokia phones always want a jad file. The jad file was rejected by the only SonyEricsson phone the application has been tested on. The SonyEricsson phone still allowed the jar to be installed without the jad.
3. Copy the DictionaryMIDlet.jar and DictionaryMIDlet.jad files to your mobile phone. Depending on what facilities are to hand, this could be done over a Bluetooth connection, over a USB connection or by storing the files on a removable memory card.
4. Find the jar and jad files on the phone and install them. Some phones will automatically install the files and others will have to be asked to install them.
5. Go to the directory where the MIDlet has been installed on the phone and run it. It may takes a second or two to load.

How to prepare a dictionary for use with the software

If you have an electronic dictionary already marked up in a machine-readable format, it is a trivial matter to convert it into a format that can be used by the mobile phone dictionary application and compile a version of the application containing your dictionary. I converted the files used in the Kaurna mobile phone dictionary into the right format from an XML master file using a nonce script (as in a nonce usage). The source code and demonstration content for the dictionary application is available here. To use your own dictionary with this code, replace the resource files in the ‘res’ directory with your own resource files, make sure that the constants that specify the starting menu name and the maximum menu depth are set correctly and compile the dictionary.
The procedure for compiling the application is not entirely straightforward. The application requires the Java ME libraries and will not compile in a Java SE development environment (Java SE is the version of Java that is used on microcomputers). I believe that a Java ME development environment can be set up on Windows and Linux systems by using the Wireless Toolkit from Sun. Sun does not produce this toolkit for the Mac platform, however. It is necessary to piece together your own development environment on a Mac. There is lots of advice on how to do this on the web. The two articles that I found the most helpful were probably J2ME development on OS X revisited and Do-it-yourself midp on OS X (which is fairly old).
The source code bundle downloadable from here contains an ant build script ‘build.xml’ in the directory ‘build’. If you read this script you can see what steps are required in building the application and what libraries and tools are required. You can modify this script so that the paths to the tools are right for your system and then use it to build the application. Note that this script copies a jad file for use with the jar file it produces into the ‘dist’ directory but it does not actually make sure that the jad file matches the jar. At the very least the ‘MIDlet-Jar-Size’ field in the jad will have to be set. If you want to change the program icon or program name, you will have to modify the relevant fields in the jad file.
Dictionary entries and menus are stored as plain text files in the directory ‘res/dic’. The name of each file is used as the name of the menu or entry that it describes. Inside the file every line must start with a numeral. The numerals are mark-up that indicates what type of data is being stored on that line. Immediately following the numeral is the data. The line is terminated with a carriage return. The last line with content in the file should be terminated with two carriage returns.
The meanings of the numerals used to mark up data are described in detail below. In addition to this description, it may be helpful to examine the files for the Kaurna dictionary to see how they are structured.
Mark-up codes
1 – Text of a menu item
2 – Text of a menu item referring to an entry with sound
3 – Name of target file
4 – Part of speech
5 – Gloss or definition
6 – Name of linked sound file
If a file starts with data or type 1 or 2 its contents will be rendered as a menu. Data types 1 and 2 represent the text of menu items. Type 1 can be any type of menu item, whereas type 2 should only be used to link to dictionary entries with sound. Type 1 menu items are rendered as text and type 2 items are rendered as text with a preceding speaker icon. For example, if the dictionary program encounters the line ‘1bidna’, it will create a menu item ‘bidna’ that links to the file ‘bidna’. If the user selects this menu item, the dictionary program will then try to open the file ‘bidna’ and either construct a menu or an entry from it, depending on the type of data on the first line. If the dictionary program encounters the line ‘2bidna’, it will create a menu item ‘bidna’ where the text is preceded by a speaker icon. Apart from this difference in display, the two menu items will work the same way.
Lines of data of type 1 and type 2 can be immediately followed by data of type 3. Type 3 data is the name of the file to link to from a menu item if the name of the file is different from the displayed text of the menu item. For example, in a bilingual reverse index there may be the type 2 data ‘2charcoal’, which would be rendered as a menu item with the text ‘charcoal’ and a preceding speaker icon. This should not link to a file called ‘charcoal’, however. It should link to the file ‘bidna’. Underneath the line ‘2charcoal’ there should be the line ‘3bidna’. This will cause the dictionary program to open the file ‘bidna’ when the ‘charcoal’ menu item is selected. If type 3 data is used in a menu file, it must be used after every type 1 or type 2 line of data. It is not possible to have a file that has type 3 data for some menu items and not others. This decision was made to simplify the code of the dictionary application. I felt it was OK to do this because if a file uses type 3 data it is likely to do so for every item.
The content of a file that does not start with data of types 1 or 2 is rendered as an entry. Entries should contain data of types 4, 5 and 6. Data types 4 and 5 are rendered as plain text in the body of entries. They are not treated differently by the dictionary program, but are marked up differently to recognise the different nature of their content. Data of type 6 is not displayed in an entry, but if it is present, a play button appears in an entry. When the play button is pressed, the sound file that is referred to by the type 6 data is played.
Sound files are stored in mp3 format in the Kaurna dictionary. It is possible to store the sound in any format as long as the format is supported for playback on the target phone. If a different format for the sound is used, the MIME type in the line in the code where the sound player is created would have to be modified to reflect the change in format.

Follow