WordPress 外掛主題中文化：Poedit 翻譯教學

前台那些 Add to cart、Proceed to checkout、My account 的英文殘留，可能是網站語言、翻譯完整度、載入路徑或原始程式國際化出了問題。裝好外掛或佈景主題後，偏偏關鍵字串還是英文，這正是這篇文章要解的事。

答案很簡單：WordPress 的中文化是靠一份「翻譯檔」運作的，沒有檔案就沒有翻譯。而 Poedit 就是那個讓你自己產出這份檔案、把任何外掛主題翻到 100% 繁體中文的桌面工具。這篇會帶你從「為什麼會有英文殘留」一路走到「翻譯檔上架、更新後還不會消失」的完整流程，不靠工程師、不靠外掛開發者，你自己就能搞定。

先看懂 gettext：WordPress 翻譯背後那套機制

WordPress 不是「想到中文就顯示中文」這樣運作的。它的每一行字，從「閱讀更多」到結帳按鈕，在原始碼裡都被包在一個叫 gettext 的國際化標準函式裡，例如 PHP 的 __('Add to cart', 'my-plugin') 或 _e('Proceed to checkout', 'my-plugin')。括號裡第一個值是原文（通常是英文），第二個值是這個外掛或主題的文字網域（text domain），用來標示「這句話是誰家的」。

WordPress.org 的官方國際化文件把這套寫法講得很清楚：開發者只要用對 gettext 函式、宣告好 text domain，這個外掛就具備了被翻譯的「資格」。但「有資格」不等於「已經有人翻好」。WordPress 在執行時會根據你設定的網站語言（繁體中文的代號是 zh_TW），去固定的資料夾找對應的翻譯檔，找到了就把英文換成中文，找不到就原封不動顯示英文。

判斷一個外掛有沒有「翻譯資格」，看原始碼最快。一個國際化做得扎實的外掛，PHP 裡幾乎找不到寫死的英文字串，所有會顯示給使用者的文字都被包成類似這樣的形式：_e( 'Add to cart', 'my-plugin' )（直接輸出）或 $label = __( 'Add to cart', 'my-plugin' )（回傳字串再處理）。而 escape 版本像 esc_html__()、esc_attr_e() 則同時兼顧資安過濾與翻譯。相對地，如果你看到 echo 'Add to cart'; 這種沒有任何函式包裹的寫法，那行字就翻不動。前面提到的官方 i18n 文件把這組函式家族整理成完整清單，懂 PHP 的讀者可以直接對照原始碼，秒判這個外掛值不值得你花時間翻。

所以你看到的英文殘留，本質上只有三種可能：

• 這個外掛或主題還沒有繁中翻譯檔（最常見）。
• 有翻譯檔，但只翻了七成，剩下的字串沒有人處理。
• 翻譯檔存在，但檔名或路徑不對，WordPress 根本載不到（這個最折磨人，後面會專門講）。

理解這點之後你就會明白，Poedit 解的是第一種與第二種問題：它讓你親手產生並編輯那份翻譯檔。第三種問題要靠搞懂 WordPress 的載入路徑，那是另一層功課。

看懂三種檔案：POT、PO、MO 各自做什麼

翻譯 WordPress 一定會撞上這三個副檔名，搞混它們是新手最大的卡關點。以下把它們的角色一次拆清楚：

檔案類型	誰產生它	給誰看	用途
.pot（Portable Object Template）	外掛/主題開發者，或你用工具掃出來	翻譯者	範本。列出所有可翻譯的原文，沒有任何翻譯內容。
.po（Portable Object）	翻譯者（就是你）	人	你在範本上填入中文後的成果，純文字、可編輯、可版本控管。
.mo（Machine Object）	Poedit 從 .po 編譯出來	WordPress（機器）	二進位編譯檔，這才是 WordPress 真正讀取、用來替換字串的檔案。

