Gatsby: Gatsbyでウェブサイトを国際化するための公式ガイドを追加する

GatsbyJSでi18nextを使用する方法についてのこの記事があります。これは、私にとってこれまでで最も高度な方法です。

しかし、i18nextが「静的な方法」であるとは思えません。

ブログ投稿について、私はこれらの質問/予約をしました：
https://twitter.com/semdubois/status/930389055388508160

https://github.com/angeloocana/gatsby-plugin-i18nがあり

私もjslinguiに出くわしましたが、特にv2がリリースされたばかりの場合は有望なようです。

私もこれを理解しようとしています。 投稿でi18nextメソッドを使用するのが最も便利で直感的ですが、2つの質問が残っています。

1. gatsby-plugin-i18nソリューションのように、言語用に異なるマークダウンファイルを組み込むにはどうすればよいですか？

2. これは、コンテンツの静的レンダリングを完全に放棄しますか？

参考までに@angeloocana

react-intlを使用して、現時点でどのように処理するかについて簡単に説明します。 このアプリはまだ本番環境にないため、この設定で問題が発生する可能性がありますが、これまでのところ正常に動作しているようです。

ほとんどすべてのコンテンツ（Wordpressブログから移行されたもの）をContentfulに保持しています。 その翻訳機能は使用しませんが、代わりに言語ごとに1つのスペース（プロジェクトまたはフォルダーの種類）を取得しました。 このデータをフェッチするためにgatsby-source-contentfulプラグインを使用していますが、以前はこのデータを自分でフェッチしてJSONファイルに変換し、 gatsby-source-filesystemプラグインを使用していました（ /en/blog/...ようなフォルダー構造を使用し/de/blog/... ）、したがって、各ノードがそのロケールを知っている限り、Contentfulを使用しているかどうかは実際には問題ではありません。

また、ボタンラベル、一部のリンク、Co​​ntentfulからのものではない静的コンテンツなどのテキストもありますが、代わりにTransifexで翻訳され、リポジトリに保存されているJSONファイルに同期されます。 この部分では、i18nライブラリを使用する必要があり、 react-intlを使用することにしました。これは、すでに知っていて、日付と数値の書式設定も処理できることを知っているからです。 設定方法は次のとおりです： https ：//github.com/gatsbyjs/gatsby/issues/3830#issuecomment-362710469。 次に、テンプレートでメタタグや<FormattedMessage /> 、 <FormattedDate />などのコンポーネントを生成するときにintl.formatMessage <FormattedDate />などを使用します。

@szimek私があなたを正しく理解しているなら、あなたはreact-intlにコンポーネントのテキスト翻訳を処理させ、投稿はページディレクトリの下のハードコードされたルートにありますか？

つまり、静的にレンダリングされるのはハードコードされたルートだけですか？ そして、i18nコンポーネント間変換は動的にレンダリングされますか？

@deltaskeltaあなたの質問を理解できるかわかりません。

現在、カスタムのクライアント側ルーティング（たとえばここで説明）はなく、静的に生成されたページのみがあります。 postページを生成する場合（ロケール固有のページ付けされたindexページとcategoryページも、わずかに変更されたバージョンのgatsby-paginationプラグインを使用して生成します）次のコードを使用します。

posts.edges.map(({ node }) => {
  const id = node.contentfulid;
  const locale = node.node_locale;

  return createPage({
    path: `/${locale}/blog/posts/${id}`,
    layout: locale,
    component: path.resolve('./src/templates/post-page.jsx'),
    context: {
      id,
      locale,
    },
  });
});

JSを無効にしている場合でも、メタタグを含むすべてのコンテンツは正しい言語でレンダリングされます。

私たちの側では、いくつかの調整を加えたi18nextしています

主な原則は次のとおりです。

• ロケールは.jsonファイルとして利用可能であり、ビルド中に/dist/ディレクトリに移動するだけです。
• onCreatePage （ gatsby-node.js ）を使用して、言語と同じ数の静的バージョンを生成する1つのページに取り組んでいます。
• ページ情報（パス名など）は単一のファイルに一元化されます。

ロケール

翻訳は主にページごとにグループ化されており、ページごとに1つの名前空間（= JSONファイル）+ 1つのグローバルファイル（ヘッダー/フッターなどの共有テキスト用）があります。

|- src/
  |- locales/
    |- en/
      |- foo.json
      |- bar.json
    |- fr/
      |- foo.json
      |- bar.json

残念ながら、ロケールの変更にはホットリロードはありません👎

i18next

i18nextは、次の構成で初期化されます。

import i18n from "i18next";
import Backend from "i18next-xhr-backend";
import { reactI18nextModule } from "react-i18next";
import config from "config";  // Our custom configurations env-specifics

const NAMESPACES = [
  "foo",
  "bar",
  ...
];

export default function createI18n() {
  const options = {
    fallbackLng   : false,
    whitelist     : ["en", "fr"],
    ns            : NAMESPACES,
    debug         : config.debug,
    interpolation : {
      escapeValue : false
    },
    react         : {
      wait : true
    },
    backend       : {
      loadPath : `${config.pathPrefix}locales/{{lng}}/{{ns}}.json`
    },
    parseMissingKeyHandler : () => "",  // Display an empty string when missing/loading key
  };

  return i18n
    .use(Backend)
    .use(reactI18nextModule)
    .init(options);
}

