WordPress 6.5 I18N 新邏輯與自訂翻譯的注意事項
WordPress 6.5 正式發佈後對非英語系國家使用者最大的改善就是，使用本地化語言版本載入網站頁面再也不會像以前那樣緩慢了！
根據 WordPress 開發者的分析研究，一直以來，使用本地化語言的 WordPress 網站在頁面載入所花費的時間與使用預設語言 (en_US) 的 WordPress 網站相比之下，有可能需要多花費超過 40% 的時間 (根據所使用佈景主題、外掛而有所不同)。
WordPress 6.5 I18N 新邏輯
在這篇分析文章中，提到了當時提出的幾種改善效能的候選方案，後來也成為 WordPress 6.5 I18N 處理翻譯檔案的新邏輯。
我們從分析數據可以看出，使用新方法的本地化版本確實能夠大幅改善頁面載入速度。
效能比較
分析文章中對載入的「頁面」選擇了三種情景：
- 區塊化佈景主題的首頁 – Twenty Twenty-Three Block Theme
- 傳統佈景主題的首頁 – Twenty Twenty-One Classic Theme
- Admin 管理後台頁面
測試的語言版本為：
- 本地化 – de_DE
- 非本地化 – en_US
WordPress 核心版本則為 6.3 RC 版，測試次數為 30 次並以載入時間的中位數為比較基準。
我們摘錄其中具代表性的頁面載入數據讓大家參考並感受新方法能夠帶來的效益，如果想看完整比較數據，可以直接參考上述的分析文章連結或是原始的基準測試。
區塊化佈景主題首頁
| 語系 | 方法 | 物件快取 | 使用記憶體 | 總載入時間 |
|---|---|---|---|---|
| en_US | 15.60 MB | 133.58 ms | ||
| en_US | V | 15.67 MB | 121.53 ms | |
| de_DE | 29.14 MB | 181.95 ms | ||
| de_DE | V | 29.01 MB | 167.67 ms | |
| de_DE | Ginger MO (PHP) | 16.98 MB | 138.14 ms | |
| de_DE | Ginger MO (PHP) | V | 16.85 MB | 127.97 ms |
傳統佈景主題首頁
| 語系 | 方法 | 物件快取 | 使用記憶體 | 總載入時間 |
|---|---|---|---|---|
| en_US | 15.35 MB | 120.79 ms | ||
| en_US | V | 15.19 MB | 107.26 ms | |
| de_DE | 28.79 MB | 172.10 ms | ||
| de_DE | V | 28.59 MB | 154.30 ms | |
| de_DE | Ginger MO (PHP) | 16.56 MB | 124.73 ms | |
| de_DE | Ginger MO (PHP) | V | 16.37 MB | 112.94 ms |
管理後台頁面
| 語系 | 方法 | 物件快取 | 使用記憶體 | 總載入時間 |
|---|---|---|---|---|
| en_US | 15.42 MB | 139.83 ms | ||
| en_US | V | 15.66 MB | 112.69 ms | |
| de_DE | 31.92 MB | 187.76 ms | ||
| de_DE | V | 31.84 MB | 164.26 ms | |
| de_DE | Ginger MO (PHP) | 17.09 MB | 139.66 ms | |
| de_DE | Ginger MO (PHP) | V | 17.01 MB | 118.52 ms |
從分析數據可以明顯地看出：
- 使用物件快取的好處。
- 使用新方法處理本地化翻譯檔後不再需要那麼大量的記憶體與載入時間，頁面載入時間都更加貼近原始的英文語系 WordPress 網站了。
這應該會是讓 WordPress 在非英語系國家提升普及率的一大改進。
I18N 新邏輯
而這個方法也被整合到 WordPress 6.5 成為 I18N 處理本地化翻譯檔的新邏輯了。
大家如果對升級到 6.5 版還駐足不前的話，可以先使用 Performant Translations 外掛就能享受到新邏輯的效能提升效益了。
在新的邏輯下，系統會將本地化的 MO 翻譯檔轉為 PHP 檔，並且在讀取翻譯檔的時候直接從 PHP 檔讀取，藉此提升處理效率、減少記憶體使用。
並且支援同時載入多個語系，使得轉換語系時的速度能再提升。
此外，新邏輯也支援 PHP 檔中包含的翻譯，避免使用二進位檔案格式並利用 OPCache (如果有) 以提升載入速度。
簡單來說，新的翻譯檔案格式 *.l10n.php 會取代 *.mo 作為系統使用的主要本地化翻譯來源。系統會在 WordPress、佈景主題、外掛進行版本更新、語言包更新時，下載使用 translate.wordpress.org 翻譯平台的語言包，將其 (*.po *.mo) 轉換為 *.l10n.php。
但因為這個新效能改善方法還在逐步進行中，網站中佈景主題、外掛如果只有 *.mo 檔，會直接使用 MO 檔案格式載入翻譯，反之依然。
隨著新版本推出，也提供了一些新功能讓大家可以廣泛運用，因為與下個章節要討論的「自訂翻譯」主題遭遇到的問題有關，這部分我們在後面一併說明。
自訂翻譯的注意事項
大約是 WordPress 6.5 發佈不到兩周，因為正在翻譯一個 LMS 外掛而遭遇到下述問題。
起因在於，有不少佈景主題、外掛廠商在建議使用者如果有自行翻譯的需求時 (因為社群所提供的翻譯品質不一定適合商務需求使用)，除了利用 Loco Translate 外掛之外，如果遇有 Loco 外掛偵測不到的字串時可以使用 POEDIT 軟體翻譯從 translate.wordpress.org 下載的 PO 檔，並將翻譯完成的 MO 檔放到以下路徑：
- /wp-content/languages/plugins/
而這在與 WordPress 開發者溝通之後，已確認是錯誤的操作了。
當自訂翻譯遇上 I18N 新邏輯
在網站 WordPress 升級到 6.5 之前，這個目錄在舊有機制下鮮少被更動，所以在翻譯、測試時每次完成一小段翻譯，上傳到這個目錄下就能看到 WordPress 網站前端、後台相關的文字立即變為翻譯後的文字。
升級到 6.5 之後，則是發現有些字串突然變成沒翻譯或是其他翻譯內容，仔細檢查後才發現這是 WordPress 6.5 I18N 的新邏輯，目錄下多了一個檔案 *.I10n.php，內容正是與 translate.wordpress.org 外掛目錄下的翻譯一致的。*.po 與 *.mo 同樣是被社群版本下載覆蓋了。
原因則是這段時間 WordPress 6.5 語言包有更新，所以如上述所說的邏輯一致，重新產生了翻譯檔將自行上傳的檔案都覆蓋掉了。
為了找到解決方案，我們嘗試了以下幾種方法。
嘗試一：自行產生 PHP 翻譯檔
為了能更好的理解新邏輯的運作機制，首先嘗試將自行翻譯好的 MO 檔上傳到目錄下，接著執行因應 I18N 新邏輯所提供的新 WP CLI 命令。
步驟如下：
- 使用 Application User SSH 登入主機
- 進到 /wp-content/languages/plugins/ 目錄下
- 執行命令 “wp cli version” 確認 WP-CLI 版本是不是 2.10.0
- 執行命令 “wp help i18n” 可查看 i18n 命令的說明文件，或是直接訪問官方網站
- 執行命令 “wp i18n make-php .”，對目錄下所有 PO 檔產生 PHP 檔
- 如果只想產生特定 PO 檔的 PHP 翻譯檔，執行命令 “wp i18n make-php xxx-zh_TW.po”，就會產生 xxx-zh_TW.l10n.php 檔了
對目錄下所有 PO 檔產生 PHP 檔：
wp i18n make-php .對目錄下特定 PO 檔產生 PHP 檔：
wp i18n make-php xxx-zh_TW.po測試結果
這個方法因為自訂翻譯檔案都還是放在 /wp-content/languages/plugins/ 目錄下，所以一段時間都有可能會被 translate.wordpress.org 外掛目錄下的翻譯覆蓋掉。
也是上述所說的錯誤方式。
此外，也發現了在目前的 WP CLI 版本下 (2.10.0) 手工執行命令將 PO 產生 PHP 檔的已知問題。
以往的邏輯，只要上傳翻譯好的 MO 檔，因為 MO 檔只包含「已」翻譯的字串，所以網站上只有已翻譯的部分會被替換成翻譯後的語言。
如果使用 I18N 將 PO 產生 PHP 檔，因為 PO 檔一般會是翻譯字串的「全量」，如果當中包含了「未」翻譯的字串，這些未翻譯的部分在網站上就會變成空的、不見了，連預留位置 (placeholder) 也沒有。
目前開發者提供的因應措施為：
- 更新 i18n-command package，或
- 更新到 WP-CLI nightly 版本
即可解決此問題。
大家未來如果有使用到這個功能時可以觀察一下，或許可以等到相關套件功能修復後再使用。
嘗試二：改變讀取翻譯檔的格式與路徑
既然將翻譯檔案放在 /wp-content/languages/plugins/ 目錄是錯誤的方式，按照開發者與阿力獅的建議我們就來自定讀取翻譯檔的路徑吧，因為自訂路徑的優先級會是最高的。
並且為了在翻譯過程中能快速檢查翻譯結果，指定系統讀取 MO 檔而非 PHP 檔，如此一來就不需要執行 WP CLI 命令進行轉檔。
指定系統讀取 MO 檔
因為初引進這個新邏輯，所以還是保留了方法讓大家可以指定系統在載入翻譯檔時，將預設檔案格式改為使用 MO 檔。
add_filter(
'translation_file_format',
static function () {
return 'mo';
}
);自訂系統讀取翻譯檔的路徑
為了改變系統讀取翻譯檔的路徑，除了原先就有的 load_testdomain_mofile filter 可以指定自訂 MO 檔的載入路徑之外，現在也提供了新的 filter load_translation_file 可以指定自訂 MO 檔或 PHP 檔的載入路徑了。
以下參考了 load_testdomain_mofile 說明文件中的範例，並改為使用 load_translation_file filter 以增加未來的泛用性。
add_filter( 'load_translation_file', 'my_custom_translation_file', 10, 2 );
function my_custom_translation_file( $mofile, $domain ) {
if ( 'plugin_name' === $domain ) {
$mofile = WP_CONTENT_DIR . '/my-languages/plugin_name-' . get_locale() . '.mo';
}
return $mofile;
}測試結果
使用程式碼片段外掛 WPCodeBox 加入了以上兩段 PHP 程式碼之後，發現系統還是無法如預期的從 /wp-content/my-languages/ 目錄中讀取自行上傳的翻譯檔。
系統依然會以 /wp-content/languages/plugins/ 下找的到的 MO/PHP 檔為優先，找不到的字串則會從 /wp-content/my-languages/ 下的 MO 檔中補齊。
嘗試三：將嘗試二中的程式碼放到 MU Plugins 中執行
I18N 的開發者認為嘗試二中無法改變翻譯檔格式與讀取路徑的原因應該是因為外掛載入翻譯檔的速度 & 優先級太快、太高了。
建議對這個問題的因應措施可以將這些程式碼寫為 MU (must-use) 外掛。
步驟並不複雜，就是將上述 PHP 程式碼寫在一個 PHP 檔中，並將這個 PHP 檔放到 /wp-content/mu-plugins/ 目錄下。
於是，我就寫了人生中第一個 MU 外掛了！
測試結果
將程式碼放到 MU 外掛中執行後，如預期的系統在讀取翻譯檔時直接從自訂目錄中讀取了 MO 檔。
我們也就此找到了解決方案。
結語
WordPress 6.5 帶來的 I18N 新邏輯值得大家期待，但也同時提醒了許多使用「自訂翻譯」的站長們，該是時候檢查目前所使用的載入自訂翻譯檔方式是不是會受到新版本升級的影響。
建議大家，如果手邊有正在進行中的外掛翻譯工作，可以參考上述方式處理，測試過程中指定系統讀取 MO 格式，可以免去手工執行 WP CLI 命令進行轉檔的重複工作。
一旦翻譯完成，則只需「自訂系統讀取翻譯檔的路徑」的程式碼，將程式碼中讀取的檔案格式改為 .l10n.php，並執行 WP CLI 命令將上傳的 MO 檔轉為 PHP 檔。
這樣一來，不僅可以使用「自訂翻譯」，更能利用到 I18N 新邏輯帶來的頁面載入效能提升。
當然，大家如果對升級到 6.5 版還駐足不前的話，可以先使用 Performant Translations 外掛就能享受到新邏輯的效能提升效益了。
以上內容總結於我在社團的分享與討論紀錄，也歡迎大家加入社團才能夠在第一時間獲得最新資訊！
本文精選圖片部分材料取自 StorySet 網站。
