Shopify AI商品翻訳ワークフローのリサーチ

必要な翻訳経路を選ぶ

編集者が直接翻訳を管理できる場合は、Shopifyのマーチャントツールを使います。再現可能な外部レビューキューが必要で、開発者がアプリケーションを保守できる場合は、GraphQL Admin APIを使います。API経路では、別のモデルクライアントがテキストをドラフトし、保存された翻訳はShopifyが扱います。

開発ストアと一つの商品から始めます。翻訳可能なフィールドを読み、候補を準備し、レビューを得てから意図した変更だけを送信します。モデル設定、ストア認証情報、公開権限を分け、各手順を独立に検査して修正できるようにします。

マーチャントワークフローとアプリケーションを比較する

ShopifyのTranslate & Adaptドキュメントには、手動編集と自動翻訳、および公開前のレビューが説明されています。アプリケーションを構築せず、マーチャントが直接編集を管理したい場合は、これで十分かもしれません。カスタム統合は、外部レビューキューなど特定の要件がコネクターを所有する理由になる場合にだけ適しています。

レビューキューとフィールドマッピングを誰が保守するかに応じて選びます。サードパーティーアプリでは、インストール前に文書化された設定、権限、エクスポート動作を確認します。マーチャント向けエディターと外部モデルによるドラフトを備えたアプリケーションは、異なる運用上のニーズを解決します。

認証とバージョンの境界を計画する

translatableResourceリファレンスにはread_translationsが、translationsRegisterにはwrite_translationsが必要です。開発ストアを使ってテストし、アプリのインストール、APIバージョン、付与されたスコープを記録します。LLMゲートウェイの認証情報でShopify Admin APIリクエストを認証することはできず、Shopifyトークンをモデルエンドポイントへ送ってはいけません。

アプリケーション設計で許されるなら、まず検出用の読み取りアクセスから始めます。後の承認済みワークフローに必要な権限だけを追加します。記録されていないlatestエイリアスに対してデプロイせず、リファレンスを確認した後で対応するAPIバージョンを固定します。トークンはサーバー側に保ち、レビューのエクスポートとリクエストログから除外します。

ダイジェスト付きで翻訳可能フィールドを読む

文書化されたクエリは、リソース識別子と、key、value、digest、localeを持つ翻訳可能なエントリを返します。これらのフィールド固有のダイジェストをソーススナップショットとともに保持します。スプレッドシートからコピーした商品タイトルではなく、実際に読み取ったコンテンツへ翻訳案を結び付けられます。

以下のクエリは公式スキーマから適応した読み取り専用の例です。開発環境で承認済みの商品GIDを渡します。返されたキーを検査し、明示的なフィールド許可リストを使います。ブラウザの言語から推測せず、返されたソースロケールを使ってください。

query TranslationSource($resourceId: ID!) {
  translatableResource(resourceId: $resourceId) {
    resourceId
    translatableContent {
      key
      value
      digest
      locale
    }
  }
}

Shopifyの外で翻訳候補を生成する

リソースID、フィールドキー、ソースダイジェスト、対象ロケール、用語集リビジョン、ドラフト値を含む内部候補記録を作ります。モデルにはテキストと必要な商品コンテキストだけを送ります。SKU、価格、通貨、在庫、バリエーション識別子は生成パッチから外します。

バイリンガルレビュアーに候補を見せる前に、必須テキスト、プレースホルダー、承認済み用語を検証します。商品レビュアーには、元のソースに照らして主張と警告を確認してもらいます。ストアフロントを翻訳するブラウザ拡張機能は、この記録を作らず、Shopifyが翻訳を保存したことも確定しません。検査の補助にすぎません。

承認済みで最新の翻訳だけを登録する

translationsRegisterミューテーションは、translatableContentDigestを持つ翻訳フィールドを受け付けます。文書化された結果にはuserErrorsが含まれます。コネクターは、HTTPレスポンスだけを成功の証拠とせず、その結果を検査しなければなりません。

承認済みの書き込み前に、現在のソースとレビュー済みスナップショットを比較します。変わっていたら候補を保留し、新しいレビューを得ます。意図したフィールド変更と、復旧のための以前の翻訳を明示的な一覧で保持します。開発ストアでは一つのフィールドから始め、パッチを広げる前に読み戻します。

ストアフロントを別に検証する

Shopifyの文書化されたワークフローでは、保存された翻訳とストアフロントでの利用可能性は別のチェックポイントです。マーチャントとロケール設定およびテーマチェックを計画します。翻訳値を保存しただけで、言語を公開したり市場設定を変えたりする権限が自動的に与えられるわけではありません。

開発ストアで対象商品、ロケールセレクター、フォールバックコンテンツ、リンク、バリエーションラベルを確認します。保存された翻訳を読み戻し、承認済みの値と比較します。フィールドがない場合は、別の翻訳を生成する前にリソース対応またはテーマ描画を調べます。ライブのマーチャント成功として提示せず、観測結果を保持してください。

証拠とコネクターの限界

公式リファレンスはShopifyの翻訳インターフェースを確立しています。APIsRouterに接続したアプリケーションはここではテストしておらず、レビューしたソースはShopifyやTranslate & Adaptで任意のゲートウェイbaseURL設定が使えることを確立していません。カスタムアプリケーション経路は、開発ストアの結果が得られるまでコネクターリサーチとして扱います。

完全なテストでは、アプリケーションバージョン、範囲を限定した認証記録、ソースクエリ、候補、承認、登録結果、読み戻し比較を保持します。ソース変更の競合と拒否されたリクエストを含めます。モデル識別情報と使用量をストア操作から分け、互換性の主張に明確な範囲を持たせます。

よくある質問