ページ情報

ページのすべてのi18nバージョンを生成する前に、 pagesInfos.jsファイルにグループ化したいくつかの情報を知る必要があります。

module.exports = {
  index : {
    id          : "index",
    namespace   : "home",
    path        : {
      fr : "/",
      en : "/en/"
    }
  },
  projects : {
    id          : "projects",
    namespace   : "projects",
    path        : {
      fr : "/nos-clients/",
      en : "/en/our-clients/"
    }
  },
  // etc...

ここで、キーはページのファイル名であり、名前空間はロケールのファイル名です。 それらは異なる可能性があります🚨

この場合：

|- src/
  |- pages/
    |- index.js
    |- projects.js
  |- locales/
    |- en/
      |- home.json
      |- projects.json
    |- fr/
      |- home.json
      |- projects.json

また、pathは、ページの将来のバージョン（言語）のパス名です。

ページを作成する

上記と同じ例で、ここでの目標は、ホームページとプロジェクトページのFR + ENバージョンを作成することです。

それを実現するために、専用の関数を作成しました。

/**
 * Generate a custom page informations
 * <strong i="15">@param</strong>  {Object} defaultInfos  Default informations generated by Gatsby
 * <strong i="16">@return</strong> {Object}               Customized page object
 */
function generatePagesInfos(defaultInfos) {
  const pageId = defaultInfos.jsonName.slice(0, -5);  // NOTE: Get pageId from "pageName.json"
  const pageInfos = pagesInfos[pageId];

  const pageFR = {
    ...defaultInfos,
    context : {
      pageId      : pageInfos.id,
      namespace   : pageInfos.namespace,
      language    : "fr"
    },
    path : pageInfos.path.fr
  };

  const pageEN = {
    ...defaultInfos,
    context : {
      pageId      : pageInfos.id,
      namespace   : pageInfos.namespace,
      language    : "en"
    },
    path : pageInfos.path.en
  };

  return [pageFR, pageEN];
}

このヘルパーは、 onCreatePageフック中に使用され、正規表現を介して各ページを選択します。

exports.onCreatePage = async ({ page, boundActionCreators }) => {
  const { createPage, deletePage } = boundActionCreators;

  return new Promise((resolve, reject) => {

    if (page.path.match(page.path.match(/^\/$/))) {
      const i18nPages = generatePagesInfos(page);
      deletePage(page);                         // Remove old default page
      i18nPages.map(page => createPage(page));  // Create custom i18n pages
    }

    if (page.path.match(/^\/projects\/?$/)) {
      const i18nPages = generatePagesInfos(page);
      deletePage(page);
      i18nPages.map(page => createPage(page));
    }

    // etc...

    resolve();
  });
}

これで、各ページに2つのバージョンがあり、カスタムパス名（ページ情報ファイルから）があります。 pathContext介して各ページにlanguage情報を渡していることに気付くかもしれません。 この値は、適切な言語を表示するために各ページで使用されます。

適切な言語を表示する

ページにReactクラスを使用しています。次のデコレータは、現在のページの言語を自動的に認識し、必要に応じてi18nを更新します。

import React from "react";
import PropTypes from "prop-types";
import { i18n } from "context";    // Our custom context

/**
 * <strong i="10">@returns</strong> {React.PureComponent} Component with locales as proptypes
 */
export default function setLanguageFromPage() {

  return WrappedComponent => (
    class extends React.PureComponent {

      static propTypes = {
        pathContext : PropTypes.shape({
          language : PropTypes.string.isRequired
        })
      }

      componentDidMount() {
        const currentLanguage = i18n.language;
        const pageLanguage = this.props.pathContext.language;

        // First request
        if (!currentLanguage) {
          i18n.language = pageLanguage;
        }

        // Only update on language change
        if (currentLanguage !== pageLanguage) {
          i18n.changeLanguage(pageLanguage);
        }
      }

      render() {
        return <WrappedComponent {...this.props} />;
      }

    }
  );

}

次に、ページでそれを呼び出します。

@setLanguageFromPage()
export default class ProjectsPage extends React.PureComponent {
// ...

ちなみに、今やらなければならないのは、i18nextの変換機能を使用することだけです。

結論

👍ビルド中に必要な数のバージョンを生成する単一のソースファイル
👍簡単なページ出力管理
👍最初はいくつかの努力が必要ですが、その後はすべてが簡単です

👎ロケールのホットリロードはありません

それは本当に「静的な生き方」ではないように感じます...しかし、それは私たちが今のところ得ることができた最高のものです。

私はあなたがこれについてどう思うか、そしてあなたたちがこれをどのように管理するかを見たいと思います。

PS。 @szimekを突く、それは私が数日前にこれをあなたに見せたかったものです:)

私は@angeloocanaのhttps://github.com/angeloocana/gatsby-plugin-i18n+ React-intlを使用しており、上記の方法ほど複雑ではありませんが、いくつかの制限があり（リポジトリの問題を参照）、私はReact-intlについてはあまり満足していません。 @ tricoder42のhttps://github.com/lingui/js-linguiを試してみたいと思い

@monsieurnebo createPage直前にdeletePageを実行する目的は何ですか？ 私はあなたの解決策が好きで、それを実装しようとしましたが、いくつかのエラーがあります。

• 私はどちらかの取得、誤ったpathContext.language使用せずにdeletePage

• または、例のようにdeletePageを含めると、ビルドエラーが発生します。 （それは言うTypeError: Cannot read property 'id' of undefinedビルドはに到達したときにrun graphql queries段階）

これは私がこれまでに見た中で最高の解決策です。

@deltaskeltaよろしくお願いします！

deletePageは、Gatsbyによるデフォルトページの作成をキャンセルするために使用されます。 これを追加しない場合は、カスタムページとデフォルトのページを取得します。

この行がある場合とない場合のpublicディレクトリを確認すると、違いがわかります;）

エラーについては、コードなしで推測するのは困難です。 コードを使用してリポジトリを作成できますか？ それでは見てみます。

編集：例に興味が

ああ、それはdeletePage呼び出しとは無関係でした。 例を変更したので、pagesオブジェクトをコピーしないという問題でした。 しばらくjsから離れた後、私はいつもオブジェクトのコピーにつまずきます;）

@monsieurnebo私はあなたのソリューションで遊んでいますが、jsonファイルからロケールをロードするにはまだjavascriptが必要なようですそれは正しいですか？ その上、 react-i18next HOCでラップされているすべてのコンポーネントは、コンポーネント内の何かをレンダリングするためにjavascriptが必要なようです...

これがあなたの側でどのように機能しているかを確認できますか？

編集：ところで、私はあなたの例の言及を逃しました、もしあなたが時間があれば私は完全な例を見たいです。

@deltaskelta空き時間があるときに例を挙げます:)

