Elementor & Divi テンプレートのレイアウトを崩さずに翻訳する方法

あなたはすべて正しく行いました。プレミアムテーマを購入し、.poファイルを見つけ、慎重に翻訳し、.moファイルを言語フォルダにアップロードしました。テーマのヘッダーの文字列は正しく更新されます。フッターはスペイン語で表示されます。WooCommerceのチェックアウトもローカライズされています。しかし、ホームページを開くと、Elementorで構築されたすべての見出し、ボタン、テキストブロックがまだ英語のままです。

.poファイルを確認します。コード内の英語の文字列が見えます。再翻訳します。何も変わりません。キャッシュをクリアします。何も変わりません。何かが壊れていると自分を納得させますが、フォーラムの誰かが優しく指摘してくれます。Elementor（およびDivi、Beaver Builder、Bricks）はコンテンツを.poファイルに保存しません。これまでもそうでした。あなたは、使用しているアプローチでは解決できない問題と戦っていたのです。

このガイドでは、ページビルダーコンテンツがテーマやプラグインコンテンツとアーキテクチャ的に異なる理由、それを翻訳する2つの方法、そして翻訳中にウィジェットのマークアップを損なわないようにして、苦労してデザインしたレイアウトが崩れないようにする方法を説明します。

ElementorとDiviが.poファイルを使用しない理由

.poファイルは、コード内に存在する文字列を保存します — PHPテンプレート全体に散らばる__( 'Shop', 'mytheme' )呼び出しなどです。ビルドツールWP-CLIはこれらの文字列を.potテンプレートに抽出し、翻訳者は.poファイルで作業し、コンパイルされた.moファイルが実行時に読み込まれます。

ページビルダーのコンテンツは異なります。Elementorの見出しウィジェットに「Welcome to our store」と入力しても、そのテキストはどのPHPファイルにもありません。それは、配置した投稿に関連付けられたwp_postmetaテーブルにJSON（Elementor）またはショートコードの塊（Divi）として保存されます。

ページビルダーのコンテンツが実際に存在する場所

Elementorは、各ページのウィジェットツリーを_elementor_dataというキーでpostmetaに保存します。データベースの任意の投稿を開くと、すべてのセクション、カラム、ウィジェットを記述するJSON配列が設定とコンテンツとともにインラインで見つかります。

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Diviは、ページコンテンツをpost_contentに埋め込まれたショートコードとして保存します。

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks、Beaver Builder、Oxygenも独自の形式で同じパターンに従います。これらのコンテンツはどれも.po / .moファイルには一切触れません。

.poファイルに実際に存在する内容

ページビルダープラグイン自体には、エディタのボタンラベル、エラーメッセージ、管理通知などのUI文字列があります。これらは.poファイルにあり、wp-content/languages/plugins/内の.moファイルによって翻訳されます。これが通常、人々が混乱する理由です。彼らは「Elementor」の文字列を翻訳し、エディタのUIがスペイン語で表示されるのを見ますが、そのウィジェットで構築した実際のコンテンツは英語のままです。

この区別は、翻訳が表示されない場合のトラブルシューティングガイドのチケットの半分が根本原因となっているものです — 読者は.moファイルがフロントエンドに表示されるコンテンツに影響を与えると期待しますが、コンテンツはデータベースにあり、コードにはありません。

ページビルダーサイトで.poファイルが実際にカバーするもの

それぞれのファイルタイプが何を処理するのか正確にわかるように、この2つの間に明確な線を引いてみましょう。

.po / .mo ファイルが翻訳するもの

• テーマのテンプレート文字列: get_template_part、header.php、footer.php、functions.php内のハードコードされたテキスト。
• プラグインのUI文字列: WooCommerceのチェックアウト、Yoastの管理ラベル、Contact Form 7のフィールドラベル。
• ページビルダープラグインのUI: Elementorのエディタボタン、Diviの保存確認メッセージ。
• プラグインがフロントエンドにエコーする動的な文字列: WooCommerceの「Add to cart」、「Out of stock」、カートの合計。

.po / .mo ファイルが翻訳しないもの

• Elementorウィジェットに入力された見出し、段落、ボタンのテキスト。
• Diviモジュール内の画像キャプション、ホバーエフェクト、アコーディオンタイトル。
• 再利用可能なテンプレート、グローバルセクション、保存されたブロック内のコンテンツ。
• ビルダーウィジェット内のカスタムCSSラベルまたはインラインスクリプト。

