Redirection 是一款熱門的網站轉址與 404 監控外掛，安裝數超過 200 萬，繁體中文的翻譯進度卻是 0%，745 個介面字串一句都還沒有人翻完。用的是同一份英文原文，簡體中文那邊已經有 76.9% 核准可用。
這不是 Redirection 一家的問題。繁體中文完成度跟外掛紅不紅、安裝數多寡沒有穩定的對應關係——WooCommerce、Contact Form 7 這類幾乎人人會裝的外掛，繁體中文完成度都在 9 成以上，但同樣安裝數破 200 萬的 Redirection 卻是 0%。多數外掛作者確實花了心力做國際化，字串最後有沒有被翻完，關鍵在有沒有志工社群剛好排到這支外掛，跟外掛本身受不受歡迎、作者用不用心關係不大。對經營中文網站的人來說，這代表裝好的某支外掛，介面很可能永遠停在英文，等社群志工排到自己這支外掛的那一天，遙遙無期。
要解決這個困境，還是有辦法不必乾等社群排隊。用 Loco Translate 這支外掛，你可以直接在自己的網站後台，把這些還沒人翻的英文字串填成繁體中文，不用碰任何程式碼。不過動手之前，先弄清楚繁體中文為什麼特別容易被漏掉，這牽涉到外掛怎麼被翻譯、以及翻譯社群怎麼分工。
多數外掛沒有中文，繁體版本又比簡體更少被翻好
外掛會不會有中文介面，起點不是使用者裝了什麼翻譯工具，而是外掛作者當初有沒有把每一句要顯示的文字，用 __()、_e() 這類函式包起來，並宣告一個跟外掛 slug 完全一致的文字領域（text domain）。少了這一步，那段文字在原始碼裡就是死的英文字串，任何翻譯工具都無法把它抓出來變成可翻譯項目，包括 Loco Translate 也一樣。多數主流外掛的作者都有做到這一步，缺口通常出在下一關，有沒有人把它翻完。
這句字串被標記成可翻譯之後，接下來要靠一個叫 GlotPress 的翻譯協作平台，讓志工社群認領翻譯工作。繁體中文（zh_TW）與簡體中文（zh_CN）是兩個各自獨立運作的語系團隊，各自有自己的審核者與翻譯人力，優先順序也不一樣。同一支外掛丟到兩個團隊手上，進度可以差到一個是 0%、另一個接近全數審核完成，Redirection 正是這種落差的具體例子：745 個字串，繁體中文一句都還沒翻，簡體中文卻已經有 573 個核准、172 個等待審核，等於整份原文都已經有人翻過一輪。
就算志工真的動手翻了一部分，使用者的網站也不一定馬上看得到。WordPress 的語言包（language pack）機制規定，字串核准比例要達到 90% 以上，系統才會自動產生語言包並推播給各個網站下載；官方 Polyglots 手冊寫得很明確，只要某個外掛或佈景主題在特定語系的核准比例達到 90%，語言包會在翻譯更新後 30 分鐘內產生。換句話說，翻了 50%、80% 都還不算數，網站介面照樣顯示英文，這也是為什麼有些外掛明明社群已經翻了不少，介面卻還是英文。
這種結構性落差不是單一案例。就算是安裝數動輒破百萬的外掛，繁體中文完成度也可能天差地遠——有的接近全數翻完，有的像 Redirection 一樣完全掛零，差別不在外掛本身受不受歡迎，而在有沒有志工社群剛好接手。只要一支外掛沒被排進志工優先名單，網站介面停留在英文就幾乎是常態。搞懂這套分工邏輯之後，接下來要處理的問題就很具體，與其乾等志工排隊，不如自己動手補上，這正是 Loco Translate 要做的事。
Loco Translate 是什麼？從 PO 到 MO 的翻譯運作方式
Loco Translate 是一支免費外掛，核心身份是「PO 檔編輯器加 MO 編譯器」，讓你在瀏覽器裡直接編輯翻譯檔案，存檔的同時自動編譯成 WordPress 讀得懂的格式。它不是自動翻譯外掛，雖然可以選擇性串接付費翻譯 API，但預設情況下每一句翻譯都要人工填入；它也不會處理資料庫裡的動態內容，像是某個外掛設定頁讓使用者自訂的顯示文字，那種內容要改的地方是那支外掛自己的設定畫面，跟 Loco Translate 無關。
Loco Translate 官方的產品介紹頁把自己定義成「主要是一支檔案編輯器」，並列出三條明確的邊界：不翻譯動態內容、不會自動翻譯整個網站、也不負責偵測或切換網站的語言設定。搞懂這三條邊界，才不會誤會「翻完介面卻還是看到某段文字沒變」是工具壞了。多半是那段文字本來就不在它的管轄範圍內。
PO、POT 與 MO 三個檔案各自的角色
這套翻譯機制的底層是 gettext，使用者在 Loco Translate 編輯器裡看到的畫面，實際上對應到磁碟上三種不同角色的檔案。.pot（Portable Object Template）是外掛或佈景主題原始碼抽出來的英文字串範本，本身沒有任何翻譯內容，功能比較像一張空白表格，交給譯者去填。.po（Portable Object）是譯者已經填入某個語言翻譯的可讀文字檔，一種語言對應一份；.mo（Machine Object）則是由 .po 編譯出來的二進位檔案，WordPress 的 gettext 函式實際載入、拿去顯示在畫面上的就是這個檔案。.po 跟 .pot 本身，WordPress 不會直接讀取。
這也是為什麼有時候會出現「明明已經翻了，介面卻沒變」的狀況，多半是 .po 存檔之後沒有成功編譯出對應的 .mo。另外，.po 檔案裡每一條字串都用 msgid（原文）和 msgstr（譯文）標記，如果某句翻譯是靠系統比對舊版本相似字串自動帶入、還沒有人工確認過，會被標上 fuzzy 旗標，代表這句翻譯可能已經不準，需要人工複核才能真正生效。看到編輯器裡某句翻譯標成待確認，通常就是這個狀態。
系統、作者與自訂三個位置的載入順序
翻譯檔案不是只能放在一個地方，Loco Translate 把可能的存放位置分成三種。「系統」（System）指的是 WordPress 全域語言目錄 wp-content/languages/，WordPress 內建的語言安裝程式會直接覆寫這裡的檔案；「作者」（Author）指外掛或佈景主題自己資料夾內附的語言檔，外掛更新時整個資料夾會被整批換掉，裡面的翻譯也跟著消失；「自訂」（Custom）則是 Loco Translate 額外提供的保護目錄 wp-content/languages/loco/，不受 WordPress 自動更新影響。
三個位置的載入順序是自訂優先於系統、系統優先於作者。只要 Loco Translate 正常運作，網站會先套用自訂目錄裡的翻譯，找不到的字串才依序往系統、作者版本回退去補齊。這是合併，不是整份取代，自訂檔案裡沒覆蓋到的字串，仍然會用原本該載入的版本顯示。搞懂這個順序，才知道為什麼下一節新增語言時，位置一定要選自訂資料夾。
實際動手，替 Redirection 外掛補上繁體中文
以前面提到、繁體中文完成度 0% 的 Redirection 當範例，從安裝 Loco Translate 開始，就能一步步在後台把介面翻成繁體中文。整套操作走的是 Loco Translate 官方文件記載的標準流程，不管拿來翻哪一支外掛或佈景主題都通用，只是這裡剛好挑一個進度掛零、缺口看得最清楚的外掛來示範。
先在網站後台的「外掛」選單搜尋 Loco Translate，安裝並啟用，跟安裝任何一支外掛的流程完全一樣，不需要額外設定金鑰或帳號。啟用之後，左側選單會多出一個 Loco Translate 的入口，底下會列出「佈景主題」與「外掛」兩個子選單，接下來的操作都在「外掛」這邊進行。
動手之前，先看這個外掛目前的翻譯進度
點進 Loco Translate 的外掛清單，會看到網站上已安裝的每一支外掛各自列一行，包括 Redirection。點進 Redirection 那一行，畫面會列出這支外掛目前已經存在的語言檔案，以及各自的完成度與所在資料夾標籤，System、Author 或 Custom 都會標出來。如果清單裡完全沒有 zh_TW 這個語言，代表接下來要做的是新增語言，從零建立一份全新的翻譯檔；如果已經有 zh_TW、但完成度偏低，就是打開既有檔案繼續往下補。
以 Redirection 目前的狀態來說，清單裡不會看到任何一份完成度不是 0% 的 zh_TW 檔案，也符合前面查到繁體中文完成度掛零的事實。這種情況下，要做的就是點下新增語言按鈕，開始建立第一份繁體中文翻譯。
新增語言檔時，位置要選自訂資料夾
點下新增語言之後，畫面會依序要求選擇語言和存放位置，這一步的選擇會直接決定翻譯會不會在下次外掛更新時被整批洗掉。位置選項固定包含三種：Author，僅適合外掛作者本人使用，外掛一更新就會被覆蓋；System，由 WordPress 全域語言安裝程式管理，同樣有被覆蓋的風險；Custom，也就是 Loco Translate 保護的自訂資料夾，官方標示為建議選項，更新不受影響，載入優先權也最高。部分外掛還會額外提供自己的 Other 自訂路徑，但那需要另外查該外掛自己的文件才知道用法，多數情況下選 Custom 就夠了。
語言可以直接從 WordPress 內建的語言代碼清單挑選「中文（台灣）」，對應的就是 zh_TW，不必自己去記代碼。畫面下方還有一個模板選項，預設是只複製英文原文字串，這個選項適合從零建立全新翻譯，也是這次示範會用到的選項；只有在兩個語系夠相近、可以整包沿用既有翻譯時，才需要勾選複製既有翻譯。選好語言、位置與模板選項之後按下確認，Loco Translate 就會產生一份空白的繁體中文 .po 檔，接下來就能進到編輯器開始逐條翻譯。
在編輯器裡把介面字串換成繁體中文
新增完成後會自動進入 Loco Translate 內建的編輯器，畫面分成左邊的原文字串清單和右邊的譯文輸入框，可以用關鍵字搜尋想翻的字串，例如搜尋 redirect 就能一次看到跟轉址設定相關的所有句子。編輯器支援幾個鍵盤快速鍵加快進度：Ctrl+Enter 完成目前這條並跳到下一條、Shift+Ctrl+↓ 直接跳到下一個還沒翻譯的字串、Ctrl+S 存檔並同時觸發編譯。逐條把選單名稱、按鈕文字、404 記錄相關的用語填上對應的繁體中文，是這一步最花時間、但也最直接的部分。
原文字串裡如果出現 %s、%1$s 這類 printf 格式的佔位符，代表程式執行時會被替換成實際的數字或文字，例如轉址筆數或某個網址。翻譯這類字串時，佔位符本身不能刪除也不能更動符號，只能依照中文語序調整它出現的位置，像是原文「Redirected %s times」只需要把佔位符搬到句子該有的位置，翻成「已轉址 %s 次」，符號原封不動保留。漏改或刪掉佔位符，畫面顯示的地方輕則出現亂碼，重則直接觸發錯誤，這一步務必小心核對。
存檔後，到外掛畫面驗證繁體字真的顯示
每次存檔 .po 檔案時，Loco Translate 都會嘗試在同一個位置自動編譯出對應的 .mo 檔案，前提是伺服器對那個資料夾有正常的寫入權限，否則編譯會失敗、翻譯不會真的生效。存檔之後，回到 Redirection 自己的後台畫面重新整理一次，確認剛剛翻好的選單名稱與按鈕文字真的已經換成繁體中文，再往下翻其他字串，比一次翻完幾百條才回頭檢查來得保險。
如果網站另外裝了快取外掛，記得先清一次快取，才能在前台或後台真的看到翻譯結果，快取沒清乾淨是最容易誤以為翻譯沒生效的原因之一。萬一清完快取還是看不到中文，通常是兩種完全不同的狀況造成的。
翻譯進度停滯，通常出在這兩個環節
翻到一半最常遇到問題的地方，通常不脫兩種性質完全不同的狀況：一種是字串本身沒有被系統認出來，另一種是搞不清楚要找的字串屬於哪個外掛或佈景主題。分清楚自己屬於哪一種，才不會對著同一個地方反覆嘗試。
介面上有些字串，其實還沒被程式碼標記可翻譯
有些畫面上明顯是英文的文字，不管在 Loco Translate 編輯器裡怎麼搜尋都找不到對應項目，根源通常不在翻譯工具這一端，而在原始碼。外掛的範本檔案只會收錄作者實際用 __()、_e() 這類函式包裝過、並且宣告正確文字領域的字串，原始碼裡其他寫死的英文文字並不會出現在範本裡，自然也不會出現在 Loco Translate 的可翻譯清單中。
遇到這種情況，翻譯工具本身沒有辦法繞過，能做的是聯絡外掛作者反映，或是等作者在未來的版本補上國際化包裝。另外要分清楚一種常見的誤會：Loco Translate 只處理靜態、寫死在程式碼裡的文字，像某些外掛允許在自己的設定頁面自訂顯示文字，那類存在資料庫裡的動態內容，不在它的處理範圍之內，要改就得回到那支外掛自己的設定畫面去改。
用文字領域反查字串屬於主題還是外掛
一個網站同時裝著佈景主題與好幾支外掛時，常常分不清眼前這段文字出自哪一邊，逐一打開每個項目用眼睛找相當沒有效率。每個外掛與佈景主題在程式碼裡宣告可翻譯字串時，都要帶上一個專屬的文字領域，而且規定必須跟該外掛或佈景主題的 slug 完全一致，這正是 WordPress 用來分辨這句翻譯屬於誰的依據。
WordPress 官方外掛目錄裡有一支免費外掛叫 Text Domain Inspector，可以在前台或後台畫面上直接標出每一段可翻譯文字對應的文字領域，滑鼠移到標記上就會顯示來源。裝上它之後，看到一段還沒翻的英文，先移過去確認文字領域是哪一個，再回到 Loco Translate 打開對應的佈景主題或外掛，比憑印象亂猜快得多。
外掛版本更新後，翻譯不被洗掉的做法
辛苦翻完的字串，最怕的就是外掛一更新整批被洗掉重來。這裡要分兩種情況處理：一種是本來就該一開始就做對的存放位置，另一種是原文字串本身跟著版本改變時該怎麼因應。
翻譯檔案存放在安全的自訂資料夾
前面提過，wp-content/languages/loco/ 是 Loco Translate 提供的保護目錄，WordPress 的自動更新程序不會去寫入或刪除這裡的檔案，這也是為什麼新增語言時，位置一定要一開始就選 Custom。
如果翻譯檔案目前存放的位置不對，例如之前圖方便選了 Author 或 System，已經被某次外掛更新洗掉過，Loco Translate 的編輯畫面提供一個 Relocate（重新定位）分頁，可以把整組相關檔案一次搬到自訂資料夾，不用重新翻譯一次。這裡有一點容易被忽略，官方文件特別提醒，只搬動 .mo 檔案可能沒辦法正常運作，要用 Relocate 功能把 .po 跟其他關聯檔案一起搬過去，才算搬乾淨。
來源字串變動時，同步功能用相似比對留住舊翻譯
外掛作者發布新版本時，原文字串本身可能跟著改變，可能新增了幾句、刪掉了不再使用的功能、或只是微調了用字。這時候手上的 .po 檔案記錄的原文，會跟外掛實際使用的新原文對不上，Loco Translate 會在編輯畫面提示檔案已經跟範本不再相符，這時候要做的是按下同步（Sync）功能，讓系統重新比對新舊原文。
同步之後，新增的字串會被加進待翻清單，已經不存在的字串會被標記為過時、可以清除；如果某句原文只是些微修改，跟舊版夠相似，既有翻譯會被系統保留下來，而不是整句清空重翻，這個相似度比對機制稱為 fuzzy matching，是 gettext 標準做法的一部分。被保留下來的翻譯會加上 fuzzy 旗標，提醒使用者這句可能已經有一點誤差，值得花點時間重新確認一次是否還準確。
從根本解決，加入官方翻譯社群的路徑
把自己網站的介面處理好，只是解決眼前這一支外掛的問題；繁體中文整體翻譯人力不足的落差，其實可以靠更多人參與慢慢補上。任何人都可以直接登入 WordPress 官方帳號，在翻譯協作平台上對想要的外掛送出翻譯建議，不需要事先取得任何權限，操作跟前面在自己網站上用 Loco Translate 翻譯幾乎一樣，差別只在於這次翻好的內容送出去之後，是進到一個等待審核的公用清單，而不是直接生效在自己的網站上。
送出的翻譯建議要等具備專案翻譯編輯（Project Translation Editor，簡稱 PTE）身分的人核准，才會變成正式翻譯；累積到前面提過的 90% 核准比例，語言包才會觸發自動產生，這也是全站所有繁體中文使用者共同受惠的那一刻。想更長期參與，甚至申請成為某支外掛的 PTE，官方流程是在 WordPress 官方的 Polyglots 社群張貼申請，附上外掛名稱與語系，由該語系資深的總翻譯編輯（General Translation Editor，簡稱 GTE）評估後授權。
回到最開頭那個 0% 跟 76.9% 的落差，繁體中文會被漏掉，從來不是哪個網站設定錯了，而是整個翻譯生態系分工的結果——不同語系各自排隊，人力多寡直接反映在完成度上。Loco Translate 能做的，是讓使用者不必等排隊結果出爐，先把自己網站最常用到的那幾支外掛翻好；真正把這個落差縮小，還是要靠更多人願意花幾分鐘，在官方翻譯平台上多送出幾句翻譯建議。下次再打開一支還在顯示英文介面的外掛，至少已經知道問題出在哪一層，也知道自己能從哪一步動手補上。