@monsieurneboメソッドが文字列を静的にhtmlにレンダリングせず、javascriptが必要であることを確認できますか？

うん、それが完全に「静的な生き方」ではない理由です😐

代わりに静的テキストを生成するプラグインが欲しいです。

うーん、なるほど。 静的レンダリングは私が行く必要がある方法です...

gatsby-nodeほとんどのページの言語名でコンテキストが既に渡されているので、各ページのgraphqlクエリでメッセージキーを要求するのはそれほど難しくないと思いました。そしてそれらをそのように渡しますが、可能であれば私はむしろi18nツールをずっと使用したいと思います...

@szimek react-intlは、ビルドステップで翻訳をレンダリングし、jsを使用しないのはどうですか？

前述のように、私が見る限り、Gatsby-plugin-i18nは静的テキストを生成します。 その例を確認しましたか？

@deltaskeltaええと、すべての翻訳はビルド時に利用できるので（それが私が複数のレイアウトを使用している理由です）、それは「うまくいく」™️;）v2でも機能し続けることを願っています...欲しいです。 私はファイルではなくContentfulを扱っているので、まだgatsby-plugin-i18nを調べていません。

詳細は読んでいませんが、gatsby-plugin-i18n +コンテンツのあるコンボについてのディスカッション（またはモノローグ）があります： https ：

@szimek例に非常に興味があります。 @sedubois gatsby-plugin-i18nも静的テキストを生成することは知っていますが、完全に静的なファイルを生成するためにi18nextにない魔法がどこで発生するかわかりません。

なぜ今なのかわかるかもしれません...レンダリング中にgatsby-node pathContextを介してreact-intlメッセージを渡していますか？

編集：これが事実である場合（これは理にかなっています）、使用されるi18nライブラリは「ある程度」無関係です。これは、コンテキストを介してメッセージを渡し、静的にレンダリングするためです。これは純粋なgatsbyセットアップであり、i18nlibは次のような特殊なケースのみを処理します。 jsを使用した日付と複数形。

両方の更なる試験の際にi18nextとreact-intlの翻訳HOCようだi18next 、メッセージがコンテキストを経由して渡され、静的にレンダリングされていてもそう、ロードするためにはJavaScriptが必要ですtranslate HOCを使用すると、実行するためにjavascriptを必要とするコンポーネント全体がレンダリングされます。

react-intlのFormattedMessageコンポーネントは、デフォルトのメッセージ（渡されたコンテキストに基づくことができます）をレンダリングし、ビルド時に静的にhtmlにレンダリングします。

設計上、HTMLで静的にレンダリングされた翻訳を実現したい場合は、i18nとreact-intlをより自然に統合できると思います。 あなたたちが使っている流れを私が誤解しているなら、私を訂正してください

@mattferdererはここで正しい考えを持っていましたが、少し調整する必要があると思います。 https://github.com/gatsbyjs/gatsby/issues/3830#issuecomment -362715706

レイアウトはページの前にレンダリングされるため、複数のレイアウトを作成しないと、 createPages関数からコンテキストを介してメッセージを渡す方法はありません（ここで間違っている場合は修正してください）。 したがって、i18nを最も簡単にするために、レイアウトはchildren()を呼び出すだけでよく、 gatsby-node言語ごとに異なるパスを作成させることで、言語ごとに異なるレイアウトを実現できると思います。コンテキストを介してメッセージを渡すことができるpages/indexインデックスページ

編集：ランブルして申し訳ありませんが、それはすべて明らかになり、どこかに記録する必要がありました

EDIT2：私は間違いなく上記で間違っています、ヘッダーとフッターはレイアウトに入れる必要があります、私は複数のレイアウトを作成せずにそれらにメッセージを取得する方法がわかりません。 私が考えることができる他の唯一の方法は、URLを分割し、ロケールを再確認することです...しかし、それはやっかいなことのように感じます