WordPress 只認得 .mo 檔，你翻得再漂亮的 .po 檔它一個字也看不懂。.po 是給你和 Poedit 之間溝通用的「工作檔」，.mo 是 .po 編譯後的成品、給 WordPress 用的。所以整個流程的起點是 .pot 範本，終點是 .mo 編譯檔，Poedit 就是那個把 .pot 變成翻好的 .po、再自動編譯成 .mo 的中間人。

一個常見的誤解是「只要把 .po 檔丟上主機就好了」。.po 是供人編輯的來源檔，Poedit 存檔時通常會編譯出 WordPress 可載入的 .mo。WordPress 6.5 起也支援效能較佳的 .l10n.php 執行格式，但 Poedit 這套手動流程仍以 .po 與 .mo 為主。

動手前最重要的一步：搞清楚 WordPress 怎麼「找到」你的翻譯檔

這一段是大部分教學會跳過、卻是讀者最常翻完發現「怎麼沒反應」的關鍵。WordPress 載入翻譯檔時，會依循一套固定的檔名規則與路徑優先順序，檔名錯一個字、放錯資料夾，檔案再完美也載不進來。

檔名規則是：text-domain-locale.mo。例如外掛的 text domain 是 ry-woocommerce-tools，繁中 locale 是 zh_TW，那麼檔名就必須是 ry-woocommerce-tools-zh_TW.mo，一個字都不能錯。主題也一樣：your-theme-slug-zh_TW.mo。

更關鍵的是放在哪裡。WordPress 會依照下列這組優先順序去找翻譯檔：

1. wp-content/languages/plugins/<text-domain>-zh_TW.mo（全域外掛翻譯，推薦，更新不會被覆蓋）
2. wp-content/languages/themes/<text-domain>-zh_TW.mo（全域主題翻譯）
3. wp-content/plugins/<text-domain>/languages/<text-domain>-zh_TW.mo（外掛內建資料夾，更新時會被覆蓋）
4. wp-content/themes/<text-domain>/languages/<text-domain>-zh_TW.mo（主題內建資料夾）

WordPress 的官方本地化文件說明了翻譯檔的載入方式。外掛或主題自己的 languages/ 目錄會隨套件更新被替換，不適合放唯一的自訂翻譯；wp-content/languages/ 不會被一般外掛檔案更新直接覆蓋，但相同語系的官方語言套件更新仍可能替換對應檔案，因此要保留一份可重新部署的 .po 原始檔。

還有一個前提：你的 WordPress 網站語言必須設成繁體中文。進入後台「設定 → 一般 → 網站語言」，選「繁體中文」，zh_TW 這個 locale 才會被啟用，WordPress 才會開始尋找對應的翻譯檔。這步漏了，後面全白工。

下載安裝 Poedit，建立你的第一個 zh_TW 翻譯檔

機制講完了，現在進入實作。Poedit 是跨平台的桌面翻譯編輯器，也是 gettext 工作流程常用工具之一，可從 Poedit 官網下載。它提供免費與付費方案，各版本功能會隨產品更新；安裝前可依當前方案頁確認預先翻譯、翻譯記憶與 WordPress 支援是否符合需求。

第一步：找到外掛或主題的 .pot 範本

安裝好 Poedit 之後，你需要一份 .pot 範本當起點。有幾個地方可以拿到：

• 外掛/主題的 languages/ 資料夾：透過 FTP 連到主機，在 wp-content/plugins/外掛代稱/languages/ 或 wp-content/themes/主題代稱/languages/ 裡，通常會有一個 外掛代稱.pot 檔。如果你不熟 FTP 操作，可以先看我們寫的 WordPress FTP 完整教學，把檔案下載回來再開始。
• WordPress.org 翻譯專案：若套件未附 .pot，可到 translate.wordpress.org 找對應專案並匯出字串；能否取得完整範本要看專案與匯出格式。
• 用 WP-CLI 自己產：如果連 .pot 都沒有（開發者忘了附），可以用 wp i18n make-pot 指令掃描原始碼自動產生一份。這需要 SSH 權限，適合進階玩家。

第二步：在 Poedit 建立翻譯檔

