Subtitle Translator：把整季字幕丟進去，時軸留在本地
Translate a whole season of subtitles in one pass — .srt/.ass/.vtt/.lrc, 120+ languages, 27 LLM providers, timing untouched ｜ 整季字幕一次译完，时轴不动，支持 120+ 语言
秒懂
- 它是什麼？
- 這個專案把字幕的時軸與對白在本地拆開，只把對白送去翻譯引擎，再用批次與快取處理整季檔案。核心判斷是：它適合怕時軸被改壞、又不想一個檔一個檔慢慢翻的人，但不適合期待開箱即用高品質文學翻譯的人。
- 適合誰用？
- 如果你手上是一整季的 .srt 或 .ass，最在意的是時間碼一個字都不能動，而且願意自己申請一組 API key，Subtitle Translator 的結構分離與 IndexedDB 快取正好對上這個需求；反之，如果你需要的是逐句校對、術語表控管或專業字幕軟體的排版能力，這個工具不會幫你解決，翻譯完仍要進 Aegisub 之類的編輯器處理。採用前先驗證三件事：用你的實際檔案格式跑一次單檔，確認輸出的時軸與原檔逐行一致；確認你選的供應商是否被 CORS 擋住而需要走 Relay；以及用 CLI 跑一次同樣的檔案，確認瀏覽器與命令列兩條路徑的結果一致。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是通用翻譯工具改壞時軸這件事
把一份 .srt 貼進 ChatGPT 或 Google 翻譯，通常會發生兩件事。第一，模型會把時間碼當成文字的一部分重寫，00:01:23,456 變成 00:01:23.456 或直接被省略；第二，你只能一個檔一個檔來，一季十二集就是十二次複製貼上。Subtitle Translator 的 README 開頭就是把這兩個痛點寫成產品定位：時軸在本地被剝離，只有對白被送到引擎，時間軸在物理上不可能被動到。
目標使用者相當明確。做字幕組或個人漢化的人、需要把技術演講或訪談上字幕的人、手上有一批 .lrc 歌詞要轉語言的人。這些人的共同點是檔案數量多、格式雜、而且對時間碼的容忍度是零。相對地，如果你只是偶爾翻一集影片，用什麼工具差別不大。
結構分離：本地拆解、雲端只碰對白
README 描述的做法是先把檔案解析成結構與文字兩部分。時間碼、cue 編號、ASS 的 header、VTT 的 cue ID 全部留在本地，送出去的只有對白文字。翻譯回來之後再按原本的順序重組。這就是為什麼它敢說時軸不會被改動：不是靠提示詞約束模型，而是模型根本沒看到時間碼。
格式支援涵蓋 .srt、.ass、.vtt、.lrc，自動偵測。README 特別提到 WebVTT 的 NOTE、STYLE、REGION 這類非 cue 區塊會被正確跳過，不會被當成對白送去翻譯。這一點值得注意，因為很多簡單的解析器會把這些註解一起翻掉，結果在播放器裡出現莫名其妙的字幕行。
翻譯流程本身是分塊壓縮加平行處理。LLM 模式下有所謂的上下文感知：每個批次會夾帶前後若干行作為 context，讓對白連貫、角色語氣一致。相關的兩個設定是 Concurrent Lines（預設 20，同時翻譯的行數上限）與 Context Lines（預設 50，每批夾帶的上下文行數）。README 直接點出這兩個值的取捨：Concurrent Lines 開太高會撞到速率限制，Context Lines 開高則連貫性更好但 token 消耗更多。
這裡有一個 README 自己標註的限制：參數低於 70B 的模型在上下文模式下可能產出對不齊的結果，官方建議用 Claude、GPT、DeepSeek、Gemini 這類主流線上大模型。這等於承認本地跑小模型雖然可行，但對齊品質不保證。
快取放在 IndexedDB，重新整理不會丟檔案
所有翻譯結果快取在瀏覽器的 IndexedDB 裡，README 說沒有瀏覽器儲存空間上限，重新整理頁面不會遺失已翻譯的檔案。這個設計對批次工作是實際有用的：一季十二集跑到第八集斷線，重跑時前七集直接命中快取而不用再付一次 API 費用。
代價是快取綁在瀏覽器設定檔上。換一台機器、換一個瀏覽器、或清掉站點資料，快取就沒了。專案沒有提到跨裝置同步快取的機制，所以如果你的工作流程橫跨多台電腦，得自己把輸出檔案留好，不要只依賴快取。
另一個實際的隱私說法是：整個工具跑在客戶端，字幕內容與 API key 不經過專案方的伺服器，LLM 請求從瀏覽器直接打到你設定的 API 端點。這個描述在架構上說得通，但也意味著你的 key 存在瀏覽器裡，共用電腦時要留意。
27 家 LLM 與 8 家傳統 API，以及 CORS 這道牆
傳統機器翻譯 API 有 8 家：DeepL、Google、Azure、DeepLX、Qwen-MT、TranslateGemma、GTX、Edge。其中 GTX 與 Edge 完全不需要設定，是零配置的預設值，而且互為備援。README 對這兩者的穩定性評為三星，屬於能用但別指望它承擔正式專案的程度。
LLM 供應商與閘道合計 27 家，包含 DeepSeek、OpenAI、Claude、Gemini、Qwen、Moonshot、Doubao、Zhipu GLM、MiniMax、Mistral、xAI、Perplexity、Cohere、YandexGPT，以及 OpenRouter、Groq、SiliconFlow、GitHub Models、Nvidia NIM、Azure OpenAI、LiteLLM 等閘道，另外還有任何 OpenAI 相容的自訂端點（Ollama、LM Studio、vLLM 等）。
這裡有個容易被忽略的現實問題：瀏覽器有 CORS 限制，部分供應商不允許從瀏覽器直接呼叫。README 的解法是走 API relay，內建 relay 開箱可用，也可以在 API Settings 的 Relay address 指向自己部署的 relay Worker。換句話說，這個工具在「純客戶端」的宣稱下，實務上仍可能需要一個中間層，而那個中間層是你自己維運的。這不算缺點，但採用前應該知道。
跑起來：從網頁到 yarn cli
最短路徑是直接用線上版：https://tools.newzone.top/en/subtitle-translator。把整季的 .srt 拖進去，選目標語言，選引擎。GTX 與 Edge 不用填 key，其他供應商要在 API Settings 裡填。
要腳本化的話，README 給的命令是 yarn cli，說明它跑的是同一套引擎、解析器與快取。也就是說瀏覽器版與命令列版在解析與翻譯邏輯上共用程式碼，這對需要排程或整合進既有流程的人有用。
值得留意的幾個操作細節。批次處理是每個檔案獨立翻譯、獨立下載，並保留原檔名，跑完會給一個彙總的成功失敗統計，README 舉的例子是 Exported (3/5)。多目標語言是同一趟跑出多個檔案，語言碼接在檔名後面，例如 movie.zh.srt 與 movie.fr.srt。雙語輸出可以把譯文插在原文上方或下方。如果來源是 SRT 或 VTT，還能匯出成 ASS，並套用兩套樣式：Default 70pt 白色與 Secondary 55pt 青色，之後可以在任何字幕編輯器裡調整。
另外有一個和翻譯無關但實用的功能：字幕萃取。把 cue 與時間碼剝掉，匯出乾淨的文字並自動複製到剪貼簿，適合拿去做摘要或改寫。
什麼情況下它會讓你失望
第一個限制寫在 README 裡：上下文模式下小於 70B 的模型可能產出對不齊的結果。這代表「用本地 Ollama 跑一個 7B 模型來省錢」這條路，在需要上下文連貫的模式下是有風險的。
第二個是格式轉換的單向性。README 列出的一鍵轉換是 SRT ↔ VTT 以及 SRT/VTT → ASS，沒有 ASS → SRT 這條路。如果你的來源素材是 ASS 而目標是 SRT，這個工具不會幫你轉。
第三個是品質的性質。機器翻譯 API 與 LLM 都能把對白換成另一種語言，但兩者都不會處理字幕的閱讀節奏。一行對白在原文裡是 12 個字，翻成中文可能變成 30 個字，超過單行顯示寬度就會被播放器折行或截斷。這個工具負責對齊與時軸，不負責斷行與每行字數控制。字幕組的實際做法仍是翻完匯入 Aegisub 之類的工具手動調整。
第四個是 API 成本。README 說快取沒有大小限制，但沒有說翻譯本身免費。整季字幕、多目標語言、LLM 模式加上 50 行上下文，token 消耗會比你想像的高。快取只在你重跑同一份檔案時省錢，第一次跑該付的還是要付。
和同類做法的差異：DeepL 官方工具與通用 LLM 對話
最直接的對照是 DeepL 自己的文件翻譯與字幕功能。DeepL 的優勢是品質穩定、不需要自己管 key 的輪替，但它是單一供應商，語言與模型選擇受限，而且你要把整份檔案交給它處理，時軸保護取決於對方的解析器。Subtitle Translator 走的是相反路線：把結構留在本地，引擎可替換，代價是你得自己申請與管理 API 憑證，還要面對 CORS 與 relay 的維運。
另一個對照是直接把字幕貼進 LLM 對話視窗。那條路零設定，但沒有快取、沒有批次、沒有格式解析，而且時軸幾乎一定會被改動。Subtitle Translator 的價值不在翻譯品質比 LLM 好，而在於它把「解析、切塊、平行、快取、重組」這幾件事自動化，而這些正是手動貼上時最容易出錯的部分。
選擇的關鍵因此不是「哪個翻得比較好」，而是「你願不願意為了保住時軸與批次效率，付出管理 API 憑證的成本」。
授權、維護與升級成本
專案採 MIT 授權，這意味著你可以自由使用、修改、再散布，包含商業用途，只要保留著作權與授權聲明。這對要把它整合進內部流程的團隊是低摩擦的。實際的授權條款仍應以倉庫中的 LICENSE 檔案為準，本文不構成法律意見。
維護節奏從版本紀錄看得出來：v3.1.0 在 2026-08-23，v3.1.1 在 2026-09-01，v3.2.0 在 2026-09-09，大約一到兩週一個版本，最後推送時間與最新版本同一天。這種節奏通常代表專案在活躍開發中，但也代表介面與設定有可能變動。
升級成本主要落在兩處。一是 API 設定，供應商清單與 relay 位址會隨版本調整，自架 relay 的人要跟著更新。二是快取結構，如果 IndexedDB 的 schema 在新版本改變，舊快取可能失效，屆時重跑就等於重新付一次翻譯費用。這兩點在版本紀錄裡沒有明說，屬於採用時要自己觀察的部分。
另外，專案本身是 MIT，但你串接的翻譯 API 各有自己的服務條款與計費方式，DeepL、Azure、OpenAI 這些的授權與用量限制和本專案無關，要分開確認。
編輯結論
如果你手上是一整季的 .srt 或 .ass，最在意的是時間碼一個字都不能動，而且願意自己申請一組 API key，Subtitle Translator 的結構分離與 IndexedDB 快取正好對上這個需求；反之，如果你需要的是逐句校對、術語表控管或專業字幕軟體的排版能力，這個工具不會幫你解決，翻譯完仍要進 Aegisub 之類的編輯器處理。採用前先驗證三件事：用你的實際檔案格式跑一次單檔，確認輸出的時軸與原檔逐行一致；確認你選的供應商是否被 CORS 擋住而需要走 Relay；以及用 CLI 跑一次同樣的檔案，確認瀏覽器與命令列兩條路徑的結果一致。
社群筆記