跳轉到

中文化與文件翻譯

文件站三語同步流程

anoni.net 文件站維護 zh-TW、zh-CN、en 三個語系。zh-TW 是 single source of truth，新文章先寫 zh-TW，zh-CN 從 zh-TW 同步，en 的做法見下方「zh-TW → en」。

zh-TW → zh-CN

社群用 AI 協作工具直接翻譯做候選稿，不採 OpenCC 半自動方式，用哪一家的服務都可以（入口檔與角色分工見貢獻者百科的「AI 協作」一節）。理由：

  • OpenCC 的 phrase 庫對「核心」這類詞會誤譯成「内核」（kernel 語境替換誤套）
  • 純機翻無法做語境化的政治措辭調適與讀者輪廓判斷
  • zh-CN 既有的人類校對檔已示範這個深度（例如針對 zh-CN 讀者輪廓寫的政治脈絡描述）

每篇翻譯流程：

  1. AI 工具讀 zh-TW 來源檔
  2. 同時做台繁→簡 + 台式→中式詞彙轉換（網路→网络、資料→数据、檔案→文件、影片→视频、伺服器→服务器、訊息→消息、預設→默认、連結→链接、登入→登录、註冊→注册等）、政治措辭適配、外部連結適配
  3. 保留：技術術語英文原文（Tor、Tails、OONI、ASN、VPN）、品牌名 anoni.net、URL、code 區塊
  4. 輸出到 zh-CN 對應位置
  5. 維護者在上線前審過詞彙與政治措辭差異，合入。審過就是上線的條件，檔案裡不另外標註「AI 候選稿、待校對」

重要規則：

  • 結構搬遷時不重翻覆蓋既有檔案。zh-CN 既有人類校對的內容直接 git mv，只調整 frontmatter 與內部連結
  • 同步機制：當 zh-TW 既有檔案有更新時，做 zh-TW 新舊 diff、把 diff 套到 zh-CN，不是用最新 zh-TW 整個重翻覆蓋
  • 標點集合保持台繁版本「、」「，」「。」「：」「「」」「（）」（簡中渲染相容、與 zh-TW 一致）

zh-TW → en

en 的定位與 zh-CN 不同，是策展型的原創軌道，不逐頁對應 zh-TW，也不追求頁數對齊。判斷一頁要不要進 en 只看一件事：這個主題在英文世界有沒有別人（EFF、Tor Project、OONI 等）寫得更完整、更權威。有的話連過去，不自建。沒有的話就是 en 該做的內容，例如台灣的觀測資料、社群本身的介紹與路線圖、想對國際讀者說明的原創觀點。blog 的 en 版同樣處理：來源多半本來就是英文，不必逐字翻 zh-TW，改寫成 anoni.net 的英文觀點，文首用 !!! info "" 放原文連結，補上台灣與華語區的角度。英文版的完整說明見 English 版的 i18n 頁。

決定要進 en 的頁面，需要的人工比 zh-CN 多，因為文化脈絡轉換比語系翻譯費時。流程跟 zh-CN 類似但更倚重人類校對：

  • AI 工具起草初譯
  • 在地脈絡（台灣法規、政治敏感詞）需要重新組織說明，給國際讀者背景
  • 連結優先選國際讀者熟悉的來源（例如 EFF、Reuters、HRW，而非台灣媒體中文版）

zh-CN 與 en 的翻譯不必同步上線，依社群人力滾動處理。每次只修一個語系時，記得在 PR 描述標註「zh-CN/en 待同步」。

校對時要抓的是翻漏

英文版補齊的三個批次執行品管管線時，最難發現的一類問題是 zh-TW 寫明的具體資訊在英文版被換成上位詞或泛稱。單看英文完全通順，事實查核也會通過，因為每一句都是真的，少掉的是原文有的細節。實際掉過的例子：

  • 中國、伊朗、白俄羅斯變成 several countries
  • Gmail、Discord 變成 messaging platforms
  • Chainalysis、Elliptic、TRM Labs 變成 chain analysis firms
  • 紐約時報、衛報變成 major outlets
  • 自然人憑證、健保署變成 government services

判準是 zh-TW 有具名的國家、公司、產品、機構、法條、數字，en 換成上位詞或整段消失，就列為候選。