拿到 .pot 之後，打開 Poedit，點「檔案 → 新增自 POT/PO 檔案」，選擇你下載的 .pot。Poedit 會問你要翻譯成什麼語言，這時選「Chinese (Taiwan)」或直接輸入 zh_TW，千萬別選成 Simplified Chinese 或 Chinese (China)，那會是簡體中文的 locale，WordPress 不會把它當繁中載入。

選好語言後，Poedit 會把 .pot 裡所有字串載入，左側是原文清單，右側是你填入翻譯的地方。這時你存檔，Poedit 會自動建議檔名為 外掛代稱-zh_TW.po，接受這個檔名，不要自己改成什麼 my-translation.po，檔名錯了 WordPress 就找不到。

第三步：開始逐句翻譯

翻譯介面很直覺：上方選單點一條原文，下方輸入框打中文，按 Enter 或「下一條」繼續。每條字串有三種狀態標記：

• 未翻譯（空白，灰底）
• 已翻譯（你填好了，綠勾）
• 模糊（fuzzy）（黃底，表示這條是 Poedit 從翻譯記憶或舊版推測出來的，需要你人工確認）

模糊狀態是個好用的功能，但也是陷阱：fuzzy 標記的字串不會被 WordPress 載入，Poedit 編譯時會跳過它們。所以你看到黃底一定要點進去，確認翻譯沒問題後按快捷鍵把 fuzzy 標記取消，它才會真正生效。若 .mo 上傳後前台仍顯示英文，先檢查字串是否還掛著 fuzzy。

第四步：存檔，自動編譯出 .mo

翻完（或翻到一個段落）按下存檔，Poedit 會在同一個資料夾、用同樣的檔名產出 .po 和 .mo 兩個檔。把這兩個檔案一起準備好，下一步就是上架。

翻譯實戰：佔位符、複數形、上下文，這些細節決定能不能 100%

逐句翻中文聽起來簡單，但翻譯 WordPress 字串有幾個技術細節，處理不好就會讓你的翻譯「看起來翻完了，實際上壞掉」。這一段是實務上最常踩雷的幾個關鍵要點。

佔位符（placeholder）必須原封不動地保留

很多字串裡藏著 %s、%d、%1$s 這類佔位符，它們代表程式執行時會動態填入的值。例如 Your order #%s has been received，那個 %s 會在結帳時被替換成訂單編號。翻譯時你必須把這些佔位符一模一樣地放進中文裡：

• 原文：Your order #%s has been received.
• 正確：您的訂單 #%s 已收到。
• 錯誤：您的訂單已收到。（少了 %s，訂單編號會消失，也可能造成格式檢查或程式輸出問題）

遇到有編號的佔位符像 %1$s、%2$s，更要小心：它們允許你在中文裡調換順序。例如 %1$s reviewed %2$s's profile，中文文法是受詞在前，你可以翻成「%2$s 的個人檔案已被 %1$s 瀏覽」，只要編號對得上，WordPress 會正確替換。Poedit 對佔位符有內建的格式檢查，存檔時會跳出警告提醒你哪幾條少了符號，這個警告務必處理掉，別忽略。

複數形（plural forms）：中文其實佔了便宜

gettext 支援複數形，原文可能是 %s comment / %s comments。每個 .po 檔的檔頭會宣告一套「複數規則」，告訴系統這個語言有幾種複數形式、什麼條件用哪個。英文是兩種（單數和複數），其他語言也可能有更多形式。

繁體中文通常使用 nplurals=1; plural=0;，意思是只有一種複數形式。Poedit 在你選 Chinese (Taiwan) 時會帶入規則，因此可把 %s comment 和 %s comments 都翻成「%s 則留言」，並保留數量佔位符。若檔頭沿用錯誤規則，部分字串可能無法如預期顯示。

上下文標記（msgctxt）：同一個字、不同意思

