Gratuit - free for personal use

1.01 (2008/03/29)

Jiten FAQ

Can I change the British flag for the one of my own country?

You should create a 32×32 16 colour icon (.ico) file. Place a rectangle of 32 pixels across and 20 pixels down (leaving 6 rows unused at the top and bottom - these should be set as 'transparent'). In the rectangle, draw your flag.
Then save your flag as myflag.ico within Jiten.

Here is an example flag. The dark green represents the 'transparent' part.

The Canadian flag.

And when set up as 'myflag.ico', the "Language" part of the main window will now look like:

Using the Canadian flag.

To make things easier for you, some library flags are provided within Jiten. There are flags for Australia, Canada, New Zealand, and the United States. Simply rename as appropriate.
New Zealand
United States
United Kingdom


How many words are in the dictionaries?

There are 64,150 Japanese words cross-referenced with 104,694 English words.

This is because many words do not have a 1:1 relationship. If you look up the Japanese word kokoro you will see that it can mean mind or body or spirit, now looking up spirit (exactly) as an English word will give you 43 possible Japanese words that can mean spirit (of which kokoro is ninth).

The master dictionary table contains 71,511 entries.


I wanted to look at the dictionary data, and now Jiten mucks up or crashes, why?

You probably used a text editor that does not fully understand files where lines are not terminated in Windows CRLF format - the Jiten data files are stored according to RISC OS conventions.
You may be able to fix this if you can find an editor that is capable (such as Metapad) and save the file in "Unix text (LF)" format.
If that does not work, or if you do not know how to do this, you would be best to reinstall Jiten.


Is it possible to remove rude words from the dictionary?

No, not without completely rebuilding the main dictionary and the associated references.

However, if you edit the shortcut that loads Jiten to include the command line option -omitrude, then any 'rude' words will be replaced with "- obscenity -". You can still look up rude words, but the definitions will not be shown. This may be desirable in certain situations, such as if using this software in a school.

To edit the shortcut, right-click it. A menu with lots of options will appear. Choose the Properties option at the bottom of the menu.
You will see something like this:

Editing Jiten's properties.

Go to the "Target" and append the text " -omitrude" (as shown). Click on OK.

Now, whenever a rude word is looked up, the definitions will be hidden, like this:

Obscenities not wanted.
Obviously I have blurred out the word I looked up, as well as the Kanji and Romaji - all of which are displayed as normal.

Please note that this only works when starting Jiten from the shortcut that you edit. If you have it as a shortcut on the 'backdrop', you'll need to edit that as well. It isn't foolproof by any means, however I feel that a child smart enough to find and start the program without using the shortcuts (assuming your system policy has not disabled the "Explorer" and "Run" commands) will probably have better things to do than learn how to say rude words in Japanese... after all, you do filter external internet access don't you? ☺


Why can't I type numbers into the search box?

In the writeable text area where you enter what you wish to look for:

Search for writeable icon.
You can only enter letters and spaces. Numbers and punctuation is not permitted.


Where did the dictionary come from?

