動的コンテンツは、WordPress の翻訳が難しくなる場所です

通常の投稿翻訳がエディターの境界で止まる理由

WordPress 翻訳で最も簡単なのは投稿コンテンツ内のテキストです。なぜなら、明確な元データ、安定した言語割り当て、そしてエディター内の予測可能な場所があるからです。翻訳ツールは通常、そのコンテンツを読み取り、言語ごとの版を作成し、版同士の関係を維持できます。

動的コンテンツはこの仕組みを崩します。テキストがウィジェット、ショートコード、ブロックのレンダーコールバック、プラグインテンプレート、または AJAX リクエストによって後から組み立てられる場合、それは投稿内の単一の編集可能なフィールドとして存在しないことがあります。つまり、翻訳レイヤーは通常のコンテンツで使うのと同じ保存・対応付けのルールに頼れません。

実務上の結果として、多言語の挙動は、その動的な表示要素が翻訳可能な入力を公開しているか、言語を意識したデータを保存しているか、あるいはリクエスト時に言語ごとに異なる形でレンダリングできるかに依存します。そうでない場合、メインの投稿が正しくローカライズされていても、翻訳済みページに未翻訳の断片が残ることがあります。

どの WordPress 表示要素が明示的な互換対応を必要としやすいか

ウィジェットやサイドバーには、メインの投稿エディターの外で設定されるテキストが含まれることが多いため、翻訳は投稿コンテンツだけでなくテーマやプラグインの設定まで踏み込む必要があります。

ショートコードは特に難しいことがあります。見えている出力が、編集可能なページテキストとして表現されない属性、保存済みオプション、またはプラグインデータから生成されるためです。

ブロックには静的なものと動的なものがあります。静的ブロックはコンテンツを投稿内に保存しますが、動的ブロックはサーバー側ロジックからレンダリングされることがあり、その場合、表示テキストは実行時に生成されるため、別途翻訳対応が必要になることがあります。

プラグインが生成する出力、通知、アカウント領域、AJAX で読み込まれる断片も、ページ本文だけではなくプラグイン所有のデータやリクエスト固有の状態から組み立てられるため、よくある失敗箇所です。

これらの表示要素は、すべての構成で自動的に未翻訳になるわけではありませんが、通常の翻訳経路の外に置かれがちで、そのため言語間で正しく動作させるには明示的な互換対応が必要になります。

中核となる技術課題: 翻訳には、見えるテキストだけでなく安定したデータが必要

多言語システムが翻訳できるのは、識別でき、言語に関連付けられるものだけです。通常、それには安定した元データ、予測可能なオブジェクト関係、そしてページを壊さずに別の言語で同じ出力を再現する方法が必要です。

動的コンテンツは、投稿メタ、カスタムフィールド、プラグイン所有のレコード、または実行時条件に依存することがよくあります。これらの入力が言語ごとの対応先にマッピングされていないと、翻訳済みページには誤ったテキスト、誤ったリンク先オブジェクト、または複数言語の混在が表示されることがあります。

だからこそ、コンテンツの関係性が重要です。翻訳済みページは単なるテキスト置換の問題ではなく、ルーティングと関連付けの問題でもあります。訪問者がサイトのローカライズ版を見ているときに、どの翻訳済み投稿、ターム、テンプレート、関連オブジェクトを使うべきかをシステムが把握していなければなりません。

この対応付けが不完全だと、失敗の形は完全な失敗ではなく部分的な翻訳になることが多いです。ページは読み込まれるものの、一部の断片が元の言語のまま残ったり、誤った言語版を指したり、ラベルやリンクが不整合になったりします。

実行時レンダリングが翻訳ワークフローを変える

動的レンダリングでは、最終的な HTML は投稿保存時点では完全には決まりません。代わりに、ページはテンプレート、ブロックのレンダーロジック、プラグイン設定、またはリクエストコンテキストから後で組み立てられることがあります。

これにより、翻訳ワークフローは 2 つの点で変わります。第 1 に、翻訳システムはレンダリング済み出力ではなく、基になるデータソースを翻訳する必要があるかもしれません。第 2 に、正しい言語版が実行時に組み立てられるよう、各リクエストごとに出力を再評価する必要があるかもしれません。

これは同じテンプレートを複数言語で使う場合に便利ですが、依存関係のリスクも生みます。動的コンポーネントが共有オプション、グローバル設定、または言語非依存のレコードを参照していると、そのコンポーネントが明示的に言語対応になっていない限り、すべての言語に同じテキストが引き継がれてしまいます。

WordPress の運用者にとっての問いは、ページを翻訳できるかどうかだけではなく、そのページを生成するコンポーネントが、レンダリング時に正しい言語別データを選べるかどうかです。

多言語 WordPress サイトでよくある失敗パターン

よくある失敗の 1 つは、ローカライズ済みページの中に未翻訳の断片が残ることです。これは、メインの投稿は翻訳されているのに、ウィジェット、ショートコード、またはプラグイン出力が元言語の設定を参照している場合に起こります。

別の失敗は、関連付けの破綻です。基になるオブジェクトの対応付けが言語対応になっていないと、翻訳済みページが誤った関連投稿、商品、ターム、またはアカウント表示にリンクしてしまうことがあります。

ルーティングも、動的コンテンツの端で失敗することがあります。コンポーネントが現在のロケールを考慮せずにリンク、正規化シグナル、または言語別パスを生成すると、訪問者が誤ったサイト版に送られたり、検索エンジンに不整合なシグナルが送られたりします。

AJAX コンテンツはさらにリスクが高くなります。初期ページと後から読み込まれる断片が、明示的にそのように処理されない限り、同じ言語コンテキストを共有しない可能性があるからです。

アカウント領域や通知は特に敏感です。ユーザー状態、セッション状態、またはプラグイン所有のデータに依存することが多いためです。こうした表示要素には、公開ページコンテンツとは別の翻訳ロジックが必要になることがあります。

互換対応で通常カバーすべきこと

互換対応は一般に、テキストがどこにあるか、それがどのように言語に関連付けられているか、そして正しいコンテキストでどうレンダリングされるか、という 3 つの問いに答える必要があります。

テキストが投稿メタ、カスタムフィールド、またはプラグイン設定にある場合、翻訳レイヤーには言語別の値を保存または参照する方法が必要です。

テキストがブロック、ショートコード、またはテンプレートのコールバックによって生成される場合、レンダリングロジックはどの言語版を出力し、どの関連オブジェクトを読み込むかを知っている必要があります。

出力にリンクやナビゲーション先が含まれる場合、それらの先は元のソースオブジェクトではなく、翻訳済みオブジェクトに解決される必要があります。

出力が非同期で読み込まれる場合、リクエスト自体が、断片を訪問者がすでに見ているページと一致させるのに十分な言語コンテキストを運ぶ必要があります。