多言語WooCommerce：言語間で同期を保つべきもの

基本モデル：コンテンツを翻訳し、コマース状態を同期する

多言語WooCommerceストアでは、すべての商品フィールドが同じ役割を持つわけではありません。あるフィールドは特定の言語で買い物客とコミュニケーションするために存在し、別のフィールドは実際に購入可能な商品を定義し、その商品がどこに表示されても一貫している必要があります。

この違いが重要なのは、言語版が単なるテキストの複製ではないからです。通常、それらは同じ基盤となる商品関係を別の形で表したものです。翻訳版が在庫、SKU、バリエーション構造、またはタクソノミーの対応関係でずれると、ストアは見た目はローカルでも、チェックアウトでは別の商品として振る舞う商品を表示してしまう可能性があります。

データカテゴリ	一般的な扱い	理由
商品タイトル、説明文、短い説明	翻訳する	これらは顧客向けのコンテンツフィールドです。
価格	同期する	ビジネスが意図的にローカライズ価格をサポートしていない限り、言語間で価格が異なると購入動作に一貫性がなくなります。
在庫数量と在庫状況	同期する	在庫は、言語版をまたいで同じ物理商品または販売可能な商品を表します。
SKU	同期する	SKUは商品またはバリエーションの識別子であり、翻訳間でずれるべきではありません。
タクソノミーの関係	同期する、または慎重に対応付ける	カテゴリー、タグ、属性用語は、閲覧、絞り込み、商品グループ化に言語間で影響します。
バリエーション	構造と識別子を同期する	各言語版で同じ購入可能な選択肢を提供できるよう、バリエーションのセットは同等でなければなりません。
チェックアウト動作	同期する	カート、チェックアウト、注文ロジックは、言語に関係なく同じ商品ルールに解決される必要があります。
パーマリンクとルーティング	言語を考慮しつつ一貫させる	各言語には独自のURLパスまたはルーティングパターンが必要ですが、商品関係は引き続き正しく解決されるべきです。
正規URLと言語関係	関係レベルで同期する	検索エンジンと内部ナビゲーションには、言語版間の安定した対応付けが必要です。

翻訳可能な商品コンテンツは、買い物客が読む層です

最も分かりやすい多言語フィールドは、商品を自然言語で説明するものです。タイトル、長い説明文、短い説明文、そして商品ページに付随するその他の顧客向けコピーがこれに当たります。

これらのフィールドは、商品そのもののアイデンティティを変えずに言語ごとに異なっていて構いません。翻訳の目的はそこにあります。買い物客は自分の言語で同じ提案を理解できるべきですが、ストアは引き続き同じ商品レコード、または連携された商品ファミリーを販売している必要があります。

コマースデータは購入ロジックを動かすため、同期を保つ必要があります

価格、在庫、SKU、バリエーション構造は、単なる表示フィールドではありません。これらは、その商品を購入できるかどうか、注文でどのように識別されるか、カートに追加する時点でどの選択肢が利用可能かを決定します。

ある言語版で在庫状況やバリエーションセットが異なって表示されると、ストアフロントの整合性が崩れる可能性があります。買い物客は、利用可能に見える翻訳ページにたどり着いても、基盤となる購入可能状態が別の版に属しているため、チェックアウトで失敗するかもしれません。逆も起こりえます。同期が壊れていると、ある言語表示では在庫切れなのに、別の表示ではまだ利用可能に見えることがあります。

タクソノミーと属性は、安易な複製ではなく、意図的な対応付けが必要です

カテゴリー、タグ、商品属性は、コンテンツとコマースの中間に位置します。買い物客の閲覧、絞り込み、比較を助ける一方で、商品のグループ化やバリエーション定義にも影響します。

多言語構成では、これらの関係を慎重に扱う必要があります。翻訳されたカテゴリー名は、別のカテゴリー関係そのものではありません。対応付けが誤っていると、商品が想定されたアーカイブページから消えたり、フィルターが一致しなくなったり、翻訳ページが言語間で対応しないタクソノミー用語を指したりする可能性があります。

バリエーションは、多言語商品モデルで最も壊れやすい部分です

可変商品は、一貫した構造に依存しています。同じバリエーションセット、同じ属性ロジック、そして親商品と子バリエーションの同じ関係です。

その構造は翻訳後も維持されなければなりません。属性の表示ラベルは言語ごとに変えられますが、バリエーションモデル自体は分断されてはいけません。ある言語版に別のバリエーションセットがあると、買い物客には他の言語には存在しない選択肢が見えたり、翻訳された商品をカートに追加したときに正しい購入可能バリエーションを解決できなかったりします。

チェックアウト動作は、ロジック層では言語に依存しないままでなければなりません

チェックアウトは、多言語の表示が終わり、コマースロジックが引き継ぐ場所です。カートとチェックアウトの流れは、そこに到達するために使われた言語に関係なく、同じ商品ID、価格ルール、在庫チェック、バリエーション選択を解決しなければなりません。

そのため、チェックアウト動作は同期層に属します。買い物客はある言語でインターフェースを読み、別の言語で購入を完了できますが、基盤となる注文データは依然として同じ商品レコードとバリエーションレコードを指している必要があります。この対応付けが壊れると、注文項目が言語コンテキスト間で曖昧または不整合になる可能性があります。

パーマリンク、ルーティング、正規シグナルは、商品のずれを起こさずに言語分離を支えます

各言語版には、検索エンジンとユーザーが正しいローカライズページに到達できるよう、独自のルートが必要です。しかし、別々のURLは別々の商品を意味しません。

ルーティング層は、言語版を区別しつつ、それらの関係を維持する必要があります。その関係が、内部リンク、正規シグナル、言語対応ナビゲーションの整合性を保ちます。URLが分離されていても商品リンクが弱いと、検索エンジンはページを無関係な重複とみなしたり、内部リンクから買い物客が誤った言語版に着地したりする可能性があります。

運用上の問いは、どのフィールドが正本かです

実装上の有用な判断は、各商品フィールドを所有権で分類することです。翻訳管理のフィールドは言語ごとに変えられます。コマース管理のフィールドは単一の正本を持ち、すべての言語版に反映されるべきです。

この分類により、更新時の曖昧さが減ります。たとえば、販売後に在庫が変わった場合、その更新はすべての言語版に流れるべきです。マーケターが商品説明を書き直した場合、その変更は翻訳コンテンツ層にとどまるべきです。編集者がどのフィールドがローカライズ可能で、どのフィールドが設計上同期されるのかを理解していれば、ストアは保守しやすくなります。