wudict (1)

Queries the selected dictionaries concurrently and streams one line per dictionary as it finishes. Lines arrive in completion order, never in slot order: each hit carries i, its index in the begin line's slots array.

A dictionary that fails, that cannot serve the requested mode, or that was declined by the memory cap reports that on its own line. None of those is a request failure, and the other dictionaries still answer.

A search is cancelled after 30 seconds.

Answers 204 with the extension grant. The extension's own requests are CORS-simple and never preflight; this exists so a future one does not meet a 405 that explains nothing.

begin carries the total immediately, from registry ids alone, so a client can show "0 of 105" before any dictionary is opened. Rows follow in completion order.

Images, stylesheets, scripts and audio, as the article references them.

path is the whole remainder of the URL and may contain slashes, which an OpenAPI path parameter cannot express: send it unencoded, exactly as the article asks for it.

Speex audio is transcoded to WAV and answered as audio/wav. A .spx that cannot be transcoded, or one supplied in a res/ override folder, is answered raw as audio/ogg. Files from a res/ folder are served uncached, so an edit takes effect on reload.

The contract of the running build, served by it.

Reads the dictionary folders again, warms the registry, and then answers exactly as /api/dicts does. Use it after adding files on disk.

Brings one dictionary to the feature state you ask for, streaming Server-Sent Events:

event: progress   data: {"done":N,"total":M}
event: done       data: {…a /api/dicts row…}
event: error      data: {"error":"…"}

Each switch is a state, not a verb: a parameter you leave out keeps whatever that feature is now, so toggling one thing cannot strip another. Progress is emitted at most every 200 ms.

Everything in the library folder, whether or not it is currently enrolled. Listing is not consent: reading this never adds anything to the registry.

Removes the prepared folder, the original files, or both. Both default to on, which is "remove this dictionary".

Irreversible. Files are unlinked, not moved to a Trash or Recycle Bin, and nothing here can be undone.

From the machine running wudict this is always allowed - it is your library and your disk. From a browser on another machine it follows ALLOW_REMOTE_DELETE (default off); with that off, the remote caller gets a 403 and canDelete: false in GET /api/config.

One row per language, merging the published catalogue (LEMMA_URL) with what is present in LEMMA_DIR, plus the state of any download running right now. Always answers 200: what is installed is the half of the answer that needs no network, and an unreachable catalogue is reported in error rather than by failing.

Starts a download and returns at once; follow it with GET /api/lemmas. The download runs in the server, not in this request, so it survives the page being reloaded, closed, or rotated away on Android.

The catalogue is never taken from the caller: only the configured LEMMA_URL is fetched. A second call for a language already downloading joins the running download instead of starting another.

On success the language is searchable immediately - no restart, because the lemma folder is re-indexed in place.

Removes every file in LEMMA_DIR supplying this language, not only the one in use, and re-indexes the folder. Deleting English falls back to the pack compiled into the binary rather than losing the language. Unlike dictionary removal this is offered on every platform: these are files wudict downloaded, not files the user brought.

Drives the first-run page. Without save it only reports what the folder holds, which is what live typing needs. With save=1 it switches the registry over and writes DICT_DIR. Repeat path for several folders; found is then the deduplicated total across all of them, because overlapping folders must not be counted twice.

What the panel's folders section shows, including which layer set DICT_DIR - so the page can say that saving will not take effect, rather than silently doing nothing.

Healed against the dictionaries that exist right now. exists is false on a first run, which is the client's cue to adopt what an older build left in localStorage, once, instead of starting the user over.

Array order is the user's order. Entries record the path as well as the id, because ids are derived from the path: moving a dictionary folder changes every id at once, and the path is what re-attaches the state instead of resetting it. Body is capped at 1 MiB.

Two CSS files the user owns, applied to everything wuDict renders. app styles the page itself - its colours, its own layout - and its :root custom properties reach articles too, because they inherit across the shadow boundary. article styles what dictionaries render, in both article flavours (shadow root and sandboxed iframe).

The split is what keeps body{}, p{} and a{} - written with articles in mind - from also restyling the chrome.

dir is where the two files live on disk, beside the wudict.toml in effect, so they can be edited with an ordinary text editor as well; writable is false when there is no config directory at all, and the editor says so instead of failing to save.

Omit a field to leave that file untouched: absent and empty are different, and the App tab and the Article tab are one editor sending different bodies. An empty string REMOVES the file, so "I cleared the box" and "there is a file here containing nothing" do not become two states that behave the same but read differently.

Each file is capped at 256 KiB. A stylesheet that hides the app can be stepped around with GET /?style=off, which omits it.

Files the user uploaded so that something they wrote can reference them by URL: an image for a background-image in their custom CSS, a font for an @font-face, an imported stylesheet, a script, a PDF a private dictionary links to. They live beside the two stylesheets, in an assets folder under the same directory GET /api/style reports, and are served from /files/<name>.

No type restriction: the store is "files the page can reach by URL", and an extension allowlist would only mean the feature is missing for whoever needed the entry it lacks. limits is reported rather than assumed, so a client's message about a refused upload cannot drift from the rule that refused it.

The request body is the file itself, raw - there is one file per request and no other field, so multipart would add a parser to carry nothing. The name comes from name, and is one path segment of A-Z a-z 0-9 . _ - starting with a letter or digit, at most 64 characters; it is an allowlist, not a cleaning pass, so nothing here can name a path.

Uploading onto an existing name is refused with 409 unless replace=1: a silent overwrite is the one mistake this endpoint can make that the user cannot undo, because their stylesheet already points at that name.

Removing what is not there is a success: the caller asked for it to be gone and it is. Nothing checks whether a stylesheet still references the name - that is the caller's warning to give, before it asks.

Selecting a dictionary is a statement that it is about to be searched, so its headword index is prepared at once rather than waiting for the first query to discover it is missing. On a large dictionary that first query would otherwise have to search the source format directly, which is what the search budget is too short for.

The request returns as soon as the work is queued; the ingest outlives it. Progress is not reported here - a client learns the dictionary is ready from /api/dicts, where dbSize becomes non-zero.

Idempotent: repeated selection of the same dictionary neither queues a second ingest nor restarts a running one, and a failed preparation is retried only after a cooldown. Does nothing when AUTO_INDEX is off, where preparation is the dictionary panel's job; the response then reports indexing: false.

Same-origin only. It is not part of the client API a browser extension reaches (D69): it starts work and writes to the user's library folder.

The dictionary's own annotation: the publisher's blurb, the edition, the copyright. Composed from the live sidecar beside the source file where the format ships one (Lingvo's <stem>.ann) and otherwise from the description its header declared, then normalised server-side - plain text escaped, markup reduced to prose elements - so a client renders html as-is and needs no sanitiser of its own.

Same-origin only. It is not part of the client API a browser extension reaches (D69): an annotation names a file on the user's disk. It is also deliberately absent from /api/dicts, which is built without opening any dictionary; this endpoint is fetched lazily, per dictionary.

Loopback only, and limited to the paths this app already displays: a remote browser must not open a window on someone else's desktop, and an arbitrary path must never reach the shell.

How the Android shell tells the server what the platform just told it - onStop, onTrimMemory, thermal throttling, battery saver - which an exec'd server has no other way of learning.

active is normal. background stops all indexing and closes every handle that can be reopened, while prepared databases stay open so returning is instant. restricted closes those too, leaving the process holding nothing but its listener.

Loopback only, and POST because it changes state: a GET here would be followed by every link prefetcher on the network.