これが、テーマ作成者の翻訳に関するドキュメントが技術的には正しいものの、エンドユーザーにとってはしばしば役に立たない理由です。当社のWordPressテーマをローカライズする方法に関するガイドは、テーマ側を徹底的にカバーしています — この投稿は、その続きを扱います。

ページビルダーのローカライズにおける2つの方法

ページビルダーのコンテンツを翻訳する方法は正確に2つあり、どちらも実際のトレードオフがあります。

方法1: 言語ごとにページを複製する

WPML、Polylang、TranslatePressのような多言語プラグインを使用します。これは、言語ごとにすべてのページのコピーを作成します。Elementorでは、レイアウト全体を複製し、各コピーのテキストを交換します。Diviでは、ショートコードの塊をコピーし、タグ間のテキストを翻訳します。

メリット: 各言語で独立してデザインされたレイアウトを持つことができます（翻訳されたテキストが長すぎて元のデザインを壊す場合に便利です）。ページビルダーのビジュアルエディタとの完全な互換性があります。

デメリット: 線形スケーリング — 5言語は5倍のレイアウト作業を意味します。デザイン変更は5回適用する必要があります。データベースが急速に増大します。キャッシュが難しくなります。

方法2: 文字列翻訳レイヤー

一部のプラグイン（Polylang Pro、WPMLのString Translationモジュール、TranslatePress）は、ページビルダーウィジェット内の個々の文字列を翻訳用に公開し、レンダリング時にそれらを交換できます。あなたは1つのレイアウトを維持し、プラグインは文字列をその場で翻訳します。

メリット: レイアウトの単一ソース。デザイン変更がすべてに適用されます。

デメリット: 翻訳されたテキストの長さが大幅に変わった場合の柔軟性が低下します。一部のウィジェット（ネストされたコンテンツ、動的リスト、フォームを持つ複雑なもの）は文字列をきれいに公開しません。レンダリングごとのパフォーマンスコストがかかります。

当社のPolylang vs WPML vs TranslatePressの比較では、各プラグインのトレードオフについてさらに詳しく説明しています。

翻訳中にウィジェットのマークアップを安全に保つ方法

どの方法を選択しても、翻訳されたコンテンツはビルダーの構造的マークアップを保持する必要があります。翻訳者がElementorのショートコードを削除したり、データ属性を置き換えたり、ネストされたタグを並べ替えたりすると、ウィジェットが破損してレンダリングされます。

Elementorの危険な領域

Elementorのウィジェットは、テキスト設定内にショートコードと動的タグを埋め込みます。見出しウィジェットのタイトルフィールドには、以下が含まれる場合があります。

Welcome to <strong>our</strong> [user_name] store

この[user_name]は動的タグであり、Elementorはレンダリング時にログインユーザー名に置き換えます。翻訳によってこれが破損すると、ユーザーには文字通りの「[user_name]」が表示されてしまいます。

ボタン内のアイコンは、翻訳してはならないクラス属性を使用します。画像のaltテキストは画像URLとは別に保存されます。カラムレイアウトは、個別の処理が必要なブレークポイント固有の設定（title_mobile、title_tablet）を使用します。

Diviのショートコードのネスト

Diviのショートコードは深くネストします: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]。この塊をプレーンテキストとして扱う翻訳者は、角括弧をエンコードしたり、属性値を翻訳したり、閉じタグを失ったりするでしょう。これらのいずれかによってモジュールが破損し、Diviはそれをレンダリングできなくなります。

安全なパターン

どちらのビルダーでも、翻訳は次の手順に従う必要があります。

1. ウィジェットの形式を解析する（ElementorはJSON、DiviはショートコードAST）。
2. ユーザーに見えるテキストフィールドのみを特定してツリーを走査する。
3. ショートコード、動的タグ、HTML属性、インラインCSSをロックする。
4. コンテキストとともにテキスト表面のみを翻訳者に送信する。
5. 翻訳されたテキストを元の構造に再挿入する。

これは、当社のエンジンが.poファイルに適用するのと同じ原則です。コード変数を壊さずに.poファイルを翻訳するためのガイドでは、%sとプレースホルダーのパターンについて詳しく説明されています — ページビルダーの同等物はショートコードと動的タグです。

