WordPress多言語サイトにおけるカスタムデータテーブルの設計と実践

あるワードプレス多言語サイトを作成する際、プラグインやテーマレベルで製品、イベント、不動産情報などのカスタムデータを保存し始めると、ほぼ必ず直面する避けられない問題があります：自分でデータテーブルを作成すべきか.

多くのプロジェクトは初期段階で「構造を明確にする」ために、すぐにカスタムテーブルを導入した。しかし第二言語、第三言語が導入された後、問題が徐々に表面化した。一部のコンテンツが欠落しているものもあれば、 URL 衝突、それにバックエンドを少し変更するだけで、関連する部分まで影響が及ぶ。

多言語処理自体は複雑ではないが、真に試されるのは初期のデータ構造設計である。ここでは実際のプロジェクト経験を踏まえ、比較的安定しており、後々トラブルを起こしにくい手法について述べる。

核心的な結論は明確である：
WordPressのネイティブ機能で実現できるなら、わざわざカスタムテーブルを作成する必要はない。どうしてもカスタムテーブルを使うなら、言語を完全に分離すべきだ。

本当にカスタムデータテーブルが必要なのか

テーブルを作成する前に、立ち止まって現実的な質問を投げかけよう：このデータは、本当にカスタムテーブルでなければならないのか？

WordPressネイティブソリューションの実践能力

WordPressは多言語に対応しています。
カスタム投稿タイプとの連携 ACFMeta Box のようなフィールドプラグインは、本質的にすでに多くの業務シナリオをカバーしている。

このモデルでは：

データは保存されています wp_posts 歌で応える wp_postmeta
Polylang、WPMLなどのプラグインで多言語を直接管理できます
タイトル、本文、フィールド、スラッグ、SEO情報をすべて翻訳できます
検索経路が明確で、検索エンジンにもより親和性が高い

もしあなたのデータ構造が「記事のように見える」場合、例えば製品カタログ、事例紹介、チームメンバー、コースリストなど、この方法が最も手間がかからないことが多い。

実は、多くのプロジェクトがここまで来ると、すでに9割のニーズは解決されている。

いつカスタムテーブルを検討する価値があるのか

カスタムテーブルは禁忌ではないが、その敷居はより高くすべきである。通常、以下の状況においてのみ、それが真に意味を持つ：

データ量は明らかにWordPressの快適領域を超えている。例えば百万レベルのレコードなど。
クエリの関係が複雑で、複数のテーブルの結合（JOIN）を頻繁に含む
フィールドの高構造化、使用 postメタ 肥大化し、非効率になる

もし単に「時計を使う方がプロフェッショナルに見える」という理由なら、それは将来的にメンテナンスコストを生み出すことになる。

多言語カスタムテーブルのコア分割アプローチ

カスタムテーブルを使用すると決めた時点で、多言語設計は最初から明確に考える必要がある。

どのデータが言語と混同されるべきではないか

一部のフィールドは、ページがどの言語で表示されても本質的には変わらない：

業務ID、SKU内部一意の番号
状態、並べ替え、価格、在庫、数量
作成日時、更新日時
各種関連ID、例えば作者、親要素、分類関係など
メディアID（画像自体に言語区分がない場合）

これらのフィールドは、言語と結合されると、後々複雑さを増すだけである。

どのデータを言語別に区別する必要があるか

もう一つのフィールドは、本来「言語バージョン」に属する：

タイトル、本文、要約、説明
SEOタイトルとメタディスクリプション
スラッグ（URLエイリアス、これが特に重要）
多言語コピーライティング、地域別説明

ここには一つの最低ラインがある：
主テーブルに追加しないでください title_enそしてtitle_zh この列。

最初は手間がかからずに見えたが、言語が増えると、表の構造はすぐに制御不能になる。

推奨構造：主テーブル + 翻訳テーブル

実践において、最も確実で長期的なメンテナンスが容易な方法は、言語を「列」ではなく「行」に分解することである。

主テーブルは業務エンティティのみを扱う

主テーブルの役割は非常に抑制されており、言語に依存しないコア情報のみを保持する。
フィールドが冷静であればあるほど、後期の安全性は高まる。

翻訳表は言語の差異を表現する役割を担う

翻訳表において、各行は同一エンティティが特定の言語で表現される形を表す：

とおす ベースID 関連主テーブル
とおす ラング マークアップ言語
タイトル、説明、SEO、スラッグはすべてここに集約されています

base_id + lang 組み合わせは一意でなければならない。これは最適化の提案ではなく、厳格な制約である。

