多言語対応のShopifyからWordPressへの移行を構築する方法

数ヶ月かけて多言語対応のShopifyストアを構築しました。商品の説明はフランス語、ドイツ語、スペイン語に翻訳されています。チェックアウトフローは3つの言語で動作します。そして、より多くの制御、より良い利益率、またはプラグインの柔軟性を求めて、WordPressとWooCommerceに移行することにしました。

商品のデータは問題なく移行されます。画像も移行されます。しかし、翻訳はどうでしょうか？消えてしまいます。

これは、誰も警告してくれない多言語WordPress移行の隠れたコストです。Shopifyは翻訳を独自のプロプライエタリシステムに閉じ込め、WordPressはまったく異なるアーキテクチャを使用します。明確な計画がなければ、すでに持っていたものを再構築するのに何週間も費やすことになります。このガイドでは、その計画を提供します。

多言語移行が失敗する理由（そしてShopifyがそれを悪化させる理由）

プラットフォームの移行は、単一言語のストアでも十分に面倒です。複数の言語を追加すると、複雑さはさらに増します。根本的な原因はアーキテクチャにあります。ShopifyとWordPressは、翻訳を根本的に異なる方法で処理します。

Shopifyの翻訳モデルは閉鎖的な環境

Shopifyは、Translate and Adapt APIを介して、リソースに添付されたメタデータとして翻訳を保存します。各商品、コレクション、ページには、Shopifyの内部リソースIDに関連付けられた翻訳エントリがあります。

Cart2Cart、LitExtension、CSVエクスポートなどの移行ツールを使用してストアをエクスポートすると、デフォルト言語のコンテンツが取得されます。翻訳は、ほとんどの移行ツールが完全に無視する別のレイヤーに存在します。

実際にエクスポートされるもの（と失われるもの）

一般的なShopifyからWordPressへの移行ツールが転送するものは次のとおりです。

パターンは明確です。デフォルト言語のコンテンツは移行されます。翻訳は移行されません。また、手動で抽出したとしても、Shopifyの翻訳をWordPressに貼り付けることはできません。システムは文字通り異なる言語を話します。

Shopifyの言語をWordPressの翻訳ファイルにマッピングする

再構築を開始する前に、WordPressが多言語コンテンツをどのように処理するかを理解する必要があります。これは、ほとんどの移行ガイドで不足している点です。

Gettextシステムを理解する

WordPressはGettextローカリゼーションシステムを使用しています。翻訳をデータベースレイヤーに保存する代わりに、人間が読める.poファイルからコンパイルされた静的なバイナリファイル（.moファイル）から読み取ります。

.poファイルは次のようになります。

msgid "Add to Cart"
msgstr "Ajouter au panier"

msgid "Search results for %s"
msgstr "Résultats de recherche pour %s"

すべてのWordPressテーマとプラグインには、翻訳可能なすべての文字列を含む.potテンプレートファイルが付属しています。言語ごとに.poファイルを作成し、翻訳を入力し、.moにコンパイルして、適切なディレクトリにドロップします。

これは、Shopifyの翻訳をマッピングする必要があるシステムです。

言語コードの不一致の問題

ShopifyはIETF言語タグ（en、fr、de）を使用します。WordPressは、地域バリアント（fr_FR、de_DE、es_ES）を持つロケールコードを使用します。移行中に、各Shopify言語を正しいWordPressロケールにマッピングする必要があります。これを間違えると、WordPressは翻訳ファイルを見つけることができません。

人々をつまずかせる一般的なマッピング：

• ShopifyのptはWordPressのpt_PT（ポルトガル）またはpt_BR（ブラジル）にマッピングされます - 互換性はありません
• Shopifyのzh-CNはWordPressのzh_CNにマッピングされますが、Shopifyのzh-TWはzh_TWにマッピングされます
• Shopifyのnb（ノルウェーのブークモール）はWordPressのnb_NOにマッピングされます

.poファイルと.moファイルにWordPressロケールコードで名前を付けます：themename-fr_FR.po、woocommerce-de_DE.mo。コードが間違っていると、WordPressはファイルをサイレントに無視します。

ステップバイステップの多言語WordPress移行ワークフロー

ShopifyからWordPressへの移行中に翻訳を保持するための具体的なワークフローを次に示します。

ステップ1：Shopifyの翻訳をエクスポートして監査する

