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 的讀者可以直接對照原始碼，秒判這個外掛值不值得你花時間翻。

前台出現未翻譯字串，可能是語言包缺漏、載入路徑或 text domain 不符、快取仍顯示舊頁面、字串由 JavaScript 處理，或原始程式沒有正確國際化。先定位字串來源，再決定用 Poedit、後台工具或回報開發者。

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

理解這點之後就能分清 Poedit 的用途：它能讓你編輯 PO 翻譯來源並產生對應的 MO 檔，適合處理可翻譯字串尚未翻好或需要更新的情況。若問題出在 text domain、載入路徑、快取或 JavaScript 翻譯檔，仍要按字串來源另外排查，不能只靠重新存檔解決。

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

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

POT 是待翻譯字串範本，PO 是可編輯的語言檔，MO 是傳統的編譯輸出。Poedit 常用 PO 編輯、儲存後產生 MO；新版本 WordPress 也可能使用其他可執行翻譯格式，所以不能說它永遠「只認得 .mo」。排查時以目前 WordPress 版本和實際載入的檔案為準。

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

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

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

翻譯檔名稱常由 text domain、語系和載入位置組合，例如外掛語言套件可見 text-domain-zh_TW.mo。主題、外掛自身目錄與 WordPress 語言套件路徑可能有不同規則；先查看開發者文件與現有檔案，再按該套件實際的 text domain 命名，不要把單一範例當成所有情境的唯一規格。

更關鍵的是放在哪裡。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 中的字串，讓你逐條填入繁中譯文。存檔名稱要依外掛的 text domain、zh_TW 語系與預定載入路徑核對，不要假設工具建議的檔名一定符合 WordPress。以 wp-content/languages/plugins/ 為例，常見檔名是 text-domain-zh_TW.po 與對應的 .mo；放在外掛自身目錄時，還要依該外掛的載入設定確認。

第三步：開始逐句翻譯

翻譯介面很直覺：上方選單點一條原文，下方輸入框打中文，按 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% 翻譯」背後的真相：哪些字串你永遠翻不到

Poedit 的字串清單找不到某段英文，不能直接判定開發者沒有國際化。也可能是 POT 尚未更新、字串來自另一個外掛或主題、由 JavaScript 翻譯檔提供，或頁面仍在顯示快取。先定位輸出來源，再查對應 text domain 與原始碼。

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

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

在 PO 或 POT 中找到字串，優先檢查譯文、佔位符與語言檔載入；找不到時，先更新範本並確認字串所屬外掛或 JavaScript 套件。只有在確認原始程式將可見文字寫死、未提供可翻譯介面後，才回報開發者處理國際化問題。

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 與程式碼搜尋追查來源。

也因此，翻譯之前先搞清楚「字串從哪裡來」比急著動手翻更重要。同一份 PO 可以保存 PHP 與 JavaScript 字串的譯文，但 WordPress 的 JavaScript 翻譯還需要產生對應來源檔的 JSON，並由外掛註冊腳本翻譯；只上傳 MO 不會自動照顧 JS 元件。排查時把 PHP 載入、JSON 產生與腳本註冊分開核對，也能看出外掛是否有完整的國際化支援。

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

部署翻譯前，先確認來源檔備份、版本對應與預定載入路徑。把 MO 放進某個資料夾能否持久生效，還取決於官方語言包、外掛更新及站點部署方式；上線後要重新載入頁面核對實際字串。

路徑一：上傳到 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、快取與字串來源逐項排查。

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

另一個要查的是翻譯檔名與實際 text domain 是否一致。WordPress.org 外掛的 text domain 原則上應與外掛 slug 相同；先核對官方 slug、主檔 Text Domain（若有）與程式中翻譯函式使用的 domain，再依檔案所在目錄確認命名。不要只從外掛顯示名稱推測，也不要把自訂外掛的特殊設定當成 WordPress.org 外掛的通用規則。

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 負責正式翻譯與校稿，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。讓它跟著官方更新走，以後你連自己維護都省了。

Poedit 可用來編輯可翻譯的字串，但不保證任何外掛或主題能達到 100% 繁中。先確認站點語系、字串來源與翻譯檔路徑，再依更新流程保留 PO 原始檔；未提供國際化介面的字串應由開發者修正。

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

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

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

這個「更新而非重來」的流程，靠的是把既有譯文保留在 PO 原始檔，讓團隊能版本控管、備份與接手。Poedit 的翻譯記憶則是電腦上的獨立本機資料庫，不會因為交付 PO 檔就自動跟著轉移；需要跨電腦延續建議譯文時，應另外規劃翻譯記憶的移轉。管理良好的 PO 檔仍是重要的「繁中翻譯資產」，但要同時記錄套件版本與部署位置。

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

長期維護的站點應保存 PO 原始檔、對應版本與部署方式，更新外掛後比對新增字串。若使用官方語言包或多人協作，還要分清自訂譯文與社群譯文的覆蓋關係，避免下次更新時不知道哪份檔案正在生效。