有時候同一個英文單字在不同位置意思完全不同。Post 在部落格情境是「文章」，在電子商務可能是「張貼」這個動作。gettext 用 msgctxt（context） 來區分它們，Poedit 會顯示成 Post [button]、Post [noun] 之類的標記。看到中括號裡的 context 提示，照著那個語境翻，不要一律翻成「文章」。WordPress Polyglots 手冊維護了一份繁體中文的標準譯名詞彙表，不確定某個詞該怎麼翻的時候，去查這份詞彙表，能讓你的用語跟官方社群一致。

台灣用語的一致性，比翻得「漂亮」更重要

翻譯 WordPress 字串有個很容易被看漏的品質指標：同一個概念，整份翻譯檔裡從頭到尾要用同一個詞。例如 Cart 在台灣電商語境固定翻成「購物車」，就別有幾條翻成「購物清單」；Checkout 固定翻「結帳」，就別混進「付款」。Account 翻「帳號」還是「會員中心」也最好統一，否則使用者在結帳頁看到「我的帳號」、在會員頁看到「會員中心」，會搞不清楚是不是兩個不同的東西。

維持一致最有效的方法是自己建一份術語對照表，每翻好一個核心詞就記下來，之後遇到同一個原文一律套用。Poedit 的翻譯記憶在這裡幫得上忙，但更保險的是你主動維護一份清單，因為翻譯記憶只比對字面相似度，不會幫你判斷「這個詞在這個專案裡約定翻成什麼」。前面提到的 Polyglots 繁中詞彙表是很好的起點，官方社群已經把核心術語的標準譯法定下來了，跟著它走能讓你的用語跟大多數繁中網站一致，使用者學習成本最低。

另一個在地特有的小坑是大陸慣用語的滲入。很多外掛的簡中翻譯早就完成了，如果你圖方便拿簡中版來改，很容易殘留「視頻」「點擊這裡」「默認」「鏈接」這類用語，在地使用者一看就知道不對勁。繁中的標準是「影片」「點這裡」「預設」「連結」，差一個字都會折損專業感。養成逐條人工校稿的習慣，這些細節才不會漏網。

活用翻譯記憶與預先翻譯

一個外掛動輒幾百條字串，逐條手翻很累。Poedit 兩個省時功能值得認識：

• 翻譯記憶（Translation Memory）：免費版就有。它會記住你之前翻過的句子，下次遇到相同或相似的原文，會在建議區跳出你過去的譯法，按一下就帶入。長期翻同一個外掛的多個版本時特別有用。
• 預先翻譯（Pre-translation，Pro 版）：付費功能，會從線上翻譯記憶庫自動幫你把整份檔案填滿建議譯文，你只要事後校稿。對字串量大、又急著上線的情境很省事。但要誠實說，機器預填的品質參差，佔位符、context 標記常常會被弄錯，預先翻譯之後一定要逐條人工校稿，不能直接上架。

「100% 翻譯」背後的真相：哪些字串你永遠翻不到

標題說 100%，這裡必須誠實說明：有些字串，你用 Poedit 怎麼翻都不會出現在中文介面裡，原因是它們根本沒有被包進 gettext 系統。這不是你的錯，是外掛開發者的程式碼問題。先把這個真相講清楚，你才不會卡在那 5% 死胡同。

例如前台出現 Your subscription will renew on %s，但在 Loco Translate 與 Poedit 的 .pot 範本都搜不到，原因可能是開發者用字串拼接，沒有用 gettext 函式包住完整句子。這種情況不是翻譯檔漏譯，而是原始程式沒有正確國際化，應回報開發者修正。

這類「翻不到」的字串，通常有幾種來源：

類型	為什麼翻不到	解法
後端字串拼接	開發者用 . 串字串，沒用 gettext 函式	只能改原始碼並回報給開發者修
JavaScript 裡的文案	放在 .js 檔，需要的是 .json 翻譯檔（wp-i18n 機制），不是 .mo	用 WP-CLI 產出對應的 .json 並另開一套翻譯流程
資料庫裡寫死的內容	外掛啟用時把英文選項寫進資料庫	要從後台設定頁或直接改資料庫值
第三方服務回傳的訊息	金物流、API 回傳的英文訊息不在外掛翻譯範圍	看該服務是否支援中文設定