レイアウトが1つしかないv2の@KyleAMathewsでは、パスまたは言語キーの配列に基づくコンテキストを介して、i18nメッセージなどのデータをルートレイアウトコンポーネントに渡すにはどうすればよいですか？

これができれば、i18​​nの実装は簡単ですが、複数のレイアウトを作成せずに実装する方法がわかりません。

@deltaskeltaこれが私たちが行っていることの例です： https ： react-intlコンポーネントを使用する方法、 react-intl injectIntl HOCを使用してタイトルを設定する方法（またはintl.formatMessageヘルパーなどを使用するインデックスページ用のその他のメタタグ）。

生成されるページは次のとおりです。

• /en
• /en/hello-world
• /pl
• /pl/witaj-swiecie

実際のアプリでは、元のバージョンがレイアウトオプションをサポートしていないため、 gatsby-pagination変更バージョンを使用しています。 また、各投稿にpost_idフィールドを設定して、同じ投稿の翻訳を検索できるようにします。たとえば、このデモアプリの場合、両方の投稿のpost_idは同じになります。

ところで。 Swiftype（使用する検索エンジン）が取得したページを認識できるように、言語ごとに個別のサイトマップを生成する必要がある可能性が高いことに気づきました。

@deltaskelta簡単に言うと、言語ごとにページコンポーネントがあり、次に言語ごとにレイアウトコンポーネントがあります。 これを行う1つの方法があります。

// French
import React from 'react'
import FrenchLayout from '../components/layouts/french'
import ImportantPage from '../components/pages/important-page'

export default ({ data }) => (
  <FrenchLayout>
    <ImportantPage {...data} />
  </FrenchLayout>
)

// French query here

// English
import React from 'react'
import EnglishLayout from '../components/layouts/english'
import ImportantPage from '../components/pages/important-page'

export default ({ data }) => (
  <EnglishLayout>
    <ImportantPage {...data} />
  </EnglishLayout>
)

// English query here

@KyleAMathewsこれらのファイルはテンプレートですよね？ 3つのページタイプと7つの言語がある場合、21のテンプレートが必要になるということですか？ :)

上記はそれを行うための最も最適化された方法です。 各レイアウトコンポーネントにそれほど違いがない場合は、それらを1つのレイアウトコンポーネントに組み合わせて、アクティブな言語に応じてレイアウトを切り替えることができます。

詳細は読んでいませんが、gatsby-plugin-i18n +満足のいくコンボについての議論（または独白）があります：angeloocana / gatsby-plugin-i18n＃31

@sedubois 、はい。 概要：動作させ、このPRを介してGatsbyドキュメントにgatsby-starter-contentful-i18nスターターリポジトリを含めました： https ：

上記の他のソリューション、特にコミュニティプラグインre：SEOなどとの比較に興味があります。

@mccrodpあなたのソリューションは私のものと非常によく似ています。主な違いは、 gatsby-plugin-i18nではlayoutオプションをcreatePageに明示的に渡す必要がないことですが、それはあなたに代わって行われます。舞台裏。 ただし、それでも複数のレイアウトを使用しています;）

@KyleAMathewsの提案にi18nlibを使用するcomponents/Layoutを作成し、gatsbyレイアウトフォルダーを完全に削除しました。 このようにして、 gatsby-nodeで自分のロケールのページを作成でき、パスを含め、ページがアクセスできるすべてのものにアクセスできます。

次に、ロケールをレイアウトコンポーネントに直接渡すことができます。レイアウトコンポーネントは、ロケールをi18nに渡します。

各ページレベルのコンポーネントをレイアウトでラップする必要があるのは少し不便ですが、それによって多くの混乱が解消され、コードが大幅に簡素化されました。

ねえ@deltaskelta 、あなたはあなたの解決策の例を持っていますか？ コミュニティi18nプラグインにアップストリームをプッシュするために、そこから何かを学ぶことができるかどうかを確認したいと思います。 ありがとう。

私のプロジェクト全体は現在乱雑な状態ですが、基本をレイアウトできると思います...

1. レイアウトなし-（私が正しく覚えていれば）レイアウトはパスや非常に重要な何かの前に機能し、適切なメッセージオブジェクトを与えることができなかったためです...

2. コンテキストを介してgatsby-nodeの適切なmessagesとlocaleをフィードします...

exports.onCreatePage = ({ page, boundActionCreators }) => {
  const { createPage, deletePage } = boundActionCreators;

  if (page.path.includes('404')) {
    return; // no need for localized 404 pages
  }

  return new Promise(resolve => {
    // if it is not the app page then I need localized static pages
    const pages = localizedPages(page);
    deletePage(page);
    pages.map(page => createPage(page));

    resolve();
  });
};

// to be passed to the localized pages so it can calculate the matchPath
const getMatchPath = lang => {
  return `${locales[lang]['path']}/app/:path`;
};

// this is a helper function that makes pages in each language.
const localizedPages = (page, matchPathFunc) => {
  var pages = [];
  Object.keys(locales).map(lang => {
    const path = locales[lang]['path'] + page.path;

    pages.push({
      ...page,
      path: path,
      matchPath: matchPathFunc ? matchPathFunc(lang) : undefined,
      context: {
        locale: lang,
        messages: locales[lang],
        pathRegex: `/.pages${page.path}./` // so pages can match markdown in their dir
      }
    });
  });

  return pages;
};

