Jitendex: an offline Japanese-to-English dictionary you download and update monthly

A dictionary you download instead of a site you visit

Jitendex is a free and openly licensed Japanese-to-English dictionary, and the distinguishing feature it claims over the web applications people already use is not the content but the delivery. The README names Jisho, Jotoba and Lorenzi's Jisho as similar applications, all of which you reach through a browser, and states that Jitendex can be downloaded and used offline in a variety of formats. That difference shows up in practice in three places. A lookup does not need a network round trip, which matters on a train or on a plane. There is no account, and nothing about your reading habits leaves the machine. And the dictionary file is yours, so it can be updated on your schedule and kept alongside other dictionaries in the same reader. The audience is a learner or reader with a Japanese dictionary habit who has already accepted that a browser extension or a dedicated dictionary app is where lookups happen.

Yomitan and MDict as the two supported readers

The formats are named in the README, and they define what the project is. Yomitan is a browser extension for pop-up dictionary lookups, and MDict is a dictionary file format used by a family of mobile and desktop dictionary apps. Both are supported currently, and the repository topics list both, along with Anki and GoldenDict, which points at the wider ecosystem the dictionary files are meant to sit in. The design consequence is that Jitendex is not an application. There is no search box, no interface, no account, and no feature list, because the interface belongs to the reader. That also means the dictionary cannot be judged on its own usability, only on the quality of its entries, its coverage, and the formats it produces, which is a different kind of evaluation from the one most open source projects get.

Monthly publications and where the files come from

Updated versions of Jitendex with new content are published once a month, and the README directs you to the project site, jitendex.org, to learn more and download the dictionary. The monthly cadence is a design decision rather than a limitation of effort, and it is worth understanding what a monthly cycle implies for a study tool. A dictionary file is a snapshot: it does not update itself in the reader, so the file has to be replaced, and a reader may need to re-index it before the new entries are searchable. Anyone building a study workflow around Jitendex therefore has a recurring maintenance step, and the Anki and Yomitan topics in the repository suggest that some users are exporting entries into a spaced repetition deck, which makes a monthly refresh a habit rather than a chore.

The build system rewrite and the warning above it

The repository opens with a warning that the code is under construction and not yet production ready, pointing at the History section. That section explains more than a status banner would. Jitendex began in 2023 and was built with a collection of poorly written Python scripts, which have never been published. Work started in 2025 to rewrite the build system, that work is not finished, and new publications of the dictionary files are still produced using the old system. The new build system is written in C# and is public in this repository, and there are plans for a web application and an API. So there are two codebases in play, and only one of them produces the files you download. That distinction matters for anyone who wants to contribute or self-build: the visible C# sources are the future of the pipeline, and the artefacts currently published are not the output of what you can read here.

The justfile recipes that drive an import cycle

The build is driven by a justfile, and the recipes show the shape of the pipeline. Updating the source data pulls the dictionary archive, checks out its main branch and verifies the commit signature before anything else runs:

edrdg-update:
  git -C Data/edrdg-dictionary-archive pull origin main
  git -C Data/edrdg-dictionary-archive checkout main
  git -C Data/edrdg-dictionary-archive verify-commit HEAD

The same recipe then runs the import projects for JMdict, JMnedict, Kanjidic2 and Tatoeba, followed by the processing steps for JMdict and Tatoeba. Running a single importer is a separate recipe:

jmdict:
  dotnet run -c Release --project Source/Import.JMdict

Every importer and processor is a separate project under Source, which is how a pipeline of that size stays navigable, and the release configuration is passed on the command line rather than baked into a project file. The source data lives in Data as a git submodule, which is why the archive is addressed with a git -C prefix rather than being copied into the tree. The verifying of the commit is the detail that matters most: an upstream archive is a third party input, and a build that checks its signature before importing it is a build that can refuse tampered content.

The home dictionary import and export cycle

One more recipe pair deserves its own reading, because it explains what the project does with content that is not from a public corpus. The home import runs the home importer, and the home export runs the home exporter, and a third recipe runs the two back to back as a cycle:

home-cycle:
  @just home-import
  @just home-export

An import followed by an export in one step is the shape of a pipeline that reads a source of personal entries and writes them back out in a form the dictionary files can use, so a reader's own additions can be merged with the published entries rather than living beside them. The README does not describe the format of those home entries or the merge rules, so this part of the system is the least documented, and the import and export projects are where a curious contributor should start reading. The rest of the repository layout is conventional for a .NET solution: a solution file, shared build properties, Source for the code, Data for the inputs, Libraries for dependencies, and Scripts for helper tooling.

AGPL-3.0, a release line from 2024, and an open plan

The licence is AGPL-3.0, and the COPYING file at the root of the tree is the licence text, so the terms are available to read rather than summarised. For a dictionary, the interesting question is what happens to derived work, and the AGPL is a strong copyleft licence, so anyone who modifies the build and hosts the result has obligations the README does not spell out. The release history is dated. The visible tags are v4.7 on 2024-04-21, v4.6 on 2024-03-24 and v4.5 on 2024-03-17, and the repository is not archived with the last push on 2026-08-21, so the published artefacts and the code have drifted apart. The default branch is named dotnet, which matches the rewrite, and the README mentions plans for a web application and an API. For now, the practical path is the site: download the published file for your reader, and treat the repository as the place where the next generation of the build lives.

Editorial conclusion

Jitendex fits a reader who works offline, in a browser extension or a dictionary app, and who is comfortable downloading a monthly file update rather than opening a website. It does not fit an application that needs a query API today, and the repository's own warning says the rewritten build system is not production ready while published files still come from the old one. Verify first that your reader supports the format you need, Yomitan or MDict, then download a current release from jitendex.org rather than building the dictionaries yourself, and read the History section before you rely on the C# sources.

Frequently asked questions

Official sources

1. Jitendex/Jitendex on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases