REEID アーキテクチャ
WordPress のための、よりスマートな多言語アーキテクチャ。
REEID は、既存の WordPress 構造を中心に保ち、各訪問者に必要な言語別コンテンツを追加します。言語が増えても、同じサイト構造を何度も作り直す必要はありません。
中心原則
体験を翻訳するのであって、システム全体を翻訳するのではありません。
WordPress はページ、商品、レイアウト、運用構造の所有権を保持します。REEID は、それに紐づく言語別の顧客向けコンテンツを追加します。
WordPress 構造
↓
REEID 言語レイヤー
↓
ローカライズされた顧客体験
アーキテクチャモデル
1 つの WordPress 構造。複数の言語体験。
REEID は、各言語をサイトの別個の独立したバージョンとして扱うのではなく、元の WordPress エンティティを中心に保ち、翻訳された顧客向けコンテンツをそれに関連付けます。
構造の重複
すべての言語が別の構造になるとき
多言語アプローチの中には、同じ基盤コンテンツの周囲に並列レコードや関係性を生み出すものがあります。
- レコードが増えるほど、保守が必要になる場合があります。
- 構造変更には調整が必要になる場合があります。
- 編集者が並列の言語構造をまたいで作業することがあります。
- 言語が増えるたびに複雑さが増すことがあります。
正確な影響は、使用している多言語システムとサイトアーキテクチャによって異なります。
REEID モデル
元のエンティティを中心に保つ
REEID は、言語を完全な運用構造の別コピーとしてではなく、既存の WordPress エンティティに関連付けられたコンテンツとして扱います。
- 元のページや商品が中心のまま残ります。
- 言語コンテンツはそれに紐づいたままです。
- レイアウトと構造上の関係は WordPress に残ります。
- 編集者は、慣れ親しんだサイトエンティティを使い続けます。
翻訳は、別のサイトアーキテクチャではなく、言語レイヤーになります。
明確な所有権
各システムは、すでに最も得意としていることに責任を持ち続けます。
REEID は、WordPress やページビルダー、コマースエンジンになろうとはしません。既存の責任を維持したまま、多言語機能を追加します。
01
WordPress
ページ、投稿、商品、メタデータ、タクソノミー、およびサイトのコンテンツ構造を形成する関係性を所有します。
02
編集者 & ビルダー
レイアウト、ブロック階層、レスポンシブ動作、そしてサイトチームが使用する編集ワークフローを管理します。
03
WooCommerce
商品カタログ、コマース関係、運用上のストアモデルを所有します。
04
REEID
WordPress エンティティとその周囲のワークフローに関連付けたまま、言語別の訪問者向けコンテンツを追加します。
コンテンツを翻訳。構造は維持。
WordPress が管理する内容を再定義せずに、訪問者が読む内容を変更します。
この区別は意図的なものです。顧客向けの言語は言語レイヤーに属し、構造的・運用的な設定は、それを所有するシステムに残ります。
言語レイヤー
顧客向けの意味を翻訳する
言語レイヤーは、訪問者が理解し、移動し、行動するために必要な情報に焦点を当てます。
- ページおよび投稿コンテンツ
- 対応ブロックおよびウィジェットのコンテンツ
- 顧客向けの商品テキスト
- メニューとインターフェース文字列
- SEO 向け言語コンテンツ
- その他の対応する訪問者向けフィールド
中心構造
運用上の所有権を維持する
サイトアーキテクチャと運用上の関係は、すでに属している場所に残ります。
- ページと商品の識別情報
- レイアウトとレスポンシブ設定
- ブロック階層とビルダー構造
- コマース関係
- プラグイン設定
- 無関係な運用メタデータ
モデルの仕組み
元のエンティティが制御の起点のままです。
このアーキテクチャは、シンプルな所有権の流れに従います。WordPress がサイトエンティティを定義し、REEID がそれに言語コンテンツを関連付け、訪問者は適切なローカライズ体験を受け取ります。
01
通常どおり作成・管理する
あなたのチームは、すでに使っているワークフローを通じて、元の WordPress ページ、商品、または対応エンティティを管理します。
02
言語コンテンツを関連付ける
REEID は、周囲の構造の所有権を移すことなく、対応する翻訳済みの顧客向けコンテンツを元のエンティティに接続します。
03
ローカライズされた体験を提供する
訪問者は言語別コンテンツを受け取り、基盤となる WordPress エンティティは構造的な真実の中心ソースのまま残ります。
この区別が重要な理由
ウェブサイトの基本的な管理方法を変えずに、多言語を成長させる。
構造の所有権を明確に保つことで、多言語作業の理解がしやすくなり、言語レイヤーを、チームがすでに理解している WordPress ワークフローにより近づけられます。
01
構造の重複を削減
各顧客体験ごとに完全な WordPress 構造を意図的に作り直すことなく、言語を追加できます。
02
慣れ親しんだ編集モデル
編集者は、すでに知っている WordPress のページ、商品、対応ビルダーを使い続けます。
03
明確な責任分担
WordPress、ビルダー、コマースシステム、REEID は、所有権を争うのではなく、それぞれの役割を維持します。
04
拡張可能な言語成長
同じ中心的な所有権の原則で、サイトの拡大に合わせて追加の言語別顧客体験を支えられます。
よくある質問
アーキテクチャ FAQ
中心構造モデルが、実際の WordPress 利用で何を意味するのか。
REEID は、言語ごとに完全な複製ページを作成しますか？
いいえ。このアーキテクチャは、元の WordPress エンティティを中心に保ちながら、対応する言語別の顧客向けコンテンツをそれに関連付けるよう設計されています。
REEID は Gutenberg、Elementor、WooCommerce を置き換えますか？
いいえ。これらのシステムは、すでに管理しているレイアウト、ブロック、商品、設定の所有を続けます。REEID は、対応コンテンツの周囲に多言語レイヤーを追加します。
レスポンシブ設定とレイアウト設定はどうなりますか？
構造的な表示設定は、既存の WordPress またはビルダー設定の一部のままです。通常の翻訳済み顧客コンテンツとして扱われることはありません。
元のコンテンツが変更されたらどうなりますか？
元の WordPress エンティティは、構造上の参照先のままです。言語別コンテンツは、ページ全体の構造の無関係なコピーになるのではなく、そのエンティティに関連付けられたままです。
同じアーキテクチャで多くの言語をサポートできますか？
はい。追加の言語別顧客向けコンテンツは、言語ごとに新しいアーキテクチャ原則を必要とせず、同じ中心的所有権モデルに従えます。
アーキテクチャの上に構築する
REEID Translate が WordPress 内でこのモデルをどのように適用するかを見る。
製品そのものを確認するか、REEID があなたのウェブサイトで既に使っている WordPress ツールをサポートしているかを確認してください。