Direct answer
A static offline dictionary is a data product with a browser delivery lifecycle, not automatically a neural translation system. Decide whether the experience returns a reviewed word or phrase entry, morphology information, a phrasebook match, or an optional model-generated suggestion. Label those outputs differently. A dictionary lookup can be deterministic for an exact key and still be incomplete for inflected forms, compounds, transliteration, dialects, or ambiguous senses. A local model fallback does not turn missing dictionary entries into verified translations. Start by defining the licensed dataset and its structure. Each entry needs a stable identifier, source and target language tags, direction, headword, senses, usage labels, morphology or inflection links when available, source attribution, data version, and update date. Preserve the original editorial wording where the license requires it; do not silently normalize away diacritics, script distinctions, or explanatory notes. Record the dataset license and attribution requirements separately from the application code license. A free-to-access web page is not automatically a dataset with redistribution permission. Browser offline support normally combines a service worker with one or more storage mechanisms. A service worker can intercept eligible requests and coordinate an application shell or data response; Cache Storage stores request/response pairs, while IndexedDB is designed for structured client-side data. Their lifetimes, quota behavior, origin scope, and update semantics differ. Cache entries are not a permanent database and browser storage can be evicted. IndexedDB durability is also subject to browser policy and available space. Treat the browser as the source of local state, not as a guaranteed archive. Use a versioned cache strategy. Install a new application shell under a new cache name, verify that required files are present, then activate it and remove only obsolete caches owned by this application. For large dictionary data, store a manifest with schema version, language direction, record count, file size, and a trusted digest when one is provided. If the server publishes no trusted checksum or signature, say that integrity has not been authenticated; a browser-calculated hash can detect later byte changes only when compared with a value the application already trusts. Updates should not strand a reader halfway through a lookup. Keep the previous usable dataset while downloading a candidate, validate its format and version, then switch the active pointer atomically. If storage is insufficient or the tab closes, retain the old dataset and show a recoverable state. Do not promise that a service worker will complete a long operation while the browser is closed. Provide a clear way to see language packs installed, their versions, and how to remove local files or data. Test the actual published origin over HTTPS because service worker registration requires a secure context, with localhost treated specially for development. Test first visit online, refresh after installation, a new tab after network loss, app-shell versus dictionary-data availability, update interruption, stale-cache cleanup, browser restart, and explicit deletion. Check that language direction and missing-entry states remain clear offline. These checks prove only the tested browser and storage scenario; they do not establish universal browser support, dictionary completeness, or translation quality.
A reader opens a bilingual glossary on a train
A small publisher offers a bilingual glossary as a web app. A reader opens it once while online, then loses connectivity before looking up an inflected word. A new edition is available, but the device may have limited storage and the previous edition must remain usable if the update fails.
Decision
Separate reviewed entries from optional generated suggestions, version the lexical dataset, cache the application shell through a service worker, store structured records using an explicit strategy, and switch only after validation.
Expected outcome
The reader can use the installed glossary offline, see whether a term is exact or unresolved, and retain the last complete dataset if an update is interrupted.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Dictionary and license manifest
- Offline browser fixtures
- Update, cache, and deletion tests
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
- Define entries, language direction, and dataset rights. Choose the exact data source and redistribution permission. Give each record stable identity, language tags, direction, sense, morphology links when available, attribution, schema version, and dataset revision.
- Choose browser storage by responsibility. Use Service Worker and Cache Storage for request/response resources such as the app shell and immutable pack files. Use IndexedDB for structured records or an update index when useful. Document origin scope, expected quota failure, and how each local copy can be removed.
- Install a versioned application shell. Serve the app from HTTPS, register the service worker, cache only named application-owned resources, and make an offline fallback explain which dataset is present. Do not imply that first install works without a prior download.
- Validate and switch dictionary revisions safely. Download the candidate manifest and files without deleting the active pack. Check schema, language direction, record count, file length, and a trusted digest if supplied. Change the active version only after checks pass; otherwise keep the old usable pack.
- Design lookup and uncertainty behavior. Return exact entry matches, inflection suggestions, ambiguous senses, and misses as distinct states. Preserve script, diacritics, and language direction. If an optional local model proposes text, label it as generated and keep it separate from reviewed dictionary content.
- Test offline transitions and user controls. Test installation and update online, then lookup in a fresh tab after network loss, browser restart, and interrupted update. Verify pack version visibility, cache cleanup ownership, and explicit deletion without claiming browser storage is permanent.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every pack has a documented source, redistribution terms, language direction, schema version, and update identity.
- A failed or interrupted update leaves the prior complete pack usable and does not expose a partially written candidate as active.
- Exact entries, ambiguous senses, inflection suggestions, generated suggestions, and missing results are visibly distinct offline states.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Network-only dictionary | Fetch each lookup from a remote endpoint | Can use current server data but does not satisfy offline lookup when connectivity is absent. |
| Service Worker and Cache Storage | Cache application resources and immutable responses | Supports offline request handling but does not make cache permanent or replace structured data management. |
| IndexedDB lexical store | Keep structured entries and update metadata in browser storage | Enables local indexed lookups and controlled revisions while remaining subject to quota, origin, and browser storage policy. |
Failure patterns to prevent
- Calling static lookup neural translation
- Caching mutable latest assets
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- On-device AI architecture overview
- MDN: Caching in Progressive Web Apps
- MDN: CacheStorage API
- MDN: IndexedDB API
- MDN: Service Worker API
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does adding a Service Worker make the dictionary fully offline?
No. The worker can coordinate cached requests, but required application files and data must first be installed successfully. Test each route and dataset after losing the network.
Can Cache Storage be treated as permanent model or dictionary storage?
No. Cache Storage holds request/response data and browser storage may be cleared or evicted. Keep a versioned manifest, handle missing data, and offer a recoverable redownload when online.
If a lookup falls back to a local model, is its answer dictionary-verified?
No. Generated suggestions and reviewed lexical entries are different evidence classes. Label them separately and preserve ambiguity or missing-entry states instead of presenting generated text as an authoritative dictionary entry.