As credited in the help file:

  • This software
    © 2008 Rick Murray - <heyrick -at- merseymail -dot- com>
    This software was written at home in Brittany, France. I designed the window layouts and fiddled with (Philip's) !Jiten on 2008/03/27. I wrote (my) Jiten on 2008/03/28. I wrote the web page and added some extra 'fluff' on 2008/03/29. ☺
  • The dictionary data table
    This was created by Philip Murray-Pearce from the EDICT file.
    The english.table and romaji.table files were converted from Philip's lookup files; translated into a form that my software can make better use of.
  • Inspiration
    © 1998 Philip Murray-Pearce.
    I examined just enough of his !Jiten program to see how he displayed the Kanji VDU font. The actual implementation of everything is my own code, based upon the behaviour of !Jiten.
    The email address given is <philip.murray-pearce -at- which -dot- net>
    I wanted to contact him about my software but my email was rejected. If this address is valid, or if you know of an up-to-date address, please do get in touch!
  • The EDICT dictionary file
    This is a project coordinated by Jim Breen of the Monash University of Australia. The URL given in Philip's help file (dating from 1998) is
    I have worked with the data provided with Philip's software as I do not have Internet access at home. I will, in time, look to see if the EDICT file has expanded and work on a way to generate the necessary dictionary tables directly from the EDICT originals.
  • The RISC OS VDU Kanji font
    Neither Philip nor myself know the author of this data.


Say I have a later version of !Jiten, how do I update the dictionaries?

The dictionary data was sourced from Philip's !Jiten version 1.01 dated 1998/08/12.

To update, perform the following file copies, noting that Jiten is installed at:

  • C:\Program Files\HeyRick\Jiten
!Jiten filename (RISC OS)   Jiten filename (Windows)
Efsb->K   english.txt
JEDR-TSVt   master.table
Rb->K   romaji.txt

Then delete the files english.table and romaji.table.

When you next start Jiten, it will rebuild the data tables. This process can take two to five minutes, depending on the speed of your computer.
Once this has been done, english.txt and romaji.txt can be removed, they are no longer required.

  • You don't need to copy KanjiFont if it has not changed.
  • It is imperative that you copy the files verbatim. Jiten includes specific support for the RISC OS line termination convention (a single 0x0A byte, unlike the DOS/Windows 0x0A 0x0D pair), so there is no need to attempt to convert the data. In fact, doing so will break all of the references into the master dictionary and it'll all go badly wrong. Just copy the files...


Is it possible to build the data from the EDICT file?

At this time, no. I will look to downloading the EDICT (if it is still around? I don't have Internet at home...) and see what would be required to build the data tables directly from the source material.


Any Easter Eggs?

Of course!

Perhaps the most useful is if you provide the command line option "-mungehepburn".

What this does is attempt to translate the "wordprocessor style" Romaji into a nicer form. Thus meaning that "toukyou" would become "tôkyô" and "se-ra-fuku" would become "sêrâfuku". It is not possible to display the macron (i.e. "tōkyō", if your browser supports it), so a circumflex is used in its place, like this:

Munged Hepburn Romaji.

The translation logic is:

becomes 'â'
becomes 'ê'
becomes 'î'
"o-" or "oo" or "ou"
becomes 'ô'
"u-" or "uu"
becomes 'û'
This list was determined by comparing a source with proper Hepburn markings with various words in the dictionary; sadly the Wiki entry for Hepburn Romanisation does not have a definitive list; therefore if this is incorrect or incomplete, please contact me.

Please note that this munging is a one-way process, you must enter words to search for in the wordprocessor style (i.e. "toukyou" in Japanese, not "tokyo").


I found your info easter egg. Why is the dictionary in memory so much bigger than on disc?

You mean you found this (scaled to save space):

Miscellaneous info.

The reason for the size disparity with the table is that when on disc, string data is stored in ANSI format. That is to say that "cute" is [63][75][74][65].
However when the data is loaded into memory, it is translated into Unicode format. That is to say that "cute" now would be [63][00][75][00][74][00][65][00].

I suppose this might be reasonable, except not only can VisualBasic 5 not display characters outside of the standard code page (i.e. characters 32 to 255), it also communicates with Windows using the ANSI versions of the API so all of the strings, internally held as Unicode, need to be munged into ANSI versions before getting Windows to do anything.

Between you and me, I think this bogosity is because VB went Unicode a long time before Windows did. Only a small subset of functions are Unicode on WIN32 (that is, Windows 95, 98(SE), and ME). In that era, extended languages such as Japanese were represented with DBCS (double-byte character string). It wasn't until XP hit the mass market that a properly Unicode-aware version of Windows was available.
This doesn't help us though, as while XP is Unicode and VB is Unicode, the interface between the two is strictly ANSI. It has to be that way, else it'd all go wrong on older versions of Windows...

Copyright © 2008 Richard Murray