講到 WordPress 在地化外掛，多數人第一個想到的是翻譯：把中文換成英文、加個語言切換器，好像就完成了。但翻譯只是在地化的其中一塊。真正讓海外讀者覺得「這個網站是為我做的」，往往是那些不起眼的細節——文章日期顯示成他習慣的格式、結帳頁的地址欄位順序符合他的國家、貨幣符號落在數字正確的一側。

貨幣與多語系的教學網路上已經很多，這篇刻意把焦點放在最常被略過、卻最容易讓使用者誤讀的兩個面向：日期格式與地址格式。我們會拆解 WordPress 在地化外掛在這兩件事上實際做了什麼、內建機制與外掛各自負責哪一段，並把幾款常見外掛的支援程度攤開來比較，最後給台灣站台一份能直接套用的設定方向。

在地化外掛處理哪些翻譯以外的事

WordPress 在地化外掛的工作，是把網站「翻譯成在地語言」之外，再「調整成在地習慣」。前者是文字轉換，後者是格式與呈現的調整，兩者經常被混為一談，但實作層面差很多。

國際化（i18n）與在地化（l10n）是一組常被搞混的詞。國際化是開發者在寫主題或外掛時，預先把字串、日期、數字包成可替換的函式，讓程式「具備」被在地化的能力；在地化則是針對某個特定地區，把這些可替換的部分填上當地的語言與格式。一個主題就算翻譯做得再好，如果開發時沒有用對國際化函式，日期照樣會以伺服器的預設格式硬輸出。

翻譯以外，在地化外掛實際會碰到的面向包括這幾類：

• 日期與時間格式：同一個發布日期，在不同地區要顯示成不同排列順序與月份名稱
• 數字與貨幣格式：千分位用逗號還是句點、貨幣符號在數字前還是後
• 地址欄位：欄位的順序、是否需要郵遞區號、州或縣市的填法
• 文字方向：阿拉伯文、希伯來文等由右至左（RTL）語言的版面鏡像
• 圖片與圖示：方向性圖示（如指向右的箭頭）在 RTL 語境下可能要鏡像

這幾項裡，日期與地址是最容易被使用者一眼看出「沒做好」的兩個。數字格式偶爾誤讀還能猜，但日期排錯會直接讓人會錯意，地址欄位順序不對則會卡住結帳流程。

日期格式在不同地區為什麼會搞混讀者

日期之所以難搞，是因為光是「年月日」三個欄位的排列順序，各地就沒有共識。最經典的衝突是純數字日期：02/12/2026 在美國讀作二月十二日（月／日／年），在英國與多數歐洲國家讀作十二月二日（日／月／年），在台灣與日本則習慣由大到小寫成年／月／日。同一串數字，三種讀法。

這不只是順序問題，還牽涉幾個容易被忽略的細節：

• 月份要不要用名稱：英文常寫成 June 14, 2026，中文則習慣 2026 年 6 月 14 日，名稱本身要跟著語言翻譯
• 星期幾的譯名：Thursday 在法文站要顯示 jeudi，在中文站要顯示「星期四」
• 前導零與分隔符：2026-06-14 與 2026/6/14 是不同地區的偏好
• 時區：發布時間如果直接吃伺服器時區，跨國讀者看到的時間會整批偏掉

把這些攤開後就能理解，為什麼日期在地化不能只靠翻譯外掛把月份名稱換掉——順序、分隔符、時區是另一套邏輯，得交給 WordPress 的日期函式處理。

WordPress 日期在地化的內建機制與外掛分工

要弄懂日期在地化，得先知道 WordPress 核心其實已經內建了大半功能，外掛多半是在這個基礎上做整合，而不是另起爐灶。

WordPress 用來在地化日期的核心函式是 wp_date()。它的行為類似 PHP 原生的 date()，但多做兩件事：套用站台設定裡的時區（而不是伺服器時區），以及把月份與星期名稱翻譯成目前語系的版本。在法文站呼叫 wp_date( 'l' ) 會回傳 jeudi 而不是 Thursday，這就是它跟原生函式最大的差別。

在 wp_date() 出現之前，大家用的是 date_i18n()。自 WordPress 5.3 起，官方建議新程式改用 wp_date()，而 date_i18n() 如今實質上是 wp_date() 的包裝層，仍可運作但屬於舊寫法。兩者第二、第三個參數的時區處理方式不同，是開發者最常踩雷的地方：date_i18n() 吃的是「Unix 時間戳加上時區偏移秒數」的合值，wp_date() 的時區處理則乾淨許多。

這裡有個常被誤解的點：上面這兩個函式只翻譯「月份與星期的名稱」，它們不會自動把你指定的格式字串改成在地慣用的排列順序。換句話說，如果你在程式裡寫死了 'F j, Y'（美式的「月 日， 年」），就算在中文站，輸出也只是把月份名稱換成中文，順序仍是美式。要讓「順序」也在地化，常見做法是改讀站台設定裡的 date_format 選項，例如 wp_date( get_option( 'date_format' ), $date )，讓格式跟著後台設定走。

由此可以畫出內建機制與外掛的分工：

• WordPress 核心負責：發布日期、留言日期等「系統產生」的日期，透過 wp_date() 自動套用語系與時區
• 站台設定負責：後台「設定」→「一般」裡的日期格式與時間格式，決定預設的排列順序
• 在地化外掛負責：當一個頁面同時存在多個語言版本時，讓不同語言版本套用各自合適的日期格式；以及處理「手動寫在內文裡」的日期