実際に機能するハイブリッドワークフロー

ほとんどのチームにとって、実用的な答えは両方のアプローチを組み合わせることです。

ステップ1: テーマとプラグインのUIを.poファイル経由で翻訳する

テーマと主要なプラグイン（WooCommerce、Yoast、ページビルダーUI）から.potファイルをエクスポートします。.po形式を尊重するクラウド翻訳ツールを使用して一度翻訳します。コンパイルされた.moファイルをwp-content/languages/にドロップします。これにより、サイトのインターフェース文字列の80%が、ほぼゼロの継続的なメンテナンスで処理されます。

ステップ2: 動的コンテンツ用の多言語プラグインを選択する

投稿、ページ、製品コンテンツ用にPolylangまたはWPMLをインストールします。URL構造（/es/、/fr/）とhreflangタグを設定します。これにより、言語ごとのデータベースコンテンツのインフラストラクチャが得られます。

ステップ3: ページビルダーテンプレートを選択的に複製する

トラフィックの多いランディングページ、ホームページ、基盤となるマーケティングコンテンツについては、各言語でページを複製し、ウィジェットを手動で翻訳します。これにより、重要な場所で完全にデザインを制御できます。

ステップ4: 繰り返しブロックに文字列翻訳を使用する

すべてのページに表示されるグローバルセクション、再利用可能なテンプレート、フッターCTAについては、多言語プラグインの文字列翻訳機能を使用します。1か所で更新し、レンダリング時に交換します。

ステップ5: 品質チェックを実行する

翻訳されたページビルダーのコンテンツは、レイアウトのずれなくレンダリングされるべきです。長い言語（ドイツ語、ロシア語）はボタンの幅を壊すことがあります。短い言語（中国語、日本語）は不自然な余白を残すことがあります。公開する前に、各言語で各テンプレートをテストしてください。

よくある落とし穴とその回避策

すべてのページビルダーローカライズプロジェクトで現れるいくつかの落とし穴です。

画像のAltテキストが翻訳されない

ElementorとDiviはどちらも、メディアライブラリではなく、ウィジェットインスタンスごとにaltテキストを保存します。元の画像を翻訳しても、それを使用するすべてのウィジェットのaltテキストが翻訳されるわけではありません。複製された各ページでaltテキストを更新してください。

フォームとカスタムフィールド

ページビルダーウィジェットに埋め込まれた問い合わせフォームには、独自の文字列（ラベル、プレースホルダー、検証メッセージ）があります。フォーム側については、Gravity FormsとContact Form 7を翻訳するためのガイドをご覧ください。

グローバルウィジェットとテンプレート

グローバルテンプレートへの変更は、翻訳されたコピーを含む、それを使用するすべてのページに伝播します。これは、共有コンテンツを望むか、個別のコンテンツを望むかによって、有用であるか壊滅的であるかが異なります。テンプレートごとに明示的に決定してください。

翻訳キャッシュの期限切れ

ページビルダーはレンダリングされたHTMLを積極的にキャッシュします。翻訳後、Elementor CSSキャッシュ（Elementor > Tools > Regenerate CSS）とDiviの静的CSSキャッシュを含む、すべてのキャッシュをクリアしてください。

全体をまとめる

ElementorまたはDiviで構築されたサイトを翻訳することは、静的なテーマを翻訳することよりも難しいわけではありません。ただ、正しいメンタルモデルが必要です。テーマとプラグインの文字列は.poファイルに存在し、.moファイルを経由して伝達されます。ページビルダーのコンテンツはデータベースに存在し、多言語プラグインまたは手動複製を経由して伝達されます。この2つの方法を混同することが、「なぜ翻訳が機能しないのか」というフラストレーションの最も一般的な原因です。

成功するワークフローはシンプルです。コードに存在するすべてのものには静的な.moファイル、ページコンテンツには多言語プラグイン、そして価値の高いランディングページには手動でのキュレーションです。これらすべてを1つのツールで処理できるものはなく、そう約束する者は何かを売ろうとしているだけです。

ウィジェットのマークアップを壊さずに、テーマとプラグインの.poファイルを翻訳する準備はできていますか？SimplePoTranslateを無料で試す — クレジットカードは不要です。.poをアップロードし、安全な翻訳をダウンロードして、wp-content/languages/にドロップするだけです。