Aictionary: a dictionary that is a local file, not a service

The dictionary is a SQLite file you download once

Aictionary describes itself as a fast and unusually useful English-Chinese dictionary app focused on the small matter of looking words up, and the first line of the feature description is the architecture.

Looking up a word returns immediately from a local database, and the README says the database holds more than eighty thousand learner-oriented Chinese definitions that explain usage, context and common collocations, rather than just handing over a meaning. The database is a local SQLite file, downloaded once, and every query after that happens on the machine, so the app keeps working with the network off.

That single decision shapes everything else. A lookup is a local database read, which is why the app is fast, and a lookup needs no account, no key and no round trip, which is why it works offline and why the privacy story is simple. The upstream project that builds the data is separate, the open-dictionary repository, and it is built on a snapshot of Wiktionary and Wiktextract with the explanations written by a language model. The current count is 84,212 entries.

The distribution mechanism is equally plain. The application downloads the database from a GitHub release as a compressed file, verifies it, and unpacks it, and the only mandatory step after installation is opening the dictionary settings and letting that download happen. The language model endpoint is optional, and the README is clear that without it the application is a complete offline dictionary on its own.

The data belongs to the upstream project, not to this application, and the README says so directly, that this app is a consumer of it, and that questions about the build pipeline, the word selection rules and the quality of the definitions belong upstream. That separation is worth noting because it tells you where to file what.

The word that is not in the database is the interesting case

A dictionary with eighty thousand entries still meets words it does not have, and the README names the cases explicitly: rare words, technical terms and newly coined internet slang.

For those, the application can ask a language model to write an entry on the spot, and the requirement is only that you configure an OpenAI compatible endpoint. The generated entry is written into your personal dictionary, and the README points out that it survives a re-download of the main database, so the work you did to explain an obscure term is not thrown away when the upstream data is refreshed.

That is a clean separation of concerns between the two data sources, and it is the same idea the frequency data uses later. The shared dictionary is a shared artefact that everybody gets, and anything specific to your work or your machine lives in your own store, where the application merges the two at lookup time.

The implementation detail that makes the fallback possible is in the package manifest, where the OpenAI provider package from the AI SDK is a runtime dependency, and the acknowledgements name the AI SDK among the projects the application is built on. Since the endpoint is OpenAI compatible, the same setting works with a range of providers rather than one vendor.

The privacy angle is spelled out too. The API keys are stored on the device and are sent only to the provider you selected, and the README states that they are not sent to the application's developers.

Four speech providers, and a network story worth reading

The text to speech section is a small table of four providers, and the default is the interesting choice.

Edge TTS is the default and needs no key at all, because it is Microsoft's Edge reading service, and the README describes it as free, zero configuration, with a choice of voices. If you want a better voice, you can switch to Fish Audio, which supports models and lets you fill in a reference id to use a cloned voice, to OpenAI's text to speech interface, or to ElevenLabs.

Generated audio is cached locally, with the cache path given as an example on macOS, so the same word is only synthesised once. Combined with the local dictionary, that means a word you have looked up twice never touches the network again.

The network note is the part that tells you the project has been used in difficult environments. Some networks reset the websocket connection that Edge TTS relies on, and the settings have a network section where a proxy can be configured. On the desktop the app reads the environment variables and the system proxy settings automatically, while on Android and iOS you fill it in by hand. If your proxy uses a custom certificate authority, the same page accepts a PEM certificate, and it applies to the language model calls, the dictionary download, the Anki integration and the speech requests. One more detail: the automatic update of the application itself keeps using the system certificate store rather than the custom certificate.

That is a small, well-specified set of behaviours, and it is the difference between an app that works for its author and one that works on the network a user actually has.

Anki cards, frequency data, and the small conveniences

The remaining features are the ones that decide whether a dictionary becomes a habit.

The Anki integration is the most substantial of them. It depends on the community's AnkiConnect plugin, so Anki has to be running with that plugin enabled, and the settings hold the API address, which defaults to the local AnkiConnect port, the deck name, which is created if it does not exist, and the card template. Each saved card contains the word, the phonetic transcription, the definition, the word forms, detailed example sentences and a comparison of the senses, and the application adds its own tag to the card.

