reader.dict packages Wiktionary for the devices people actually read on

The packaging target is the whole point

The project describes itself as the most comprehensive universal, multilingual and monolingual dictionaries, made for e-readers, phones, tablets and desktop applications, and powered by Wiktionary. The topic list is where the specificity lives, because it names the formats and the readers the output is aimed at, with Kindle, Kobo, PocketBook, Plato, KOReader and Kindlegen among them, and the dictionary applications GoldenDict and StarDict as well. So the deliverable is not a website and not a library, it is a set of files laid out the way those programs expect to find them. That is a narrower and more useful thing to build than a general dictionary application, and it is also why the repository is a toolchain rather than a product, with the site hosting the downloads and the repository holding the code that produces them.

The dependency list is a Wiktionary parsing pipeline

The runtime requirements read like a description of what the code does. `wikitextparser` at 3.0.0 parses the wiki markup, and alongside it is a direct install of the project's own fork of `wikitextprocessor` from its GitHub branch, which means the wikitext side is not a stock dependency but something the project maintains. `marisa-trie` is a fast static string matching library, which is the structure a dictionary index wants. `jaconv` handles the Japanese character conversion, `Jinja2` templates the output, `scour` sanitises the XML that goes into the dictionary files, and `mistune` is noted as being for reading the DictFile format. `python-idzip` reads the compressed Wiktionary dumps, `requests` fetches things, `rich` and `docopt` handle the command line, and `mediawiki-langcodes` is there for up to date language data, with a comment saying it is required by wikitextprocessor. The result is a pipeline that downloads, parses, indexes, templates and sanitises, and every step is pinned.

The tests have to run in two steps, and some of them need the internet

The development instructions are worth reading closely, because the two step test run is not a quirk of one contributor's machine. The comment in the readme says all tests must be run in two steps to prevent database issues, and the two commands are the doctest pass over the package and the test suite itself. The first runs the doctests inside the package modules, which matters for a project with this much templating, because the doctests are where the rendering functions are pinned down, and the second runs the tests directory. There is a third form for a machine without an internet connection, and it works by excluding the tests marked as needing one:

python -m pytest tests -m "not webtest"

That marker is registered in the project configuration, where the `webtest` marker is described as an internet connection being required for that test, and the warning configuration turns warnings into errors apart from the notice about `imghdr` being removed in Python 3.13. The strictness of the warning handling is a good sign about how the project treats its own output.

The type checker is set to the strict end

The mypy configuration in the project metadata is the strictest thing in the repository, and for a project that mostly transforms text into files, it is the right place to be strict. Untyped definitions are disallowed, as are incomplete definitions and untyped calls, and the configuration adds `disallow_any_generics` with the comment that it restricts dynamic typing a little, and `warn_return_any` for functions that are not declared to return Any. It also warns about redundant casts and about unused ignores and unused configs, which are the checks that stop a type checker from being quietly defeated. Import handling is permissive, with missing imports ignored and imports followed normally, which is a necessary compromise given that a couple of the dependencies are not typed. The ruff configuration is in the same spirit, with a line length of 120, a target of Python 3.13, and the formatting rules set to double quotes and space indentation, with the F, I and U rule sets selected on top of the defaults.

One script is the gate for a pull request

Before submitting a pull request the readme asks you to run the linters and the quality checkers, and the command is a single script, `./check.sh`. That is a small thing, but it is the shape of a well run project, one command that a contributor can run locally and that a CI job can run for them. The script sits at the root next to `add-to-cache.py` and `log-analyzer.py`, the latter two being the practical parts of the pipeline, adding a finished dictionary to a cache and reading the logs of a build. The rest of the root is the usual mixture, an `index.html` for the published site, a `DEBUG.md`, a `server.py`, a `scripts/` directory, the `tests/` directory, and the `wikidict/` package itself, which is the only thing included in the sdist and in the wheel according to the build configuration.

Releases are named after languages

The release list is the part of the repository that tells you what has actually been built. The three releases visible are `lt` for Lithuanian, `ja` for Japanese and `zh` for Chinese, and the dates are the first two in January 2026 and the Chinese one in August 2025. So the releases are per language rather than per version of the software, which makes sense for a project whose artefact is a dictionary in a language and whose cost is proportional to the size of the language's Wiktionary. It also means the software has no versioned releases of its own in the usual sense, and the only way to see what is current is to look at the language tags. The last push to the repository was on 2026-10-18, so the tooling is actively worked on even where a particular language has not been rebuilt for a while.

The data comes from Wiktionary, and that is the licence question

The final point is the one an adopter has to think about. The code in this repository is MIT licensed, and the dictionary content is not, because the content is Wiktionary's and carries its own terms. The repository lists Wiktionary as the source in its own description, and the topics include the dump and the parser, so the pipeline is a converter rather than an author of data. Anyone planning to redistribute a generated dictionary has to deal with that distinction, and the site hosting the downloads is where the terms for the data itself are set out. The contributor list also tells you something about how the project is run, with a mix of code contributions and translation roles, the translation entries being people credited for bringing a language into the set, which is the part of the work that no amount of engineering substitutes for.

Editorial conclusion

reader-dict monolingual suits a reader who wants a dictionary for a language on a device that does not have one, and who is willing to wait for a language build, since the releases are published per language rather than as one universal file. It is a poor fit if you need the dictionary to be current, since a dictionary is a snapshot of a dump and the release dates are the only signal of how stale a given language is, and it is a poor fit if you want to build it yourself without a network, because a web test marker exists for the cases that need one. Before you rely on it, check three things: whether your language has been built at all, since the release list only names a few, how fresh that build is, and the licence of the underlying Wiktionary content, which is separate from the MIT licence of this tooling and is the question that decides whether you can redistribute a dictionary you built from it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. reader-dict/monolingual on GitHub
4. README
5. Releases