Open-source project
crimx/ext-saladict avatar
crimx/ext-saladict

Saladict: a browser extension that turns selection into dictionary lookups

🥗 All-in-one professional pop-up dictionary and page translator which supports multiple search modes, page translations, new word notebook and PDF selection searching.

13,351 stars840 forksTypeScriptMIT

At a glance

What is it?
Saladict is a Chrome and Firefox WebExtension that shows dictionary entries and translations for selected text, including inside PDFs, and stores what you look up in a notebook. It is aimed at people who read a second language in the browser and want the lookup to happen where the text is.
Who is it for?
Adopt Saladict if you read a second language in Chrome or Firefox and want lookups to happen inside the page, with a notebook that accumulates what you selected. Do not adopt it if you need a maintained server-side pipeline, or if you cannot accept that the code is MIT but the Saladict name, the 沙拉查词 name, logos and icons are not, so a public fork has to ship under its own branding.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 6 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What Saladict replaces, and for whom

Reading a page in a language you half know splits your attention. You select a word, open a new tab, paste it, read a definition, come back, and lose the sentence. Saladict removes that round trip. The README calls it a "Chrome/Firefox WebExtension. Feature-rich inline translator with PDF support", and the pop-up appears over the page you are already reading.

The audience is narrow and specific. It is for people who read foreign-language articles, documentation, papers or forum threads in a desktop browser and want a definition without leaving the paragraph. It is also for people who want a record of what they looked up: the README points at a notebook feature and shows a notebook screenshot, so the lookups are meant to accumulate rather than vanish.

It is not a translation service. Saladict is a client. The dictionaries and machine translation backends it queries are separate products, and several of them need your own API credentials. That distinction matters more than any feature list, because it decides who can run the thing at all.

How the extension is put together

The repository is a TypeScript project built with webpack, and the package description states it is an "inline translator powered by multiple online dictionaries". The dictionary providers are separate packages pulled in as dependencies, with @opentranslate/baidu, @opentranslate/caiyun and @opentranslate/google visible in package.json. The same file lists @ant-design/icons and React-related packages, so the pop-up UI is a React application rather than injected plain DOM.

Two build configurations exist side by side: webpack.config.js and webpack.mv3.config.js, exposed as build:mv2 and build:mv3. That is the manifest version split. Chrome and Firefox have moved at different speeds on Manifest V3, and keeping both targets means the extension can ship to a store that still expects the older manifest without abandoning the newer one. The browserslist config and the .neutrinorc.js and .neutrinorc.mv3.js files sit alongside that split.

PDF support is not part of the webpack bundle. The build instructions run yarn pdf before yarn build, and package.json defines pdf as node scripts/pdf.js. The .env.example exposes PDFJS_VERSION with the note that leaving it empty downloads the latest PDF.js version. So the PDF path is assembled by a script at build time, which is a deliberate choice: you are not shipping a prebuilt viewer, you are fetching one.

Building Saladict from source and loading it

The README gives the build steps directly. Clone the repository, install with yarn, run the PDF script, then build. The clone command in the README uses the SSH form, so substitute the HTTPS URL if you do not have keys configured.

bash
git clone [email protected]:crimx/ext-saladict.git
cd ext-saladict
yarn install
yarn pdf

Before building, create a .env file following the .env.example format. The README says to leave it empty if you do not use these dictionaries, so an empty file is a valid configuration and the build should still complete.

bash
BAIDU_APPID=
BAIDU_KEY=
CAIYUN_TOKEN=
TENCENT_SECRETID=
TENCENT_SECRETKEY=
YOUDAO_APPKEY=
YOUDAO_KEY=
PDFJS_VERSION=

Then run the build. The default build script chains both manifest targets, so it produces MV2 and MV3 artifacts in one pass.

bash
yarn build

The README states that artifacts can be found in build/. That directory is what you load as an unpacked extension in Chrome or Firefox for local testing. Note the engine constraint in package.json: node is pinned to <= 16.20.2. A current Node release will not satisfy that field, and the .nvmrc file is there to tell you which version the project expects.

If you only want to use Saladict rather than build it, the README lists the Chrome Web Store, Firefox Add-ons and Microsoft Edge Addons as the distribution channels, and points at the releases page for more.

Credentials, backends and where a lookup can fail

The .env.example is the honest map of Saladict's dependencies. It names Baidu, Caiyun, Tencent and Youdao as services that take credentials, plus Google Analytics 4 measurement keys. Nothing in the file suggests a bundled offline dictionary. If a backend is unreachable, rate-limited, or your key is wrong, the pop-up has nothing to show for that provider, and the README does not document a fallback order or a retry policy.