1. 次に、すべてのページレベルコンポーネントで呼び出す必要のあるグローバルレイアウトコンポーネントを作成します...

// this is the main entrypoint for the layout to the site
const GlobalLayout = ({ locale, children, path }) => {
  const theme = getTheme();
  return (
    <MuiThemeProvider theme={theme}>
      <CssBaseline>
        <IntlProvider locale={locale} messages={locales[locale]}>
          <div>
            <Header locale={locale} messages={locales[locale]} path={path} />
            {children}
          </div>
        </IntlProvider>
      </CssBaseline>
    </MuiThemeProvider>
  );
};

1. 適切なロケールとコンテキストから渡されたメッセージを持つページレベルのコンポーネントを使用して、グローバルレイアウトコンポーネントを呼び出します

const BlogPost = ({ data, pathContext, location }) => {
  const { locale } = pathContext;
  return (
    <GlobalLayout locale={locale} path={location.pathname}>
      <FullWidth>
        <h1>{data.markdownRemark.frontmatter.title}</h1>
        <h3>{data.markdownRemark.frontmatter.date}</h3>
        <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} />
      </FullWidth>
    </GlobalLayout>
  );
};

このコードをクリーンアップして再編成する必要があります。これは、コードが機能することを証明するためにすばやく実行したため、後で再検討する予定です...これで要点がわかるといいのですが。

js-linguiを使用してメッセージを翻訳するgatsbyスターターを作成しました。
https://github.com/dcroitoru/gatsby-starter-i18n-lingui

実際のアプリでは、元のバージョンがレイアウトオプションをサポートしていないため、gatsby-paginationの修正バージョンを使用しています。 また、各投稿にpost_idフィールドを設定して、同じ投稿の翻訳を検索できるようにします。たとえば、このデモアプリの場合、両方の投稿のpost_idは同じになります。

@szimek変更したgatsby-paginationを共有できる可能性はありますか？ 私自身も同様の問題を抱えているので、私はそれを見たいと思っています。

@martynhoyerパッチがマージされたので、 gatsby-paginationの元のバージョンに戻しました。 どんな問題がありますか？

こんにちは@sgoudie
このチュートリアルを使用しています： //www.gatsbyjs.org/blog/2017-10-17-building-i18n-with-gatsby/しかし、 locales/{lang}/*.json見つかりません。 誰か手がかりがありますか？

私の構成：
gasbty-node.js
`` `javascriptexports.onPostBuild =（）=> {
console.log（ 'ロケールのコピー'）
fs.copySync（
path.join（__ dirname、 '/ src / locales'）、
path.join（__ dirname、 '/ public / locales'）
）。
}

`` `

追加

exports.onPostBootstrap = () => {
    console.log("Copying locales");
    fs.copySync(
        path.join(__dirname, "/src/locales"),
        path.join(__dirname, "/public/locales")
    );
};

gatsby-node.js

@ThiagoMiranda同じ問題に直面していたのですが、 gatsby developがonPostBuildを呼び出さず、 gatsby buildだけがそれを呼び出すことに気付きました。 onPostBootstrapは毎回呼び出されます。

レイアウトにhttps://moz.com/learn/seo/hreflang-tagを作成する方法を知っている人はいますか？

@RobinHerzogヘルメットを使用してテンプレートで作成しています。 これらはページタイプに固有であるため、少なくとも私たちの場合、レイアウトで作成することは意味がありませんでした。

@szimek返信ありがとう

<link rel="alternate" href={Route['en-us'][this.props.data.prismicDocument.data.group]} hreflang="en-us" /> <link rel="alternate" href={Route['fr-fr'][this.props.data.prismicDocument.data.group]} hreflang="fr-fr" />

今のところ、あなたが言ったように、すべてのテンプレートでそれらの行をコピーします。

私はReact / JavaScriptで開発を始めたばかりですが、i18nをサポートするために私が見たものはすべて複雑すぎました。 これが最も一般的な使用法のための私自身の仕事です：賢明なスターター

ライブリロード、SEOフレンドリー、デフォルト言語はURLのキーを使用しません。
すべての.jsページは、すべての言語用に生成されます。
エラーを防ぐために、すべての言語に対してすべてのレイアウトと.mdを作成する必要があります。
LangSelectおよびLinkコンポーネントはi18nスマートです。

私を助けて、コードとスタイルを改善する方法を説明していただければ幸いです。

@ Tom-Pichaud、メッセージをページコンポーネントに渡さないため、そこで静的にレンダリングされることはないと思います。

gatsby-nodeでのマークダウンi18nのセットアップは、人々がここで行っていることと似ているように見えますが、ページコンポーネントでjavascriptを無効にして静的レンダリングを取得しているのかどうか知りたいですか？

はい、私は静的レンダリングを取得します、それはとにかく私の目的でした、 i18n-reactはトリックを行います！

@TomPichaudは、あなたが言及したi18n-reactがjs-linguiよりも優れていることを共有することは可能でしょうか？

私が完全に理解していないことの1つは、翻訳されたメッセージをロードするための外部パッケージの実際の必要性です（おそらく複数形と親戚以外）。

静的コンテンツを含む単純なサイトの場合、各言語onCreatePageのページを複製し、ロケールをcontext渡します。