換句話說，Poedit 能讓你「翻得到的部分」做到 100%，但翻不到的部分要靠改程式碼或換工具。判斷方法是：你在 Poedit 的字串清單裡搜尋那句英文，搜得到就是翻譯問題，搜不到就是開發者的 i18n 問題。前者你來解，後者乖乖去外掛的支援論壇發 issue，或乾脆自己改 code 用子外掛覆寫。

JavaScript 裡的字串是另一套規則：你需要的是 .json 不是 .mo

現代 WordPress 外掛大量使用 JavaScript，尤其是區塊編輯器與結帳互動元件。開發者會在 JS 裡使用 __( 'Add to cart', 'my-plugin' ) 等函式，再為各來源檔產生對應的 .json 翻譯。檔名可依 WordPress 規則使用腳本 handle 或來源路徑雜湊，不能只假設一定是 text-domain-zh_TW-<script-handle>.json；外掛也必須呼叫 wp_set_script_translations() 才能載入。

如果 PHP 字串已中文化，唯獨 JS 元件仍是英文，應檢查對應的 .json 是否由 WP-CLI wp i18n make-json 正確產生，以及腳本是否註冊翻譯。只看元素目前出現在 DOM 裡，無法可靠判斷它最初由 PHP 或 JavaScript 產生；可配合頁面原始碼、Network、Sources 與程式碼搜尋追查來源。

也因此，實務上常強調，翻譯之前先搞清楚「字串從哪裡來」比急著動手翻更重要。一個結構完整的外掛會把 PHP 字串與 JS 字串都妥善包好，你翻一套 .po 就能同時照顧兩邊；結構不嚴謹的外掛則會讓你 .mo 傳了 .json 沒傳、翻了後端漏了前端，永遠在補破網。挑外掛的時候，這個細節值得當成評估指標。

翻譯檔上架的三條路徑，加上更新後翻譯不消失的保護策略

翻譯做完了，接下來是把 .mo 檔送上主機讓 WordPress 載到。這一步看似簡單，但放錯位置是日後翻譯憑空消失的最大元兇。以下整理三條上架路徑，並說明哪一條最安全。

路徑一：上傳到 wp-content/languages/（推薦，更新後存活）

用 FTP 或主機檔案管理員，把 外掛代稱-zh_TW.mo 和保留用的 .po 上傳到 wp-content/languages/plugins/（主題對應 wp-content/languages/themes/）。依 WordPress.org 官方的外掛更新機制文件，一般外掛更新不會替換外掛目錄以外的檔案；但官方語言套件可能更新相同路徑與檔名，所以仍應在版本控管或站外備份保留來源檔。

路徑二：上傳到外掛/主題內建的 languages 資料夾（不推薦）

把檔案丟到 wp-content/plugins/外掛代稱/languages/，這條路徑 WordPress 也讀得到，但有個致命缺點：外掛每次更新，整個資料夾會被官方新版覆蓋，你的翻譯檔會連同舊版一起被刪掉。下次你會發現前台又變英文，然後又得重傳一次。除非你翻譯的是絕對不會更新的自訂外掛，否則別走這條。

路徑三：透過 Loco Translate 等後台外掛「保護」模式上架

如果你不想碰 FTP，可以用後台翻譯工具建立並管理檔案。Loco Translate 可把自訂翻譯存到其管理的 Custom 路徑，降低外掛或主題更新覆蓋的風險；實際目錄與載入狀態仍要以目前版本的設定畫面確認。Poedit 與後台工具的差異可參考 Loco Translate 教學。

不管走哪條，動手上傳前請先做一次完整備份。翻譯檔本身不會搞壞網站，但 FTP 操作有時會手滑覆蓋到別的檔案。如果你還沒建立備份習慣，先看過 WordPress 備份與還原完全指南 再動手，心裡踏實得多。

翻譯上傳了，前台卻還是英文？逐項排查清單

