# ScTranslator puts every translation source on one page and lets you compare them

> ScTranslator is a browser extension for Chrome, Edge and Firefox that is built around one idea, which is showing you what several translation engines say about the same text side by side rather than hiding them behind a dropdown. It also keeps a translation history in a single page, has a separate translate window, and lets you collect translations into named groups.

**chunibyocola/sc-translator-crx** — Focus on providing a great inline web translation experience.

- Repository: https://github.com/chunibyocola/sc-translator-crx
- Stars: 532 · Forks: 46
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/chunibyocola-sc-translator-crx

## One page, several engines

The project describes itself with a focus on providing a great inline web translation experience, and then lists what that means in a single run-on sentence.

Translate with multiple translation sources at the same time. Translation history in a single webpage. Separated translate window. Customize theme. Text preprocessing. Translation Collection. Webpage translation.

The first item is the one that explains the rest. Most translation tools present one engine at a time, and you choose which one before you know what you need. ScTranslator queries several at once and shows you the results together, which turns a choice you have to make blind into a choice you make with the evidence in front of you.

That is a genuinely different interaction model. Translation quality varies enormously by language pair, by domain and by the kind of text, and no single engine wins everywhere. If you are translating a technical paragraph, or a paragraph of literary prose, or a menu, the best engine for that case is not predictable, and comparing is the only way to find out.

The second item is translation history in a single webpage, which is a smaller feature than it sounds but a more useful one in practice. Every translation you have done is kept and visible in one place, rather than being scattered across the tooltips and side panels where translation extensions usually put them. If you are translating a document over time, or working through a terminology list, that history is the work product.

The separated translate window is the third, and it is about the fact that a browser extension competes with the page for space. Most inline translators pop up a small bubble next to the text, which is fine for a single word and cramped for a paragraph or for a result you want to copy. A separate window gives you room, and it can sit beside the page.

The remaining items are more conventional. Customize theme is a dark mode for the interface. Text preprocessing is about what happens to the text before it is sent, which matters for the common case of a page with awkward whitespace and line breaks. Translation Collection is grouping saved translations into named sets. And webpage translation is the whole-page mode.

The project is TypeScript, GPL-3.0 licensed, with the default branch master and releases v5.11.0 from 2026-07-21, v5.10.0 from 2025-10-30 and v5.9.0 from 2025-09-04.

## Where you can get it, and the four ways

The extension is published in three stores and can also be built and side-loaded, and the four routes are worth setting out because they behave differently.

There is a Chrome Web Store listing, an Edge Add-ons listing and a Firefox Add-ons listing. And there is the option to download the ZIP from the latest release, unzip it, and load it unpacked on the extensions page with developer mode enabled.

The store route is the normal one and gives you automatic updates. The unpacked route is for people who want to modify the extension or who are working on it, and the developer mode requirement is the browser's way of saying you are loading code that did not come from the store.

Publishing to three stores is more work than publishing to one, and it is worth noting that a single codebase serves all three. The topic tags list chrome-extension and firefox-addon separately, and the Firefox build uses the WebExtension manifest format rather than the Chrome one, so the difference is real but confined.

The build section is the standard four commands for a webpack project:

```bash
git clone https://github.com/chunibyocola/sc-translator-crx.git
cd sc-translator-crx
yarn install
yarn build
```

That is worth reading as a statement about the project, because there is no scaffolding step and no global tooling to install beyond node and yarn. You clone, install the dependencies and build, and what comes out is a loadable extension.

The repository layout is compact and conventional for a browser extension in TypeScript. There is src/ for the source, public/ for the static assets the manifest and the popup need, config/ for the webpack configuration, docs/ for the documentation and the images used in the README, and a CHANGELOG.md at the root alongside the LICENSE and the README.

There is also an eslint.config.js at the root, which is the flat configuration format rather than the old .eslintrc file, and a babel.config.json for the Babel presets, plus a tsconfig.json and a yarn.lock.

The docs/ directory holds the images and a link to more animated demonstrations in the discussions area of the repository, which is a reasonable place to put visual examples that would otherwise bloat the README.

## Redux and signals in the same extension

The dependency list is short and there is one combination in it that tells you something about how the extension is written.

The state libraries are Redux, the toolkit, react-redux and redux itself, and then there is react-signal-slot.

Redux with the toolkit is the standard choice for a React application of any size, and the toolkit gives you the slice pattern and the async thunks. React-redux is the binding layer. And then react-signal-slot is the one dependency that is not part of the Redux family, and its presence suggests a second, signal-style mechanism for state alongside the store.

Running both in one extension is a deliberate choice rather than an accident of dependencies, and it reflects where the React ecosystem was when the version was written. Redux remains the right answer for application state that many parts of the UI care about, while signals are a better fit for the high-frequency local state that a translation tool has plenty of: the text in the input box, the position of a tooltip, the live preview while you type.

The expensive kind of state for Redux is state that changes on every keystroke and that only one component reads, because every dispatch goes through the store and re-runs the subscribers. A translation input is exactly that. So the sensible architecture is signals for the hot local values and the store for the history, the settings and the collection, which is shared and which changes rarely.

React itself is at 19.2.7, with react-dom alongside it, and the type packages match. The React compiler is not in the dependency list, but the eslint plugin for react-hooks is, which is the older linting counterpart for hook rules and dependency arrays.

TypeScript is at 6.0.3 and the type check is a separate script, check-types, running tsc with the project file and no emit. The separation is worth noticing: the build is webpack with Babel, so Babel strips the types without checking them, and the type check has to be a separate step or it does not happen at all.

