上星期突然想到是否可以請 Claude Code 寫個程式來幫我翻譯？
之所以要這麼搞剛，是因為 Web AI 都聽不懂人話居多，請他逐字逐字翻譯，結果都無法照做？當然也有可能是我不會用導致？不過，我並沒有用其他第三方的 AI 網站，而是直接使用我有訂閱的 Gemini 或是 Claude。
一開始 Claude 就知道要用 PyMuPDF 來處理 PDF，不過，對於圖表或是程式碼的判斷差強人意。
隔天有空搜尋了一下，原來這套軟體非常有名，大家都是使用他來處理 PDF。
官方也很貼心的提供一個範例，並將翻譯過的內容使用圖層的方式貼到原本文字上，這意味著當翻譯不好時，我們隨時可以關掉圖層直接看原文，這實在是很方便的一個功能。
於是我第二版的程式就以官方範例為底稿，直接請 Claude Code 增添功能。
配合圖層的設計，終於我也有一個堪用的 PDF 翻譯工具了。
過程中，也釐清了一些我原來不懂的問題。
也許網路上還有更好的解法，但現在的方法對我來說已經夠用了，缺點就是要花時間把手邊一些文件重新翻譯。
NotebookLM 不是說不好，但有些時候，你還是需要閱讀原文才知道 AI 是不是有誤會什麼？
下面節錄我請 AI 整理的報告內容
七、關於 PDF 格式語意結構的討論
--------------------------------
問：check.py 都是自己判斷格式，是 PDF 格式沒有定義，還是函式庫的問題？
答：主要是 PDF 格式本身的設計所致，與函式庫（PyMuPDF）無直接關係。
PDF 的設計初衷是「視覺呈現」，儲存的是：
- 文字的座標、字型、大小
- 圖片像素資料
- 向量圖形繪圖指令
PDF 格式本身不儲存語意結構，不知道「這段是頁首」「這段是程式碼」。
PDF 有一個選用規格稱為 Tagged PDF（PDF/UA），允許文件作者加入語意標籤：
<H1> 章節標題 </H1>
<P> 段落文字 </P>
<L> 清單（項目符號）</L>
<Table> ... </Table>
PyMuPDF 可以讀取這些標籤，若 PDF 有正確標注則不需要啟發式規則。
本文件的實際情況：
- 產生工具：PDFium
- Tagged PDF：否（未加語意標籤）
- PyMuPDF 回傳的 XML 標籤（block、line、char）是函式庫自行解析的
幾何結構，並非 PDF/UA 語意標籤
- 結論：PyMuPDF 無從得知各 block 的語意角色，因此必須以啟發式
規則（正規式、座標範圍、關鍵字）自行推斷
簡言之：這是絕大多數市面上 PDF 的共同現況，並非 PyMuPDF 的限制。
八、目前已知限制與未來改進建議
--------------------------------
1. 項目符號：僅跳過 • 等符號開頭的 block，若使用其他少見符號需手動擴充
BULLET_PATTERN。
2. 程式碼偵測：以「同時含 { 與 ;」為條件，可能誤判含這兩個字元的自然語句。
更精確的做法是檢查文字區塊所使用的字型名稱（等寬字型如 Courier、
Consolas 通常代表程式碼）。
3. 頁首／頁尾：比例閾值（8%）適用於大多數標準排版，但若文件邊距特別大
或小，可能需要調整，或升級至方案 B（自動偵測重複內容）。
4. 表格偵測：PyMuPDF 的 find_tables() 對有明顯框線的表格效果佳，對無框線
表格可能漏判。安裝 pymupdf_layout 套件可提升偵測精確度。
5. 翻譯品質：使用 Google Translate API（免費版），有次數限制與品質限制，
專業術語翻譯可能不準確。
有了 AI 不用白不用，以下是 Web Claude 給的解決方案
英文技術文件翻譯成中文：5 個最佳方案
針對技術文件的完整翻譯，我為你整理了五個經過實測效果不錯的方案，並依照不同使用情境分類。
方案一：Claude / ChatGPT / Gemini（大型語言模型）
直接將文件內容貼到對話框，或上傳檔案請 AI 翻譯。
優點
- 翻譯品質目前在技術文件領域是最高的，能理解上下文、保留技術術語的一致性
- 可以下指令客製化，例如「保留程式碼區塊不翻譯」、「使用台灣繁中習慣用語」、「術語表優先」
- 能處理 Markdown、HTML 等格式，輸出後排版幾乎不需要再整理
- 遇到模糊語意時會根據語境合理判斷，而非機械式直譯
缺點
- 長文件需要分段處理，否則容易遇到輸出長度限制（通常一次 3000–5000 字較穩定）
- 不同段落之間的術語一致性需要自己維護術語表，或在 prompt 中明確指定
- 免費版本通常有用量限制，重度使用需要訂閱
- 偶爾會出現幻覺，特別是專有名詞或版本號，需要人工校對
最適合： 重視翻譯品質、文件量中等（一份文件數千到數萬字）、願意動手調整 prompt 的人。
方案二：DeepL（含 DeepL Pro / DeepL Document Translator）
專注於翻譯的服務，支援 .docx、.pptx、.pdf、.txt 等檔案上傳，整份翻譯後下載。
優點
- 翻譯流暢度極佳，中文輸出比 Google 翻譯更自然
- 文件上傳後會完整保留原始排版（字型、表格、圖片位置）
- 操作極簡，零學習成本
- 有 API 可串接到自己的工作流程
缺點
- 對於最新的技術術語（特別是 AI、區塊鏈等新領域）有時不如 LLM 精準
- 免費版有每月字數和檔案大小限制（單檔約 5MB、每月 3 份）
- 無法針對特定術語做客製化翻譯記憶（這是 Pro 才有的 Glossary 功能）
- 對程式碼區塊的處理不如 LLM 細緻，有時會誤譯變數名稱
最適合： 需要保留原始檔案排版、追求穩定輸出、不想花時間調整參數的人。
方案三：Immersive Translate（沉浸式翻譯）瀏覽器擴充功能
主要用於網頁翻譯，但也支援 PDF、EPUB 等文件，採雙語對照顯示。
優點
- 雙語對照模式對技術文件閱讀極友善，原文與譯文並列方便核對
- 可以串接多種翻譯引擎（Google、DeepL、OpenAI、Claude、自訂 API 等）
- 支援線上文件（GitHub README、官方文件網站）即時翻譯
- PDF 翻譯保留原始排版，輸出雙語 PDF
- 免費版功能已足夠日常使用
缺點
- 串接 OpenAI/Claude API 需要自己申請金鑰並支付費用
- PDF 翻譯的進階功能（如完整檔案翻譯下載）需要 Pro 訂閱
- 對於要交付的「翻譯成果」不是最佳選擇，比較適合自己閱讀
- 排版複雜的 PDF 偶爾會出現對位錯誤
最適合： 主要是「自己要看懂」技術文件、會頻繁瀏覽英文網頁文件、想要保留原文對照的人。
方案四：Crowdin / Lokalise / Weblate（專業在地化平台）
針對軟體與技術文件設計的協作翻譯平台，支援多種檔案格式（Markdown、JSON、PO、XLIFF 等）。
優點
- 有完整的翻譯記憶庫（TM）和術語表（Glossary）功能，確保跨文件術語一致
- 支援團隊協作、版本控管、審校流程
- 可直接串接 GitHub/GitLab，文件更新時自動同步
- 整合機器翻譯（MT）作為初稿，再由人工校對
- 適合長期維護的文件專案
缺點
- 學習曲線較陡，初次設定需要花時間
- 主要為團隊與企業設計，個人偶爾使用過於笨重
- 免費方案限制較多（Crowdin 有開源專案免費方案，Lokalise 沒有真正的免費版）
- 不適合一次性的翻譯任務
最適合： 持續維護的技術文件（如開源專案 docs、產品手冊）、團隊協作、需要版本控管的場景。
方案五：Google 翻譯（含 Google Docs 內建翻譯 / Google 文件翻譯）
老牌通用翻譯工具，可直接上傳文件或在 Google Docs 中使用「翻譯文件」功能。
優點
- 完全免費，無使用量限制
- 支援格式廣泛，文件上傳可保留基本排版
- 速度極快，整份文件幾秒鐘完成
- 與 Google Workspace 整合良好
缺點
- 翻譯品質在技術文件上明顯落後於 DeepL 和 LLM，中文常有「翻譯腔」
- 不擅長處理技術術語，有時會把專有名詞硬譯
- 無法客製化術語或語氣
- 程式碼區塊處理粗糙
最適合： 對品質要求不高、需要快速理解大意、預算為零的場景。
我的建議組合
如果是要交付的正式翻譯成果，實務上最有效率的做法是混搭：
LLM（Claude/ChatGPT）做初翻 → 人工校對 → DeepL 或 Immersive Translate 對照檢查
如果你能告訴我這份技術文件的類型（API 文件？產品手冊？學術論文？）、長度，以及翻譯後的用途（自己看 / 交付給客戶 / 發佈），我可以給你更具體的方案推薦。
