MouseTooltipTranslator's manifest says 0.1.89 while the stores ship 0.1.248

package.json says 0.1.89 while the newest release is 0.1.248

The manifest in the repository root opens with `"name": "mouse_tooltip_translator"` and `"version": "0.1.89"`. The three newest releases are 0.1.248 from 2026-09-06, 0.1.247 from 2026-08-17 and 0.1.246 from 2026-08-05. That is 159 patch releases between the number in the source tree and the number in the wild, and nothing in the build instructions explains how the store listing gets its version.

The dates are worth reading closely, because the release and the last push land on the same day. The most recent commit is dated 2026-09-06 and release 0.1.248 was published about four minutes later the same day, which is the shape of a release cut from the tip of the default branch rather than from a tagged, prepared build.

Two other lines in the same file explain why the version number cannot be traced outward. The package is marked `"private": true`, so it is never published to a registry under that name, and there is no publish step in the script list. Whatever version the stores display therefore comes from a hand-edited listing or a manifest field outside this file, and the number 0.1.89 in the tree tells you nothing about which store build you are looking at.

Firefox is advertised in three badges and built by a script the page never names

The download line sends readers to the Chrome Web Store, the Edge Extension store and Firefox Addons, and a fourth badge points at Softpedia. The documented build command is one line, `npm run build`, and it produces a Chrome unpacked folder. Nothing on the page mentions Firefox again.

The scripts list is where the Firefox target actually lives, and it is a separate toolchain rather than a flag on the same one:

"watch": "webpack --mode=development --watch --config config/webpack.config.js",
"build": "webpack --mode=production --config config/webpack.config.js",
"zip": "npm-build-zip",
"zip-firefox": "npm-build-zip --name=firefox",
"build-firefox": "webpack --mode=production --config config/webpack.firefox.config.js",
"build-firefox-web-ext": "web-ext build --source-dir=build --artifacts-dir=web-ext-artifacts --overwrite-dest",
"build-firefox-zip": "npm run delete && npm run build-firefox && npm run zip-firefox",
"watch-firefox": "web-ext run --source-dir=build --firefox=firefox"

Two webpack configs live under `config/`, one for each browser, and Firefox is packed with `web-ext` rather than `npm-build-zip`. So the Edge and Firefox artifacts in the three badges are not the output of the four commands the page prints, and the Firefox add-on has its own developer loop (`web-ext run`) that never appears in the instructions. Two builds, two configs, two packagers, one documented command.

The build snippet's own comments would break a pasted shell

The build instructions are a six step list where step one is installing Node.js and specifies version 18, with a bare angle-bracketed URL as the reference. Step two is the only fenced block, tagged as console output rather than as a shell script, and it carries a trailing comment:

git clone https://github.com/ttop32/MouseTooltipTranslator.git
cd MouseTooltipTranslator
npm install
npm run build        // or 'npm run watch' for developing

That comment uses slashes, which a shell does not read as a comment, so the line as printed cannot be pasted into a terminal without editing. The rest of the sequence is prose rather than commands: you will see the build path, open chrome://extensions, turn on developer mode in the top right corner, then open `MouseTooltipTranslator/build` as an unpacked extension folder. So the last four steps of the whole build have no copyable form, and the reader who wants a script has to assemble one.

Above that block sits a heading named Result with nothing under it at all, and the section titled How to use is a single link to an anchor inside `doc/intro.md`. Two empty doorways in a page that is otherwise a list of links and badges.

Two named translators, no key step, and nothing said about what leaves the page

The feature list states that Google translator and Bing translator are used for translation, and that Google text to speech produces the pronunciation when you press the modifier. Everything the extension does with your text depends on those two services, yet the entire documented setup asks for one thing: Node.js, at version 18. There is no API key step, no account, no configuration file to edit and no endpoint to point at a self-hosted translator.

That silence has a practical consequence for anyone assessing the extension in a managed environment. Selecting text is what triggers the request, so the selected text is what crosses the network, and this page does not say what is sent, whether anything is stored, whether a cache exists, or whether there is an offline path. The PDF path has the same shape: the feature list credits PDF.js for displaying translated tooltips on top of a PDF, which means the text has already been translated somewhere before the overlay is drawn.