Then there is the frequency data, which comes from a separate English corpus database and shows a Zipf score and the number of occurrences per million words, which is the number that tells you whether a word is common or academic. The lookup history and the frequency statistics together mean the words you looked up most often are a ready-made review list.

The conveniences are the usual set for this kind of application, and they are the ones the README lists first. Typing letters suggests words from the local database, with the up and down keys to pick one and Return to look it up. A global hotkey summons the application and looks up whatever is in the clipboard, so reading English text does not require touching the mouse. And a tray icon, or the keyboard shortcut, opens a small lookup window that floats above the current application and disappears when you click elsewhere.

The window behaviour is what makes it usable while you work, and it is the reason the application is a desktop application rather than a web page, even though the interface is built with web technologies.

The code is MIT and the data is not

The licensing section is the most consequential part of the README, and it is split into three rows.

The code of the upstream dictionary and of this project is MIT. The upstream dictionary data is CC BY-SA 4.0, as a derivative work of Wiktionary content. And the built-in English frequency data is also CC BY-SA 4.0, taken from the wordfreq project at version 3.1.1 by Robyn Speer, with the full attribution and provenance kept in a separate database and a data note in the source tree.

The README then states the consequence in plain terms. The data is distributed under the share-alike terms, so redistributing it or making derivative works requires publishing under the same licence and keeping the attribution and licence information for the corresponding data sources.

That is worth internalising before you build anything on top of it. A team that wants to ship a modified word list, or a web service built on the database, or a bundled offline copy inside another product, is in the share-alike regime for that data, while the application code around it stays MIT. The attribution requirement is not a formality either, since the provenance is kept in a database of its own and the README points at it.

For a personal application the obligations are trivial. For anything distributed, they are the first thing to check with whoever owns the licensing at your organisation.

A React and Tauri application with a release pipeline for every platform

The build section describes a modern desktop application, and the stack explains the platform list.

The front end is React 19 with Vite, Tailwind version 4 and the shadcn component set, while the desktop shell and the back end are Tauri 2 in Rust. The Tauri plugins in the package manifest show what the shell does: the autostart plugin for launching with the system, the clipboard manager for the lookup hotkey, the global shortcut plugin, the dialog and opener plugins, and a process plugin.

The development commands use bun, and the Tauri prerequisites are Node.js or bun plus a stable Rust toolchain, with the webkit libraries needed on Linux as well:

bun install
bun tauri dev
bun tauri build

The build output lands in the bundle directory of the Rust target. The Android build additionally needs the Android SDK and NDK and JDK 21, and it is a separate command:

bun tauri android build --apk

The release plumbing is described next. GitHub Actions builds the desktop platforms and a signed Android package when a tag is pushed and uploads them to the releases, and the iOS signing, upload and external testing flow is documented separately in the repository. The macOS package is signed with an Apple Developer ID and notarised, with the ticket attached to the application and to the disk image, so a user does not have to run anything in a terminal to get past the quarantine check, and the architecture is chosen per machine, arm64 for Apple silicon and x86-64 for Intel.

The releases themselves are frequent, with versions 3.3.1, 3.4.0 and 3.5.0 landing within a month, and the iOS build was still waiting for Apple's external testing review at the time of writing, which is a reasonable description of where a cross-platform project of this size is.

Editorial conclusion

Adopt Aictionary if you read English on a desktop and want a dictionary that works without a network, that explains usage and collocations rather than listing bare meanings, and that can feed your Anki collection. Do not adopt it expecting the bundled data to be free of obligations, because the upstream dictionary data and the frequency data are both published under CC BY-SA 4.0 while only the code is MIT, and a derivative work has to keep the same licence and the attribution. Before you redistribute anything built on it, read the data licensing section in the README, and if you use the language model fallback, remember that entries it writes land in your personal dictionary and are stored locally on your machine.

Frequently asked questions

Official sources

1. ahpxex/Aictionary on GitHub
2. Issues
3. License: MIT
4. README
5. Releases