REEID 編集部
多言語 WordPress におけるメニューとナビゲーションは構造化データである
多言語 WordPress では、メニューは単なる翻訳済みラベルの一覧ではありません。階層、リンク先、タクソノミーアーカイブ、カスタム URL、プラグイン生成項目、言語固有のルーティングルールで構成された構造化されたナビゲーションオブジェクトです。これらの関係が言語ごとに保持されていないと、見た目には翻訳されていても、基盤となるナビゲーションは壊れてしまいます。
重要なポイント
多言語メニューは言語を意識した構造化データとして扱いましょう。必要な箇所はラベルを翻訳しつつ、項目間の関係、リンク先の対応付け、ルーティングの挙動も保持して、各言語版が一貫したページ、アーカイブ、URL に解決されるようにします。
ナビゲーションは翻訳テキスト以上のもの
多言語メニューには同時に 2 つの役割があります。現在の言語で読みやすいラベルを表示すること、そして各項目が WordPress のどこへ向かうべきかを示す構造を保持することです。その構造には、親子関係、各項目の背後にあるリンク先の種類、そして項目が解決されるべき言語コンテキストが含まれます。
表示テキストだけを翻訳しても、メニューが誤ったコンテンツを指したままになることがあります。特に、メニューにページ、タクソノミーアーカイブ、カスタム URL、プラグインやテーマのロジックで作成された項目が混在している場合、ラベルは正しくてもリンク先が正しくないことがあります。
メニューが構造化データである理由
WordPress のメニューは、単なる平坦な文字列の一覧ではありません。各項目は、そのタイトル以上の意味を持っています。メニューは階層を表現でき、ある項目を別の項目の下に入れ子にできます。また、リンク先の種類も表現できるため、メニュー項目はページ、タクソノミー用語アーカイブ、カスタム URL、またはプラグイン生成のエンドポイントを指すことがあります。
つまり、翻訳では単語だけでなく関係性も尊重しなければなりません。親項目が別の言語に変わっても、子項目が同等のリンク先に対応していなければ、ナビゲーションツリーは不整合になります。その結果は単なる不自然な表現ではなく、その言語版における情報設計の破綻です。
リンク先の対応付けが重要な理由
同じメニューラベルでも、言語ごとに基盤となるリンク先は異なる場合があります。翻訳されたページは別のパーマリンクを持つことがあります。タクソノミーアーカイブは、用語が作成されて関連付けられるまで、ある言語には存在しないことがあります。カスタム URL は、ソース言語のリンクをそのまま複製するのではなく、言語固有のパスが必要になることがあります。
だからこそ、多言語ナビゲーションは単純なテキスト置換として扱えません。メニュー項目は、アクティブな言語で正しいリンク先に解決されなければなりません。そうでないと、ユーザーは誤ったコンテンツ、フォールバック言語、あるいは行き止まりにたどり着いてしまいます。実務上、メニューは単なる表示ではなく、ルーティングの一部なのです。
言語固有のルーティングがメニューの形を変える
多言語サイトでは、同じ概念上のセクションでも、言語版によって異なる URL、異なるアーカイブ先、あるいは異なるメニュー階層が必要になることがあります。これはルーティングが言語を意識しているためです。ある言語で機能するパスが、別の言語では正規のパスではない場合があるのです。
ルーティングが異なるなら、メニューはそれを隠すのではなく反映しなければなりません。翻訳されたナビゲーション項目がソース言語の URL を指していると、表示言語と実際のコンテンツパスの間に不一致が生じます。その不一致は使い勝手を損ない、運用面でもサイトを把握しにくくします。メニューがサイトの言語構造をもはや反映しなくなるからです。
メニューを文字列として翻訳したときによく起こる失敗
1 つ目の失敗は階層のずれです。親項目は翻訳されているのに、子項目が同等の言語コンテンツに対応付けられておらず、サブメニューが同じ概念的なまとまりを表さなくなります。
2 つ目はリンク先のずれです。ラベルは翻訳されているのに、項目が元のページ、タクソノミーアーカイブ、またはカスタム URL を指したままになっています。3 つ目はプラグイン項目のずれで、プラグイン所有のデータから生成されたメニュー項目を、基盤となるオブジェクト関係を保持せずにコピーしてしまうケースです。いずれの場合も、メニューは完全に見えても、ナビゲーションロジックは不整合になります。
これらの失敗は、サイトが複数のコンテンツタイプを混在させているときに特に目立ちます。ページ、カテゴリアーカイブ、カスタムリンクを含むメニューでは、各項目タイプをそれぞれのルーティング挙動に応じて扱う必要があります。
WordPress の所有者と実装者にとっての運用上の意味
WordPress の所有者にとっての実務上の判断は、多言語ナビゲーションを言語を意識した関係の集合として管理するのか、それとも翻訳済みラベルの集合として管理するのか、という点です。前者はページ、アーカイブ、カスタムリンクをまたいで一貫性を保ちます。後者はローカライズされて見えても、ローカライズされたナビゲーションとしては機能しないメニューを生み出す可能性があります。
開発者や実装者にとっての重要な設計上のトレードオフは、単純さと正確さのどちらを優先するかです。単純な翻訳ワークフローは最初は保守しやすいですが、メニューが依存する構造的な関係を保持できません。構造化されたアプローチは、項目の対応付けと言語ルーティングにより注意を払う必要がありますが、ナビゲーションツリーを各言語のコンテンツモデルに整合させたままにできます。
よくある質問
メニューラベルだけ翻訳して、リンクは同じままにできないのはなぜですか？
ラベルはメニュー項目の一部にすぎないからです。ラベルの背後にあるリンク先には、別のパーマリンク、アーカイブ先、または言語固有の URL が必要になることがあります。リンクが正しい言語版に対応付けられていないと、メニューは翻訳されて見えても、ユーザーを誤った場所へ送ってしまいます。
多言語メニューではカスタムリンクはページリンクと違って動作しますか？
はい。カスタムリンクは翻訳されたコンテンツオブジェクトに自動的に結び付けられていないからです。URL をアクティブな言語に合わせるために、言語固有のルーティングや手動の対応付けが必要になることがよくあります。ページリンクやタクソノミーリンクにも、それぞれのリンク先関係を保持する必要がありますが、カスタムリンクは特に、パスを調整せずにそのままコピーされやすいのです。
ある言語から別の言語へメニュー構造をコピーする主なリスクは何ですか？
見た目の構造はコピーされても、基盤となる関係はコピーされない可能性があることです。その結果、親子のまとまりは保たれていても、項目がソース言語のコンテンツ、存在しないアーカイブ、またはターゲット言語には存在しないプラグイン生成のリンク先を指してしまうことがあります。
出典と根拠
アーキテクチャを活用する
WordPress の統合が多言語システムでどのように動作するかを見る
REEID 統合ディレクトリで、プラグイン固有の互換性、翻訳対象、実装メモを確認してください。
