LanceMoe/openai-translator: A PWA Translator That Talks to Any OpenAI-Compatible Endpoint
A translator built using OpenAI.
At a glance
- What is it?
- This is a browser-based translation front end that sends your text to the /v1/chat/completions API of whichever OpenAI-compatible provider you point it at. It installs as a PWA, keeps history in local storage, and ships no server component of its own.
- Who is it for?
- Adopt it if you already pay for an OpenAI-compatible endpoint and want a self-hosted translation UI with no backend to operate, and if you are comfortable that your API key lives in the browser. Skip it if you need a browser extension that translates pages in place, since the README describes a standalone PWA rather than an extension, and skip it if you need a server-side key proxy or team-wide key management.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 12 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What LanceMoe/openai-translator actually is, and who it is for
The README describes a PWA translator powered by OpenAI-compatible chat models, installable on phone or desktop. That is the whole scope. It is a client: a React single-page app that takes text you type, sends it to a chat completions endpoint, and renders the reply. There is no translation engine inside the repository, no model weights, no inference code. The quality of every translation you get is the quality of whatever model your API key can reach.
The audience is narrow and specific. You need an API key for an OpenAI-compatible provider, and you need to be willing to paste that key into a web page. In exchange you get a translation interface with no subscription of its own, no account on the author's side, and no server you have to run. The README notes that the project uses the `/v1/chat/completions` API with optional streaming output, which means any provider that speaks that shape (not only OpenAI itself) can back it. That is the design decision that matters most here: this is a translation skin over a chat API, and it is honest about being one.
The README also says the author thinks the project will help you learn the techniques in its stack. Read that as a signal about intent. This is a small, legible codebase meant to be read as much as used.
How the request path works: chat completions, streaming, and local history
Everything flows through one call. Your text becomes a chat message, the app posts it to the configured base URL at the chat completions path, and the response is displayed. The README lists `@microsoft/fetch-event-source` among the dependencies, which is the library you would reach for to consume a server-sent event stream, and the README confirms streaming output is optional. So the two modes are a single blocking response, or a token-by-token stream rendered as it arrives.
Configuration is client-side. You set a custom API base URL and an API key, then pick a model. The README says the default model is `gpt-5.6-luna`, and the configuration page suggests a list that mixes OpenAI families (`gpt-4o-mini`, `gpt-4o`, `o3-mini`, `o1`) with open-weight identifiers (`gpt-oss-120b`, `gpt-oss-20b`). The README is explicit that availability depends on your provider and credentials. Treat the suggested list as a convenience, not a guarantee.
Translation history is saved locally. The README says so directly and does not describe a sync mechanism, so history is per-browser and per-device. State management is `zustand`, data fetching is `@tanstack/react-query`, and the UI is React 19 with Tailwind CSS 4 and DaisyUI 5. Nothing in the repository layout suggests a database or an auth service. The `src/` directory plus a static `dist` output is the entire runtime.
Installing LanceMoe/openai-translator and translating your first sentence
Local development needs pnpm, which the README links to at pnpm.io/installation. Clone the repository, install dependencies, and start the dev server. The `dev` script passes `--host`, so the Vite server binds beyond localhost, which is useful if you want to open the app from a phone on the same network.
pnpm install
pnpm devThe README states that Vite should open your browser automatically. If it does not, check the terminal output for the local URL.
For a production build, the README gives two routes. The Docker route builds an image and runs it behind nginx on port 80 inside the container:
docker build -t openai-translator-web .
docker run -p 3000:80 openai-translator-webThen open http://localhost:3000/ . The Dockerfile is a two-stage build: `node:22-slim` compiles the app with `pnpm build`, and the resulting `dist` folder is copied into `nginx:alpine` along with `nginx/default.conf`. The container exposes port 80, and the README's run command maps it to 3000 on your machine.
The non-Docker route produces static files, which the README says land in `dist` and can be treated as a static website:
pnpm buildAfter the app loads, open the configuration page, enter your API base URL and API key, and choose a model. Type a sentence and translate. If the request fails, the first thing to check is whether your provider exposes the chat completions path at the base URL you entered, since the app does not adapt to a different API shape.
The API key lives in the browser, and that is the central trade-off
There is no backend in this repository. The README describes a static build and a Docker image that serves static files through nginx. That means your API key is entered in the browser and used from the browser. For a personal tool on your own machine this is a reasonable simplification. For anything shared, it is the thing to think hardest about.
The README does not document a server-side proxy, a key vault, or any mechanism for keeping credentials off the client. It also does not document rate limiting, request logging, or cost controls. If you deploy this on a public URL and hand out access, every user is spending against whatever key is configured, and the project gives you no instrumentation for that. Self-hosting the static files does not change this, because the constraint is architectural rather than a missing feature.
A second limitation is scope. The README describes a PWA you install and open. It does not describe a browser extension, page-level translation, or automatic detection of foreign text on a page. People searching for an extension that translates web pages in place are looking for a different kind of tool, and this repository does not claim to be one. The credit section notes the project was inspired by a Bob plugin, which is a plugin for a specific macOS translation app, not a browser extension.
A third is history. Because history is local, clearing site data clears it. There is no export path documented in the README.
How it compares with an API client you already have
The honest alternative is not another translator. It is the chat client you already use. If you have an OpenAI-compatible endpoint configured in a desktop chat app or a terminal client, you can paste text and ask for a translation, and you will get the same model output this project produces. The difference is the interface around the request.
What LanceMoe/openai-translator adds is a purpose-built form: a translation-oriented input, a language selection, a history list, and a PWA shell you can install on a phone home screen. It removes the prompt-writing step and the chat scaffolding. What it does not add is any translation-specific machinery. There is no glossary, no translation memory, no term base, no document ingestion. The README lists no such features, and the dependency list shows no parsing libraries for documents.
So the comparison is between a general chat client and a narrow front end. If your work is occasional sentence-level translation, the chat client is already sufficient and costs you nothing to set up. If you translate frequently enough that opening a chat window and typing a prompt each time is friction, the dedicated form earns its place. If you need terminology consistency across a large document set, neither tool is the right answer, because this project has no mechanism for it.
The other comparison worth naming is the upstream inspiration. The README credits a Bob plugin as the inspiration, and a Bob plugin runs inside the Bob macOS app with its own key management. This project's difference is reach: a browser PWA runs on phones, Windows, and Linux, at the cost of putting the key in a page.
Maintenance, build cost, and the GPL-3.0 licence
The repository is not archived, and the last push was on 2026-09-04. That is recent relative to today, so the codebase is being touched. There are no releases retrieved, which means there is no tagged version to pin against; the `package.json` shows version `0.3.0`, but the README does not describe a release process. If you deploy this, you are deploying a commit, and you should record which one.
Upgrade cost is dominated by the front-end stack rather than the translation logic. React 19, Vite 8, Tailwind CSS 4, DaisyUI 5, React Router 7, and React Query 5 are all current majors, and the repository has a `pnpm-lock.yaml` plus a `pnpm-workspace.yaml`, so `pnpm install --frozen-lockfile` gives you a reproducible dependency set. The Dockerfile uses exactly that flag, along with `--ignore-scripts`, which is worth noting because it means postinstall scripts do not run during the image build. Husky is wired through the `prepare` script for git hooks, and eslint plus prettier are configured, so contributing a change means passing lint and format checks.
The licence is GPL-3.0. That is a copyleft licence, and the practical consequence is that if you distribute a modified version of this app, you are expected to make the corresponding source available under the same terms. Running it for yourself, or hosting it internally, is a different question from shipping a modified build to others. The repository does not contain a separate licensing note for the suggested model identifiers or the upstream inspiration, and the README does not address licence compatibility with anything you might combine it with. If you plan to redistribute, read LICENSE.md and get proper advice rather than inferring from this paragraph.
Editorial conclusion
Adopt it if you already pay for an OpenAI-compatible endpoint and want a self-hosted translation UI with no backend to operate, and if you are comfortable that your API key lives in the browser. Skip it if you need a browser extension that translates pages in place, since the README describes a standalone PWA rather than an extension, and skip it if you need a server-side key proxy or team-wide key management. Before deploying, verify on your own provider that the model identifier you intend to use appears in the configuration page's suggested list or is accepted by that provider, and confirm the GPL-3.0 obligations if you plan to redistribute a modified build.
Frequently asked questions
How do I use OpenAI Translator?
Install dependencies with pnpm install and start the dev server with pnpm dev, or build the Docker image and run it on port 3000. Then open the configuration page, enter an API base URL, an API key, and a model, and translate text in the input. The README says the app uses the /v1/chat/completions API, so your provider must expose that shape.
Does OpenAI Translator need my own API key?
Yes. The README lists configuring a custom API base URL and API key for OpenAI-compatible providers as a feature, and the app has no backend of its own. Your key is entered in the browser and used from there.
Is OpenAI Translator free to use?
The software is licensed GPL-3.0 and the source is public, so there is no licence fee. The translations themselves are not free: you pay whichever API provider your key belongs to, and the README states that model availability depends on the provider and credentials you configure.
Is there a Chrome extension version of OpenAI Translator?
The README describes a PWA that installs on phone or desktop, not a browser extension. It does not document page-level or in-place translation of web pages.
Which models can OpenAI Translator use?
Any chat-model identifier your configured provider supports. The README says the default is gpt-5.6-luna and that the configuration page also suggests gpt-4o-mini, gpt-4o, o3-mini, o1, gpt-oss-120b, and gpt-oss-20b among others, with availability depending on the provider.
Can I run OpenAI Translator as a self-hosted Docker container?
Yes. The README gives docker build -t openai-translator-web . followed by docker run -p 3000:80 openai-translator-web, and the Dockerfile serves the built files through nginx on port 80 inside the container.
Community notes