跟上面第二條要分開看。譯者為國際讀者主動增補的背景說明是 en 版該有的東西，不算翻漏。要抓的是 zh-TW 有、en 該有卻掉了的具名資訊。

檢查方式是拿 zh-TW 對著 en 逐段比。docs-style-lint 抓不到這一類，它是單檔掃描，看得到粗體句開頭、冒號標題、擬人化，看不到跨語系的落差。品管配置雙語對照的 lens 時，任務描述要寫明「找 zh-TW 有而 en 沒有的具名資訊」。只寫「檢查誤譯」的話，通常只會比對已經寫出來的部分，缺口不會被翻出來。

同一套判準適用 zh-TW → zh-CN。簡繁之間文化脈絡接近，泛化的動機比較少，實際發生率低很多。

相關規則檔

  • 寫作風格、品牌名稱與受眾見貢獻者百科的「寫作風格規範」
  • 目錄歸屬與分類見貢獻者百科的「檔案命名與目錄」，實際的 nav 以 mkdocs.yml 為準

翻譯外部文章到 blog

Tor Project、OONI、EFF 這類組織的部落格文章，會整理翻譯成文件站的 blog，並補上在地觀點。想推薦值得追蹤的來源，用 GitHub 的「來源建議」issue 範本。

順序與校稿停點

  1. 先寫 zh-TW：整理翻譯原文，文末寫台灣脈絡的觀點段。寫完先停下來校稿，詞彙與觀點段確定之後才往下做。
  2. zh-CN 與 en 一起做。zh-CN 以校過的 zh-TW 為準，改成簡體與中國用語，觀點段改寫成中國境內與使用簡體中文地區（含海外華人）的視角。en 照上方「zh-TW → en」的定位，不逐字翻，改寫成 anoni.net 的英文觀點，沒有英文讀者需要的新內容時可以不做 en。
  3. 兩個版本也校稿之後，三個語系（或兩個）放在同一個 PR 送出。

檔案與 front matter

  • 放在 docs/<lang>/blog/posts/，三個語系的檔名與 slug 相同
  • date 用發布當天
  • categories 加上 翻譯文章、翻译文章、Translated Article，其餘沿用主題分類
  • summary 與 description 交代這篇整理了什麼、文末補了哪些在地觀點
  • image 可以用原文的主視覺，圖片來源寫在文末

內文結構

  • H1 之後第一個區塊是 !!! info ""，註明原文出處，常見寫法是「以下內容原文翻譯來自以下文章，主詞角色為 Tor Project：」，接著列原文標題、日期與連結
  • 前言之後放 <!-- more -->，分隔 blog 列表頁的摘要
  • 術語第一次出現用註腳補白話說明，站內有對應的頁面就連過去
  • 文末放在地觀點段，zh-TW 是台灣脈絡，zh-CN 是中國境內與海外華人的視角，最後列出原文全文與圖片來源。需要時加「相關閱讀」連到站內文章
  • en 開頭的 info 區塊寫明這篇建立在哪一篇原文上，並連到兩個中文譯本

寫作規則照貢獻者百科。校稿時同樣要抓上方「校對時要抓的是翻漏」那一類問題。

社群參與過的上游翻譯

社群對外貢獻的翻譯工作會記在這裡。每個案例附起點 PR、翻譯平台、完成 release，方便接手的志工知道從哪裡延續。

CryptPad（zh_Hant、zh_Hans）

項目 內容
上游專案 CryptPad（XWiki SAS 開發，AGPLv3）
翻譯平台 Weblate cryptpad
範圍 主應用、Accounts plugin、User Guide 全部子段，合計上千條字串
起點 PR cryptpad#1329（2023/12/05，修正語言選單用詞並詢問新增 zh_Hant 流程）
完成回報 Issue cryptpad#2237（2026/03/13）
收進 release CryptPad 2026.5.0（2026/05/13，含 locale alias 機制 #2254）
累計工作時間 約兩年半

完整敘事見 CryptPad 2026.5.0 上線：正體中文（zh_Hant）正式收進內建語系。要接著補新版本字串或修錯字，直接到 Weblate 上的 zh_Hant 專案 提交。

上游翻譯工作流：從 Weblate 到 release