// some file with the locales
const locales = {
  en: {
    path: 'en',
    default: true,
  },
  pt: {
    path: 'pt',
  },
}

// gatsby-node.js
exports.onCreatePage = ({ page, boundActionCreators }) => {
  const { createPage, deletePage } = boundActionCreators

  return new Promise(resolve => {
    deletePage(page)

    Object.keys(locales).map(lang => {
      const localizedPath = locales[lang].default
        ? page.path
        : locales[lang].path + page.path

      return createPage({
        ...page,
        path: localizedPath,
        context: {
          locale: lang,
        },
      })
    })

    resolve()
  })
}

次に、実際のページで、コンテキスト内のロケールを使用して、graphqlのフィルターを使用してコンテンツを照会します。

/data/home/en.jsと/data/home/pt.jsホームコンテンツがあるとしましょう：

import React from 'react'

const IndexPage = ({ pathContext: { locale }, ...props }) => {
  const { childHomeJson: data } = props.data.allFile.edges[0].node

  return <div>{data.hello}</div>
}

export const query = graphql`
  query HomeContent($locale: String) {
    allFile(filter: { name: { eq: $locale } }) {
      edges {
        node {
          childHomeJson {
            hello
          }
        }
      }
    }
  }
`

export default IndexPage

netlifyCMS（i18nをサポートするまでは少し冗長ですが）およびJSONファイル内の画像（Gatsbyのファイルシステムが取得できるように相対パスを使用して新しいNodeFieldを作成する必要があります）で正常に動作します

ほとんどの場合、これで十分ではありませんか？

私はまだテスト中であり、本番環境ではこれを使用していませんが、ロケールにreactのコンテキストAPIを使用して、ローカライズされたリンクなどの保留中の問題を解決することを考えています

@pbrandoneこれは私にとって素晴らしいアプローチのようです。 同様のことが公式に文書化されるべきだと思います。

すべての入力に感謝します。ここで説明するアイデアの量は、十分に文書化されたi18nサポートの需要を明確に示しています。

@pbrandoneこのクエリのIndexPageで子コンポーネントによって使用されるすべてのキーを明示的に指定し、小道具を介してすべてのコンポーネントに翻訳を渡す必要があるということですか？

また、私は複数形のルールと相対的な日付を使用しているので、とにかく追加のロケール固有のデータをロードする必要があります：/

ただし、単純なケースでライブラリを使用せずにi18nを実行する方法と、最も人気のあるライブラリを使用して実行する方法について、公式のドキュメントを用意しておくとよいと思います。

@szimekええ、この場合はそうです。

react-intl（または他のi18nライブラリ）を追加するのは非常に簡単です。

// in src/components/layout/index.js

import React from 'react'
import { IntlProvider, addLocaleData } from 'react-intl'

// Locale data
import enData from 'react-intl/locale-data/en'
import ptData from 'react-intl/locale-data/pt'

// Messages
import en from '../../data/en.json'
import pt from '../../data/pt.json'

const messages = { en, pt }

addLocaleData([...enData, ...ptData])

const Layout = ({ locale, children }) => (
  <IntlProvider locale={locale} messages={messages[locale]}>
    {children}
  </IntlProvider>
)

export default Layout

そしてページ上：

import React from 'react'
import { FormattedMessage } from 'react-intl'

import Layout from '../components/layouts'

const IndexPage = ({ pathContext: { locale } }) => (
  <Layout locale={locale}>
    <FormattedMessage id="hello" />
  </Layout>
)

export default IndexPage

ただし、複数のJSONファイル（ページごとなど）を使用したり、それらのファイルにすべてのCMSデータを入れてgraphqlの機能でクエリや変換を行ったりすることはできません。
たとえば、graphqlアプローチを使用すると、JSONファイル内の画像へのパスを含むいくつかのキーを使用して、ロケールごとに異なる画像をロードし、それらでgatsby-imageを使用できます。
次に、netlify CMSを追加して、これらのJSONファイルを編集します😃

gatsby v2を適切に調べていませんが、子コンポーネントでクエリを実行できるStaticQueryコンポーネントがあるようです（間違っている場合は誰かが修正してくれます！）

その場合は、Reactコンテキストを作成してロケールをどこでも利用できるようにし、ロケールフィルタリングを使用して各コンポーネントで必要なキーをクエリできます。

@pbrandoneあなたは正しいです、それは静的にそのようにレンダリングします。 過去にテストして失敗したことを覚えていますが、それはgatsbyがどのように機能するかを十分に理解する前で、javascriptなしではレンダリングされないように見えるgatsbyブラウザーでreact-intl設定していた可能性があります。 私のソリューションは今あなたのソリューションと同じように見えます

@KyleAMathewsページをGatsbyからv2に更新しようとしていますが、 react-intlセットアップとgraphqlクエリに問題があります。

以前、言語固有のレイアウトを使用してGatsbyv1で言語データを読み込む方法について説明しました-https ：//github.com/szimek/gatsby-react-intl-example。 Gatsby v2では、これらのレイアウトを言語固有のページコンポーネントに置き換えるというアイデアがありました。 言語に依存しないsrc/templates/Post.jsコンポーネントと、言語データのみをロードして言語に依存しないコンポーネントをレンダリングするsrc/templates/Post.en.js 、 src/templates/Post.de.jsなどの言語固有のコンポーネントがあります。