最後這點要特別留意。像 TranslatePress 這類外掛，對於「來自 WordPress 的日期」（例如文章發布日）會自動透過 wp_date() 調整格式；但如果你是在編輯器裡手動打了一個日期，外掛無法知道那是日期，得在翻譯該段內容時自己把格式一併在地化。系統日期交給核心與外掛，手寫日期靠人工，這條界線要先分清楚。

地址格式在地化外掛要解決的欄位順序問題

地址在地化的核心難題，是各國的地址結構根本不一樣——欄位數量、順序、必填與否都不同，硬套同一張表單會讓使用者填得很彆扭。

最直觀的差異是書寫方向。台灣與日本的地址是由大到小：先縣市、再區、再路名門牌；英美則由小到大：先門牌街道、再城市、再州、最後郵遞區號。一張固定順序的表單，對其中一方一定是逆著直覺填。

其他常見的結構差異還包括：

• 郵遞區號的位置與必要性：美國的 ZIP code 是必填且格式固定，部分國家則沒有郵遞區號或非必填
• 行政區層級的名稱：美國叫 State、英國習慣用 County、台灣是縣市，欄位標籤該跟著國家換
• 門牌與樓層的拆分：有些地區習慣把街道、號、樓拆成多欄，有些則合在一個欄位

在純內容型的 WordPress 網站上，地址多半只是顯示用的文字（例如聯絡頁），這時用翻譯外掛把標籤文字換掉就夠了。真正需要「動態地址格式」的，是 WooCommerce 這類電商情境：結帳頁要根據使用者選的國家，即時調整地址欄位的順序、顯示或隱藏州別欄位、切換郵遞區號的必填規則。

值得釐清的是，這部分的重活其實是 WooCommerce 核心在做。WooCommerce 內建了各國的地址格式規則，會依結帳時選定的國家自動重排欄位；多語系外掛在這裡的角色，是把這些欄位的「標籤文字」翻譯成對應語言，並確保語言切換時欄位邏輯不被打亂。換句話說，地址的「結構在地化」靠的是電商核心或專門的結帳欄位外掛，「文字在地化」才是多語系外掛的守備範圍。如果你的站台會收款，這層分工尤其要先想清楚，但本文不展開金流設定，只點出格式責任的歸屬。

常見在地化外掛在日期與地址上的支援比較

把市面上幾款常被提到的在地化相關外掛攤開比較，會發現它們的定位差異很大：有的主打全站多語系翻譯，有的單純補日期或時間的顯示，沒有一款是「什麼都包」的萬用解。

下表整理常見外掛在日期與地址這兩件事上的實際角色，幫助你依需求對位選擇：

從表格可以看出一個共同點：這些外掛在地址上幾乎都只負責「翻譯標籤文字」，沒有一款會去重排地址欄位的順序——因為那是 WooCommerce 核心或專門結帳外掛的工作。日期方面則差異在於整合深淺，多語系大廠（WPML、Polylang）會跟著語言版本切換日期語言，但「排列順序」普遍還是吃站台後台的日期格式設定，而不是逐語言獨立。

所以選型時的判斷邏輯是：如果你只需要文章日期顯示正確，調好後台日期格式加上任一款支援 wp_date() 的多語系外掛就夠；如果你跑的是跨國電商，地址欄位的動態重排得靠 WooCommerce 本身，多語系外掛只負責把那些欄位標籤翻好。

台灣站台設定日期與地址在地化的實務建議

對以台灣讀者為主、偶爾兼顧海外的站台來說，日期與地址在地化不必一開始就上重型多語系外掛，先把內建設定調對，往往就解決了八成問題。

日期部分，建議的執行順序是這樣：

• 第一、先設後台日期格式：到「設定」→「一般」，把日期格式設成符合台灣習慣的 Y 年 n 月 j 日 或 Y-m-d，這會成為全站系統日期的預設排列
• 第二、確認時區設定正確：時區選「台北」而非單純的 UTC 偏移，跨日邊界的發布時間才不會錯位
• 第三、檢查主題有沒有寫死格式：如果主題的日期顯示沒跟著後台設定走，多半是樣板裡用了寫死的格式字串，需要改成讀取 get_option( 'date_format' )
• 第四、手寫日期靠人工：內文裡手打的日期，要記得依目標語言調整寫法，外掛不會自動處理

地址部分，先看站台性質再決定要不要動外掛：

• 純展示型網站（聯絡頁、關於頁的地址）：直接用台灣由大到小的書寫方式填寫文字即可，要做英文版時用多語系外掛翻譯標籤與內容
• WooCommerce 電商站：地址欄位的結構交給 WooCommerce 核心處理，它會依買家選的國家自動重排欄位；你要做的是確認在地化語系檔有載入，讓欄位標籤顯示成中文
• 避免自己硬刻地址表單：手刻表單很容易漏掉各國郵遞區號與州別的差異，能用電商核心或成熟外掛就別自己造

把這條路徑走完，日期不會再讓海外讀者誤讀，地址也不會卡住跨國買家的結帳。在地化外掛該扮演的是「補上多語系與標籤翻譯」的角色，而不是替你決定每一個格式細節——格式的地基，仍在 WordPress 的核心函式與後台設定裡。先把地基設對，外掛才有東西可以接手。