Loco Translate 教學：WordPress 主題與外掛中文化翻譯的完整指南
Loco Translate 是用來翻譯 WordPress 主題與外掛「系統字串」的免費工具，能把按鈕、表單標籤、提示訊息這類英文介面改成中文，它在 WordPress.org…
Loco Translate 是用來翻譯 WordPress 主題與外掛「系統字串」的免費工具，能把按鈕、表單標籤、提示訊息這類英文介面改成中文，它在 WordPress.org 累計活躍安裝數超過一百萬次、評分接近滿分 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]。它不翻文章內容，要翻整站多語系內容的人該選 Polylang 或 TranslatePress。新手最常踩的雷是把翻譯檔存成主題內建位置，主題一更新就把翻譯覆蓋掉，這也是整個中文化流程最關鍵的一步。
重點先看：Loco Translate 翻的是介面字串不是文章內容，翻譯檔一定要存「自訂」位置才不會被主題更新覆蓋；它本身免費，要付費的是它串接的 DeepL、Google 第三方 API。
Loco Translate 處理的是介面字串，與多語系外掛定位相反
Loco Translate 處理的是主題與外掛的系統字串，也就是那些寫死在程式碼裡、用來顯示介面的文字，像「加入購物車」、「閱讀更多」、「Submit」這類按鈕與標籤。它把這些字串抓出來讓你輸入中文，後台與前端的英文介面就會變成中文。它不會幫你把一篇文章翻成英文版加中文版各一份，那是另一種工具在做的事。
很多站長把 Loco Translate 跟 Polylang、TranslatePress、WPML 搞成同一件事，但這兩類外掛解決的根本是不同問題。Loco 翻的是介面那一層，讓一個單語言站的後台前端顯示中文；多語系外掛翻的是文章與頁面內容，讓英文訪客看英文文章、中文訪客看中文文章，兩套文章各自獨立存在。一個動的是顯示層，一個動的是內容層，方向相反，挑錯工具再努力也會卡在同一個地方。
從 gettext 機制理解：為什麼 WordPress 中文化會踩坑
要徹底搞懂 Loco Translate 能做什麼、不能做什麼，得從底層的 gettext 機制講起。WordPress 的整個在地化體系都建立在 gettext 之上，這是一套 PHP 生態沿用了二十多年的字串標記與翻譯交換標準。開發者在寫主題或外掛時，把要顯示的英文用專門的函式包起來，例如把字串放進 () 或 _e() 裡，等於告訴系統「這段文字需要被翻譯，請到語言檔裡找對應的翻譯」。翻譯檔有兩種格式：.po 是人看得懂、可編輯的純文字來源檔，.mo 則是由 .po 編譯出來的二元機器檔，PHP 在執行時讀的是這份 .mo。Loco Translate 的工作，就是讓你在後台直接編輯 .po、即時編譯成 .mo，省掉你手動跑編譯工具的步驟。
理解了這層機制，前面那些「為什麼抓不到字串」「為什麼更新會消失」的問題就有了清楚的答案。一個字串會出現在 Loco 編輯器裡，前提是開發者當初有用 gettext 函式把它標記出來；沒標記的字串等於不存在於翻譯系統，Loco 自然搜尋不到。同樣地，.mo 檔存放的路徑決定了它會不會被主題更新覆蓋，這就是儲存位置這件事的根本來源。把 gettext 機制記在心裡，後面所有操作都不會淪為照表操課卻不知道原因。
介面字串 vs 內容多語系：一張表看懂定位
| 比較項目 | Loco Translate（系統字串在地化） | Polylang / TranslatePress / WPML（內容多語系） |
|---|---|---|
| 翻譯對象 | 主題與外掛的介面字串（按鈕、標籤、提示） | 文章、頁面、自訂文章類型的內容 |
| 語言呈現 | 全站單一語言顯示 | 多種語言並存，訪客可切換 |
| 是否需要各語言一份內容 | 不需要 | 需要，每篇文章每種語言各寫一份 |
| 典型用途 | 國外主題中英夾雜、後台改全中文、接案交付 | 英文站加中文站、依訪客語言切換 |
| 定價 | 完全免費 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉] | 有免費版也有付費版（WPML 全付費） |
Loco Translate 在 WordPress.org 累計活躍安裝數超過一百萬次，評分 4.9 分接近滿分，屬於長期維護、社群信任度高的主流外掛 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]。數字會持續變動，以官網即時顯示為準，但量級夠大，不太需要擔心外掛本身是不是來路不明。如果你正在挑主題，可以先看看 Astra 主題免費版教學 或 WordPress 佈景主題推薦清單這類長期更新的主流佈景，再決定要不要花時間中文化。
那什麼時候你會真的需要它？舉幾個我遇過的場景。客戶買了一個國外形象主題，前端跑出「Our Services」「Latest News」這種英文標題，客戶要求全中文；或你接手一個電商站，結帳流程裡的按鈕、欄位標籤全是英文，訪客看不懂就放棄購物。這時 Loco Translate 幾分鐘就能解決。但如果你要的是「英文版跟中文版同時存在、訪客點一下切換」，那請直接去看 Polylang 多語系網站教學 或 TranslatePress 多語系內容翻譯，別在 Loco 上浪費時間，這兩類外掛的定位完全不同。
判斷你要不要裝 Loco Translate
判斷的起點只有一條：你要翻的是介面還是內容。如果是介面（主題外掛的按鈕、標籤、提示），而且只做單一語言站，那 Loco Translate 就是對的工具。如果只是要改三五個字，連外掛都不必裝，直接在主題設定或用子主題覆寫更快。
裝外掛有個原則值得守住：能用設定解決的事就不開外掛，能不碰翻譯檔就不碰，因為每一個外掛都是未來更新的維護成本。接著就可以從三個角度替自己做快速判斷。
- 先分清楚對象：介面字串交給 Loco 或主題設定，文章內容的多語系則屬於 WordPress 多語系外掛深度評比 裡 Polylang、TranslatePress、WPML 那一類，兩邊不該混用。
- 網站只顯示單一語言，用 Loco 就夠；要讓英文、中文版同時存在、訪客自由切換，那就不是 Loco 的戰場。
- 只有三五個字要改，去主題或外掛的設定選項調，或用子主題覆寫，比開翻譯檔省事；數十個以上散在各處，Loco Translate 集中處理才划算。
舉個反面例子。有人買了 Astra Pro 主題 或參考 Astra Pro 主題深度評測選定主題後，覺得「Read More」這個字很礙眼，於是裝了 Loco Translate 去翻它。其實 Astra 在「自訂」裡就有欄位可以直接把這段文字改成中文或「繼續閱讀」，連外掛都不用開。能用主題設定解決的，永遠比開翻譯檔穩定，因為設定值不會被更新覆蓋，也不會因為字串 key 改了而失效。
反過來說，如果你的網站裝了 WooCommerce，整個購物流程從「Add to cart」到結帳、訂單確認、Email 通知，幾十個系統字串散在各個檔案裡，用 Loco Translate 集中翻才是合理選擇。這時可以搭配 WooCommerce 購物網站架設 與 Astra 搭配 WooCommerce 購物網站 的流程一起看，中文化跟商店設定同步進行更省事。
Loco Translate 安裝與基本設定
Loco Translate 走的是標準外掛安裝流程。進 WordPress 後台「外掛 > 安裝外掛」，搜尋 Loco Translate，安裝後啟用，整件事就完成了。不需要任何付費、不需要註冊帳號，核心功能全部免費 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]。它也常出現在 WordPress 必裝外掛清單 裡，因為國外主題幾乎都會碰到中文化需求。
啟用後進入「Loco Translate > 主要資訊」，這個頁面會自動列出你網站目前啟用的所有主題與外掛。點進任何一個項目，就能看到它的翻譯狀態、已有的語言檔，以及開始翻譯的入口。如果你對後台介面還不熟，可以先過一次 WordPress 後台操作上手 或 WordPress 後台核心功能，回來會順很多。安裝過程不懂的話，WordPress 外掛安裝三種方法 講得更細，主題安裝則是搭配中文化時會一起用到的前置作業。
新手常問要不要付費買 Loco Translate，答案是不用。外掛完全免費，真正會花錢的是它串接的 DeepL、Google、Microsoft、Yandex 四家自動翻譯 API [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]，而且那筆錢是付給服務商、需要你自己申請憑證，與 Loco 本身無關。外掛本身的安全性也不用過度擔心，百萬級安裝量、長期維護、評分接近滿分，屬於 WordPress 生態裡相對可靠的工具。不過任何外掛都建議搭配 WordPress 資安防護外掛 與 WordPress 備份外掛評比 做底層防護，這是基本動作，主機端也會提供額外的備份層。
主題與外掛中文化的完整流程
以 Astra 主題為例，完整流程是五個步驟：選擇項目、新增繁體中文、選儲存位置、搜尋字串輸入翻譯、儲存。其中第三步「儲存位置選自訂」是整個流程成敗的關鍵，選錯位置等於把翻譯交給主題作者每次更新決定要不要留。
- 選擇要翻的項目：在「Loco Translate > 主要資訊」點進目標主題或外掛，例如 Astra。
- 新增繁體中文語言：點「新增語言」，從語言清單選擇「繁體中文（zh_TW）」。
- 選擇檔案儲存位置（最重要）：在建立檔案的對話框裡，儲存位置選「自訂」。這會把翻譯檔放到 Loco 專屬的 loco 目錄，跟主題原始檔分離，更新不會覆蓋它。
- 搜尋原文並輸入翻譯：進入編輯器，用搜尋框找到英文原文，點選後在下方輸入中文翻譯，按儲存。
- 重複處理其他字串：評論表單、按鈕、麵包屑、頁首標題，都可以用同樣方式逐一套用。
實際操作時，Astra 的評論區塊就是典型範例。原本會顯示「Leave a Reply」「Your email address will not be published」這類中英夾雜的字串，你在編輯器裡搜尋「Leave a Reply」、輸入「發佈留言」，儲存後重新整理前台，英文就會被替換成中文。整個主題的「Read More」「Search」「Previous」「Next」也能一次處理掉。如果你想對 Astra 做更系統性的設定，用 Astra 打造形象網站 有完整的搭配建議。
有一點要先講清楚：編輯器上方那個「自動翻譯」按鈕，預設是灰色的。要點亮它、真的送出翻譯請求，你必須先到「Loco Translate > 設定」裡輸入第三方 API 憑證，而且費用依照各服務商規則計算。沒設定憑證，這個按鈕就只是裝飾品。對大多數只翻一個主題的人來說，手動逐字翻反而比較快，因為系統字串通常不超過幾百條。
儲存位置決定翻譯會不會被更新覆蓋
「我明明翻好了，主題更新之後翻譯全不見」是 Loco Translate 使用者回報最多的問題。原因幾乎千篇一律：翻譯檔被存進了主題或外掛的內建語言資料夾，那個資料夾會在主題更新時被新版本整個覆蓋掉。
| 儲存位置 | 實際路徑 | 更新會不會被覆蓋 | 推薦度 |
|---|---|---|---|
| 作者內建 | 主題/外掛自己的 languages 資料夾 | 會，主題一更新就被新檔案覆蓋 | 不推薦 |
| 系統 | wp-content/languages/ | 通常不會，但與其他外掛共用以易混淆 | 可用 |
| 自訂 | wp-content/languages/loco/ | 不會，與主題原始檔完全分離 | 最推薦 |
「自訂」位置就是 Loco Translate 專門設計來防止覆蓋的機制，根據 Loco Translate 在 WordPress.org 外掛頁面的功能說明，這個 loco 專屬目錄是它區別於作者內建位置的核心設計 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]。檔案放在 loco 專屬目錄，主題更新時動不到它，更新完翻譯依然在。實務上無論如何都建議一律選自訂，這是唯一能讓你安心按更新的選項。如果你已經翻錯位置，補救方式是：先在 Loco 裡匯出翻譯檔，把儲存位置改回自訂，再把舊檔匯入或用 Poedit 補齊抓不到的字串 開啟舊檔搬移過去，整個搬移過程也能搭配小工具與側邊欄、選單設定一起檢查，確保前端顯示一致。
這裡要補充一個常被忽略的細節：Loco Translate 在你按下儲存的當下，會同時生成 .po 與 .mo 兩個檔案。你編輯的是 .po，網站實際讀取的是編譯後的 .mo。極少數狀況下，伺服器權限或檔案鎖定問題會讓 .mo 沒有跟著更新，這時症狀是「我在編輯器裡明明改了，前台卻還是舊翻譯」。排查方向是回到檔案總管頁面，確認目標語言的 .mo 檔修改時間跟你的最後一次儲存一致；不一致就手動重新儲存一次，或檢查該目錄的寫入權限。這條排查路線比反覆重灌外掛有效得多。
這裡要釐清一個常被誤解的狀況。有時候你更新主題後發現某些字串變回英文，但翻譯檔其實還在，只是主題大改版時把字串的 key 改了。例如原本的「Read More」變成「Continue Reading」，你的翻譯還在，但對應不到新的 key。這不是覆蓋，是字串本身改了，需要重新進編輯器補翻新的字串。判斷方式是進 Loco 看你的翻譯檔是否還在，在的話就是字串改版，不在的話才是被覆蓋。搭配 WordPress 搬家外掛推薦 或 WordPress 快取外掛推薦 做網站層級的備份與快取管理，也能降低這類風險。
抓不到的字串：Loco Translate 的限制與 Poedit 互補
Loco Translate 只能翻譯主題或外掛「有正確做好 gettext 標記」的字串。如果開發者把一段文字硬寫進程式碼、或那串文字是由 JavaScript 動態產生，Loco 根本抓不到它，你搜尋也搜不到。這不是 bug，是 gettext 機制的先天限制，跟你用的是 WordPress 頁面編輯教學 裡哪種編輯器也有關。
實務上最常見的三類「抓不到」字串：未做 gettext 標記的硬編碼文字、由 JavaScript 動態渲染的文字、頁面編輯器模組內的文字。第三種特別麻煩，因為 Elementor、Divi 這類編輯器的內容多半存在自己的資料結構裡，根本不在主題的語言檔範圍。像 Elementor 頁面編輯器教學、Elementor Pro 功能指南 或 Divi 主題終極指南 這類工具的文字，大多要在它們自己的編輯介面改，而不是動 Loco 的翻譯檔。
- 能在主題設定或外掛選項直接改的文字，就去設定改，不要動翻譯檔。
- 頁面編輯器（Elementor、Divi、Gutenberg 區塊編輯器外掛）內的文字，在各自的編輯介面修改，這跟文章內容編輯是兩條獨立的路線。
- 真的寫死在程式碼裡的字串，改用 Poedit 離線編輯語言檔，抓取範圍更廣。
- 大型外掛如 WooCommerce 字串極多，建議分區塊分次翻譯，一次全翻容易出錯。
這也是為什麼我會說 Loco Translate 跟 Poedit 不是二選一，而是互補。Loco 勝在後台直接操作、即時看到結果，適合處理主流字串；Poedit 勝在離線編輯、能處理更底層的語言檔，適合補齊 Loco 抓不到的那一成字串。兩個一起用，才有機會逼近所謂的系統字串全翻譯。如果你對兩者差異有興趣，前面提到的 Poedit 比較與操作有更詳細的說明，搭配 用 AI 挑選 WordPress 外掛 的方法，也能更快把整套中文化工具鏈挑齊。
要承認 Loco Translate 有它的邊界。有一種典型情境：網站用了冷門的聯絡表單外掛，前端的「Send Message」怎麼樣都翻不掉，原因是開發者把字串寫死在 JS 裡，這時繞過翻譯機制、直接改子主題的範本檔反而最快。所以遇到 Loco 抓不到的字串，不必一直跟它耗，換一條路（子主題、設定、或聯絡開發者）往往更快。
三種 WordPress 翻譯工具評分卡：Loco、Poedit、Codestyling 該選誰
講完 Loco 與 Poedit 的互補關係，把比較範圍再拉大一點。WordPress 生態裡能編輯翻譯檔的工具，主流的就這三套：Loco Translate（後台外掛）、Poedit（桌面離線軟體）、Codestyling Localization（早期流行的後台外掛）。它們解決的是同一件事，但操作位置、更新相容性、適合的場景差很多。接下來這張評分卡把六個維度攤開來比，每個維度給一個定位判斷。
| 評分維度 | Loco Translate | Poedit | Codestyling Localization |
|---|---|---|---|
| 操作位置 | WordPress 後台 | 本機電腦離線 | WordPress 後台 |
| 適合新手 | 最友善，所見即所得 | 需下載安裝與 FTP 傳檔 | 介面較舊，學習曲線中等 |
| 字串抓取範圍 | 主題外掛的 gettext 字串 | 可手動指定檔案，範圍最廣 | 主題外掛字串，與 Loco 接近 |
| 維護狀態 | 長期活躍更新 | 持續維護 | 更新較慢，新版 PHP 相容性風險較高 |
| 批次校稿 | 單筆逐條為主 | 支援模糊比對、術語庫 | 單筆逐條為主 |
| 團隊協作 | 單人後台操作 | 檔案可交付，適合多人工接續 | 單人後台操作 |
從這張卡可以歸納出一條選擇路線。絕大多數站長用 Loco Translate 就能把主題外掛的介面中文化做完，門檻低、即時看到結果。當你碰到 Loco 抓不到的底層字串，或需要對照多個版本的語言檔做校稿，Poedit 才派上用場。Codestyling Localization 在早期是熱門選項，但近年更新步調放慢，在新版 PHP 與新版 WordPress 上的相容性不如前兩者穩定，新站通常不會優先考慮它。三套工具的取捨，本質上是「後台即時操作、離線批次校稿、舊工具相容」三條路線的選擇，依你的工作流程挑一條主用、另一條補缺口，會比執著於單一工具更實際。
自動翻譯 API 的費用與值不值得開
Loco Translate 本身完全免費，要付費的是它串接的第三方翻譯 API。它支援 DeepL、Google、Microsoft、Yandex 四家服務 [來源：〈Loco Translate — WordPress.org 外掛頁面〉〈https://wordpress.org/plugins/loco-translate/〉〈2026〉]，這些服務照各自用量計費，費率與免費額度由各服務商決定，會不時調整，一切以其官網公告為準。
那到底要不要開自動翻譯？判斷標準很簡單：看字串量。系統字串通常只有幾百條，手動翻往往比設定 API 憑證、管理金鑰、回來逐條校稿更快更準。機器翻譯在系統字串上的表現很尷尬，因為很多字串是「Submit」「Cancel」「Search」這種短詞，機翻結果不一定比你自己想一個好的中文對照詞更貼切。
| 使用情境 | 建議做法 | 理由 |
|---|---|---|
| 只翻一個主題（數百條字串） | 手動翻譯 | 設定 API 的時間比直接翻還長 |
| 常翻多種語言、跨站重複 | 自動翻譯產草稿再校稿 | 量大時省下重複勞動 |
| 大型外掛如 WooCommerce | 分區塊手動翻 | 字串語境差異大，機翻易出錯 |
如果決定要用，正確流程是先用自動翻譯產生草稿，再逐條人工校稿，不要直接採用機翻結果上架。系統字串雖然短，但放錯一個按鈕文案可能影響轉換率，例如把「加入購物車」翻成「增加至推車」這類機翻味很重的詞，訪客會愣一下。有一個資安動作一定要做：API 金鑰用完可以在 Loco 設定裡移除，不要讓金鑰留在不用的網站上。如果你對網站加速跟資源優化也有需求，可以一併參考 WP Rocket 網站加速設定 或 WordPress 效能優化外掛，權限控管則分開處理。
費用這塊不適合寫死數字，因為 DeepL、Google、Microsoft 的計費方式與免費額度每年都在變。大方向是：四家都有免費額度，超過才計費，實際金額請到各服務商官網查詢當下方案。Loco Translate 只是幫你把 API 串好，帳單跟它無關。網站整體資源調度還可以搭配圖片壓縮與延遲載入一起優化，避免翻譯外掛與圖片外掛同時吃資源。
若要再細分四家服務在系統字串翻譯上的特性，可以從三個實務角度切。DeepL 對中文的語感在四家裡相對自然，短詞與常見介面用語的表現穩定，是不少中文化工作者的首選草稿來源；Google 翻譯覆蓋語種最廣、回應速度快，但短按鈕文案有時會出現偏書面的譯法，需要人工微調；Microsoft 翻譯在商務與介面詞彙上的表現平均，與 Google 同屬大廠級的穩定選項；Yandex 在歐洲語系表現較突出，中文相對是次要支援。把這段當成草稿階段的選擇參考就好，最終上架前一律以人工校稿為準，因為機器翻譯無法判斷你的品牌語氣與產業用語習慣。
常見問題與疑難排解
使用 Loco Translate 最常遇到的三類問題，可以對應到三個解法。翻譯沒生效，多半是快取或語言檔沒正確載入；更新後翻譯消失，是存錯位置；字串抓不到，是沒做 gettext 標記。把問題先歸類，再對症下藥，比漫無目的重灌外掛有效率。
- 翻譯沒顯示：先清網站快取與瀏覽器快取，確認 wp-content/languages 或 loco 目錄裡的.mo 檔有正確生成。
- 更新後翻譯不見：檢查儲存位置是不是被設成「作者內建」，改成「自訂」後重新匯入翻譯。
- 字串抓不到：改用 Poedit 離線編輯，或回到主題與外掛設定直接改那段文字。
- 語言檔權限問題：檢查 wp-content/languages 與 loco 目錄是否有寫入權限，缺權限會導致檔案存不進去。
- 大型外掛字串太多：像 WooCommerce 這類外掛建議分區塊分次翻譯，例如先翻結帳流程、再翻 Email 通知。
WooCommerce 的中文化值得一提。它本身有提供語言檔，但常常不完整或翻譯生硬，很多站長會用 Loco 補強。如果你正在架購物網站，可以照 WordPress 自架網站費用解析 先抓預算，再把商店設定跑起來，最後用 Loco 做介面中文化，三件事並行會更順。WooCommerce 金物流外掛設定 與 Flatsome 購物網站主題教學 也是同一邏輯，設定完順手把對應字串一起翻掉。
不該用 Loco Translate 的三種情境
一款工具再好用，也有它不適合上場的時候。把 Loco Translate 放進三種不該用的情境裡檢驗，能幫你避開事倍功半的決定。第一種是要做多語系網站，讓英文版、中文版同時存在、訪客自由切換，這屬於內容多語系，方向與 Loco 完全不同，硬用 Loco 只會卡在半路。第二種是只需改三五個字的零星調整，這時打開主題或外掛的設定選項直接改文字欄位，比開翻譯檔更快也更穩。第三種是想翻的是文章、頁面的正文內容，這些內容不存在於主題的語言檔，Loco 根本碰不到。
| 你的需求 | 該不該用 Loco | 更合適的選擇 |
|---|---|---|
| 多語系網站，訪客切換語言 | 不該用 | Polylang、TranslatePress、WPML |
| 只改三五個字的介面 | 不必用 | 主題或外掛的設定選項 |
| 翻文章、頁面的正文內容 | 碰不到 | 多語系外掛的內容翻譯介面 |
| 主題外掛介面字串大量中文化 | 該用 | Loco Translate（存自訂位置） |
| 主題設定沒提供欄位的字串 | 該用 | Loco Translate 搭配 Poedit 補缺口 |
這張決策表的核心訊息只有一句：先確認你要翻的是「介面字串」且「只做單一語言站」，再來開 Loco Translate。在這兩個條件成立之前，把它當成多語系方案或少量改字工具，都會走冤枉路。把需求判斷做在前面，比事後收拾半成品省下的時間多得多。
多語系專案與團隊協作的翻譯檔管理
當網站規模變大、牽涉到主題加上好幾個外掛，甚至多人分工校稿時，翻譯檔的管理就會從「打開來改一改」升級成一個需要紀律的小型專案。Loco Translate 本身是單人後台工具，沒有版本控管與多人協作的內建機制，所以協作要靠工作流程與檔案交接來補。實務上比較穩的做法是：指定一個人負責維護每個主題外掛的語言檔，其他人改完內容後回報需要翻的字串，由負責人統一進 Loco 編輯，避免多人同時改同一個檔造成覆蓋。
以一個用 WooCommerce 做中文化的中型購物站為例，這類網站常見的狀況是：主題本身加上結帳、Email 通知、金物流、會員、訂單這幾個外掛，可翻譯的系統字串散落在約 4 到 8 個檔案裡，總量依外掛組合大約落在約 800 到 2000 條之間。依典型表現幅度，把這批字串第一次跑完人工翻譯，含校稿大約需要約 6 到 12 小時的工時，若再串 DeepL 自動翻譯先產草稿，能省下約三到五成的初翻時間，但介面按鈕與結帳流程的關鍵字仍得逐條人工校稿，否則像「加入購物車」「前往結帳」這類詞被機翻成生硬用語，會直接拉低訪客的結帳完成率。這類站最常踩的失敗點，是第一次把全部字串翻完就直接上線，沒有依區塊分批驗收，結果某個金物流外掛更新後字串 key 改了，整段結帳流程又退回英文，得回頭補翻。所以實務上比較穩的決策角度，是先翻結帳與付款這條與轉換率直接相關的路徑，上線觀察約一兩週確認沒有漏字串，再回頭把 Email 通知、會員、訂單頁分次補齊；每次主題外掛更新後也固定回 Loco 檢查未翻項目，把維護當成例行動作，而不是一次翻完就放著。要特別說明的是，上述的字串數量與工時區間是這類站的典型幅度概估值，實際會依外掛數量與翻譯完整度而有明顯落差，不能當成精準報價依據。
- 建立術語對照表：把「購物車」「結帳」「會員」這類高頻詞的標準譯法寫下來，所有參與者共用同一份用語，避免同義不同詞造成介面不一致。
- 固定儲存位置：全站所有主題外掛一律存「自訂」位置，集中放在 loco 目錄，方便備份與搬站時一次帶走。
- 定期匯出備份：把
.po檔匯出存到網站外的位置，主題外掛大改版或搬家失敗時能快速還原。 - 主題外掛更新後檢查：每次更新後回 Loco 確認翻譯是否還在、有沒有新出現的未翻字串，把維護變成例行動作。
- 交接時交付檔案：結案或換人維護時，把整套語言檔與術語表一併交付，下一位接手的人不必從零開始。
這套流程的好處在於把翻譯從「想到才改」變成「有節奏地維護」。WordPress 生態規模夠大，根據 W3Techs 的調查，WordPress 在所有使用內容管理系統的網站中佔約 59.2%，相當於全網約 41.5% 的網站 [來源：〈W3Techs — Usage Statistics and Market Share of WordPress〉〈https://w3techs.com/technologies/details/cm-wordpress〉〈2026-06-29〉]。這個量級意味著主題外掛的更新頻率與中文化需求會持續存在，把翻譯檔當成長期資產來管理，比每次更新後才補救更省力。如果你同時經營購物網站，WooCommerce 在電商系統的佔比同樣很高，W3Techs 調查顯示它在所有電商系統裡佔約 48.6% [來源：〈W3Techs — Usage Statistics and Market Share of WooCommerce〉〈https://w3techs.com/technologies/details/cm-woocommerce〉〈2026-06-29〉]，字串數量龐大，更需要分區塊、分次的紀律來處理。
先搞懂要翻什麼，再決定工具
回到最初那個判斷：你要翻的是介面還是內容？介面字串、單一語言站，Loco Translate 是省事又免費的選擇，只要把翻譯檔存成「自訂」位置就不會被更新覆蓋。要翻整站多語系內容、讓訪客切換語言，那方向完全不同，請選 Polylang 或 TranslatePress。把這個問題想清楚，後面所有操作都不會走冤枉路，不論你是要架 WordPress 部落格架設指南 裡的內容站，還是 WordPress 部落格從主機到上線 的完整流程，介面中文化都只是其中一小環。
順帶一提，Loco Translate 處理的是顯示語言，不會直接影響你的 SEO 排名；但如果你做的是多語系站，多語系網站的 hreflang 語言標記、Rank Math SEO 外掛教學 跟 WordPress SEO 外掛推薦 才是真正該花時間研究的環節。想從架站到 SEO 一次看清楚，WordPress 架站與 SEO 全攻略 與 SEO 文章寫作技巧 是比較完整的入口，主機與字體細節則可延伸到 WordPress 本機託管字體 這類效能調校。
Loco Translate 常見問題 FAQ
Loco Translate 編輯器的自動翻譯按鈕為什麼是灰色的？
因為你還沒在「Loco Translate > 設定」裡輸入第三方 API 憑證。自動翻譯是選用功能，需要先申請 DeepL、Google、Microsoft 或 Yandex 的 API 金鑰並填入設定，按鈕才會亮起。沒有設定憑證時，手動逐字翻譯是完全免費的核心功能，多數只翻一個主題的人不需要開啟自動翻譯。
多個外掛都有同一個字串要翻，要重複翻嗎？
每個主題與外掛的翻譯檔是獨立的，所以同樣的英文出現在不同的主題或外掛裡，的確要分別翻。這是 gettext 機制的設計，好處是單一外掛更新不會牽動其他外掛的翻譯，代價是常用詞如 Submit、Search 會在多處重複輸入。實務上建議建立一份術語對照表，照表把高頻詞統一譯法，能加快重複字串的處理速度，也可參考 WordPress 多語系外掛深度評比 整理的常用譯法。
Loco Translate 可以同時管理多個語言嗎？
可以為同一個主題或外掛新增多種語言檔，但請記得 Loco 處理的始終是介面字串，全站只會以一種語言顯示給訪客。如果你要的是讓訪客在前台自由切換語言、每種語言各看一份內容，那就跨到內容多語系的範疇，要改用 Polylang、TranslatePress 這類工具，介面字串的部分再用 Loco 補強即可。
搬家或換主機後翻譯還會在嗎？
只要翻譯檔存在「自訂」位置，也就是 wp-content/languages/loco/ 目錄，搬家時把這個目錄連同網站一起搬過去，翻譯就會完整保留。建議搬家前先匯出整套語言檔做備份，搬家工具可搭配 WordPress 搬家外掛推薦，搬完後到 Loco 確認翻譯狀態與前台顯示是否一致。
Loco Translate 跟 Codestyling Localization 哪個好？
新站建議用 Loco Translate，它長期活躍維護、與新版 PHP 與 WordPress 相容性穩定、後台操作直覺。Codestyling Localization 是早期熱門的後台翻譯外掛，近年更新步調放慢，在新環境上的相容性風險較高，通常不會作為新站的首選。兩者定位接近，挑維護穩定的那一套更省後續麻煩。