以前のコメント（https://github.com/gatsbyjs/gatsby/issues/3853#issuecomment-367115380）で、各ページコンポーネントに言語固有のクエリがある例を示しました。

問題は、 createPage呼び出すときに、これらの言語固有のコンポーネントの名前（たとえば、 src/templates/Post.en.js ）をcomponentオプションとして渡すことですが、graphqlクエリは言語に依存しないコンポーネント。これは、__すべての言語でまったく同じである__（ localeに依存しますが、 context渡します）。 これらすべての言語固有のコンポーネントでまったく同じクエリを繰り返さないようにしたいと思います。

それを解決する方法はありますか？ このクエリを変数に抽出できますか？ 私が試したところ、Gatsbyはクエリ名とフラグメント名が同じであると文句を言っています...

最近、多言語URLルートとブラウザー言語検出の機能を備えたデフォルトのGatsbyスターターを追加しました。 （デモ）

gatsby-starter-default-intl

特徴：

• react-intlによって提供されるローカリゼーション（

• browser-langによって提供される

• 単一のページコンポーネント内で多言語のURLルートをサポートします。 つまり、 pages/en/index.jsやpages/ko/index.jsなどの個別のページを作成する必要はありません。

• gatsby-starter-defaultに基づいており、変更は最小限です。

@wizipleありがとう！ 本当に面白そうですね。 私はあなたがこのようなことをすることができるとは思いもしませんでした：https：//github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L38;）うまくいけば、それはまだ機能しますWebpack4で..。

ここで同じ方法でロケールデータをロードすることは可能ですかhttps://github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L6 ？ 私たちは6つ（まもなく7つの言語）をサポートしているので、ページを作成している言語だけをロードできれば素晴らしいと思います。 それが不可能な場合でも大したことではありません。幸い、これらのロケールデータファイルは比較的小さいです。

また、これらのページをどのように生成するかについても調べる必要があります。私の場合、すべてのページがすべての言語に翻訳されているわけではないため（単一の「ソース」言語はありません）、 onCreatePageを使用したソリューションはおそらく機能しません。私の場合。

うまくいけば、これにより、すべての言語固有のページコンポーネントで同じgraphqlクエリを使用するという私の問題が解決するでしょう。

@szimek
私が管理しているWebサイトには14の言語があり、各言語ファイルは12〜15KBです。 SEOデータを生成するには、ビルド時に各言語ルーターに適切な言語を提供する必要があると確信しています。 したがって、すべての言語を提供せずにこれをどのように処理できるかわかりません。

すべてのページをすべての言語に翻訳して提供するのは難しい場合があることを理解しています。 gatsby-node.js onCreatePageに例外を指定することで、これを解決できる場合があります。 私の場合、言語ルーターに関係なく、翻訳された言語を提供しないことで解決しました。 😆スターターREADME.mdから本番環境のショーケースWebサイトを見つけて、そのパフォーマンスを確認できます。

@wizipleどうもありがとうございました！

私はあなたのwithIntlコンポーネントを動的なrequireトリックで翻訳に使用しました（それを使用することに不利な点があるかどうかはわかりません）、そしてそれはうまくいくようです。 すべての言語に単一のページコンポーネントを使用することで、私が苦労していた問題（複数の言語固有のページコンポーネントで同じgraphqlクエリを処理する方法）を解決しました。

@wizipleレポ共有に感謝します。 正しい道を歩みました😄🎉

linguiはより良い代替手段のようです。 @dcroitoruが素晴らしい例として適切に認識されたとは思いません。 Gatsby2.0にプッシュするには少しの愛が必要です

私は、Linguiが本当に素晴らしいことに同意しますが、それでも完全なスターターが必要であり、Gatsbyの最新バージョンだけでなくLinguiも含まれています。 言及されたスターターは非公式であり、前回チェックしたときにいくつかの機能が欠けていました（たとえば、ローダーを使用してその場でlinguiコンパイルを実行します）。 Linguiの作者である@ tricoder42は、Lingui v3がリリースされたときにドキュメントを提供する

注意：CMS（DatoCMS）を統合した後、i18nライブラリの必要性が減少したことに気付きましたが、CMSでそれらの場所が見つからない一部の文字列や、複数化など、後で他のことを行うために、Linguiが必要です。私のコードベースにそれを保持したい。

とにかく私の場合、gatsby-plugin-i18nの存在は、メンテナンスされておらず、紛らわしい名前を持っているため、物事を非常に混乱させ、js-linguiやCMSesのような他の本当に素晴らしいソリューションから注意をそらします。理解し、一緒に組み立てながら。

皆さんを助けるためにこのスターターを作成しました： https ：
記事： https ：

私はreact-intl統合を使用して2つの国際化の例を作成しました

最初の例は、現在の翻訳のみをjsチャンクにバンドルすることに焦点を当てています（私がチェックした他のプラグインでは見つけることができなかったもの）。

2番目の例では、動的クエリを使用して、特定のページと言語の組み合わせに対して要求された翻訳のみを提供することに焦点を当てています。

うまくいけば、この例は誰かに役立つでしょう。

また、 https： //github.com/gatsbyjs/gatsby/issues/3853#issuecomment -395432693にあるもののほとんどを使って簡単な中程度の投稿を行いました（そしてここに投稿するのを忘れました）（もう少し詳しく説明しますが）。