The practical consequence is that Saladict's reliability is not Saladict's to control. A build with an empty .env is a working extension with fewer sources. A build configured against a provider whose API terms changed is a broken one. The repository does not document what happens when a provider returns an error, so treat provider configuration as the first thing to verify and the first thing to blame.

The second limit is the browser itself. Saladict is a WebExtension, so it lives inside Chrome, Firefox or Edge. It does not run on mobile browsers, and the related searches asking about an Android or app version have no corresponding artifact in this repository. There is a mac-app/ directory at the top level, but the README does not describe a macOS application or how to build one, so that directory's status is unclear from the documentation alone.

Third, PDF selection search depends on the PDF.js version fetched by scripts/pdf.js. That is a moving target when PDFJS_VERSION is empty, and a pinned one when it is set. If PDF selection behaves oddly after a rebuild, the version you fetched is a reasonable first suspect.

Saladict against a full-page translation extension

The obvious alternative category is an extension whose primary job is translating whole pages rather than defining selected words. Saladict does list page translation, but the README leads with the pop-up dictionary, the notebook and PDF selection, and that ordering reflects where the effort went. A page-translation extension inverts it: the unit of work is the document, and selecting a word is a secondary gesture.

The difference shows up in what you get back. Saladict returns entries from specific dictionaries, which is what you want when you are learning a term and need to see how it is used. A page translator returns a rewritten page, which is what you want when you only need to get through a document and never intend to remember the vocabulary. If you never open the notebook and never care which dictionary answered, you are paying for machinery you will not use.

The second alternative is the browser's own built-in translation. It requires no install, no key and no build, and it handles the whole-page case adequately. Saladict's counterargument is the notebook and the multi-dictionary pop-up, which the built-in feature does not attempt. Choose on that basis rather than on coverage claims.

Maintenance, releases and what the licence does not cover

The last push to the repository was on 2026-09-06, and the most recent release listed is v7.22.8 from 2026-07-26, preceded by v7.22.7 on 2026-07-12 and v7.22.6 on 2026-06-29. That is a steady cadence of small version bumps rather than a stalled project. The repository is not archived. The CHANGELOG.md file at the top level is where the project says changes are recorded, and the README links to it.

Upgrade cost for a user is close to zero, because the stores handle it. Upgrade cost for someone building from source is higher than it looks. The Node engine field caps at 16.20.2, the build runs two webpack configurations in sequence, and a postbuild script (scripts/firefox-fix.js) patches the Firefox output. Any of those three can break under a newer toolchain before the extension code itself does.

The licence situation is worth stating plainly. The source is MIT, and the README says you may use, copy, modify, publish and distribute it with the licence and copyright notice included. That permission does not extend to branding: the README states that the Saladict name, the 沙拉查词 name, logos, icons and related brand assets are not licensed under MIT, and that public forks should use their own name and icon and must not suggest they are official releases. TRADEMARKS.md is the file to read. This is a description of what the project states, not legal advice; if you plan to redistribute a modified build, get your own reading of those two files.

Editorial conclusion

Adopt Saladict if you read a second language in Chrome or Firefox and want lookups to happen inside the page, with a notebook that accumulates what you selected. Do not adopt it if you need a maintained server-side pipeline, or if you cannot accept that the code is MIT but the Saladict name, the 沙拉查词 name, logos and icons are not, so a public fork has to ship under its own branding. Before committing, check the .env.example keys against the dictionaries you actually use, confirm which build target you need between webpack.config.js and webpack.mv3.config.js, and read TRADEMARKS.md if you intend to redistribute.

Frequently asked questions

Which translation extension is the best for Chrome?

That depends on the job. Saladict is built around selected-word lookups from multiple online dictionaries, plus a notebook and PDF selection search; if you need whole-page rewriting, the README presents page translation as one feature among several rather than the focus.

Is there a Chrome extension for dictionary lookups?

Saladict is one. Its package description calls it an inline translator powered by multiple online dictionaries, and the individual dictionary backends are separate packages, several of which require your own API credentials in a .env file.

Is there a Chrome extension that translates entire websites?

Saladict lists page translation, but the README leads with the pop-up dictionary, the notebook and PDF selection search. If whole-page translation is your only requirement, that is not the use case the documentation puts first.

Is there a Chrome extension that can translate screens?

The README describes Saladict as a WebExtension for inline translation with PDF support, covering pages and PDF selections. It does not document a screen-capture or on-screen overlay translation mode.

Official sources

  1. crimx/ext-saladict on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/crimx-ext-saladict.svg)](https://hysenlabs.com/projects/crimx-ext-saladict)