Your pages get sent to a model, and the default endpoint is baked into the build

The default endpoint is a vendor URL and the key is a placeholder

The example environment file is four lines long and it decides where your reading goes. The endpoint is a Volcengine Ark chat completions address on a Beijing region host, the key is the literal string xxxxx, the model is named doubao-1-5-lite-32k-250115, and the temperature is 0.2. So the project does not ship an AI service of its own, and it does not make you choose a provider before it will run: it ships pointed at one vendor, with a blank key for you to fill in.

Two details matter more than they look. The temperature of 0.2 is low, which suits translation work where the same input should give the same output. And the variable names carry the VITE_ prefix, which is the convention for values compiled into a client bundle at build time rather than read at runtime, so these defaults end up inside the built extension instead of in a settings screen. A second provider is available: the dependency list includes Google's generative AI SDK, so the endpoint and model are configuration rather than a hard requirement.

Language detection, vocabulary selection and translation all run on a model

The feature list is where the data flow becomes explicit, and there is no step in it that happens locally. Source language detection is described as automatic AI identification with no need to specify a language by hand. Vocabulary selection is described as using AI large language models to analyse page content and pick words suited to the level set. Translation is the output of that same pipeline. Phonetics come from a dictionary API with a 24 hour cache, and speech comes from Youdao text to speech with the Web Speech API as a fallback.

What the user controls is amount, not destination. The translation ratio runs from 1 to 100 percent on a character based calculation, paragraph length caps how much text goes into one request, lazy loading means paragraphs are only processed when scrolled to, and trigger mode can be automatic on page load or manual. None of the visible controls is a per-site exclusion, and the documentation does not describe what is transmitted beyond page text, nor whether a whole page can be held back from the model. That is the question to answer before installing it on a machine you also read private documents on.

Eighteen languages are named, twenty are claimed, and the project adds a caveat

The multi-language line claims 20 or more languages and then names eighteen: English, Japanese, Korean, French, German, Spanish, Russian, Italian, Portuguese, Dutch, Swedish, Norwegian, Danish, Finnish, Polish, Czech, Turkish and Greek, after which the list ends with etc. The gap between the claim and the enumeration is small and the etc. covers it, so this is not a discrepancy worth alarm. The caveat attached to the same line is more interesting, because it comes from the project itself: the support theoretically depends on the capabilities of the AI model.

That single phrase moves the responsibility for language coverage from the extension to the endpoint. A language missing from the eighteen would still be attempted, and what happens next depends on the model behind the key the user pasted in. One more detail is worth knowing before choosing a target language: AI definitions are generated in Chinese specifically, described as real-time AI-generated Chinese definitions with contextual analysis, so a learner of Greek or Turkish reads its glosses in Chinese rather than in the language being studied.

Safari gets a zip script but no build script and no store listing

The script list covers three browsers and two modes with uneven coverage. Chrome has build, zip in production mode and zip in development mode. Firefox has the same three plus a dedicated dev script that sets the browser target. Safari has two scripts, both of them zip, one per mode. There is no dev:safari and no build:safari, so a Safari developer has no fast loop at all, and zip:all, which builds the production bundles for all three targets, covers only the production side of each.

The store links tell the same story with a gap. The documentation links a Chrome Web Store listing and a Firefox Add-ons listing and nothing else, while the Firefox address is the zh-CN localised page with a percent-encoded Chinese title rather than the locale-neutral one. So there is an install path for two of the three targets the build scripts produce. A Safari user has to build and sign the bundle themselves, and this repository does not describe how.

Badge links point at main while the default branch is master

The banner at the top of the documentation links a licence file at a path beginning with blob/main, and the same main path appears in the issues and releases badges and in the contributor and star badges. The repository's default branch is master, not main. So the most-clicked links in the project's own front page are written against a branch name that is not the one the project uses, and whether they resolve at all depends on whether a main branch exists as well.

The rest of the front page is in better shape. There is a language switch line pointing at README_ZH.md, and that file is in the tree, so the Chinese version is maintained alongside the English one. The showcase section below it is built from HTML blocks whose captions promise a complete demo, theme adaptation and multi-language scenarios. Those blocks are where the images were, and what remains in the text is the captions alone, so the showcase currently documents three promises rather than three features.

The manifest is private and its description field is still a template

package.json marks the package private and gives its description as the string manifest.json description, which is what a template leaves behind when nobody fills it in. Together those two facts settle the distribution question: the project is not published to a registry, which is why the documentation offers store installs and nothing else, and why there is no npm install line anywhere in it.

The rest of the manifest is more conventional. The package is named illa-helper, declares ES modules, compiles type checking with vue-tsc in no-emit mode, and runs eslint and prettier with a flat config and a CommonJS prettier file. The runtime dependency list is where the oddity sits: cors and dotenv are listed as runtime dependencies of what is a browser extension, and dotenv is a library whose job is reading a .env file from disk, which an extension in a browser has no use for. Vue 3, vue-i18n and Tailwind 4 through the Vite plugin sit alongside a component kit, and components.json at the root is the configuration file that installs it.

One regression entry point, and a check command that edits your tree

Testing here is a single command. test:regression runs vite-node over scripts/regression-main.mjs, reaching into node_modules to do it, and there is no unit test script beside it, so whatever that one file covers is the whole automated surface. Type checking is separate, as vue-tsc in no-emit mode. What is missing is a statement anywhere about what the regression script asserts.

The other entry points are worth reading for their side effects. check runs format and then lint:fix, so the command meant to verify a change rewrites your files instead of only reporting on them. prepare runs husky, so installing dependencies writes git hooks into the clone. postinstall runs wxt prepare, which generates the .wxt directory the framework needs before any dev or build command runs. Order matters here: the hooks and the generated directory both appear as side effects of npm install, which is convenient until you want to know what changed.

Learning mode blurs a word until you hover, which is the whole method

The pedagogy is stated in one line and then implemented as an interaction. The project is built on comprehensible input and the i+1 idea, meaning content slightly above the current level, and the way that reaches the page is a learning mode style: translated words appear blurred and become legible on hover. Seven translation styles are offered in total, from default and subtle through bold, italic, underlined and highlighted to that learning mode, and a glow animation marks words as they first appear.

The pronunciation layer is the deeper half. Hovering a translated word opens a tooltip with phonetics, an AI definition and audio, positioned to avoid the viewport edges; phrases get a nested word list; Youdao supplies speech with the Web Speech API as a fallback and British and American variants can be switched; TTS audio is cached in memory so the same word is not synthesised twice; and a dictionary lookup is cached for 24 hours. Five user levels from beginner to advanced adjust vocabulary difficulty, and the floating tool ball, with configurable transparency and position, is how the settings are reached.

Editorial conclusion

illa-helper is built for a reader who wants their vocabulary replaced on ordinary web pages and is willing to supply an API key and accept that page text is sent to a model. Two things decide whether that suits you, and both are in the repository rather than in a policy page. The default endpoint is a third-party chat completions URL compiled into the build, so your reading history goes wherever that key points. And the language list is qualified by the project itself, which says support theoretically depends on the model rather than on the extension. If you install from source, also expect a Safari build with no store listing and no development script, a manifest whose description field is still a template string, and a check command that rewrites your files instead of only reporting on them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. xiao-zaiyi/illa-helper on GitHub