https://blog.significa.pt/i18n-with-gatsby-528607b4da81興味のある人のために

古い問題は、30日間使用されなかった後にクローズされます。 この問題は20日間沈黙しており、古くなっているとマークされています。 ここに返信するか、「古くない」というラベルを追加して、この問題を未解決のままにしてください。

やあみんな、もう一年近く経ちました😅

私は最近、新しいgatsbyプラグインgatsby-plugin-intlをリリースしました。これにより、gatsbyWebサイトをすぐに使用できる国際化フレームワークとして簡単に作成できます。

デモ： https ：

• すぐに使える国際化- react-intl利用したフレームワーク

• ブラウザでのユーザーの優先言語に基づく自動リダイレクトをサポート

• 単一ページコンポーネントで多言語URLルートをサポートします。 これは、 pages/en/index.jsやpages/ko/index.jsなどの個別のページを作成する必要がないことを意味します。

• 上で提案したように、ビルド時に現在の言語のみがバンドルされるようになりました。

また、i18nの例/スターターの多くは実際にはクライアント側でレンダリングされていることにも言及したいと思います。 アプリがSSRとしてレンダリングされているかどうかを確認する最良の方法は、ソースコードを表示し、ローカライズされたテキストが存在するかどうかを確認することです。 あなたがSEOのためにあなたのgatsbyウェブサイトを国際化するとき、この問題を再確認してください。

やあみんな、もう一年近く経ちました😅

私は最近、新しいgatsbyプラグインgatsby-plugin-intlをリリースしました。これにより、gatsbyWebサイトをすぐに使用できる国際化フレームワークとして簡単に作成できます。

デモ： https ：

• すぐに使える国際化- react-intl利用したフレームワーク
• ブラウザでのユーザーの優先言語に基づく自動リダイレクトをサポート
• 単一ページコンポーネントで多言語URLルートをサポートします。 これは、 pages/en/index.jsやpages/ko/index.jsなどの個別のページを作成する必要がないことを意味します。
• 上で提案したように、ビルド時に現在の言語のみがバンドルされるようになりました。

また、i18nの例/スターターの多くは実際にはクライアント側でレンダリングされていることにも言及したいと思います。 アプリがSSRとしてレンダリングされているかどうかを確認する最良の方法は、ソースコードを表示し、ローカライズされたテキストが存在するかどうかを確認することです。 あなたがSEOのためにあなたのgatsbyウェブサイトを国際化するとき、この問題を再確認してください。

ねえ@wizipleどうもありがとう、私はギャツビーをローカライズするための解決策を見つけることに夢中になっていた。
たぶん私は要点を理解できませんでしたが、1つのファイルに言語のすべての文字列がありますか？
同じ構造のコンポーネントを使用して、各言語のJSONをより多くのファイルに分割することは可能でしょうか？

@ cant89あなたのgatsby developまたはgatsby buildフックします。
すべてのJSONファイルを取得し、ネストされたオブジェクトとしてマージしたら、それをフラット化オブジェクトとして変換することもできます。
https://github.com/yahoo/react-intl/wiki/Upgrade-Guide#flatten -messages-object

i18nのセットアップの良い例があります。 https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n。 i18nフレームワークについてはあまり意見がありません。 お好みで1つ選んでください。

i18nのセットアップの良い例があります。 https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n。 i18nフレームワークについてはあまり意見がありません。 お好みで1つ選んでください。

かっこいい、ありがとう、やってみよう！
とにかく、readmeのリンクが壊れています。おそらくますか？

@wardpeetあなたの例は静的に翻訳された文字列を（ビルド時に）生成しますか？ または、実行時にテキストを生成しますか？

@monsieurneboはビルド時間のように見えます

@ cant89まだDNSを更新しているので、今のところすぐに使用できます-i18n.netlify.com/が正しいリンクです。

@monsieurneboビルド時です。 すべてが静的に構築できるように、言語ごとにWebサイトのコピーを作成します。 これは、すべてが.htmlであるため、Webサイトが高速に保たれることを意味します。

他にどこに質問すればよいかわかりませんが、少し関連性があります。 これらのプラグインのいずれかがgatsbyのpathPrefixサポートしていますか？

i.e. 
// gatsby-config.js

modules.exports = {
    pathPrefix: 'bar'
}

https://foo.com => https://foo.com/bar

but now my language locales will now be https://foo.com/bar/de-DE/
when I think I would prefer it be https://foo.com/de-DE/bar if that makes sense.

興味深いことに、前者の方が通常は理にかなっていると思いますが、pathPrefixはドメインをdomain.com/prefixようなものなので、Gatsbyをサブディレクトリにインストールしたときにルートを変更します。サブディレクトリを使用する場合、言語がそれを壊す後にプレフィックスを変更する場合は、それを必要としないサブディレクトリ。

さて、質問が出てきました。そもそもなぜpathPrefixしているのですか？

参照： pathPrefixドキュメント

こんにちは、

ここでの議論のほとんどは、gatsbyサイトをi18nする方法に関するものです。 ただし、POCを機能させることと、最適化された本番環境に対応したシステムを使用することには違いがあります。

コード分​​割とi18nファイルの詳細、およびこのスレッドのほとんどのソリューションが最適化されていない理由を知りたい場合は、この問題が役立つことがわかります。