言語コードは標準形式を直接使用することを推奨します。例えば エンそしてzh-hansそしてzh-hant。後ろに何が続いても WPMLそしてポリラン、あるいは外部にAPIを提供する場合でも、よりスムーズに進むでしょう。

なお、slug は必ず言語別に保存し、かつ作成してください。 (言語, スラッグ) インデックス。多言語ルーティングの競合は、往々にしてここから始まる。

分類、タグ付けおよび関係データの多言語処理

分類とタグ付けは一見単純に見えるが、実は多言語プロジェクトにおいて最も見落とされやすい要素である。

分類名称は翻訳が必要ですが、構造は不要です。

分類自体も二層に分解できる：

基礎テーブルの保存階層、ソート順序、親子関係
翻訳テーブルの保存名、説明、スラッグ

このように処理すれば、言語を追加しても元の構造に影響を与えません。

多対多関係は翻訳不要

例えば「製品がどの分類に属するか」という関係は、言語によって変化しない。

関係表にはIDのみを保存し、表示名が必要な際は翻訳表から対応する言語コンテンツを取得する。この役割分担が最も論理的に明確である。

クエリ実行時には言語フォールバックを考慮する必要がある

この点については、実際のプロジェクトで失敗した人が非常に多い。

現在の言語のみを検索するのは、往々にして不十分である。

バックエンドでのコンテンツ更新には時間差が生じます。一部の言語は公開済みですが、他の言語はまだ翻訳中です。しかしフロントエンドでは既にページを表示する必要があります。

クエリロジックが現在の言語のみを認識する場合、ページが空白になる可能性が高い。

より現実的な方法は言語の退行である

より確実な戦略は：

現在の言語を優先的に使用
存在しない場合、デフォルト言語にフォールバックする
どちらも該当しない場合、空またはプレースホルダーを返す

このロジックは、テンプレートに散発的に追加するのではなく、統一されたクエリ層に記述するのが最善である。そうしないと、バックエンドのメンテナンス体験が急速に悪化する。

WPML / Polylang との連携方法

実際のプロジェクトでは、通常ここに2つのパスがあります。

完全な自主管理による多言語対応

データ量が多く、構造が複雑で、制御力に対する要求が極めて高いプロジェクトに適している。
すべてのJOINおよびロールバックロジックはコード層で処理され、柔軟性が高いが、コストも最も高い。

プラグインのパイプ文案、カスタムパイプ構造

より一般的で、より現実的な方法。

タイトル、本文、SEO CPT + 多言語プラグインに委ねる
価格、在庫、仕様などの構造化データはカスタムテーブルに配置する

この分業体制は、ほとんどの商業プロジェクトにおいて非常に安定して機能している。

実際のプロジェクトでよく見られる落とし穴

ある問題については、最初は見抜けなくても、後になって非常に致命的になる：

メインテーブルの言語フィールドが満杯のため、新規言語を追加するには構造を変更する必要がある
slugは言語を区別せず、ルーティングは遅かれ早かれ衝突する
翻訳表には一意性の制約がなく、重複データがひそかに発生する
言語のロールバックがなく、フロントエンドのコンテンツが不完全です
インデックスを無視すると、データ量が増えるとクエリ性能が即座に崩壊する

これらの問題は、技術能力の不足というより、初期設計段階で多言語対応の長期的な影響を過小評価したことに起因している。

直接実行可能な最小限のソリューション

今すぐ利用可能で拡張性のある多言語カスタムテーブル構造が必要な場合、以下の考え方で進めることができます：

ビルドアップ xxx_base 表には言語非依存フィールドのみを配置する
ビルドアップ xxx_i18n 表、翻訳可能なすべてのコンテンツ（スラッグを含む）を一元的に保存
翻訳表の使用 (ベースID, 言語) 唯一の制約
によって (言語, スラッグ) インデックスを作成する
統一クエリ関数をカプセル化し、言語優先順位とフォールバックを自動処理する

ここまで来れば、データ層はほぼ安定している。後で言語を追加したり、プラグインを変更したり、表示ロジックを修正したりしても、根本的な部分に影響を与えることはない。

より具体的な業務シナリオ、例えばEC製品、不動産情報、多言語フォーム構造などに対応する場合、この基盤をさらに細分化することも可能です。その段階に到達してから手を加える方が、むしろ安全です。

お問い合わせ
チュートリアルが読めない？無料でお答えします！個人サイト、中小企業サイトのための無料ヘルプ！	カスタマーサービス WeChat
① 電話：020-2206-9892
② QQ咨询：1025174874
三 Eメール：info@361sale.com
④ 勤務時間: 月～金、9:30～18:30、祝日休み