明明 .mo 檔傳上去、檔名也對，前台仍顯示 Add to cart 時，先別急著重翻。應從語系、載入路徑、text domain、快取與字串來源逐項排查。

排查項目	症狀	怎麼確認與修
網站語言沒設繁中	不只這個外掛，連 WordPress 核心都是英文	後台「設定 → 一般 → 網站語言」確認是繁體中文（zh_TW）
.mo 檔名拼錯或大小寫不對	同一外掛有些字串翻到了、有些沒翻	檔名必須是 text-domain-zh_TW.mo，zh_TW 的底線與大小寫不能錯
text domain 對不上	檔名用了外掛資料夾名，但實際 text domain 是另一個	打開外掛主檔頭看 Text Domain: 那行，用那個值當檔名前綴
翻譯檔還掛著 fuzzy 標記	特定幾條字串永遠顯示英文	在 Poedit 把對應字串的 fuzzy 取消，重新編譯 .mo 再上傳
快取沒清	原始碼裡翻譯已生效，但頁面顯示舊內容	清快取外掛、CDN、瀏覽器快取，必要時開無痕視窗確認
佔位符數量對不上	該條字串變空白或整段消失	檢查中文是否漏了 %s 或多了一個，Poedit 編譯時會警告
字串根本沒被 gettext 包起來	在 Poedit 搜尋原文搜不到	屬於開發者 i18n 問題，翻譯檔救不了，需改原始碼

這裡頭最容易被放過的是快取。很多站長裝了頁面快取外掛，翻譯檔明明更新了，前台卻一直顯示快取住的舊英文頁面，於是以為翻譯失敗、反覆重傳。下次遇到「翻好了卻沒反應」，先把快取整個清乾淨、開無痕視窗重新看一次，往往問題就消失了。

另一個高頻陷阱是 text domain 與外掛資料夾名稱不一致。假設外掛資料夾叫 woo-subscription-pro，但它在程式碼裡註冊的 text domain 是 woo-subscription（少了 pro），那麼你的翻譯檔就必須叫 woo-subscription-zh_TW.mo，而不是照資料夾名命名。怎麼確認？用文字編輯器打開外掛的主 PHP 檔，找檔頭註解裡的 Text Domain: 那一行，那個值才是 WordPress 用來匹配翻譯檔的依據。這個細節最容易卡關，排查時務必特別留意。

WooCommerce 與主題翻譯的兩個特殊情境

如果你翻的是 WooCommerce 這類大型外掛，或是一個結構複雜的佈景主題，有兩個情境跟一般外掛翻譯不太一樣，值得單獨點出來。

第一個是 WooCommerce 的翻譯量極大。WooCommerce 是 WordPress 生態最大的電商外掛，光核心字串就有上千條，加上各種狀態、信件模板、稅金標籤。如果你只翻結帳流程會用到的幾十條，其他頁面還是英文，看起來會很割裂。實務上建議，WooCommerce 核心直接用 Polyglots 的官方繁中翻譯（它維護得相當完整），你自己用 Poedit 翻的是那些官方沒翻、或翻得不合你品牌語氣的字串，例如結帳頁的按鈕文案、感謝頁的促銷話術。這種「官方翻譯打底、自己微調覆蓋」的分工，比從零翻一千條聰明得多。

第二個是 主題的字串常分散在多個檔案。一個現代佈景主題可能把字串拆在主題核心、子主題、綁定的 page builder 外掛裡，光翻主題本身的 .pot 不夠，前台還是會漏英文。例如用 熱門佈景主題 搭配 Elementor 或 Divi 的站，builder 外掛各自有自己的 text domain，要分開翻。主題本地化的官方文件有提醒這一點：只要牽涉到附掛的子外掛或 builder，翻譯要按各自的 text domain 處理，不能假設翻一個檔就全搞定。

