WordPress 外掛主題中文化不求人：用 Poedit 手把手完成 100% 繁體中文翻譯
用 Loco Translate 這類翻譯外掛遇到「系統字翻不出來」的死角時，唯一可靠的解法是回到翻譯檔的源頭：用 Poedit 開啟 pot 檔產生 po 與 mo 檔，再把檔案…
用 Loco Translate 這類翻譯外掛遇到「系統字翻不出來」的死角時，唯一可靠的解法是回到翻譯檔的源頭：用 Poedit 開啟 pot 檔產生 po 與 mo 檔，再把檔案放到 wp-content/languages 指定路徑。Poedit 是免費的翻譯軟體，支援 Windows 與 Mac [來源：Poedit 官網〈https://poedit.net〉〈2026〉]，而 WordPress 的多語系檔案路徑規範（languages/plugins、languages/themes）也是核心官方設計 [來源：WordPress.org 官方 i18n 文件〈https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/〉〈2026〉]，兩者搭配就能補上翻譯外掛抓不到的那塊拼圖。
重點先看：Loco Translate 能翻掉大部分字串，但遇到會員積點、結帳欄位這類動態字串仍有死角；回到 pot 檔用 Poedit 產生 po/mo 再上傳 languages，是唯一不會被更新洗掉的做法。WordPress 在全球超過四成網站運行，W3Techs 的調查顯示其涵蓋 41.5% 的全體網站，在有安裝內容管理系統的網站中更佔 59.2% [來源：W3Techs — Usage Statistics and Market Share of WordPress https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]，龐大生態讓翻譯檔管理成為站長必修課。
這套方法的源頭是 WordPress 的 PHP gettext 機制：所有可譯字串都靠 __()、_e()、_x()、_n() 這類包裝函式標記，再交由 pot/po/mo 三層檔案承接翻譯。正式上架到 WordPress.org 的外掛與佈景主題，都遵循這套核心官方國際化規範 [來源：WordPress.org 官方 i18n 文件〈https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/〉〈2026〉]。只要外掛照規矩寫，pot 模板就會存在，回到檔案層級用 Poedit 繁中化，永遠是最徹底的一條路。
外掛主題殘留英文的根源：pot 模板與動態字串
多數外掛主題來自國外開發者，作者只提供英文字串與翻譯用的 pot 檔，繁體中文翻譯未必齊全或根本沒做，所以畫面上會殘留英文。翻譯外掛如 Loco Translate 能抓到大部分字串，但對動態字串與深層系統字仍有死角。
具體來說，安裝一個 必裝外掛 或 新的佈景主題 之後，後台或前台蹦出一行 "Points to redeem"，翻遍了設定還是找不到地方改。原因在於這串字根本不是設定項，而是寫死在外掛程式碼裡、等著被翻譯檔覆蓋的字串。經營 WooCommerce 購物網站 時這種情況特別常見：會員積點、結帳表單欄位、訂單通知與 Email 範本，全是動態字串的高風險區。
遇到這類問題，第一反應多半是裝 Loco Translate，它確實能解掉七、八成顯示英文的狀況。難處在剩下的兩成：以某款會員積點外掛為例，結帳頁跳出一句 "You have %s points available"，Loco Translate 在編輯器裡怎麼搜都搜不到，因為它是由後端動態組合的字串，翻譯外掛的掃描根本沒收進來。這時只有回到檔案層級，自己用 Poedit 開 pot 檔處理，才有辦法收掉。換句話說，翻譯外掛解的是「表面字串」，掃得到什麼就翻什麼；檔案層級解的是「字串來源」，直接對著 pot 模板逐筆處理，兩者層級不同，不能互相取代。卡在「明明裝了翻譯外掛，字串卻翻不掉」的狀況，多半是那串字根本沒被掃進外掛的資料庫。
pot 檔、po 檔、mo 檔的角色分工
pot 檔是翻譯模板（所有字串的原始清單），po 檔是你實際翻譯編輯的文字檔，mo 檔則是 WordPress 真正讀取的編譯檔；po 存好後 Poedit 會自動編譯出對應的 mo 檔。三者是「模板、可編輯稿、機器讀取檔」的串接關係，缺一不可。
這三個檔案名詞看起來很像，差一個字母意思完全不同，很多人在這裡就搞混了。以下用一張表把它們的用途、誰會編輯、誰會讀取一次講清楚：
| 檔案類型 | 角色 | 誰來編輯 | 誰會讀取 | 產生方式 |
|---|---|---|---|---|
| pot 檔 | 翻譯模板（字串原始清單） | 外掛作者 / 開發者 | 用來生成 po | 外掛內建，或用 Poedit 掃描原始碼生成 |
| po 檔 | 某語系的可編輯翻譯檔 | 翻譯者（人） | 用來生成 mo | 從 pot 建立，或直接編輯現成 po |
| mo 檔 | 機器讀取的編譯檔 | 不自動編輯 | WordPress 核心 | Poedit 儲存 po 時自動編譯 |
簡單講，pot 列出全部可譯字串，po 是填好譯文後的版本，mo 則是 WordPress 實際讀進記憶體的編譯檔。沒有 mo，網站就不會顯示你的翻譯；但 mo 是編譯出來的，不需要、也不應該手動去改，只要把 po 顧好，Poedit 按下儲存就會自動生出 mo。WordPress 的這套 i18n（國際化）機制是核心官方設計 [來源：WordPress.org 官方 i18n 文件〈https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/〉〈2026〉]，所有正規外掛主題都遵循同一套規則。
還有一個關鍵：繁體中文的語系代碼固定是 zh_TW，簡體中文是 zh_CN，這個代碼遵循 POSIX locale 與 WordPress 官方語系清單的命名標準 [來源：WordPress Polyglots 手冊〈https://make.wordpress.org/polyglots/handbook/translating/glossary/〉〈2026〉]。檔名後面挂的就是這個代碼，寫錯一個字母 WordPress 就讀不到你的翻譯。未來要做 多語系 SEO 或整站多語言，這個代碼觀念更是地基。只要記住「pot 生 po、po 生 mo、mo 給 WordPress 讀」這條線，後面的操作都不會迷路。
翻譯外掛、Poedit、WP-CLI：三種做法的決策矩陣
要把 WordPress 繁中化，坊間流傳的做法大致有三條路：用 Loco Translate 這類翻譯外掛在後台直接編輯、用 Poedit 在本機編輯 po/mo 檔再上傳、或用 WP-CLI 在命令列批次處理。三條路各有擅長的情境，硬要二選一反而會綁手綁腳。決策矩陣把「適合誰、能做到什麼、做不到什麼」一次攤開，幫你依現況挑路線。
| 做法 | 適合情境 | 優點 | 限制 | 更新後是否保留 |
|---|---|---|---|---|
| 翻譯外掛（Loco Translate 等） | 臨時改幾串字、不想碰檔案 | 後台直覺操作、所見即所得 | 掃不到動態字串、深層系統字易漏 | 視存放位置而定，放外掛資料夾會被覆蓋 |
| Poedit 編輯 pot/po | 翻譯外掛抓不到的字串、長期維護 | 直接面對字串來源、可從原始碼掃描生成 pot | 需在本機操作、要上傳檔案 | 放 languages 路徑即永久保留 |
| WP-CLI 命令列 | 批次管理多個外掛、伺服器端自動化 | 可腳本化、一次處理整批、能重新編譯 mo | 有 SSH 門檻、不適合視覺化校稿 | 放 languages 路徑即永久保留 |
挑選邏輯很單純。只是要快速把一兩句英文換掉，且那串字能被外掛掃到，用 Loco Translate 最省事；當外掛搜尋怎麼都搜不到目標字串，或是你想要一份可以反覆編輯、版本控管的翻譯檔，就改走 Poedit；至於同時管理幾十個外掛、需要排程自動拉取官方語言包與重編 mo 的進階站長，WP-CLI 才派得上用場。多數人實際的組合會是「外掛做八成、Poedit 補兩成」，把兩種工具當互補關係來用。
還有一個常被忽略的搭配細節。Loco Translate 也能把編輯結果匯出成 po 與 mo 檔，但它的強項在「線上即時改」，弱點在「掃描覆蓋範圍」。當你發現某串字在外掛裡完全搜不到，直接切到 Poedit 從 pot 處理會更省事，反覆重裝外掛、清快取只是浪費嘗試時間。換句話說，工具的選擇應該跟著「字串有沒有被掃到」走，個人偏好擺在後面。
事前準備：找到 pot 檔、下載 Poedit
開始翻譯前要先做兩件事：第一是到外掛或主題的 languages、lang、i18n 資料夾找 pot 檔，第二是到 Poedit 官網下載安裝翻譯軟體。若完全沒有 pot 檔，Poedit 也能從外掛原始碼重新掃描字串生成模板，不會讓你卡關。
找 pot 檔這步驟聽起來玄，其實就是把外掛資料夾打開逛一圈。通常 pot 檔會放在 languages、lang、或 i18n 這幾個資料夾裡，檔名長得像 myplugin.pot。如果是透過 外掛安裝 流程跑起來的網站，想從主機端取得原始檔，可以從 WordPress.org 外掛頁下載 zip 解開來看，或從主機後台直接進到外掛資料夾翻找。接著到 Poedit 官網 依作業系統下載 Windows 或 Mac 版，安裝完成就能進入翻譯流程；若外掛已有現成繁中 po 檔，可直接開啟編輯，省去生成步驟。
Poedit 本身是免費軟體，下載後直接安裝就能用，跨平台支援 Windows 與 Mac [來源：Poedit 官網〈https://poedit.net〉〈2026〉]。付費的 Pro 版提供預先翻譯建議等進階功能，但對絕大多數站長來說，免費版要開 pot、翻字串、存 po 與 mo 已經綽綽有餘。
要留意的是，有些外掛根本沒附 pot 檔（尤其是付費外掛或開發者偷懶的那種），這時別慌，Poedit 可以直接指向外掛的資料夾，掃描 PHP 原始碼裡的 __()、_e() 這類翻譯函式，把所有字串抓出來自動生成 pot。就算外掛作者沒給 pot，也能自己生一個出來，這條後路是翻譯外掛沒有的。
用 Poedit 開啟 pot 檔、選繁中語系實做
開啟 Poedit 選「建立新的翻譯」，指定外掛的 pot 檔，接著選擇繁體中文（zh_TW）語系，就會進入可逐筆翻譯的編輯畫面，左邊是原文、右邊填入譯文。這幾步操作沒有任何程式門檻，跟用記事本改字差不多。
實際走一次流程。開啟 Poedit 後，第一個畫面會看到三個主要選項，選「建立新的翻譯」（Create new translation），接著指向剛剛找到的 pot 檔。選好之後 Poedit 會問要翻成哪個語系，務必選「繁體中文」，對應的代碼就是 zh_TW。
進到編輯畫面後，會看到一長串英文字串，那就是外掛裡所有可以翻譯的文字。以某款會員積點外掛為例，找到 "Points to redeem" 這串，在右邊的譯文欄填入「可使用點數」，就完成一筆翻譯。po 檔只是文字檔，還沒上傳之前對網站一點影響都沒有，不用擔心填錯弄壞網站。翻譯量大時善用 Command+F（Mac）/ Ctrl+F（Windows）搜尋定位最有效率。
需要特別留意的是，如果外掛已經有現成的繁中 po 檔（例如你從 RY WooCommerce Tools 這類本土外掛看到中文），那你根本不用從 pot 開始，直接開啟那個 po 檔繼續編輯即可，省下重新翻一遍的功夫。判斷的方法很簡單：去外掛資料夾看有沒有 -zh_TW.po 這個檔案。有的話直接用它，沒有的話才走 pot 建立新翻譯的路線。翻完 po 與 mo 後，下一步就是把它們搬到正確的伺服器路徑，這一步的細節接著馬上講。
特殊符號不能動，否則字串直接壞掉
字串裡的 %s、%1$s、%2$s、<b></b> 等都是系統用來塞動態數值或格式的佔位符，翻譯時必須原封不動保留，刪掉會導致畫面顯示錯亂或數值消失。大量翻譯時則用 Poedit 的搜尋功能（Command+F / Ctrl+F）逐筆定位最有效率。
這一節是整個流程最容易出事的地方，請特別小心。當你翻到某一串字，發現裡面夾雜了 %s、%1$s、%2$s、<b>、</b> 這類符號時，這些全部都是系統的佔位符。%s 會在執行時被換成某個變數（例如會員點數、訂單金額），<b> 則是 HTML 的粗體標籤。你翻譯時只要做一件事：把這些符號原封不動照抄到譯文裡，一個字元都不要動。
| 佔位符類型 | 作用 | 翻譯時處理方式 | 刪掉的後果 |
|---|---|---|---|
%s | 單一變數（如點數、金額） | 原樣保留 | 變數消失，顯示空白或錯誤 |
%1$s / %2$s | 有序變數（指定位置） | 原樣保留、順序不對調 | 數值塞錯位置，畫面錯亂 |
<b> / </b> | HTML 粗體標籤 | 原樣保留 | 版面跑掉或破版 |
%d | 整數變數 | 原樣保留 | 數字顯示失敗 |
舉個實例，原文是 "You have %s points available"，正確譯文是「你有 %s 點可用」。如果你手滑把 %s 刪掉寫成「你有點可用」，使用者就永遠看不到自己到底有多少點，這在 結帳欄位、縣市下拉選單 或積點顯示頁面會直接讓客人一頭霧水。所以只要看到這類符號，全部原封不動保留，不要動到它，這條規則沒有例外 [來源：WordPress.org 官方 localization 文件〈https://developer.wordpress.org/plugins/internationalization/localization/〉〈2026〉]。
另一個提速技巧是善用搜尋。外掛動輒幾百、上千條字串，一條條看會看到眼花。在 Poedit 裡按 Command+F（Mac）或 Ctrl+F（Windows）叫出搜尋視窗，輸入想翻的那串英文，按 Enter 或「下一筆」就能跳到目標，直接在譯文欄輸入中文。全部翻完後按 Command+S 或 Ctrl+S 儲存，這時 Poedit 就會同時產出 po 與 mo 兩個檔案。
複數形與上下文：兩個進階但容易漏掉的細節
除了佔位符，pot 裡還藏著兩種容易讓人翻錯的結構，值得單獨點出來。第一種是複數形（plural forms）。英文裡「1 item」與「2 items」是兩條不同的字串，pot 會用 %d item 與 %d items 分開登錄；繁體中文沒有單複數的形態變化，所以你會把兩條都翻成「%d 項商品」或「%d 個項目」。在 Poedit 裡，複數形字串會顯示成兩個輸入框（單數與複數），務必兩格都填，留空會導致 WordPress 在某些數量下退回顯示原文。Poedit 的 po 檔開頭那段 "Plural-Forms: nplurals=1; plural=0;\n" 標頭，就是告訴編譯器「繁中只有一種複數形」，這段設定錯了會讓整個複數機制失效。
第二種是上下文註解（msgctxt）。同一串英文在不同位置可能要翻成不同中文，例如 "Cart" 在購物車頁面是名詞「購物車」，在動作按鈕上可能是「加入購物車」。為了區分，開發者會在 pot 裡給字串加上 msgctxt 標記（例如 button、page、label）。在 Poedit 編輯畫面，這類字串會帶有一行灰色提示說明它的上下文，翻之前先看一眼提示，能避免把按鈕文案與頁面標題搞混。msgctxt 不同的字串在 Poedit 裡會當作獨立條目，所以同一串英文可能出現好幾列，這是正常的，逐筆照上下文翻即可。
| 結構 | 在 Poedit 的樣貌 | 翻譯要點 | 常見錯誤 |
|---|---|---|---|
| 複數形（plural） | 單數與複數兩個輸入框 | 繁中兩格填相同譯文 | 只填一格，導致特定數量顯示原文 |
| 上下文（msgctxt） | 條目帶灰色上下文提示 | 依提示決定譯文 | 把按鈕文案當頁面標題翻 |
| 佔位符（%s、%d） | 夾雜在原文中的符號 | 原樣照抄 | 刪除或改寫導致數值消失 |
| HTML 標籤（<b>） | 夾雜在原文中的標籤 | 原樣照抄 | 破壞版面結構 |
把這四種結構（佔位符、HTML 標籤、複數形、上下文）記清楚，翻譯時出錯的機率就會大幅下降。新手最常在這裡翻車，多半是因為只盯著英文字面，沒注意到字串背後的程式結構。養成「翻之前先掃一眼有沒有特殊符號或雙格輸入框」的習慣，等於先幫自己排掉八成的事故風險。
儲存與命名
檔名必須是「外掛或主題的文字網址名（slug）-語言代碼」格式，外掛名與語言之間用連字號「-」連接，繁體中文用 zh_TW；儲存 po 檔後 Poedit 會自動產出同名的 mo 檔。檔名寫錯，WordPress 就認不得你的翻譯。
命名這件事看似小事，卻是新手最容易翻車的地方。公式很簡單：[外掛slug]-[語言代碼].副檔名。外掛的 slug 就是你安裝時那個資料夾的全名，直接複製貼上最保險，千萬不要自己縮寫或改字。以會員積點外掛為例，它的 slug 是 yith-woocommerce-points-and-rewards，所以檔名就是：
yith-woocommerce-points-and-rewards-zh_TW.poyith-woocommerce-points-and-rewards-zh_TW.mo
| 項目 | 規則 | 範例 |
|---|---|---|
| 外掛 slug | 複製資料夾全名 | yith-woocommerce-points-and-rewards |
| 連接符號 | 半形連字號「-」 | slug-zh_TW |
| 繁中代碼 | 固定 zh_TW | zh_TW |
| 副檔名 | po 與 mo 成對 | .po 與.mo |
| 大小寫 | 代碼維持原大小寫 | zh_TW（非 zh_tw） |
這裡有兩個細節要盯緊。其一是 po 與 mo 的檔名必須完全一致，只差副檔名，如果你把 po 存成 myplugin-zh_TW.po，mo 就得是 myplugin-zh_TW.mo，不能一個有底線一個沒有。其二是繁中代碼固定是 zh_TW，注意是大寫的 TW，不是 zh_tw，這個大小寫寫錯 WordPress 一樣讀不到。簡體中文則是 zh_CN，這套代碼遵循 WordPress 官方語系清單 [來源：WordPress Polyglots 語系團隊清單〈https://make.wordpress.org/polyglots/teams/〉〈2026〉]。
儲存的當下，Poedit 會自動編譯出對應的 mo 檔，你不用手動做任何事。所以當你按下 Command+S，資料夾裡應該會同時冒出.po 與.mo 兩個檔案，這就代表翻譯檔已經備齊，可以進入上傳階段了。如果你之後還要再改翻譯，只要重新開啟 po 編輯、儲存，mo 就會跟著更新，不用動 mo 本身。命名搞定後，如果你還想為商品頁補上 商品頁 SEO 或處理 稅金設定，這些介面文字也都能用同一套方法中文化。
上傳翻譯檔到正確路徑：cPanel 與 FTP 兩種方法
外掛翻譯檔要上傳到 wp-content/languages/plugins，主題翻譯檔上傳到 wp-content/languages/themes；上傳方式可用主機後台的 cPanel 檔案管理員，或用 FTP 軟體連線上傳。po 與 mo 兩個檔案都要一起傳上去。
產出檔案後，接下來就是把它放到 WordPress 指定的位置。外掛翻譯檔的正式路徑是 public_html/wp-content/languages/plugins，主題翻譯檔則是 public_html/wp-content/languages/themes。如果你翻的是 WooCommerce 佈景主題，就走 themes 那條；如果翻的是 社群登入外掛 這類外掛，就走 plugins 那條。上傳的方法主要有兩種，看你的主機環境決定。
| 方法 | 適合情境 | 操作工具 | 優點 |
|---|---|---|---|
| cPanel 檔案管理員 | 主機有 cPanel 介面 | 主機後台「檔案管理員」 | 免裝軟體、網頁直接傳 |
| FTP 軟體上傳 | 無 cPanel 或想批次管理 | FileZilla 等 FTP 工具 | 穩定、可批次、斷線續傳 |
第一種方法是走 cPanel。許多虛擬主機商（例如 Bluehost、A2 Hosting、SiteGround、HostGator）的後台都內建檔案管理員，登入後找到「檔案管理員」這個工具，一路點進 public_html → wp-content → languages → plugins，把 po 與 mo 兩個檔案直接拖進去上傳就完成，完全不用寫程式，跟在檔案總管裡複製貼上一樣直覺。
第二種方法是走 FTP。主機沒有 cPanel（例如 Cloudways 這類雲端主機，或自架 VPS），或想一次傳很多檔案，就用 FTP 軟體連線上傳，操作細節可參考 WordPress FTP 檔案上傳教學。連上主機後，同樣進到 wp-content/languages/plugins 把檔案傳上去。不管用哪種方法，po 與 mo 都要傳，缺一個都不行。
WooCommerce 與 Email 範本的進階翻譯情境
WooCommerce 是 WordPress 生態裡翻譯需求最密集的區塊，W3Techs 的調查顯示 WooCommerce 在其統計的電子商務系統裡佔了 48.6%，涵蓋全體網站的 8.2% [來源：W3Techs — Usage Statistics and Market Share of WooCommerce https://w3techs.com/technologies/details/cm-woocommerce 2026-06-29]。這意味著大量站長會碰到的翻譯問題，幾乎都集中在購物車、結帳、訂單狀態、Email 通知這幾個模組。把這幾個高風險區一次摸熟，就能涵蓋絕大多數的實戰需求。
WooCommerce 核心本身的翻譯檔體積龐大，字串數以千計，但它有官方維護的繁中語言包，會隨版本自動更新，通常不需要你從 pot 重翻。真正會讓人卡關的，是疊加在 WooCommerce 之上的各種擴充：會員積點、結帳欄位、電子發票、物流外掛、金流回傳訊息。這些擴充的翻譯完整度參差不齊，而它們的字串又多半是動態組合的，例如「您的訂單 #%s 已出貨，預計 %s 送達」這類把變數夾在中間的句子，正是翻譯外掛最容易漏掉的類型，也是 Poedit 最能發揮的地方。
Email 範本是另一個獨立戰場。WooCommerce 的訂單確認信、出貨通知、退款通知，其文字同樣來自翻譯檔，但它們常被誤以為是「郵件外掛設定」而找不到出處。實際做法是：到 WooCommerce 的語言資料夾找對應的 woocommerce-zh_TW.po（核心郵件文案）或擴充自己的翻譯檔（自訂郵件文案），用 Poedit 搜尋關鍵字（例如 order、shipping、refund），逐筆改成繁中，再上傳回 languages 路徑。改完後記得寄一封測試訂單給自己，確認郵件真的套用了新譯文，因為有些郵件會被快取或被 訂單通知 這類轉發機制攔截。
| WooCommerce 區塊 | 翻譯檔來源 | 常見動態字串 | 處理建議 |
|---|---|---|---|
| 購物車與結帳頁 | woocommerce 核心語言包 | %s 項商品、小計金額 | 改官方語言包或用 Poedit 覆寫 |
| 訂單狀態與 Email | woocommerce 核心語言包 | 訂單編號、出貨日期 | 搜尋 order/shipping 定位 |
| 會員積點外掛 | 擴充自己的 pot | 可用點數、到期日 | 走 Poedit 從 pot 處理 |
| 金流回傳訊息 | 金流外掛語言包 | 交易結果、錯誤代碼 | 留意佔位符不可刪 |
| 物流與發票 | 物流與發票外掛 | 追蹤碼、發票號碼 | 測試一筆訂單驗證 |
一個務實的分工建議：核心 WooCommerce 的繁中交給官方語言包自動處理，你自己用 Poedit 維護的，應該鎖定在「官方語言包沒翻、或翻得不符你店鋪語氣」的那些擴充字串。這樣既能享受自動更新的便利，又能精準補上缺口。對於把 WooCommerce 當主力商店經營的站長，這套分工是兼顧效率與完整度的最佳解。
用 WP-CLI 批次管理與重新編譯翻譯
對於有 SSH 權限、或主機支援命令列的站長，WP-CLI 是管理翻譯檔的高效工具。它能一次更新全部外掛的語言包、重新編譯 mo、檢查語言包狀態，省去逐個用 Poedit 開檔的時間。WP-CLI 的語言相關指令屬於 wp language 與 wp i18n 兩個子命令群，前者管理已安裝語言，後者用來從原始碼生成 pot。
- 查看已安裝語言：
wp language core list，確認繁中 zh_TW 是否啟用 - 更新核心與外掛語言包：
wp language core update與wp language plugin update --all - 安裝某外掛的繁中包：
wp language plugin install 外掛slug zh_TW - 從原始碼生成 pot（需 WP-CLI i18n 命令）：
wp i18n make-pot 外掛資料夾 輸出.pot - 檢查語言包狀態：
wp language plugin status 外掛slug，看翻譯進度與更新
WP-CLI 與 Poedit 可以無縫搭配。你可以用 wp i18n make-pot 在伺服器端先掃出 pot，下載到本機用 Poedit 翻譯成 po/mo，再上傳回 languages 路徑；之後只要外掛改版，就用 wp language plugin update 拉官方新版，再把你自製的 po/mo 覆蓋回去。這套流程特別適合外掛數量多、或有多人協作的站台，能把維護成本壓到最低。不過 WP-CLI 對主機環境有要求，若是共享主機沒開 SSH，就回頭走 cPanel 與 Poedit 的組合即可。
需要提醒的是，WP-CLI 的 update 指令會從 WordPress.org 拉官方語言包覆蓋 languages 資料夾裡的同名檔案。所以如果你已經用 Poedit 改過某個外掛的官方繁中包，執行更新前請務必備份你的版本，否則更新一次就把你的修改蓋掉。這也是為什麼前面強調過：自製的、不想被覆蓋的翻譯，最好用獨立檔名或放在不被自動更新碰觸的位置。
翻譯沒生效的疑難排解清單
最常見的挫折不是翻不出來，而是翻好了、檔案也上傳了，畫面卻還是英文。這時不要急著重翻，先照下面的清單逐項排除，九成的「翻譯沒生效」都能在十分鐘內找到原因。這份清單是依照發生頻率由高到低排列，從最可能的快取問題開始排查最有效率。
以這類「翻好了卻還是英文」的回報情境為例，依典型表現幅度，原因分布大約落在：快取未清約佔四到五成、只傳了 po 沒傳 mo 約佔兩到三成、檔名或路徑錯誤約佔一成多、網站語系沒切到繁中約佔一成、其餘（權限、多語例外掛接管、硬編碼）合計約佔一成以內。常見的狀況是，站長用 Poedit 翻完、也確認過檔名正確，卻忘了 WordPress 實際讀的是 mo 檔，而 Poedit 在 po 有語法錯誤時可能存檔成功但 mo 並未更新，於是畫面紋風不動；另一種近似狀況是 mo 確實產出了，卻被上傳到外掛資料夾而非 languages，更新或快取清空後就讀不到。一個誠實的限制要點出來：這套分布只是這類站普遍的相對排序，實際比例會因主機環境、快取層數、外掛組合而漂移，並不是一份測量過的數據。決策角度上，與其逐項猜測，不如固定從「無痕視窗＋確認 mo 檔存在於正確 languages 子路徑」這兩步先收斂，因為這兩項合計就能排除掉大半的典型案例，再往下走檔名、路徑、語系才更有效率。
- 快取未清：頁面快取、快取外掛、CDN、瀏覽器快取都會讓舊畫面留在前台，先清快取再測
- 檔名拼錯：slug 少一個字母、zh_TW 寫成 zh_tw、底線與連字號混用，都會讓 WordPress 讀不到
- 路徑放錯：外掛翻譯誤放到 themes、主題翻譯誤放到 plugins，兩者子資料夾不同
- 只傳 po 沒傳 mo：WordPress 實際讀的是 mo，缺了 mo 等於沒翻
- mo 編譯失敗：po 檔有語法錯誤時 Poedit 可能存檔但 mo 未更新，重新開啟 po 儲存一次
- 檔案權限：languages 資料夾或 mo 檔權限過嚴，Web 伺服器讀不到，調為 644 或 755
- 網站語系設錯：後台「設定 → 一般 → 網站語言」必須設為繁體中文，否則不會載入 zh_TW 檔
- 多語例外掛覆寫：Polylang、WPML 等多語系方案可能接管語言載入，需在其設定內處理
- 外掛本身硬編碼：極少數外掛沒走 gettext，字串直接寫死在 PHP，這種只能改原始碼並承受更新風險
排查時建議搭配瀏覽器的無痕視窗測試，這樣能排除本機快取與登入狀態的干擾，看到最接近訪客的真實畫面。如果清完所有快取、檢查過檔名路徑與 mo 檔都沒問題，字串卻仍是英文，那就回到「字串來源」這一步，確認它到底是不是走 gettext 機制。能在 pot 裡搜到的字串，幾乎都走得通；搜不到的，才需要懷疑外掛是否硬編碼。
判斷字串是否走 gettext，有一個實用的快速驗證法：用 Poedit 開啟該外掛的 pot 或掃描產生的 pot，用搜尋找那串英文。找得到，代表它是可譯字串，問題出在載入或命名；找不到，代表它可能寫死在程式碼，或是由 JavaScript、範本檔動態產生。值得多點出來的是，前端由 JavaScript 動態渲染的字串（例如結帳頁的區塊或 AJAX 回傳訊息）並不走 PHP 的 gettext，就算 pot 裡也搜不到，這類字串要用腳本本地化（wp-i18n 的 Jed 格式 json 檔）另行處理，把它當成一般 po/mo 翻只會白忙一場。另一個容易混淆的邊界是快取層疊加：頁面快取、物件快取、CDN 與瀏覽器快取任何一層沒清乾淨，都可能讓你誤判「翻譯沒生效」，實際上 mo 早已正確讀入。這一步能把「翻譯沒生效」的方向一次收斂到對的軌道上，避免在錯誤的方向上白費功夫。
翻譯檔必須放 languages，不能放外掛資料夾
把自製翻譯檔放在外掛原本的資料夾，下次更新外掛時檔案會被官方版本整個覆蓋洗掉；放在 wp-content/languages 下則是 WordPress 指定的安全位置，更新不會動到它，翻譯才能長久保留。這是整篇最容易踩、也最痛的雷。
很多新手以為「把翻譯檔放進外掛自己的 languages 資料夾就好了」，這是錯的。原因在於 WordPress 的更新機制會用官方的新版整包覆蓋掉舊版外掛資料夾 [來源：WordPress.org 官方外掛更新機制文件〈https://developer.wordpress.org/plugins/wordpress-org/upgrading-your-plugin-on-wordpress-org/〉〈2026〉]，覆蓋的當下，放在那個資料夾裡的任何檔案都會被一起清掉，包括辛苦翻好的 po 與 mo。換句話說，翻了半天，外掛一更新就全部歸零。主題同理，要放 languages/themes 而非主題資料夾。
而 wp-content/languages 是 WordPress 核心層級的翻譯存放區，外掛主題更新時根本不會去碰它，放在這裡的翻譯檔能安全地長久存活，這也是 WordPress 官方文件明確推薦的位置 [來源：WordPress.org 官方主題本地化文件〈https://developer.wordpress.org/themes/functionality/localization/〉〈2026〉]。放對位置是這套方法能不能撐過更新的關鍵。
這也牽涉到備份觀念。每次更新 外掛或主題 之前，先把自己的 po/mo 檔從 languages 資料夾拉一份下來備份，萬一更新過程出意外，至少翻譯心血還在，備份可參考 WordPress 備份與還原完整指南。如果正打算換主機或搬家，也別忘了把 languages 整包帶走，免得翻譯在新環境憑空消失。
整個 Poedit 翻譯流程的步驟到此齊全：找 pot、用 Poedit 開、翻字串保符號、正確命名存檔、上傳到 languages。長期要做整站多語系的話，Polylang 或 TranslatePress 這類視覺化方案會更適合，那是另一個層級的工程；對只想把幾串英文中文化掉的站長來說，Poedit 加正確路徑就夠用了。
常見問題 FAQ
沒有 pot 檔的話還能翻譯嗎？
可以。Poedit 能直接掃描外掛的 PHP 原始碼，抓出裡面的翻譯函式字串自動生成 pot 模板，再走正常的 po/mo 流程。這條後路是翻譯外掛做不到的。
複數形與上下文字串在 Poedit 裡要怎麼處理？
複數形會顯示單數與複數兩個輸入框，繁中兩格都填相同譯文即可；上下文字串會帶灰色提示說明使用情境，依提示決定譯文。兩者都不要漏填，否則特定情況下會退回顯示原文。
WooCommerce 的 Email 通知文字要去哪裡翻？
核心郵件文案來自 woocommerce 核心語言包，擴充郵件文案則來自對應擴充的翻譯檔。用 Poedit 搜尋 order、shipping、refund 等關鍵字定位，改完上傳回 languages 路徑，再寄一封測試訂單驗證。
WP-CLI 能取代 Poedit 嗎？
不能完全取代。WP-CLI 適合批次更新語言包、生成 pot、檢查狀態，但實際的譯文填寫與校稿仍以 Poedit 的視覺化介面更順手，兩者搭配使用最有效率。
Loco Translate 和 Poedit 要怎麼選？
Loco Translate 適合臨時改幾串能被掃到的字，操作直覺；Poedit 適合處理翻譯外掛掃不到的動態字串與長期維護。多數站長的實務組合是外掛做八成、Poedit 補兩成。
翻譯檔上傳了畫面還是英文，要怎麼排查？
依序檢查快取、檔名、路徑、mo 檔是否存在、檔案權限、後台網站語系是否設為繁中，以及有無多語例外掛接管。最常見的原因是快取未清與只傳了 po 沒傳 mo。