WPGraphQLを使用した多言語コンテンツのクエリ方法 – 言語フィルタリングと翻訳

始める前に

以下のプラグインをインストールして有効化します。

• WPGraphQL（WPGraphQLプロジェクトのオープンソースプラグイン）
• WPMLおよびWPML 文字列翻訳
• WPML GraphQL（このページで解説するアドオン）

Advanced Custom Fieldsも使用する場合：

• Advanced Custom Fields Multilingual（ACFML）
• WPGraphQL for Advanced Custom Fields（WPGraphQLプロジェクト提供）

以下のクエリで結果を返すには、事前にソースコンテンツをWPMLで翻訳しておく必要があります。すべてを自動翻訳するをオンにする（WPML 5のデフォルト）と、コンテンツの公開時にバックグラウンドで翻訳が作成されます。手動で設定する場合は、WPML → 翻訳 → ダッシュボードからコンテンツを翻訳に送信します。以下のGraphQLクエリは、これらの翻訳された投稿やタームをフィルタリングして返します。

GraphQL IDE – クエリのテスト場所

WPGraphQLはWordPress管理画面にGraphQL → GraphQL IDE画面を追加します。IDEのQuery Composerには、WPMLのlanguage引数やtranslationsフィールドを含む利用可能なすべてのフィールドがリストされ、ライブサイトに対してクエリを実行できます。フロントエンドフレームワークに組み込む前に、ここでクエリをテストしてください。

言語ごとのコンテンツのクエリ

投稿、カスタム投稿タイプ、タクソノミーターム、メニュー、メニュー項目、コメントなどの任意のリストクエリにwhere: { language: "<code>" }を追加します。言語コードはWPMLが各所で使用しているコードと同じです（en、es、fr、pt-ptなど）。language: "all"を渡すと、すべての言語のコンテンツを一度に返します。

query PostsES {
  posts(where: { language: "es" }) {
    nodes {
      slug
      uri
      categories {
        nodes { name }
      }
    }
  }
}

トップレベルのノードが言語でフィルタリングされると、接続された項目（カテゴリー、タグ、カスタムタクソノミー）も自動的に同じ言語に従います。上記のクエリは、追加の引数を必要とせずに、スペイン語の投稿とスペイン語のカテゴリーを返します。

1つのクエリでのノードの全翻訳の取得

任意の投稿またはタクソノミークエリにtranslationsフィールドを追加すると、同じペイロードでノードの他言語バージョンを返します。

query PostsWithTranslations {
  posts(where: { language: "en" }) {
    nodes {
      slug
      uri
      language { code }
      translations {
        slug
        uri
        language { code }
      }
    }
  }
}

各投稿は、英語のフィールドに加えて、他言語のスラッグとURIの配列とともに返されます。これは、ページコンテンツの横にレンダリングされる言語スイッチャーが使用する形式です。1回のリクエストで、訪問者が切り替え可能なすべての選択肢を取得できます。

任意の言語でのIDまたはスラッグによる特定の投稿のクエリ

翻訳された単一の投稿を直接（翻訳されたスラッグまたはデータベースIDによって）取得するには、単数形のpostクエリにidTypeを使用します。

query PostBySlug {
  post(id: "hola-mundo", idType: SLUG) {
    title
    slug
    uri
    language { code }
  }
}

query PostById {
  post(id: "2", idType: DATABASE_ID) {
    title
    slug
    uri
    language { code }
  }
}

どちらのクエリも、フロントエンドでの追加のフィルタリングなしで、翻訳された投稿（タイトル、スラッグ、URI）を返します。

多言語メニュー

同じlanguage引数を使用して、言語ごとにメニューとメニュー項目をクエリします。

query NavES {
  menu(language: "es", id: "primary", idType: SLUG) {
    menuItems {
      nodes {
        label
        url
        path
      }
    }
  }
}

各メニュー項目のlabelとurlは、クエリされた言語で返されます。翻訳された投稿にリンクするメニュー項目は、自動的に翻訳されたURIに解決されます。このサポートはWPML GraphQL 1.1.0で追加されました。

インストール済み言語 – 言語スイッチャー用

グローバルな言語スイッチャー（単一の投稿に依存しない）の場合は、languagesおよびdefaultLanguageクエリを使用して、サイト上のすべての言語をリストします。

query SiteLanguages {
  languages {
    code
    country_flag_url
    default_locale
    native_name
    translated_name
    url
  }
  defaultLanguage {
    code
    native_name
  }
}

アクティブな言語ごとに、国旗のURL、ネイティブ名、翻訳された名前、およびその言語のホームURLを含む1つのノードを返します。これは、言語リストをハードコーディングすることなく、国旗とラベルのスイッチャーをレンダリングするのに十分なデータです。

言語ごとのACFカスタムフィールドのクエリ

ACFMLとWPGraphQL for ACFが有効な場合、投稿やカスタム投稿タイプのACFフィールドは自動的にホスト投稿の言語に従います。追加の引数は必要ありません。単一の投稿に結び付いていないACF Options Pagesの場合は、Options Pageのクエリにlanguage引数を追加します。

query Settings {
  myOptionPage(language: "de") {
    addressFieldGroup {
      addressTitle
      repeaterAddressDetails { addressDetails }
    }
  }
}

この引数には、サイトのアクティブな言語のいずれかに一致する言語コードを指定します。

既知の制限事項と回避策

• 作成者とユーザーのメタデータは翻訳された値を返しません。言語ごとに作成者のプロフィールを表示する場合は、翻訳されたプロフィールをユーザーのACFフィールドに保存し、代わりにそのフィールドをクエリします。
• 一部のクエリ形式における翻訳されたURI。URI（contentNode(id: "/de/some-slug/", idType: URI)）で翻訳された投稿を取得する場合、返されたURIがその言語で公開されているものと一致するかどうかを確認してください。一部のクエリ形式では一貫性のないパスが返されることがあります。ルーティングに組み込む前に、GraphQL IDEでテストしてください。
• language引数のないACF Options Pagesはデフォルト言語にフォールバックします。多言語サイトでのOptions Pageのクエリには、常にlanguageを渡してください。

ここに記載されていない統合の問題が発生した場合は、WPMLサポートチームがWPGraphQLスタックのWPML側を24時間年中無休でサポートします。