這也是為什麼動手翻譯之前，建議先花十分鐘盤點前台到底出現哪些英文、它們各屬於哪個 text domain。用瀏覽器的開發者工具檢查元素，看那段文字被包在什麼元件裡，再回頭對照各外掛主題的 text domain，能幫你把翻譯工作量精準聚焦在「真正會被使用者看到」的字串上，避免傻傻地把一整個外掛從頭翻到尾。

Poedit、Loco Translate、WP-CLI 三條翻譯路線誰適合你

講到這裡你應該發現，WordPress 翻譯不是只有 Poedit 一條路。市面上至少有三條主流路線，選對工具能省下大量時間。以下把它們攤開比較：

工具	在哪跑	優點	缺點	適合誰
Poedit	你的電腦（桌面軟體）	專業、離線、翻譯記憶、批次校稿順、可版本控管 .po 檔	要下載 .pot、翻完再上傳 .mo，流程多兩步	長期維護多個外掛、重視品質的站長
Loco Translate	WordPress 後台（瀏覽器）	免 FTP、免下載檔案、所見即所得、有自動保護機制	大檔案校稿體驗較差、佔用後台資源	新手、只想翻幾個外掛的站長
WP-CLI（i18n 指令）	SSH 命令列	可自動產 POT、批次編譯、適合自動化部署	需要命令列與 SSH 權限，學習曲線陡	開發者、管理多站、CI/CD 流程

實務上常見的配置是：Poedit 負責正式翻譯與校稿，Loco Translate 負責臨時改一兩個字，WP-CLI 則留給需要批次產 POT 或整合進部署流程的進階場景。如果你是第一次碰 WordPress 翻譯，從 Poedit 開始最扎實，因為它強迫你理解整個檔案生命週期，這個觀念以後換什麼工具都適用。

這裡也順帶釐清一個常被混淆的觀念：Poedit 跟 Loco Translate 解的是「翻譯字串」這層問題，把外掛原本的英文換成中文。但如果你想做的是整站多語系，也就是同一個網站同時有中文版、英文版、日文版，那需要的是 Polylang、WPML、TranslatePress 這類多語系外掛，那是另一個層級的工程，可以參考我們的 Polylang 完整教學 和 TranslatePress 多語系教學。別把「中文化單一外掛」跟「架設多語系網站」混為一談，前者一個下午能搞定，後者是網站架構級的決策。

與其自己翻，不如貢獻回 WordPress Polyglots 繁中團隊

如果你翻完一個熱門外掛，發現成果還不錯，有一個比「自己留著用」更聰明的選擇：把翻譯貢獻回 WordPress Polyglots，讓它跟著外掛更新一起發布給所有繁中使用者。

WordPress 的 Polyglots 志工體系在 translate.wordpress.org 翻譯核心、外掛與主題。翻譯建議需審核，專案也要符合語言套件產生條件，核准內容才可能透過 WordPress.org 更新提供給相同語系的網站；不是每提交一條就立即推送。

這條路的好處很實際：

• 減少個別網站的部署工作。翻譯進入官方語言套件後可隨更新取得，但新字串仍需要社群持續翻譯與審核，自訂品牌文案也要自行維護。
• 造福繁中使用者。WordPress 與 WooCommerce 都有廣泛使用者（見 W3Techs 的 WordPress 與 WooCommerce 使用統計）；經審核的繁中翻譯可被更多網站使用，但實際安裝量不宜自行估算。

任何已登入 WordPress.org 的使用者都可以在 translate.wordpress.org 找到專案並提交翻譯建議，不必先申請成為翻譯者。建議要由具權限的 PTE 或 GTE 審核後才會正式採用；持續貢獻者可依團隊流程申請特定專案的核准權。

翻譯做完之後的行動清單

觀念、工具、流程都講完了，接著用一份行動清單收尾。假設你現在要翻一個還沒有繁中翻譯的 WooCommerce 外掛：