## A build pipeline and a lint setup that take accessibility seriously

The build tooling is described by the dev dependencies and it is a modern webpack setup.

Webpack is at 5.107.2 with webpack-cli at 7, and the build script passes the production environment flag with a config file in the config/ directory. There is a separate dev script with the development environment. So the environment is passed as an environment variable rather than as a separate config file, which keeps one configuration with two behaviours.

The Babel stack is at version 8, with the core and three presets: env for the JavaScript, react for the JSX and typescript for the type stripping. The babel-loader at version 10 wires it into webpack. That is the standard arrangement for a React project built with webpack, and it is why the TypeScript check has to be a separate script, since Babel removes the types without verifying them.

The copy-webpack-plugin and html-webpack-plugin handle the two assets an extension needs: the static files from public/ copied into the output, and the HTML page for the popup and the options UI generated with the right script references.

The linting is the part worth a closer look, because the plugin list is unusually careful. There is eslint itself at version 10 with the flat config file, typescript-eslint, eslint-plugin-react for the React-specific rules, and eslint-plugin-react-hooks for the rules about hooks and dependency arrays.

And then there is eslint-plugin-jsx-a11y, which is the accessibility plugin. It checks the markup in your JSX for problems such as an interactive element without a keyboard handler, an image without alternative text, or a form control without a label.

For a browser extension that injects UI into other people's pages, that plugin is doing more than usual work, because the markup you write is frequently inserted into a page you do not control. An accessibility error in an extension's own panel is a bug; an accessibility error in a tooltip injected into someone else's page is worse.

The eslint-webpack-plugin runs the linting as part of the build rather than as a separate command, which is a design decision with trade-offs. It means lint errors fail the build and cannot be shipped, and it means the lint run happens on every build, which costs time.

## Where this fits among the translation tools

The translation tools divide into two groups, and ScTranslator is deliberately in the second one.

The first group is the built-in browser translators. Chrome, Edge and Firefox all have them, and for reading an article in your own language they are good enough that most people never install anything else. They are free, they need no permission, they work on every page, and they are already there.

The second group is the extensions that give you more control: which engine, how it is displayed, what is remembered. ScTranslator is in that group, and the way it chooses to differentiate is the multi-source comparison rather than the usual axes of a custom dictionary or a user-supplied translation source.

That is a coherent bet. The reason people install a translation extension at all is usually that the built-in one was not good enough for the text they care about, and the reason it was not good enough is that it uses one engine. So showing several engines is addressing the actual complaint.

The feature list supports the same reading. Text preprocessing is what you need when the built-in translator failed because it received a badly formatted block of text. The translation collection is for building a glossary or a terminology set over time. The separate window is for when the answer is long. And the history page is the record.

What you do not get is the other side of that trade. This is a GPL-3.0 project with no paid tier, and there is no hosted service behind it, so the translation sources it queries are the ones configured in the extension rather than a curated set the maintainer operates. That is a good thing for privacy, since your text goes to the engines you chose rather than to a broker, and it means the extension is only as good as the sources you point it at.

The maintenance question is the other thing to weigh. The last push was on 2026-08-27 and the most recent release is v5.11.0 from 2026-07-21, with the release before that from October 2025. An extension of this kind has to keep up with changes in the translation engines it calls and with the browser extension APIs, and both of those move.

So the practical summary is that this is for people who translate regularly and care about which engine they are getting, and it is a solid choice for that. If your need is occasional reading, the browser's own translator is the better deal.

## Conclusion

Adopt ScTranslator if you translate text often and want to compare engines rather than pick one blind, since the side-by-side view is the feature the whole design serves. Skip it if you only need occasional word lookups, since a built-in browser translator will already do that, and if you cannot install extensions in your browser profile. Verify first which browser you use, since the extension is published separately for Chrome, Edge and Firefox, and how you want to install it, since the store listings and the unpacked ZIP are different routes with different update behaviour.

## FAQ

### What does ScTranslator do and what are its main features?

It is a browser extension focused on providing a good inline web translation experience. The features are translating with multiple translation sources at the same time, a translation history kept in a single webpage, a separated translate window, customizable theme, text preprocessing, translation collections for grouping saved translations, and full webpage translation.

### How do I install ScTranslator and how do I build it from source?

You can install it from the Chrome Web Store, the Edge Add-ons store or the Firefox Add-ons site, or download the ZIP from the latest GitHub release, unzip it and load it unpacked on the extensions page with developer mode enabled. To build it yourself you clone the repository, change into the directory, run `yarn install` and then `yarn build`, using webpack with the production configuration.

### What is the tech stack of the ScTranslator extension?

It is TypeScript with React 19, and it uses Redux with the toolkit and react-redux for shared application state alongside react-signal-slot for local reactive values. The build is webpack 5 with Babel 8 presets for JavaScript, React and TypeScript, and linting uses eslint 10 with the flat config format, typescript-eslint, the React and react-hooks plugins, and eslint-plugin-jsx-a11y for accessibility checks on the markup injected into pages.

## Sources

- [chunibyocola/sc-translator-crx on GitHub](https://github.com/chunibyocola/sc-translator-crx)
- [Issues](https://github.com/chunibyocola/sc-translator-crx/issues)
- [License: GPL-3.0](https://github.com/chunibyocola/sc-translator-crx/blob/master/LICENSE)
- [README](https://github.com/chunibyocola/sc-translator-crx/blob/master/README.md)
- [Releases](https://github.com/chunibyocola/sc-translator-crx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chunibyocola-sc-translator-crx