WordPressを操作する前に、Shopifyからすべてを抽出します。Shopify Admin APIまたはShopify Translate CSV Exportなどのツールを使用して、翻訳を構造化されたファイルにプルします。

# Using Shopify CLI to export translations
shopify app translate export --locale fr
shopify app translate export --locale de
shopify app translate export --locale es

エクスポートを監査します。言語ごとにいくつの文字列があるかをカウントします。WordPressのCMSまたは多言語プラグインによって処理される商品コンテンツの翻訳と、.poファイルによって処理されるテーマ/UI文字列の翻訳を特定します。

ステップ2：WordPressとWooCommerceの言語構造を設定する

新しいWordPressインストールで、コンテンツをインポートする前に言語インフラストラクチャを構成します。

1. 設定 > 一般に移動して、サイトの言語を設定します
2. 設定 > 一般 > サイトの言語から、各ターゲット言語の言語パックをインストールします
3. 翻訳ディレクトリ構造を作成します：

/wp-content/languages/
/wp-content/languages/plugins/
/wp-content/languages/themes/

商品コンテンツの翻訳（タイトル、説明）には、WPMLやPolylangなどの多言語コンテンツプラグインが必要です。ただし、テーマとプラグインのUI文字列（ボタン、ラベル、エラーメッセージ、チェックアウトフロー）には、静的な.po/.moファイルが必要です。これは、プラグインの肥大化を回避するクラウドベースのアプローチです。

ステップ3：翻訳をPO形式に変換する

Shopifyテーマ文字列の翻訳は、Gettextの.po形式に変換する必要があります。これは、移行が技術的になる場所です。

Shopifyの翻訳がJSONまたはCSV形式の場合、スクリプトまたはツールを使用して.poに変換できます。重要なのは、各ソース文字列をmsgid/msgstrペアにマッピングすることです。

import csv

with open('shopify_translations_fr.csv', 'r') as infile, \
     open('theme-fr_FR.po', 'w') as outfile:
    outfile.write('msgid ""\nmsgstr ""\n')
    outfile.write('"Language: fr_FR\\n"\n\n')
    reader = csv.DictReader(infile)
    for row in reader:
        outfile.write(f'msgid "{row["key"]}"\n')
        outfile.write(f'msgstr "{row["translation"]}"\n\n')

これにより、開始点が得られますが、新しいWordPressテーマとWooCommerceインストールには、Shopifyに存在しなかった数百もの文字列があります。周囲のコードコンテキストが異なるため、WooCommerceのShopifyの「カートに追加」の翻訳を再利用することはできません。WooCommerceの文字列はAdd to cart（小文字の「c」）であるか、商品名に%s変数が含まれている場合があります。

これが、ほとんどの人が行き詰まる場所です。Shopifyからの部分的な翻訳と、翻訳されていないWordPress固有の文字列の大きなギャップがあります。

最初からやり直さずにギャップを翻訳する方法

良いニュースは、5,000ものWooCommerce文字列を手動で翻訳する必要がないことです。悪いニュースは、それらをスキップすることもできません。スキップすると、ストアにはフランス語の見出しと英語のエラーメッセージが混在して表示されます。

テーマとプラグインの文字列も翻訳する必要がある

WordPressテーマには独自の.potファイルがあります。WooCommerceには独自のファイルがあります。インストールするすべてのプラグイン（決済ゲートウェイ、配送計算ツール、フォームビルダー）には、翻訳可能な文字列があります。これらはShopifyストアには存在しませんでした。

最も迅速なアプローチは、文字列ごとに翻訳するのではなく、これらの大きな.poファイルを一括で翻訳することです。テーマの.potファイルをアップロードし、ターゲット言語を選択して、AIに重労働を任せます。

大量のWooCommerceファイルを一括翻訳する

WooCommerceの言語ファイルは巨大です。カートメッセージから税金のエラーコードまで、すべてを網羅する何千もの文字列を使用すると、これは移行における単一の最大の翻訳タスクになります。SimplePoTranslateは、スマートバッチ処理を通じてこれを処理します。特大のファイルを安全なチャンクに分割し、並行して処理し、結果を1つのクリーンなファイルにマージします。

