TOML 繁中翻譯爭議紀實：事件經過與開源 AI 貢獻的教訓
想替開源專案送 AI 輔助的翻譯 PR，先照既有語系 PR 的慣例縮小範圍、只動語系檔，並主動說明工具用途與人工審校方式；被倉促關閉時先在原串或向其他維護者詢問，不要先拉到社群平台。這些做法來自 2026 年 10 月 toml-lang/toml.io 繁中翻譯提案的爭議，完整逐則紀錄整理在 TOML 繁中翻譯爭議：事件全紀錄 （GitHub repo）。
本文只摘要紀實網站已查核的公開紀錄，資料截點為 2026-10-27；發言內容屬當事人主張，不代表已證實的事實，也不是對兩版譯文品質的認證。時間以臺灣時間（UTC+8）表示。
事件時間線
時間 | 討論串 | 經過 |
|---|---|---|
10/23 22:11 | Issue #97、PR #98 | doggy8088 提案新增 |
10/23 22:15 | PR #98 | Copilot 自動審查指出英文備援字串可能繼承非英文的 |
10/23 22:17 | #97、#98 | 專案成員 arp242 將 issue 判定為 LLM 提示詞、要求不要用 agent 提交，同一秒以「不規劃處理」關閉 #97；23 秒後關閉 PR，未合併 |
10/23 22:32 | #97 | 提案者承認以 AI 協助撰寫翻譯與 issue，表示由自己負責；詢問是否有禁止 AI 的書面規則，提議縮小到首頁與 v1.1.0 |
10/23 22:42 | PR #98 | 修正 |
10/24 00:02 | #97 | 參與者 ShikiSuen 主張應區分在地化內容與程式碼貢獻 |
10/25 20:48 | Issue #99 | 提案者重開較短的新 issue，詢問是否願意接受繁中翻譯；同時在 Facebook 公開說明 PR 被拒的經過 |
10/25 22:01 | #99 | arp242 貼出該 Facebook 貼文連結質問提案者並關閉 #99，十秒後討論被鎖定為限協作者發言 |
10/25 22:18 | #99 | arp242 表示不反對繁中或其他語言，但期待經仔細驗證的人工翻譯；同時用貶抑措辭批評 AI 譯文，並對後續 zh-TW 譯稿表示懷疑 |
10/26 01:52 至 10:07 | #97 | d4n1elchen、brlin-tw、pcchou 等人陸續留言，分別談人工審校投入、提交方式與拒絕方式各自的問題 |
截至截點，三個討論串都沒有重開，PR #98 仍關閉未合併。
雙方的爭點
提案者 ：AI 和編輯器、拼字檢查一樣是工具，應依成果是否正確、是否遵循慣例審查；找不到禁止 AI 的貢獻政策，PR 卻在未審內容下被關閉。
維護者 ：讀者需要機械翻譯可以自己用工具；正式收錄到 toml.io 的應是仔細驗證的人工翻譯。他也認為重提 #99 是在掩飾同一做法，並指控提案者在 Facebook 煽動支持者。紀實網站將這些視為個別成員的指控與評價，不等同專案正式政策。
在地化社群成員 ：意見分歧。有人認為以 AI 使用方式一概拒絕在地化貢獻不公平，若不接受應寫進貢獻指南；也有人認為沒有明文規範時，本來就不該預設維護者歡迎 AI 生成的 issue 或 PR，並批評把爭議帶到社群平台接近群體施壓，同時要求維護者關閉時給出可操作的回饋。
送 AI 輔助翻譯 PR 前的檢查
從這次紀錄可以整理出幾個具體做法，不論專案是否有 AI 政策都適用：
先看同類 PR 的慣例 。同專案的俄文 #86、法文 #96、葡文 #65 翻譯 PR 都沒先開規格式 issue，說明以必要資訊為主。長篇、條列驗收條件的說明在維護者眼中反而像 agent 產出。
只動語系檔 。翻譯 PR 改到共用模板，審查範圍就從「這份譯文」擴大成「所有語系的頁面結構」，Copilot 抓到的
lang問題正是出在共用模板。介面字串在地化可以另開 PR。修正要推進 PR 分支 。在原 PR 回覆「已修正」前，確認 commit 出現在 PR 的提交清單；只存在 fork 的其他分支，審查者看到的仍是舊版本。
主動揭露 AI 用在哪個階段 ，並附可核驗的人工審校方式，例如逐段與英文對照的方法、具名審校者。「我已審閱過」很難讓維護者相信投入足夠。
被關閉時先在原串追問 ，或禮貌詢問其他維護者；社群平台是最後手段。維護者看到外部貼文連結，容易把後續支持留言解讀成動員。
對維護者這一側，留言中較一致的建議是：若不接受 AI 輔助的貢獻，寫進 CONTRIBUTING ，關閉時說明可修改後重送的條件，避免貢獻者猜規則。
紀實網站怎麼做
紀實網站以 jakeuj 委託 Codex 協作整理與發布，目標是分開呈現可查核的紀錄、發言者主張與無法確認的問題。主要設計：
資料與呈現分離 ：每則 GitHub 留言、review、行內意見與狀態事件存成 JSON，包含來源 ID、作者、時戳、編輯時間、回應關係與查核註記；正文是原創繁中轉述，不保留原文全文。
不靠 JavaScript 也能讀：
npm run build用 Node.js 22 以上、無外部 npm 依賴的腳本把全部正文寫進 HTML；JavaScript 只加搜尋、作者／討論串篩選、複製錨點與閱讀位置，不在訪客端呼叫 GitHub API。計數差額照實標示 ：16 筆 GitHub 紀錄、三篇 Facebook 貼文共 128 則可讀留言分開記錄截點。頁面計數與可讀數不符時保留差額，不補造父留言 ID，也不推測刪除者。
測試鎖住完整性：
npm test檢查來源覆蓋不遺漏、不重複，站內錨點都可到達，時間線依時間排序，分享圖為 1200 × 630 PNG。GitHub Pages 部署 ：推送
main後由官方 Pages Actions 建置、測試再發布dist/，沒有排程、資料庫或追蹤碼。
用 SHA-256 偵測來源變更
公開討論可能被編輯、刪除或新增留言。網站在 coverage.json 記下每個來源物件內文的 SHA-256、狀態事件 ID、PR head 與提交清單，登入 GitHub CLI 後跑唯讀檢查：
腳本用 gh api --paginate --slurp 完整分頁讀取三個討論串的主文、留言、reviews、行內留言與 timeline 事件，逐項比對：
檢查失敗時要重新擷取、逐則核對並修訂轉述，再更新清單與截點；不能只更新雜湊讓檢查通過。留言的最後編輯時間不是完整修訂歷史，舊快照中的段落另外標示，不混入目前的留言總數。