近年來，有報導指出一些 WordPress 外掛在 PHP 國際化功能方面存在衝突和意外錯誤。
個別案例可能看起來像是“簡單的錯誤”，但它們反映了一個更大的結構性問題：在開發和運營文化中，國際化 (i18n) 仍然經常被視為“可選功能”。
本文並非旨在批評任何特定產品或供應商，而是為了探討為什麼國際化相關問題在網路應用程式中反覆出現，尤其是在 WordPress 生態系統中。
本文為innovaTopia獨家文章。
【社論】
現實情況是，不承擔國際化功能的環境已經成為「標準」。
WordPress 是一款歷史悠久的 CMS 軟體，為許多部落格和媒體網站提供支援。 WordPress 所使用的 PHP 語言附帶intl擴充（基於 ICU 函式庫），可以正確處理 Unicode 和語言環境。這為多語言支援提供了必要的功能，例如字串規範化、語言相關的比較以及日期和數字的表示。
然而，據說intl擴充預設未啟用的情況仍然並不少見，尤其是在美國的託管環境和開發環境中。因此，許多開發人員在編寫程式碼和進行測試時都假定 intl 不存在。
如果網站主要在英語國家使用，這種假設不太可能出現；但在每天使用多種語言和文字的環境中，設計缺陷會逐漸顯現，並導致許多問題。
「聚酯填充物」的副作用
在開發程式碼時，如果沒有假定intl可用，通常會使用用戶空間的“polyfill”，這看起來似乎是一個合理的選擇，但問題在於如何處理它們。
Unicode 規範化和語言處理的規範十分複雜且更新頻繁。多年來，ICU 一直盡可能精確、詳細地實現這些規範，但 polyfill 並非完美替代方案。此外，polyfill 的設計（它們無條件地在全域命名空間中定義）容易與其他程式碼和擴充功能發生衝突。
這不是「因為有替代實現所以沒有問題」的問題，而是用相同的名稱覆蓋語義不同的處理程序的危險問題。
為什麼 WordPress 會加劇這個問題
WordPress最大的優勢在於其外掛擴充性。然而，它的架構具有以下特點：
- 所有外掛程式共用同一個 PHP 執行環境。
- 弱依賴分離和去重機制
- 每個插件都包含自己的庫
- 使用全域命名空間是被有效允許的。
在這種架構下，如果國際化功能的假設存在差異，就會出現不穩定的故障，這些故障只能根據載入順序或環境差異來重現。很容易遇到這樣的情況：在開發人員的環境中沒有問題，但故障卻只發生在不同的區域或託管環境中。
一項故障案例研究表明
最近報導的某個 WordPress 外掛程式中 Unicode 規範化類別衝突問題也體現了這種結構：在啟用國際化擴展的環境中，會執行不必要的處理，這與其他外掛程式和標準功能衝突，從而導致錯誤。
Warning : Cannot declare class Normalizer, because the name is already in use in [...]/vendor/symfony/polyfill-intl-normalizer/Resources/stubs/Normalizer.php on line 20需要注意的是，這個問題並非只在罕見環境中發生的例外情況，而是在國際化正確啟用的環境中更容易出現。
雖然我們不會點名特定網站，但我們的調查顯示，許多網站由於此漏洞導致的錯誤，螢幕上會顯示 PHP 警告。在生產環境中，PHP 設定 `display_errors` 應該明確設定為 `Off`，使用者直接看到原始錯誤訊息是不好的，但似乎很多網站仍然沒有停用它。我們不會點名任何國家，但即使是官方政府機構也存在此設定。
為什麼這是一個全球性問題？
絕大多數網路使用者都不是以英語為母語的人，包含口音、組合字元、拼字變體和字形變體的語言環境不再是例外，而是常態。
然而，如果基礎設施和開發工具仍然基於「只要英語國家沒有問題就足夠了」的前提，那麼弱勢用戶群體將處於不利地位。這不僅是使用者體驗問題，還可能影響安全性和資料完整性。
未來所需的態度
我們需要的不是人身攻擊，而是對結構性假設的檢視。
- 將國際化擴充（例如 PHP
intl）視為預設環境，而不是例外。 - 不要無條件地定義全域命名空間或為其建立別名。
- Polyfill 是一種“最後手段”，並且會執行嚴格的存在性檢查。
- 從一開始就將多語言測驗融入你的開發過程中。
我認為國際化不是“以後可以添加的功能”，而是Web 應用程式的基本基礎設施。
[編者註]
在當今全球化的社會和經濟中，創新蓬勃發展，但邊緣地區和具有特定特徵的人群的需求往往被忽視。隨著焦點轉向全球南方和金磚國家，我認為，當今的資本主義若忽視「邊緣群體」將無法運作。我認為，在科技領域，發展也需要基於全球視野並強調可近性。