重要な詳細：翻訳されたファイルは、ソースに表示されるすべてのコード変数を正確に保持する必要があります。WooCommerceのメールテンプレートの%sプレースホルダーは、翻訳中にスペースを追加したり、位置を入れ替えたりすることはできません。これは、構文ロックが壊れた変数が本番ストアに到達するのを防ぐ場所です。

SimplePoTranslateのマルチフォーマット出力を使用すると、.po、.mo、.json、.php、.xliffファイルを1つのZIPダウンロードで入手できます。これは、WordPressスタックのさまざまな部分が異なる形式で翻訳を使用する可能性がある移行中に特に役立ちます。テーマは.moファイルを読み取ります。ヘッドレスフロントエンドには.jsonが必要な場合があります。カスタム統合では.xliffが期待される場合があります。1回の翻訳ですべてをカバーします。

3つの最も一般的な移行翻訳の失敗を回避する

適切なワークフローを使用しても、プラットフォームの移行に特有の落とし穴があり、経験豊富な開発者でさえ油断させられます。

トランザクションメールの壊れた変数

WooCommerceのトランザクションメールは、プレースホルダー（{order_number}、{customer_name}、%1$s、%2$s）で埋め尽くされています。翻訳プロセスでこれらのいずれかが破損した場合、顧客は「こんにちは{customer_name}」のようなメールを文字通り受信したり、さらに悪いことに、データが入れ替えられたメールを受信したりします。

デプロイする前に、翻訳されたファイルをソースの.potファイルに対して常に検証してください。Poeditなどのツールはプレースホルダーの不一致を検出し、構文ロックを備えたクラウドベースの翻訳者は、このクラスのエラーを完全に排除します。

不足している複数形ルール

Shopifyは複数形を簡単に処理します。WordPress Gettextは、言語によって異なる複雑な複数形をサポートしています。ロシア語には3つの複数形があります。アラビア語には6つあります。翻訳された.poファイルに正しいPlural-Formsヘッダーと一致するmsgstr[0]、msgstr[1]、msgstr[2]エントリが含まれていない場合、WordPressは翻訳されていない文字列にフォールバックします。

# Correct Russian plural forms header
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : "
"n%10>=2 && n%10<=4 && (n%100<12 || n%100>14) ? 1 : 2);\n"

msgid "%s item"
msgid_plural "%s items"
msgstr[0] "%s товар"
msgstr[1] "%s товара"
msgstr[2] "%s товаров"

これは、Shopifyがあなたに考えさせる必要がなかったことです。WordPressでは、重要です。

プラグインの交換後に孤立した文字列

Shopifyから移行する場合、プラットフォームを変更するだけではありません。プラグインエコシステム全体を置き換えることになります。Shopifyの決済ゲートウェイは、WooCommerce PaymentsまたはStripe for WooCommerceになります。レビューシステムはWordPressプラグインになります。各交換は、新しい翻訳可能な文字列を導入し、古い翻訳を時代遅れにします。

移行後にインストールするすべてのプラグインのチェックリストを作成し、それぞれに/wp-content/languages/plugins/に対応する翻訳された.moファイルがあることを確認します。1つのプラグインが見つからないだけでも、顧客は翻訳されたインターフェイスの途中で英語の文字列を見ることになります。

WordPressで多言語ストアを立ち上げる

多言語WordPress移行は、単なるデータ転送ではありません。ストアが国際的な顧客とどのようにコミュニケーションを取るかの再構築です。これを正しく理解しているストアは、英語以外の市場でコンバージョン率が高くなっています。これは、エクスペリエンスがパッチを当て合わせたものではなく、ネイティブに感じられるためです。

ワークフローは簡単です：Shopifyの翻訳をエクスポートし、WordPressロケールコードにマッピングし、.po形式に変換し、バッチAI翻訳でギャップを埋め、変数を検証し、静的な.moファイルをデプロイします。データベースの肥大化はありません。ランタイム翻訳のオーバーヘッドはありません。高速で信頼性の高い多言語コマースです。

何千もの翻訳されていないWooCommerce文字列での移行に直面している場合、SimplePoTranslateの大規模ファイルローカリゼーションへのアプローチは、手作業の数週間を節約できます。

移行後にWooCommerceストアを翻訳する準備はできましたか？ SimplePoTranslateを無料でお試しください - クレジットカードは不要です。.potファイルをアップロードして、数分で本番環境に対応できる翻訳を入手してください。