Subtitle Translator (gnehs/subtitle-translator-electron): an Electron front end for LLM subtitle translation
↔️ Translate subtitle using LLM
At a glance
- What is it?
- A desktop app that sends .srt, .ass, .ssa and .vtt subtitle files to an LLM and writes back translated subtitles, with JSON checkpoints so a long job can be resumed. The checkpoint format is the feature that matters, and the README is thin on everything else.
- Who is it for?
- Adopt it if you translate feature-length subtitles on a desktop machine and want resumable jobs without writing a script, and if you are willing to read the source to confirm which providers and API keys the current build accepts, since the README does not state them.
- 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 46 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 problem the app solves, and for whom
Machine translation of subtitles has been available for years, but the failure modes are specific: dialogue translated line by line loses the referent of a pronoun, honorifics flip, and a joke two lines later stops working because the setup was translated without knowing the punchline. Subtitle Translator's stated approach is to translate "according to the preceding and following sentences", which is the reason to use an LLM rather than a phrase-based engine. The README lists the supported inputs as .ass, .srt, .ssa, .vtt and .json checkpoints, so the target user is someone with an existing subtitle file, not someone generating subtitles from audio. There is no transcription step in the material. The app is for a person at a desktop: it is an Electron application distributed through GitHub Releases and a Homebrew cask, and the README's only described interaction for resuming work is dragging a JSON file back into the window. If your workflow is a shell script over a directory of files, this is the wrong shape.
The checkpoint file is the actual design decision
Most translation tools fail in the middle and leave you with nothing. This one writes translation checkpoints as JSON, and the README says an interrupted translation "can be resumed by dragging the JSON file back into the app". That single choice implies a data flow: the subtitle file is parsed into cues, cues are sent to the model in groups, each group's result is appended to an in-memory record, and that record is serialised to disk so a crash or a closed lid does not cost the whole run. The README does not state the checkpoint interval, the JSON schema, or whether the file stores the source text alongside the translation. Those are the details you would need before treating the checkpoint as an archive rather than a temporary file. The README also does not say whether the app validates a checkpoint against the source subtitle before resuming, which matters because resuming a checkpoint against a re-edited .srt would silently misalign lines. Treat the JSON as a resume token, not a format to build tooling on.
Context windows, batching and the quality ceiling
The feature list says translation uses ChatGPT and that sentences are translated with their neighbours as context. That is a sliding window, and it has a known cost: the model sees a fixed number of surrounding cues, so a callback to a scene twenty lines earlier is outside the window and will be translated without it. The README does not document the window size, whether it is configurable, or whether the app passes speaker names and style tags to the model. For .ass files, which carry styling and positioning in the same file, the README says nothing about whether those tags survive a round trip. Anyone adopting this for typeset .ass work should test a sample file first and diff the output against the input, because a translator that rewrites style blocks is worse than no translator. The same caution applies to .vtt, where cue identifiers and timestamps are part of the file's contract with a player.
Getting it running: Homebrew cask or a release build
The README gives one install command: brew install --cask gnehs/tap/subtitle-translator-electron. That pulls from the author's own tap, so the cask definition lives in the gnehs/tap repository rather than homebrew-cask; if the tap is not updated in step with releases, the cask can lag behind the GitHub release. The alternative is downloading from the Releases page, which the README links as the "latest stable version". The README does not document how to supply an API key, which environment variables or settings fields the app reads, or whether a local or self-hosted OpenAI-compatible endpoint can be substituted. The topics list includes open-ai, chatgpt, gpt-3 and gpt-4, which indicates OpenAI-family models, but that is a repository tag, not a configuration reference. Building from source is possible in principle because the project is TypeScript, but the README contains no build instructions, no Node version, and no package manager command. Expect to read the source before you can point it at anything other than a default OpenAI account.
Where it breaks: long files, cost and no review step
A feature-length subtitle is roughly a thousand cues. At that size, per-token billing and rate limits become the dominant constraint, and the README says nothing about retries, backoff, or what happens when the provider returns a 429 mid-run. The checkpoint mitigates the loss but not the wait. There is also no described review step: the app translates and writes output, and the only quality control is reading the result. For a language pair where the model is weak, or for a domain with heavy terminology (medical, legal, a period drama with invented vocabulary), a glossary or term-base is the feature you would want and the README does not claim one. The wrong-tool case is concrete: if you need consistent terminology across a season of episodes, this app gives you no shared glossary, so each file is translated independently and the same term can come out differently in episode one and episode four.
Alternatives: subtitle-edit and a scripted pipeline
Subtitle Edit is the obvious comparison for anyone already in subtitle work. It is a full subtitle editor with a translation mode that can route through machine translation providers, and its difference in approach is that translation is one feature inside an editing, timing and format-conversion tool. Subtitle Translator does one thing and does it in a small window. If your problem is a mistimed .srt, Subtitle Edit fixes it and this app does not; if your problem is that you want the LLM to see neighbouring lines and you want a resume file, this app is the smaller tool. The second alternative is writing your own script against the provider's API: parse the subtitle, chunk the cues, send them with context, write the results back. That gives you a glossary, a retry policy, a diff before writing, and a CLI you can run over a directory. The reason to use this app instead is that someone has already built the Electron shell, the file drag-and-drop and the checkpoint serialisation, and the MIT licence lets you keep those parts while replacing the rest.
Maintenance, licence and what to verify first
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; the README does not add terms, and nothing in the material suggests a separate commercial tier. On maintenance: the release history shows 2.0.1, 2.0.2 and 2.1.0 within about three weeks of each other in July 2026, and the last push to main is dated 2026-08-01. A burst of patch releases after a major version bump is normal, but it also means the 2.x line is young and the checkpoint format introduced or changed in 2.0 may not be stable across future versions. Before you rely on it, open a real .ass or .vtt file, translate a few dozen cues, close the app mid-run, and drag the JSON back in to confirm the resume path works on your machine. Then compare the output file's timestamps and style blocks against the input. If either check fails, the checkpoint is the only part worth keeping, and you can lift that idea into your own script.
Editorial conclusion
Adopt it if you translate feature-length subtitles on a desktop machine and want resumable jobs without writing a script, and if you are willing to read the source to confirm which providers and API keys the current build accepts, since the README does not state them. Do not adopt it if you need a headless batch pipeline, a CLI for a subtitle farm, or a review step before translated lines are written back; the project is an Electron GUI with a manual drag-and-drop resume flow. Before committing, verify three things: which provider endpoints and key names version 2.1.0 accepts, whether the translated file preserves your original timing and style tags after a round trip, and whether the checkpoint JSON is portable between machines. The MIT licence means you can fork and patch those gaps, but the README will not answer them for you.
Community notes