1. 確認網站語言是繁體中文。後台「設定 → 一般 → 網站語言」選繁體中文，這是觸發 WordPress 載入 zh_TW 翻譯的前提。
2. 找到或產生 .pot 範本。先從外掛的 languages/ 資料夾找，沒有就用 WP-CLI 或從 WordPress.org 外掛頁下載。
3. 用 Poedit 開新翻譯檔，語言選 zh_TW。檔名維持 Poedit 建議的 外掛代稱-zh_TW.po。
4. 逐條翻譯，盯緊三件事：佔位符（%s、%d、%1$s）原樣保留、fuzzy 標記全部人工確認後取消、複數形用中文單一形式帶過。
5. 處理「翻不到」的字串。在 Poedit 搜尋搜不到的英文，判斷是 JS、後端拼接還是資料庫寫死，分流處理或回報開發者。
6. 存檔產出 .mo，上傳到 wp-content/languages/plugins/。一般外掛更新不會碰這個路徑，但官方語言套件可能更新相同檔名，因此仍要在站外保留 .po 來源檔。
7. 清快取、測前台。裝了快取外掛的話記得清，不然你可能看到舊的英文頁面誤以為翻譯失敗。快取觀念可以對照 WordPress 快取外掛推薦。
8. 把品質不錯的翻譯貢獻回 Polyglots。讓它跟著官方更新走，以後你連自己維護都省了。

WordPress 的中文化換句話說，就是這麼一回事：搞懂 gettext 三種檔案、搞懂 WordPress 怎麼載入、用 Poedit 把字串一條條填好、把 .mo 放對資料夾。沒有神奇的捷徑，但每一個環節都有明確的對錯，只要照著走，就能讓任何 WordPress 外掛主題裡「可翻譯的字串」做到 100% 繁體中文（少數未被國際化的字串仍需開發者改原始碼才能處理）。把這套流程練熟，你接手的每一個 WordPress 專案，都不會再被一句沒翻到的英文卡住。

外掛每次更新都加新字串，翻譯怎麼跟著維護

翻譯不是一次性的工作。外掛開發者會持續加新功能，每加一個新按鈕、新設定頁，就多幾條沒翻過的英文字串進來。你上次翻到 100%，下次更新可能又掉回 95%。這代表你的翻譯檔需要跟著外掛版本一起迭代，不代表你之前翻錯了。好險 Poedit 的維護流程設計得很順：

1. 重新下載外掛最新版的 .pot 範本，或用 WP-CLI 重新掃一份。
2. 在 Poedit 打開你舊的 .po 檔，選「從 POT 檔更新翻譯（Update from POT file）」，不要開新檔。
3. Poedit 會比對新舊範本，自動帶入你已經翻過的字串（靠翻譯記憶與原文比對），標出新增的字串（藍色）、刪除的字串（紅色）、原文被開發者改動的字串（黃色，會重新掛 fuzzy 等你確認）。
4. 只補新字串、確認 fuzzy 標記、重新存檔編譯 .mo、上傳覆蓋舊版。

這個「更新而非重來」的流程是 Poedit 相對於純後台翻譯外掛的最大優勢：你的翻譯記憶和歷史譯文都保留在 .po 檔裡，可以納入版本控管、可以備份、可以交給團隊成員接手。一份管理良好的 .po 檔，本質上就是你這個網站的「繁中翻譯資產」，外掛怎麼更新都帶不走。

如果你的網站同時跑多個外掛、每個都得維護翻譯，建議把所有 .po 檔集中在同一個資料夾用 Git 管理，搭配一份簡單的對照表記錄每個檔案對應的外掛名稱與版本。這樣無論是主機搬家、外掛更新，還是交接給別人維護，翻譯成果都不會憑空消失。可再對照WordPress 備份與還原指南，把這些檔案納入備份排程。

這套「翻譯即資產」的觀念，在長期維護 WooCommerce 專案時尤其關鍵。一個電商網站可能同時掛著金流、物流、訂單通知、會員積分十幾個外掛，每個都得中文化，如果沒有一套版本控管的流程，每次更新都是一場混亂。把 .po 當成程式碼一樣管理，你的翻譯工作才能從「每次重來」變成「持續累積」，這才是真正不求人、還能越做越輕鬆的關鍵。