TranslateBooksWithLLMs：把整本書丟給 LLM 翻譯之前，先看它的分塊與續傳設計
Translate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.
秒懂
- 它是什麼？
- TBL 是一個 Python 桌面工具，用 Ollama 或雲端 LLM 翻譯 EPUB、SRT、DOCX、TXT，主打保留格式與中斷續傳。本文拆解它的分塊與檢查點機制、CLI 參數、以及 AGPL-3.0 帶來的採用成本。
- 適合誰用？
- 如果你要翻的是 EPUB、SRT 這類有結構的長文件，而且願意接受 AGPL-3.0 的授權條件，TBL 的檢查點續傳與格式保留是它最實際的價值；只翻幾段純文字、或想把翻譯功能嵌進閉源產品的團隊就該另找方案。動手前先跑一次 `ollama pull qwen3:14b` 與 `curl http://localhost:11434/api/tags` 確認本機推論可用，再拿一本真實 EPUB 走完 `python translate.py -i book.epub -sl English -tl Chinese`，實際檢查輸出的章節結構與樣式有沒有留下來。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是長文件的上下文斷裂，不是翻譯品質本身
一般 LLM 翻譯流程的死穴在長度。把一本三百頁的小說一次塞進 context 會爆，切成獨立段落送出去又會讓代名詞、稱謂、專有名詞在章節之間漂移。TBL 的定位就是在這兩者之間找一個可操作的切法：README 說它的 chunking 系統「preserves context between segments」，也就是切塊時仍帶著上下文，而不是把每個段落當成孤立字串。
目標使用者寫得很清楚。README 的 Quick Start 把首次啟動分成兩條路：本機路線是安裝 Ollama 後 `ollama pull qwen3:14b`，雲端路線是貼上供應商 API key。前者對應不想讓稿件離開自己機器的譯者與研究者，後者對應想用 Claude、Gemini 這類模型但不想自己寫排程腳本的人。介面是開在 http://localhost:5000 的網頁，所以它其實不是原生 GUI，而是一個本機服務加瀏覽器前端。
支援格式只有四種：EPUB、SRT、DOCX、TXT。這個清單本身就是篩選器。PDF 不在裡面，掃描書、學術論文、帶複雜表格的技術手冊都不是它的守備範圍。它要處理的是「已經有乾淨文字層與標記結構」的檔案。
格式保留是怎麼做到的：標記與時間碼分開對待
README 對格式的承諾講得很滿：「Every tag, every timestamp, every formatting detail is preserved.」這種說法需要拆開看。EPUB 的樣式、結構要留下來，代表流程不能在翻譯前把書壓成純文字再重新排版，必須在帶標記的片段上做替換，再把結果寫回原本的容器。SRT 更嚴格，時間碼與序號不能動，只有字幕文字那一行該被替換。這兩種格式的處理邏輯並不相同，但都指向同一個設計前提：翻譯單位不是整份文件，而是文件裡可替換的最小片段。
真正值得注意的是它對「風格」的處理。README 描述了一個 style preset 機制，可以從範例書中萃取風格，或手寫一份，然後套用到每一個 chunk 上，讓整本書的語域、節奏、意象維持一致。這解決的是切塊翻譯最常見的症狀：前十章用書面語、第二十章突然變成口語。
還有一個 Auto 模式。如果沒有現成的 glossary 或 preset，下拉選單選 Auto，應用程式會直接從正在翻譯的文件推導出這兩者，README 說明這是「one extra LLM call each before the job starts」，而且不會存檔。代價是每次任務開始前多兩次模型呼叫，換來的是不必事先準備術語表。對一次性專案合理，對要反覆翻譯同一系列作品的譯者就不划算，因為那些推導結果每次都會重來。
檢查點與續傳：中斷不重跑，但你要自己驗證顆粒度
README 對續傳的說法是「Interrupted translation? Pick up exactly where you left off. The checkpoint system saves progress automatically.」這是長文件翻譯最實用的功能，因為一本書跑幾小時甚至跨夜很常見，API 額度用完、本機斷電、模型服務重啟都會打斷流程。
但材料裡沒有交代檢查點的儲存位置、寫入頻率，以及「exactly where you left off」的單位是一個 chunk、一個章節還是整份檔案。這個差異很實際：如果顆粒度是章節，一個長章節失敗就要整章重翻，重複的 token 成本會落在你身上。README 也沒有說明續傳時會不會重新套用先前的 glossary 或 style preset。這些都只能靠實際跑一次中斷測試來確認，不能從文件推論。
First run 會在旁邊建立一個 `TranslateBook_Data` 資料夾存放設定，這是 README 明講的。檢查點是否也落在這裡、能不能手動備份或搬移，文件沒有說。對要把翻譯流程放進自動化管線的人來說，這是一個必須先量測的未知數。
從命令列跑：參數長相與供應商切換方式
除了桌面版，README 也給了 CLI 路徑。最基本的形式是 `python translate.py -i book.epub -sl English -tl Chinese`，輸出檔名會自動生成為「book (Chinese).epub」。來源語言用 `-sl`，目標語言用 `-tl`。
供應商靠 `--provider` 加對應的 key 參數切換。README 列出的寫法包括 `--provider openrouter --openrouter_api_key YOUR_KEY -m anthropic/claude-sonnet-4`、`--provider openai --openai_api_key YOUR_KEY -m gpt-4o`、`--provider gemini --gemini_api_key YOUR_KEY -m gemini-2.0-flash`、`--provider mistral --mistral_api_key YOUR_KEY -m mistral-large-latest`、`--provider deepseek --deepseek_api_key YOUR_KEY -m deepseek-v4-pro`、`--provider poe --poe_api_key YOUR_KEY -m Claude-Sonnet-4`，以及 `--provider nim --nim_api_key YOUR_KEY -m meta/llama-3.1-8b-instruct`。模型一律用 `-m` 指定。
本機路線有兩種。一種是 Ollama，另一種是 OpenAI 相容端點，README 點名 llama.cpp、LM Studio、vLLM、LocalAI，做法是「Point to your server's endpoint」。從原始碼安裝的步驟是 `git clone` 後進到 `TranslateBookWithLLM` 目錄，`ollama pull qwen3:14b`，Windows 跑 `start.bat`，Mac 與 Linux 跑 `chmod +x start.sh && ./start.sh`，網頁介面同樣在 http://localhost:5000。
要注意 README 的 clone 指令與 `cd` 目錄名稱並不一致：clone 的是 `TranslateBooksWithLLMs`，切換的卻是 `TranslateBookWithLLM`。這種細節在照抄指令時會直接失敗，屬於文件層面的瑕疵。
連線問題的排查方式文件也給了：Ollama 連不上先確認服務在跑，測 `curl http://localhost:11434/api/tags`；模型找不到就跑 `ollama list` 再看 `ollama pull model-name`。這兩個指令值得在正式跑書之前先確認過一次。
什麼情況下它會讓你失望
第一個限制是模型能力的天花板，而這個天花板不在 TBL 手上。它把 chunk 送給 Ollama 或雲端 API，譯文品質完全由那個模型決定。README 把品質基準放在 wiki 上，並要讀者「Find the best model for your target language」，等於承認不同語言對模型的要求差很多。用小參數本機模型翻文學作品，格式會留著，讀起來可能還是不行。
第二個是它對檔案結構的依賴。EPUB 與 SRT 的格式保留之所以做得到，是因為這兩種格式的文字與標記是可分離的。遇到排版混亂、樣式層層疊套、或文字被拆散在大量 span 裡的 EPUB，替換邏輯能不能撐住，文件沒有給出邊界條件。PDF 直接不在支援清單內。
第三個是成本控制。README 強調「No size limit」，千頁小說也能跑，但沒有提到任何 token 預算、速率限制處理或費用估算。雲端供應商按量計費，一本書的呼叫次數可能相當可觀，而 Auto 模式還會在開始前多打兩次。文件裡看不到暫停或限速的設定項。
第四個是它終究是一個本機網頁應用。要放進 CI 或排程系統，得自己處理服務的啟停與 5000 埠的佔用，README 沒有提供無介面模式或容器映像的說明。
對照組：用通用文件翻譯工具或自己寫腳本
同類工具的典型做法是走文件解析框架，把 EPUB 或 DOCX 轉成中繼格式（例如 XLIFF 或內部段落清單），逐段送翻譯引擎，再組回原格式。這條路線的優勢是格式轉換邏輯成熟、支援的檔案類型多，而且通常能接上傳統 CAT 工具鏈與翻譯記憶庫。代價是段落之間沒有共享上下文，風格一致性要靠術語表與記憶庫人工維持。
TBL 的差異就在這裡：它把「上下文跨 chunk 傳遞」與「style preset 套用到每個 chunk」當成核心設計，而不是靠外部記憶庫補救。反過來說，它沒有翻譯記憶庫、沒有多人協作、沒有 CAT 工具那種逐句確認的工作流。
另一條路是自己寫腳本，用 `openai` 或 `ollama` 的 Python 套件接 API。這樣做彈性最大，但要自己實作分塊、格式回寫、續傳與失敗重試。TBL 的價值基本上就是這四件事已經寫好了，代價是你得接受它的切塊策略與 AGPL-3.0。
授權與維護：AGPL-3.0 決定了誰能用
專案採用 AGPL-3.0。這個授權的關鍵在於網路服務條款：如果你修改 TBL 並讓使用者透過網路與它互動，你必須提供對應的原始碼。對內部自用、對個人譯者、對願意開源的專案，這不構成問題。對想把翻譯能力包進自家閉源 SaaS 的團隊，這是一道硬牆，而且不是換個函式庫就能繞過的。本文不提供法律意見，實際條款以 LICENSE 原文與你的法務判斷為準。
維護節奏可以從版本紀錄看出輪廓。近三個版本是 v1.5.8、v1.5.9、v1.5.10，其中 v1.5.8 與 v1.5.9 都在 2026 年 8 月 24 日發布，v1.5.10 在 2026 年 9 月 6 日。八月底到九月初之間連出三個版本，屬於密集修補期。這代表專案仍在活躍維護，也代表介面或行為可能在短時間內變動，升級前最好先看 release notes。
升級成本主要落在兩處：一是 `TranslateBook_Data` 裡的設定與 glossary、style preset 是否相容；二是檢查點格式若改變，進行中的翻譯任務可能無法接續。文件沒有提供版本間遷移說明，這是採用前該問清楚的問題。
供應商清單本身也是維護負擔。八家供應商、各自的 API 變動與模型命名（例如 `deepseek-v4-pro`、`Claude-Sonnet-4`、`anthropic/claude-sonnet-4` 這種大小寫與斜線規則不統一）意味著任何一家改端點，這個專案就得跟著發版。
編輯結論
如果你要翻的是 EPUB、SRT 這類有結構的長文件，而且願意接受 AGPL-3.0 的授權條件，TBL 的檢查點續傳與格式保留是它最實際的價值；只翻幾段純文字、或想把翻譯功能嵌進閉源產品的團隊就該另找方案。動手前先跑一次 `ollama pull qwen3:14b` 與 `curl http://localhost:11434/api/tags` 確認本機推論可用，再拿一本真實 EPUB 走完 `python translate.py -i book.epub -sl English -tl Chinese`，實際檢查輸出的章節結構與樣式有沒有留下來。
社群筆記