The remaining features reuse the same two services from different directions: OCR on a held modifier over an image, speech recognition for translating what is spoken, and dual subtitles for YouTube video. Whether each of those paths uses the same providers is not stated.

Four modifier chords carry every feature and none of them are tabulated

Read the feature list as a keymap and the extension's whole interface is four chords, all named in passing: hover or select highlighted text to translate, left ctrl to hear pronunciation through Google text to speech, right alt to translate the writing in an input box or the highlighted text, and hold left shift while hovering an image to run OCR on it, with manga given as the example.

Not one of those bindings appears in a table, and the page says nothing about conflicts, about whether left ctrl also keeps its normal meaning on Linux and macOS, or whether any of them can be remapped. Two left-hand modifiers carrying two unrelated features, left ctrl for sound and left shift for OCR, is the kind of pairing that is easy to document once and hard to rediscover after an update.

This is also where the single How to use link matters. It points at an anchor in `doc/intro.md` for the full set, which means the gesture reference lives one file away from the README rather than in it. The features you can reach without that file are the ones described in a single bullet line each.

Thirty three localization codes, and a contributor table with three Nulls

Two blocks of the README are generated, and both are large. The Crowdin block credits `daniel k (ttop32)` with 11435 words and then lists language codes: am, ar, bn, bg, ca, zh-CN, zh-TW, hr, cs, da, nl, en-AU, en-GB, en-US, et, fil, fi, fr, de, el, gu-IN, he, hi, hu, id, it, ja, kn, ko, lv, lt, ms and ml-IN, where the list stops mid-entry. Thirty three codes are readable, and `crowdin.yml` sits at the repository root to drive them.

The contributor table is bracketed by its own generator markers and holds more than twenty names, including three entries whose display name is simply Null and one that links to the `claude` account on GitHub. The mixed display names are the small joke in it: Daniel K, Max, Arda Satata Fitriajie, Anoir Ben Tanfous, Don-A, Renato A. Silva, a username spelled out in full as Lg28literconvectionmicrowaveoven, StarsSail, Hoang Van Nhat, Imgbot, KozakLordOfMatrix, Doom Dudash, Trần Nguyễn Tiến Thành, Silvestri, Javier, JG and Claude.

Set that against the documentation. A project with thirty three localizations, three browser targets and a PDF.js integration has a README made of badges, one feature list, one build block and one link.

__tests__ and jest are in the tree, and no script runs either

The repository root holds `__tests__/`, `babel.config.js` and a `config/` directory, and the dev dependencies include jest at `^30.0.2`, `@babel/preset-env`, webpack 5 and webpack-cli, copy-webpack-plugin, sass and sass-loader, the Vue loader set, unplugin-vue-components, unplugin-vue-router, unplugin-auto-import, web-ext, del-cli, npm-build-zip, webpack-ext-reloader for reloading the unpacked extension while you edit, size-plugin for bundle size reporting, deepmerge and cross-env.

Here is the gap. The script list covers watch, build, delete, zip, zip-firefox, build-zip, build-firefox, build-firefox-web-ext, build-firefox-zip and watch-firefox. None of them invokes jest. So the test directory and the test runner are both committed, and nothing in the package's own commands starts them; the documented four command workflow never runs a test either.

The rest of the root is documentation and assets: `doc/` for the intro page the How to use link points into, `public/` for static files, `src/` for the extension itself, plus `.github/`, `.claude/`, `CLAUDE.md`, `LICENSE`, `package-lock.json` and `.gitignore`. The MIT identifier in the repository record matches a LICENSE file at the root, so the licensing question that trips up other repositories is settled here.

Editorial conclusion

MouseTooltipTranslator is worth installing from a store rather than building, because the documented build covers only the Chrome target and the version you build does not match the version stores serve. Anyone auditing it for a managed environment should look at what the extension sends to Google's and Bing's translators, since this page names both engines and documents no key, no account and no offline mode. Two specific checks are worth doing first: confirm the LICENSE file matches the MIT identifier in the repository record, and remember that the manifest version of 0.1.89 is a dead number, so a self-built artifact cannot be mapped back to a store release by version. The test suite under __tests__ is real but unreachable from the scripts, so do not assume a passing build means vetted behaviour.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ttop32/MouseTooltipTranslator on GitHub