近年、WordPressプラグインの一部で、PHPの国際化機能を巡る衝突や予期せぬエラーが報告されている。
個々の事例だけを見れば「単なるバグ」に見えるかもしれない。しかし、これらはより大きな構造的問題──国際化（internationalization = i18n）が依然として“任意機能”として扱われがちな開発・運用文化──を反映している。
この記事では、特定の製品やベンダーを批判することを目的とせず、Webアプリケーション、特にWordPressエコシステムにおいて、なぜ国際化関連の問題が繰り返し表面化するのかを考察する。
これはinnovaTopia限定の独自記事です。
【編集部解説】
国際化機能を前提としない環境が「標準」になっている現実
WordPressは、数多くのブログやメディアを動かしている歴史のあるCMSソフトウェアです。WordPressを駆動しているPHP言語には、Unicodeやロケール処理を正しく扱うための intl 拡張（「ICU」ライブラリに基づく）が存在します。これは文字列の正規化、言語依存の比較、日付・数値の表現など、多言語対応に不可欠な機能を提供するものです。
一方で、特に米国のホスティング環境や開発用セットアップでは、この intl 拡張がデフォルトで有効化されていないケースが今なお珍しくないと言われています。結果として、多くの開発者は「intlが存在しない前提」でコードを書き、動作確認を行ってしまうのです。
この前提は、英語圏中心の利用では表面化しにくいものです。しかし、多言語・多文字種を日常的に扱う環境では、設計上の歪みが徐々に顕在化し、たくさんの問題を生んでしまいます。
「とりあえずポリフィル」がもたらす副作用
intl が使えない前提で開発されたコードでは、しばしばユーザーランド実装の「ポリフィル」(polyfill) が用いられます。これ自体は合理的な選択に見えますが、問題はその扱い方にあるのです。
Unicode正規化や言語処理は、仕様が複雑で、更新も頻繁です。ICUは長年にわたってこれらをなるべく正確に細かく実装してきましたが、ポリフィルはその完全な代替にはなりません。さらに、ポリフィルをグローバル名前空間に無条件で定義する設計は、他のコードや拡張機能との衝突を引き起こしやすいものです。
これは「代替実装があるから問題ない」という話ではなく、意味論的に異なる処理を、同じ名前で上書きしてしまう危険性の問題なのです。
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 Warning を画面に出力していたサイトが調査したところ無数にありました。実運用環境では PHP 設定の display_errors を明示的に Off にするべきであり、ユーザに生のエラーが表示されるのは良くないのですが、依然として無効にしていないサイトが多いと思われます。国名は挙げませんが、政府機関の公式でもこれになっているところがありました。
なぜこれは世界的な問題なのか
Webの利用者の大多数は、英語母語話者ではありません。アクセント記号、合成文字、表記ゆれ、異体字などを含む言語環境は、もはや特殊ではなく標準です。
それにもかかわらず、インフラや開発ツールの前提が「英語圏で問題がなければ十分」という状態に留まっていると、周縁化された地域・属性の利用者ほど不利益を被ります。これはユーザー体験の問題であると同時に、セキュリティやデータ整合性にも影響を及ぼしうるものです。
今後に向けて求められる姿勢
必要なのは、属人的な批判ではなく、構造的な前提の見直しではないでしょうか。
- 国際化拡張（PHP
intlなど）を例外ではなく基準環境として扱う - グローバル名前空間への定義やエイリアスを無条件に行わない
- ポリフィルは「最後の手段」として、存在チェックを厳密に行う
- 多言語環境を想定したテストを初期段階から組み込む
国際化対応は「後から足す機能」ではなく、Webアプリケーションの基礎インフラだと思います。
【編集部後記】
イノベーションが起きていく現代の国際社会・経済において、周縁化 (marginalize) された地域や属性の人たちのニーズは無視されていく傾向にあります。 今日の資本主義は、グローバルサウス・BRICS などが着目されていくなか、「周縁」を無視しては成り立たないのではないかと思います。テックにおいても、グローバルな視点・アクセシビリティ重視に立った開発が求められるのではないでしょうか。