想參與某個開源專案的中文化，可參考下列流程。CryptPad 的兩年半經驗大致照這條走完一輪。

1. 確認專案的翻譯平台與貢獻管道

開源專案常見的翻譯平台是 Weblate 與 Transifex，少數會自架。先到專案的 GitHub README、CONTRIBUTING.md、或官網「Localisation」分頁找連結。沒有現成連結時，到 issue tracker 開一個「How can I contribute zh_Hant translation?」詢問。

2. 註冊翻譯平台帳號、找對應子專案

確認專案是否已開 zh_Hant、zh_Hans 兩個語系子專案。沒有的話，請 upstream 維護者開（CryptPad 的 PR #1329 就是這一步）。

3. 翻譯時保留三件事

  • 介面情境：每條字串要對齊它在介面出現的位置，翻譯前先把 app 啟動起來看看，避免「儲存」、「另存」這類詞混用。
  • 既有詞表：先翻過幾條後就會建立詞彙慣例，後面要保持一致。多人協作時建議在 issue 或 pad 上維護詞彙表。
  • 不要過度本地化：技術術語（API、Tor、relay、E2EE）保留英文原文，比硬翻成中文更貼近實際使用脈絡。

4. 主動跟 upstream 維護者溝通

翻完一個子專案後，到 issue tracker 開 issue 回報進度，請 upstream 在下一個 release 啟用為內建語系。具體做法可參考 cryptpad#2237。沒有主動回報，翻譯有可能停在 Weblate 上不會自動進到 release。

5. release 之後持續維護

軟體會繼續開發，新功能會帶來新字串，每個版本上線前都建議回頭再校一輪。Weblate 上沒翻完的字串會顯示為「未翻譯」，定期掃一遍就能跟上版本。

6. 跟社群分享

完成後在 anoni.net 社群 Matrix 或社群 newsletter 上 announce 一次，把案例補到本頁的「社群參與過的上游翻譯」表格，方便日後有人接力或想複製這套流程。

找翻譯夥伴一起做

上千條字串的工作量一個人扛兩年很累，找 2-3 個夥伴分頭負責不同子專案，整體進度會穩定很多。CryptPad 案例最後是社群成員協同完成的。要找夥伴可在社群 Matrix 公開徵集，或來信 whisper@anoni.net。

OONI 工具

OONI 目前有許多工具與網站服務透過 Transifex 協作翻譯平台進行，請先在平台上註冊後，再依各產品前往協助翻譯。

  1. OONI Probe 應用程式：加入翻譯專案，並閱讀翻譯手冊。
  2. OONI Explorer：加入翻譯專案，並閱讀翻譯手冊。
  3. OONI Run：加入翻譯專案。

前往翻譯

如果你已有相關中文化與翻譯的經驗，歡迎直接前往各翻譯專案頁面加入翻譯。

OONI Blog

OONI Blog 上有審查事件分析、方法論更新與各國觀測報告。社群會挑跟台灣、華語區相關的文章，寫成 anoni.net 的中文 take（附原文連結、補上在地觀點），不做逐字翻譯。想認領某篇來改寫，到社群 Matrix 提出即可。

Tor 文件翻譯

Tor 在 2025/10 推出全新的支援入口網站，將 Tor 瀏覽器手冊與原支援入口合併至同一個地方，並開放多語言翻譯貢獻。

支援入口網站的正體中文（zh-Hant）翻譯已大致完成，持續需要人跟上每次原文更新與校對。想參與維護或補齊剩餘字串，可以透過 Weblate 翻譯平台貢獻：

  1. 前往 Weblate：Tor new-support-portal 翻譯專案。
  2. 若你是第一次參與 Tor 翻譯，請先閱讀「成為 Tor 翻譯者」入門指引。
  3. 翻譯完成後，可透過 Tor 的在地化社群入口進一步了解更多參與方式。

語言支援狀態可能有所變動

以上為目前觀察到的現況，實際語言支援情形請以 Weblate 即時語言列表為準。

關於這次 Tor 支援文件整合的背景說明，請參考：Tor 使用者文件的新家。

翻譯之外，想全面了解如何對接 Tor 上游的社群與未來方向，見 Tor Project 生態與對接。

下一步