Subtitle Translator：把时轴从翻译流程里摘出去
Translate a whole season of subtitles in one pass — .srt/.ass/.vtt/.lrc, 120+ languages, 27 LLM providers, timing untouched ｜ 整季字幕一次译完，时轴不动，支持 120+ 语言
秒懂
- 它是什么？
- 这个项目把字幕的时轴、序号、样式头在本地剥离，只把对白送给翻译引擎，从而让模型无法改坏时间码。本文讨论它的机制、上手方式、批量翻译的边界，以及它不适合的场景。
- 适合谁用？
- 如果你手上是整季的 .srt 或 .vtt，只想把对白换成另一种语言而完全不碰时轴，并且愿意自己准备 API Key，这个项目值得先跑一集验证。反过来，如果你的字幕需要重新断句、合并或拆分时间轴，或者你要求翻译过程可审计、可回滚到服务端日志，它就不合适，因为按文档描述，字幕内容和 API Key 都留在浏览器里，缓存也放在 IndexedDB。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 4 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的其实是两个错误，不是一个
把字幕文件粘进通用翻译器，README 认为会同时出两个问题：模型会改写时间码，而且你只能一个文件一个文件地做。这两件事性质不同。前者是数据完整性问题，后者是吞吐问题。项目的做法是把两者一起处理：在本地把时间码、cue 序号、ASS 头部、VTT cue ID 全部抽走，只把对白文本发给引擎，这样时间轴在物理上不可能被模型碰到；同时对整季文件做批量投递，每个文件独立翻译、独立下载，结束后给出类似 Exported (3/5) 的成功失败汇总。目标用户很明确：做字幕组、做本地化、或者要给一整季剧集配多语字幕的人。它不面向需要重新切分时间轴的场景，因为时轴被刻意保护起来了。
数据流：本地解析、只发对白、结果回填
按 README 的描述，流程是解析、剥离、发送、回填。解析层自动识别 .srt、.ass、.vtt、.lrc 四种格式，WebVTT 里的 NOTE、STYLE、REGION 这些非 cue 块会被跳过，不会当成对白送去翻译。剥离之后，只有对白文本进入翻译引擎，时轴与结构信息留在本地。回填时支持双语输出，译文可以插在原文上方或下方，跨格式保持对齐；对 SRT 和 VTT 源文件，还能导出 ASS，原文与译文使用不同样式（文档给出的默认是 Default 70pt 白色与 Secondary 55pt 青色）。LLM 模式下还会额外发送上下文行，让对白更连贯、角色语气更一致，这是传统机器翻译 API 做不到的部分。整个链路里没有中间服务器参与，字幕内容和 API Key 都留在浏览器内，LLM 请求从浏览器直接发往你配置的端点。
跑起来：网页端零配置，CLI 走同一套引擎
最快的方式是打开在线地址 https://tools.newzone.top/en/subtitle-translator，把整季文件拖进去。GTX 和 Edge 这两个免费 API 不需要任何配置，是零设置默认项，并且互为回退。要换成 DeepL、Google、Azure、DeepLX、Qwen-MT、TranslateGemma 或某个 LLM，就在 API Settings 里填 Key；如果你的提供方被浏览器 CORS 挡住，项目自带一个 relay 可以直接用，也可以在 API Settings 的 Relay address 里指向你自己部署的 relay Worker。想要脚本化，README 给出的入口是 yarn cli，它复用同一套引擎、解析器和缓存。LLM 模式下的可调项包括 system / user prompt、temperature（0 到 1）、按提供方切换的 Thinking Mode，以及并发行数 Concurrent Lines（默认 20）和上下文行数 Context Lines（默认 50）。翻译缓存写在 IndexedDB 里，文档说没有浏览器存储大小限制，刷新页面不会丢已翻译的文件。
上下文模式是有代价的，README 自己标了警告
上下文感知只对 LLM 模式生效，它把周围若干行一起送进批次，换取对白连贯性和角色语气一致性。代价写在参数说明里：Context Lines 越高，连贯性越好，token 消耗越大；Concurrent Lines 太高会触发限流。README 还给了一条明确警告，参数量低于 70B 的模型可能产生错位输出，建议在上下文模式下使用 Claude、GPT、DeepSeek、Gemini 这类主流在线大模型。这条警告值得当真，因为它意味着这个功能不是所有本地模型都能接。如果你打算用 Ollama 或 LM Studio 跑一个中小尺寸模型来省成本，上下文模式很可能不是可选项，而是要先验证的风险点。另一个需要自己判断的地方是并发与限流的平衡，默认 20 并发对免费 API 未必合适。
和传统字幕翻译工具的区别在时轴处理方式
常见的字幕翻译做法有两种。一种是把整个字幕文件交给翻译服务，由服务端解析并返回新文件，时轴是否被改动取决于服务实现。另一种是先用工具把字幕转成纯文本，翻译后再靠工具重新对齐时间码，这一步往往是错位的主要来源。Subtitle Translator 选了第三条路：时轴从不离开本地，只有对白出去，翻译结果按原结构回填。这个差异在批量场景下更明显，因为对齐错误会随文件数量放大。作为对比，DeepL 官方提供的文档翻译能力面向的是整篇文档排版，不是字幕这一层的时间结构，用它处理 .srt 时你仍然需要自己确认时间码有没有被动过。项目的取舍也很清楚：它放弃了让模型参与断句和时轴优化的可能，换取时轴的绝对稳定。
格式转换与提取是顺带能力，不是主线
翻译过程中可以顺手做格式转换，README 列出的方向是 SRT 与 VTT 互转、SRT 或 VTT 转 ASS。另有一个提取功能，把 cue 和时轴剥掉，导出干净文本并自动复制到剪贴板，用途写的是给 AI 做摘要、写脚本或者内容再利用。这两个能力都不复杂，价值在于省掉一次工具切换。需要注意的是提取出来的纯文本已经丢失了时间信息，如果后续要重新对齐，你得回到原始文件。多语言输出是另一个实用点：一次翻译可以同时产出多个目标语言，每个语言导出为独立文件并在文件名里加语言码，例如 movie.zh.srt 和 movie.fr.srt。对于要给同一部剧配多语字幕的团队，这比跑多轮省事。
维护成本与许可证：MIT，但依赖面很宽
许可证是 MIT，仓库根目录有 LICENSE 文件。这意味着你可以修改、分发、商用，具体条款以 LICENSE 原文为准，这里不构成法律意见。真正影响长期成本的是依赖面：8 个传统翻译 API 加 27 个 LLM 提供方和网关，每一个都可能改接口、改鉴权方式或调整免费额度。README 列出的免费额度里，DeepL 是每月 50 万字符，Google 是每月 50 万字符，Azure 是前 12 个月每月 200 万字符，这些数字会变，项目本身无法控制。从版本节奏看，最近的发布是 v3.2.0（2026-09-09），前两次是 v3.1.1 和 v3.1.0，间隔大约一两周，说明维护是活跃的。但活跃不等于每个提供方都被及时跟进，接入前最好先确认你要用的那一个是否可用。
什么情况下不该用它
如果你的工作流需要重新断句、合并或拆分时间轴，这个工具从设计上就挡住了这条路，因为时轴在本地被保护起来，模型碰不到。如果字幕的源语言需要先做人工校对再翻译，批量投递会把这一步挤掉。如果组织要求翻译过程留服务端日志以便审计，浏览器端直连 API 的架构不满足这个要求，字幕内容和 Key 都在客户端。另外，README 里那句约 1 秒一集的性能说法，项目自己注明 GTX 会稍慢，而且它取决于提供方和网络，实际值需要你自己在一集上量一次。最后，如果你只有一两个文件要翻，批量能力用不上，直接用通用翻译器加人工核对时间码可能更省事。
编辑结论
如果你手上是整季的 .srt 或 .vtt，只想把对白换成另一种语言而完全不碰时轴，并且愿意自己准备 API Key，这个项目值得先跑一集验证。反过来，如果你的字幕需要重新断句、合并或拆分时间轴，或者你要求翻译过程可审计、可回滚到服务端日志，它就不合适，因为按文档描述，字幕内容和 API Key 都留在浏览器里，缓存也放在 IndexedDB。上手前先确认三件事：你要用的提供方是否被浏览器 CORS 放行，否则要自建 relay Worker；源文件是不是 WebVTT 且带 NOTE/STYLE/REGION 块，这类非 cue 块项目声称会跳过；以及 LLM 上下文模式下的模型规模，README 明确提示 70B 以下的模型可能出现输出错位。
社区笔记