Gatsby: Ajouter un guide officiel pour l'internationalisation des sites Web avec Gatsby

Il y a cet article sur l'utilisation d'i18next avec GatsbyJS , qui est la méthode la plus avancée à ce jour pour moi.

Mais je n'ai pas l'impression que i18next soit la "voie statique".

À propos de l'article de blog, j'avais ces questions/réserves :
https://twitter.com/semdubois/status/930389055388508160

Il y a https://github.com/angeloocana/gatsby-plugin-i18n mais il a plusieurs limitations et il ne reçoit pas beaucoup d'activité/attention. Il pourrait être utile de le déplacer dans le référentiel Gatsby. J'aimerais moi aussi une solution consolidée appropriée.

Je suis également tombé sur js lingui et cela semble prometteur, surtout avec la v2 qui vient de sortir.

J'essaye aussi de comprendre ça. L'utilisation de la méthode i18next sur le post est la plus pratique et la plus intuitive, mais il me reste deux questions...

1. comment puis-je incorporer différents fichiers de démarques pour les langues comme dans la solution gatsby-plugin-i18n ?

2. Cela renonce-t-il complètement au rendu statique du contenu ?

Pour info @angeloocana

Je vais écrire un bref résumé de la façon dont nous le gérons en ce moment en utilisant react-intl . Cette application n'est pas encore en production, nous pouvons donc encore rencontrer des problèmes avec cette configuration, mais elle semble bien fonctionner jusqu'à présent.

Nous gardons presque tout notre contenu (qui a été migré de notre blog Wordpress) dans Contentful . Nous n'utilisons pas ses fonctionnalités de traduction, mais à la place nous avons un espace (une sorte de projet ou de dossier) par langue. Nous utilisons le plugin gatsby-source-contentful pour récupérer ces données, cependant, auparavant, nous récupérions et convertissions nous-mêmes ces données en fichiers JSON et utilisions le plugin gatsby-source-filesystem (nous utilisions une structure de dossiers comme /en/blog/... , /de/blog/... ), donc peu importe que l'on utilise Contentful ou non, tant que chaque nœud connaît ses paramètres régionaux.

Nous avons également du texte comme des étiquettes de boutons, des liens ou du contenu statique qui ne provient pas de Contentful, mais qui est plutôt traduit dans Transifex et synchronisé avec les fichiers JSON qui sont stockés dans le référentiel. Pour cette partie, nous avions besoin d'utiliser une bibliothèque i18n et avons décidé d'utiliser react-intl , simplement parce que je le connais déjà et je sais qu'il gère également le formatage des dates et des nombres. Voici comment nous l'avons configuré : https://github.com/gatsbyjs/gatsby/issues/3830#issuecomment -362710469. Nous utilisons ensuite, par exemple, intl.formatMessage lors de la génération de balises méta et <FormattedMessage /> composants <FormattedDate /> etc. dans les modèles.

@szimek Si je vous comprends bien, alors vous avez react-intl gérer la traduction du texte du composant pendant que les messages sont dans des itinéraires codés en dur sous le répertoire des pages ?

Cela signifierait que les routes codées en dur sont les seules à être rendues statiquement? Et les traductions inter-composantes i18n sont rendues dynamiquement ?

@deltaskelta Je ne suis pas sûr de comprendre votre question.

Nous n'avons pas de routage côté client personnalisé (comme décrit par exemple ici ) pour le moment, uniquement des pages générées statiquement. Lors de la génération d'une page post (nous générons également des pages index et category spécifiques aux paramètres régionaux et paginées en utilisant une version légèrement modifiée du plugin gatsby-pagination ), nous sommes en utilisant le code suivant :

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,
    },
  });
});

Même si vous avez désactivé JS, tout le contenu, y compris les balises META, est rendu dans la bonne langue.

De notre côté, nous utilisons i18next avec quelques ajustements

Les grands principes sont les suivants :

• Les paramètres régionaux sont disponibles sous forme .json fichiers /dist/ pendant la construction.
• Nous travaillons sur une seule page qui produira autant de versions statiques que nous avons de langues, en utilisant onCreatePage (en gatsby-node.js ).
• Les informations des pages (par exemple le chemin) sont centralisées dans un seul fichier.

Paramètres régionaux

Les traductions ont été principalement regroupées par page, avec un espace de noms (= fichier JSON) par page + un fichier global (pour les textes partagés tels que l'en-tête/le pied de page).

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

Malheureusement, il n'y a pas de rechargement à chaud sur les modifications de locales 👎

i18suivant

i18next est initialisé avec la configuration suivante :

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);
}

Informations sur les pages

Avant de générer toutes les versions i18n de nos pages, nous avons besoin de connaître quelques informations que nous avons regroupées dans un fichier 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...

Où les clés sont les noms de fichiers des pages et les espaces de noms sont les noms de fichiers des locales . Ils peuvent être différents

Dans ce cas:

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

Et où chemin sont les chemins de nos futures versions (langues) de nos pages.

Créer des pages

Avec le même exemple que ci-dessus, notre objectif ici est de créer une version FR + EN des pages d'accueil et de projet.

Pour y arriver, nous avons créé une fonction dédiée :

/**
 * 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];
}

Cet assistant sera ensuite utilisé lors du hook onCreatePage , en sélectionnant chaque page via une regex :

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();
  });
}

Nous avons maintenant deux versions de chaque page, avec un chemin d'accès personnalisé (à partir de notre fichier d'informations sur les pages). Vous avez peut-être remarqué que nous transmettons une information language à chaque page via pathContext . Cette valeur sera utilisée sur chaque page pour afficher la bonne langue.

Afficher la bonne langue

Nous utilisons la classe React pour les pages, le décorateur suivant connaît automatiquement la langue de la page actuelle et met à jour i18n si nécessaire :

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} />;
      }

    }
  );

}

Ensuite, appelez-le sur les pages :

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

Pfew, tout ce que vous avez à faire maintenant est d'utiliser la fonction de traduction de i18next.

Conclusion

👍 Un seul fichier source qui génère autant de versions que nécessaire pendant la construction
👍 Gestion facile de la sortie des pages
👍 Quelques efforts au début, mais ensuite tout est simple

👎 Pas de rechargement à chaud pour les locales

J'ai l'impression que ce n'est pas vraiment le "mode de vie statique"... Mais c'est le mieux que nous ayons réussi à obtenir pour l'instant.

J'aimerais voir ce que vous en pensez et comment vous gérez cela.

PS. Poke @szimek , c'est ce que je voulais vous montrer il y a quelques jours :)

J'utilise @angeloocana https://github.com/angeloocana/gatsby-plugin-i18n + React-intl et ce n'est pas aussi compliqué que les méthodes ci-dessus, mais il y a quelques limitations (voir les problèmes de repo) et je suis pas si heureux de React-intl. J'adorerais essayer https://github.com/lingui/js-lingui de @ tricoder42, je n'ai tout simplement pas eu le temps.

@monsieurnebo quel est le but d'exécuter deletePage juste avant createPage ? J'aime votre solution et j'ai essayé de la mettre en œuvre, mais j'ai quelques erreurs.

• Soit j'obtiens un pathContext.language incorrect sans utiliser deletePage

• ou j'obtiens une erreur de construction lorsque j'inclus deletePage comme votre exemple. (il dit TypeError: Cannot read property 'id' of undefined lorsque la construction arrive à l'étape run graphql queries )

C'est la meilleure solution que j'ai vue jusqu'à présent.

@deltaskelta Content de voir que ça te plait !

deletePage est utilisé pour annuler la création de la page par défaut par Gatsby. Si vous ne l'ajoutez pas, vous obtiendrez vos pages personnalisées et celle par défaut.

Vérifiez votre répertoire public avec et sans cette ligne, vous verrez la différence ;)

À propos de vos erreurs, il est difficile de deviner sans code. Pourrais-tu faire un dépôt avec ton code ? J'y jetterais un œil alors.

EDIT : Seriez-vous intéressé par un exemple ?

Oh, ce n'était pas lié à l'appel deletePage. Il s'agissait de ne pas copier l'objet pages puisque j'avais modifié votre exemple. Je trébuche toujours avec la copie d'objets après avoir été loin de js pendant un certain temps ;)

@monsieurnebo J'ai joué avec votre solution et il semble que vous ayez toujours besoin de javascript pour charger les paramètres régionaux à partir des fichiers json, est-ce correct? En plus de cela, il semble que tous les composants qui sont encapsulés avec le react-i18next HOC ont besoin de javascript pour rendre quoi que ce soit dans le composant...

Pouvez-vous confirmer si c'est ainsi que cela fonctionne de votre côté?

EDIT : au fait, j'ai raté votre mention d'un exemple, si vous avez le temps, j'aimerais voir un exemple complet.

@deltaskelta je ferai un exemple quand j'aurai du temps libre :)

@monsieurnebo pouvez-vous confirmer que votre méthode ne rend pas statiquement les chaînes dans le code HTML et nécessite javascript ?

Ouais, c'est pour ça que ce n'est pas totalement le "mode de vie statique"

J'aimerais un plugin qui génère du texte statique à la place.

Hmm je vois. Un rendu statique serait la voie à suivre...

Je pensais, puisque les contextes sont déjà passés avec le nom de la langue pour la plupart des pages de votre gatsby-node alors il ne serait pas trop difficile de simplement demander les clés des messages dans les requêtes graphql pour chaque page et les transmettre de cette manière, mais je préférerais utiliser un outil i18n tout au long si possible ...

@szimek comment react-intl rend-il les traductions à l'étape de construction et n'utilise-t-il aucun js ?

Comme mentionné, pour autant que je sache, Gatsby-plugin-i18n génère du texte statique. Avez-vous vérifié son exemple?

@deltaskelta Eh bien, toutes les traductions sont disponibles pendant le temps de construction (c'est pourquoi j'utilise plusieurs mises en page), donc ça "fonctionne" ™️ ;) J'espère juste qu'il continuera à fonctionner dans la v2... Je peux préparer un exemple d'application si vous vouloir. Je n'ai pas encore vraiment examiné gatsby-plugin-i18n , car je travaille avec Contentful, pas avec des fichiers.

Je n'ai pas lu les détails mais il y a une discussion (ou plutôt un monologue) sur le combo gatsby-plugin-i18n + content ici : https://github.com/angeloocana/gatsby-plugin-i18n/issues/31

@szimek Je serais très intéressé par un exemple. @sedubois Je sais que gatsby-plugin-i18n génère aussi du texte statique mais je ne vois pas où se passe la magie qui manque dans i18next afin de générer des fichiers totalement statiques....

Je pense que je pourrais voir pourquoi maintenant... passez-vous react-intl les messages via pathContext dans gatsby-node pendant le rendu ?

EDIT : si c'est le cas (ce qui a du sens), alors la bibliothèque i18n utilisée est "un peu" hors de propos car on passe des messages à travers le contexte et on les rend statiquement, ce qui est une configuration gatsby pure et la bibliothèque i18n ne gère que des cas spéciaux tels que dates et pluriels avec js.

Après des tests plus poussés de i18next et de react-intl il semble que le HOC de traduction de i18next nécessite javascript pour se charger, donc même si les messages sont transmis via le contexte et rendus statiquement, toute utilisation du HOC de traduction rendra l'ensemble du composant nécessitant javascript pour s'exécuter.

react-intl composant FormattedMessage , d'autre part, restitue un message par défaut (qui peut être basé sur le contexte qui lui est passé) et restitue statiquement dans le code HTML lors de la construction.

De par sa conception, je pense que l'intégration la plus naturelle d'i18n serait avec react-intl si vous souhaitez obtenir des traductions statiques en HTML. Si j'ai mal compris le flux que vous utilisez, veuillez me corriger

@mattferderer a eu la bonne idée ici, mais je pense que cela a besoin d'un peu de peaufinage. https://github.com/gatsbyjs/gatsby/issues/3830#issuecomment -362715706

les mises en page sont rendues avant les pages, donc sans créer plusieurs mises en page, il n'y a aucun moyen de transmettre des messages à travers le contexte, à partir de la fonction createPages (corrigez-moi si je me trompe ici). Donc, afin de rendre i18n plus facile, je pense que la mise en page devrait simplement appeler children() , puis les différentes mises en page par effet de langue seraient accomplies en faisant en sorte que gatsby-node crée un chemin différent par langue indexer les pages de pages/index qui peuvent être transmises via le contexte

EDIT : désolé pour la divagation mais tout est devenu clair et j'ai dû l'enregistrer quelque part

EDIT2: Je me trompe définitivement ci-dessus, les en-têtes et les pieds de page doivent être insérés dans la mise en page, je ne sais tout simplement pas comment leur faire parvenir les messages sans créer plusieurs mises en page. La seule autre façon que je puisse penser serait de diviser les URL et de regexer les paramètres régionaux ... mais cela semble être une chose difficile à faire

@KyleAMathews avec v2 n'ayant qu'une seule mise en page, comment pouvons-nous transmettre des données telles que des messages i18n au composant de mise en page racine via un contexte basé sur le chemin ou un tableau de clés de langue ?

Si cela pouvait être fait, il serait alors facile d'implémenter i18n, mais je ne vois pas comment le faire sans faire plusieurs mises en page

@deltaskelta Voici un exemple de ce que nous faisons : https://github.com/szimek/gatsby-react-intl-example. Il montre comment afficher des articles individuels, comment générer une page d'index pour chaque paramètre régional, comment utiliser les composants react-intl , comment utiliser react-intl injectIntl HOC pour définir un titre (ou toute autre balise meta) pour les pages d'index en utilisant intl.formatMessage helper etc.

Les pages générées sont :

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

Dans la vraie application, nous utilisons une version modifiée de gatsby-pagination , car la version originale ne prend pas en charge l'option de mise en page. Nous avons également défini post_id champ post_id .

D'AILLEURS. Je viens de réaliser que nous devrons probablement générer des plans de site distincts pour chaque langue, afin que Swiftype (le moteur de recherche que nous utilisons) sache quelles pages nous avons.

@deltaskelta brièvement, vous auriez des composants de page pour chaque langue, puis un composant de mise en page par langue. Voici une façon de procéder.

// 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 Ces fichiers sont des modèles, n'est-ce pas ? Cela signifie-t-il que si j'ai 3 types de pages et 7 langues, j'aurais besoin de 21 modèles ? :)

Ce qui précède est la façon la plus optimisée de le faire. Si chaque composant de mise en page n'est pas si différent, vous pouvez les combiner en un seul composant de mise en page, puis changer de mise en page en fonction de la langue active.

Je n'ai pas lu les détails mais il y a une discussion (ou plutôt un monologue) sur le combo gatsby-plugin-i18n + content ici : angeloocana/gatsby-plugin-i18n#31

@sedubois , haha, gatsby-starter-contentful-i18n dans les documents de Gatsby via ce PR : https://github.com/gatsbyjs/gatsby/pull/4138

Intéressé par l'autre solution ci-dessus, en particulier comment elle se compare au plugin communautaire re: SEO, etc.

@mccrodp Votre solution ressemble assez à la mienne, la principale différence est que gatsby-plugin-i18n ne vous oblige pas à passer explicitement l'option layout à createPage , mais le fait pour vous Dans les coulisses. Cependant, il utilise toujours plusieurs mises en page ;)

J'ai suivi la suggestion de @KyleAMathews et components/Layout qui utilise une bibliothèque i18n et j'ai entièrement supprimé mon dossier de mise en page gatsby. De cette façon, dans gatsby-node je peux créer des pages pour mes paramètres régionaux et ils ont accès à tout ce à quoi une page a accès, y compris les chemins.

Je peux ensuite transmettre la locale directement au composant de mise en page qui la transmet à i18n.

Il est légèrement gênant d'avoir à envelopper chaque composant au niveau de la page avec la mise en page, mais cela a dissipé tant de confusion et simplifié beaucoup mon code.

Salut @deltaskelta , as-tu un exemple de ta solution ? J'adorerais voir si quelque chose peut en être tiré pour pousser en amont le plugin communautaire i18n. Merci.

tout mon projet est dans un état désordonné en ce moment mais je pense que je peux exposer les bases...

1. Pas de layout - car (si je me souviens bien), le layout entre en jeu avant les chemins ou autre chose qui était très important, ce qui m'empêchait de lui donner les bons objets messages...

2. Nourrissez les bons messages et locale dans le gatsby-node travers le contexte...

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. Créez maintenant un composant de mise en page global qui doit être appelé sur chaque composant au niveau de la page...

// 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. Appelez le composant de mise en page globale avec vos composants au niveau de la page qui ont les paramètres régionaux appropriés et les messages transmis à partir du contexte

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>
  );
};

Je dois nettoyer et réorganiser ce code parce que je l'ai en quelque sorte fait rapidement pour prouver que cela pouvait fonctionner et je vais le revoir plus tard ... J'espère que cela vous en donne l'essentiel

J'ai créé un démarreur gatsby qui utilise js-lingui pour traduire les messages :
https://github.com/dcroitoru/gatsby-starter-i18n-lingui

Dans la vraie application, nous utilisons une version modifiée de gatsby-pagination, car la version originale ne prend pas en charge l'option de mise en page. Nous avons également défini un champ post_id pour chaque message qui nous permet de trouver des traductions du même message, par exemple dans le cas de cette application de démonstration, les deux messages auraient le même post_id.

@szimek est-il possible que vous partagiez votre pagination gatsby modifiée ? Je serais très curieux de le voir car j'ai moi-même un problème similaire.

@martynhoyer Mon patch a été fusionné, je suis donc revenu à la version originale de gatsby-pagination . Quel problème as-tu ?

Salut @sgoudie
J'utilise ce tutoriel : https://www.gatsbyjs.org/blog/2017-10-17-building-i18n-with-gatsby/ mais je ne trouve aucun de mes locales/{lang}/*.json . Est-ce que quelqu'un a une idée ?

Ma config :
gasbty-node.js
```javascriptexports.onPostBuild = () => {
console.log('Copie des paramètres régionaux')
fs.copySync(
chemin.join(__dirname, '/src/locales'),
path.join(__dirname, '/public/locales')
)
}

```

Ajouter

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

à gatsby-node.js

@ThiagoMiranda J'étais confronté au même problème puis j'ai réalisé que gatsby develop n'appelait pas onPostBuild, seulement gatsby build appelait. onPostBootstrap est appelé à chaque fois.

Quelqu'un sait comment créer https://moz.com/learn/seo/hreflang-tag dans les mises en page ?

@RobinHerzog Nous les créons dans des modèles à l'aide de Helmet. Ils sont spécifiques au type de page, donc au moins dans notre cas, cela n'avait pas de sens de les créer dans une mise en page.

@szimek merci pour la réponse. Je comprends mais dans mon cas ce serait intéressant de l'avoir dans les mises en page.

<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" />

Pour le moment, comme vous l'avez dit, copiez ces lignes dans tous les modèles.

Je commence seulement à développer avec React/JavaScript, mais tout ce que j'ai vu pour prendre en charge i18n était trop complexe. Voici mon propre travail pour l'utilisation la plus courante : wise-starter

Le rechargement en direct, le référencement convivial et les langues par défaut n'utilisent pas la clé dans l'URL.
Toutes les pages .js sont générées pour toutes les langues.
Toutes les mises en page et .md doivent être créés pour toutes les langues afin d'éviter les erreurs.
Les composants LangSelect et Link sont i18n smart.

Si vous pouvez m'aider et m'expliquer comment je pourrais améliorer mon code et mon style, je vous en serais reconnaissant.

@Tom-Pichaud, je pense que puisque vous ne transmettez pas de messages aux composants de la page, ils ne seront pas rendus statiquement là-bas.

La configuration Markdown i18n dans gatsby-node ressemble à ce que les gens ont fait ici, mais je suis curieux de savoir si vous obtenez un rendu statique avec javascript désactivé sur les composants de votre page ?

Oui j'obtiens un rendu statique, c'était mon objectif en tout cas, i18n-react fait l'affaire !

@TomPichaud vous serait-il possible de partager en quoi le i18n -react que vous avez mentionné est meilleur que

Une chose que je ne comprends pas tout à fait est le besoin réel de packages externes pour charger les messages traduits (autres que la pluralisation et les parents, probablement).

Pour un site simple avec un contenu statique, je duplique simplement les pages pour chaque langue onCreatePage et passe la locale à 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()
  })
}

Ensuite, sur la page réelle, j'utilise les paramètres régionaux dans le contexte pour interroger le contenu à l'aide du filtre de graphql.

Disons que j'ai le contenu de la maison dans /data/home/en.js et /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

fonctionne bien avec netlifyCMS (bien qu'un peu détaillé jusqu'à ce qu'ils prennent en charge i18n) et les images dans les fichiers JSON (bien que nous devions créer un nouveau NodeField avec le chemin relatif pour que le système de fichiers de Gatsby l'obtienne)

N'est-ce pas suffisant dans la plupart des cas ?

Je teste toujours et je n'ai rien utilisé de tout cela en production, mais je pense utiliser l'API de contexte de react pour les paramètres régionaux afin de résoudre certains problèmes en suspens comme les liens localisés

@pbrandone Cela semble être une excellente approche pour moi. Je pense que quelque chose de similaire devrait être documenté officiellement.

Merci pour toutes les contributions, la quantité d'idées discutées ici marque clairement la demande d'un support i18n bien documenté.

@pbrandone Cela signifie-t-il que vous devez spécifier explicitement toutes les clés utilisées par tous les composants enfants dans IndexPage dans cette requête et transmettre les traductions à tous les composants via des accessoires ?

De plus, j'utilise des règles de pluralisation et des dates relatives, donc je dois quand même charger des données supplémentaires spécifiques aux paramètres régionaux :/

Cependant, je suis d'accord que ce serait formidable d'avoir une documentation officielle sur la façon de faire i18n sans aucune bibliothèque pour des cas simples et ensuite comment le faire avec les bibliothèques les plus populaires.

@szimek bien, dans ce cas oui.

Il est très facile d'ajouter react-intl (ou toute autre bibliothèque i18n) tho :

// 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

puis sur les pages :

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

Mais alors vous ne seriez pas en mesure d'utiliser plusieurs fichiers JSON (par exemple par page), ni d'avoir toutes les données CMS dans ces fichiers à interroger et à transformer avec la puissance de graphql.
Avec l'approche graphql, nous pourrions, par exemple, avoir des clés avec des chemins d'accès aux images dans ces fichiers JSON pour charger différentes images par paramètre régional et pouvoir toujours utiliser gatsby-image dessus.
Et puis ajoutez netlify CMS pour éditer ces fichiers JSON 😃

Je n'ai pas correctement examiné gatsby v2 mais apparemment, il existe un composant StaticQuery qui nous permet d'interroger les composants enfants (quelqu'un me corrige si je me trompe !)

Si tel est le cas, nous pourrions créer un contexte React pour rendre la locale disponible n'importe où, puis interroger les clés nécessaires dans chaque composant avec le filtrage des paramètres régionaux

@pbrandone vous avez raison, cela rend statiquement de cette façon. Je me souviens qu'il teste dans le passé et à défaut, mais c'était avant d' avoir une bonne compréhension décente de la façon dont Gatsby œuvres, que je pouvais avoir mon react-intl configuration dans Gatsby navigateur qui semble comme il pourrait ne pas rendre sans javascript. Ma solution ressemble maintenant à la vôtre

@KyleAMathews J'essaie de mettre à jour notre page vers Gatsby vers la v2 et j'ai un problème avec notre configuration react-intl et les requêtes graphql.

J'ai précédemment expliqué comment j'utilise des mises en page spécifiques à une langue pour charger des données de langue dans Gatsby v1 - https://github.com/szimek/gatsby-react-intl-example. Dans Gatsby v2, j'ai eu l'idée de remplacer ces mises en page par des composants de page spécifiques à la langue. J'aurais un composant src/templates/Post.js indépendant de la langue, puis des composants spécifiques à la langue comme src/templates/Post.en.js , src/templates/Post.de.js qui ne chargeraient que les données de langue et rendraient le composant indépendant de la langue.

Dans votre commentaire précédent (https://github.com/gatsbyjs/gatsby/issues/3853#issuecomment-367115380), vous avez montré un exemple où chaque composant de page a une requête spécifique à la langue.

Le problème avec cela est que lors de l'appel de createPage , je passe les noms de ces composants spécifiques au langage (par exemple src/templates/Post.en.js ) en tant qu'option component , mais la requête graphql est dans le composant indépendant de la langue, car c'est __exactement le même pour toutes les langues__ (cela dépend de locale , mais je le passe dans context ). J'aimerais éviter de répéter exactement la même requête dans tous ces composants spécifiques à la langue.

Des idées comment le résoudre? Puis-je extraire cette requête vers une variable ? Quand je l'ai essayé, Gatsby se plaint que les noms de requête et de fragment sont les mêmes...

J'ai récemment ajouté un démarreur Gatsby par défaut avec des fonctionnalités de routes d'URL multilingues et de détection de la langue du navigateur. (démo)

gatsby-starter-default-intl

Caractéristiques:

• Localisation (multilingue) fournie par react-intl .

• Redirection automatique basée sur la langue préférée de l'utilisateur dans le navigateur fourni par browser-lang .

• Prend en charge les routes d'URL multilingues au sein d'un seul composant de page. Cela signifie que vous n'avez pas besoin de créer des pages distinctes telles que pages/en/index.js ou pages/ko/index.js .

• Basé sur gatsby-starter-default avec le moins de modifications.

@wiziple Merci ! Cela a l'air vraiment intéressant. Je ne savais pas que vous pouviez faire quelque chose comme ça : https://github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L38 ;) Espérons que cela fonctionne toujours dans le Webpack 4...

Est-il possible de charger les données locales de la même manière ici https://github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L6 ? Nous prenons en charge 6 (bientôt 7 langues), donc ce serait génial si je pouvais charger uniquement celle pour laquelle je construis la page. ce n'est pas grave si ce n'est pas possible - heureusement, ces fichiers de données locales sont relativement petits.

Je vais aussi devoir regarder comment vous générez ces pages, car dans mon cas toutes les pages ne sont pas traduites dans toutes les langues (il n'y a pas une seule langue "source"), donc la solution avec onCreatePage ne fonctionnera probablement pas dans mon cas.

Espérons que cela résoudra mon problème avec la même requête graphql dans chaque composant de page spécifique à la langue.

@szimek
Le site Web que je gère a 14 langues et chaque fichier de langue fait 12-15 Ko. Je suis presque sûr que nous devons fournir la bonne langue pour chaque routeur de langue au moment de la construction afin de générer des données de référencement. Je ne sais donc pas comment je peux gérer cela sans fournir toutes les langues.

Je comprends qu'il est parfois difficile de fournir chaque page traduite dans toutes les langues. Vous pourrez peut-être résoudre ce problème en fournissant une exception sur onCreatePage dans gatsby-node.js . Dans mon cas, j'ai simplement résolu en ne proposant pas de langue traduite, quel que soit le routeur de langue. Vous pouvez trouver le site vitrine sur la production à partir du démarreur README.md et vérifier ses performances.

@wiziple Merci beaucoup !

J'ai utilisé votre composant withIntl avec l'astuce dynamique require pour les traductions (je ne sais pas s'il y a des inconvénients à l'utiliser) et cela semble très bien fonctionner. Cela a résolu le problème avec lequel je me débattais - comment gérer la même requête graphql dans plusieurs composants de page spécifiques à une langue - en ayant un seul composant de page pour toutes les langues.

@wiziple merci pour le partage du repo. M'a mis sur la bonne voie 😄 🎉

lingui semble être une meilleure alternative . Je ne pense pas que @dcroitoru ait été correctement reconnu pour un bon exemple. A juste besoin d'un peu d'amour pour le pousser vers Gatsby 2.0

Je suis d'accord que Lingui est en effet vraiment sympa, même s'il a encore besoin d'un starter complet, avec la dernière version de Gatsby mais aussi Lingui. Le démarreur mentionné n'est pas officiel et il manquait certaines fonctionnalités la dernière fois que j'ai vérifié (par exemple, utiliser un chargeur pour exécuter la compilation lingui à la volée). L'auteur de Lingui @tricoder42 a déclaré qu'il fournirait de la documentation lorsque Lingui v3 sera disponible (ce qui semble être bientôt).

NB : j'ai remarqué que mon besoin d'une librairie i18n diminuait après l'intégration d'un CMS (DatoCMS), mais j'ai toujours besoin de Lingui pour certaines chaînes qui ne trouvent pas leur place dans le CMS et aussi pour la pluralisation et éventuellement d'autres choses plus tard donc j'ai définitivement veux le garder dans ma base de code.

Quoi qu'il en soit, dans mon cas, l'existence de gatsby-plugin-i18n a rendu les choses assez confuses car il n'est pas maintenu, a un nom déroutant et détourne l'attention de ces autres solutions vraiment intéressantes comme js-lingui et CMS que j'ai ensuite pris tandis que pour comprendre et assembler ensemble.

Je viens de créer ce démarreur pour vous aider : https://github.com/smakosh/gatsby-starter-i18n
Article : https://dev.to/smakosh/implement-i18n-to-a-gatsby-site-5ala

J'ai fait deux exemples d'internationalisation avec l'intégration de react-intl

Le premier exemple est axé sur le regroupement uniquement des traductions actuelles dans des morceaux js (quelque chose que je n'ai pas pu trouver dans d'autres plugins que j'ai vérifiés).

Le deuxième exemple se concentre sur l'utilisation de requêtes dynamiques pour fournir uniquement les traductions demandées pour une combinaison page/langue donnée.

Espérons que ces exemples seront utiles à quelqu'un.

J'ai également fait un message moyen rapide (et j'ai oublié de le publier ici) avec à peu près ce qu'il y a dans https://github.com/gatsbyjs/gatsby/issues/3853#issuecomment -395432693 (bien qu'un peu plus en profondeur).

https://blog.significa.pt/i18n-with-gatsby-528607b4da81 pour toute personne intéressée

Les anciens numéros seront fermés après 30 jours d'inactivité. Ce problème est resté silencieux pendant 20 jours et est marqué comme obsolète. Répondez ici ou ajoutez l'étiquette « not stale » pour garder ce problème ouvert !

Hé les gars, ça fait presque un an

J'ai récemment publié le nouveau plugin gatsby gatsby-plugin-intl qui fait facilement de votre site Web gatsby un cadre d'internationalisation prêt à l'emploi.

DÉMO : https://gatsby-starter-default-intl.netlify.com

• Cadre d'internationalisation prêt à l'emploi alimenté par react-intl

• Prend en charge la redirection automatique en fonction de la langue préférée de l'utilisateur dans le navigateur

• Prend en charge les routes d'URL multilingues dans un seul composant de page. Cela signifie que vous n'avez pas besoin de créer des pages distinctes telles que pages/en/index.js ou pages/ko/index.js .

• Comme certains d'entre vous l'ont suggéré ci-dessus, il regroupe désormais uniquement la langue actuelle pendant la construction.

De plus, je tiens à mentionner que de nombreux exemples / démarreurs i18n sont en fait rendus côté client. Le meilleur moyen de vérifier si l'application est rendue en tant que SSR est de visualiser le code source et de vérifier si les textes localisés existent. Veuillez vérifier cette question lorsque vous internationalisez votre site Web gatsby pour le référencement.

Hé les gars, ça fait presque un an

J'ai récemment publié le nouveau plugin gatsby gatsby-plugin-intl qui fait facilement de votre site Web gatsby un cadre d'internationalisation prêt à l'emploi.

DÉMO : https://gatsby-starter-default-intl.netlify.com

• Cadre d'internationalisation prêt à l'emploi alimenté par react-intl
• Prend en charge la redirection automatique en fonction de la langue préférée de l'utilisateur dans le navigateur
• Prend en charge les routes d'URL multilingues dans un seul composant de page. Cela signifie que vous n'avez pas besoin de créer des pages distinctes telles que pages/en/index.js ou pages/ko/index.js .
• Comme certains d'entre vous l'ont suggéré ci-dessus, il regroupe désormais uniquement la langue actuelle pendant la construction.

De plus, je tiens à mentionner que de nombreux exemples / démarreurs i18n sont en fait rendus côté client. Le meilleur moyen de vérifier si l'application est rendue en tant que SSR est de visualiser le code source et de vérifier si les textes localisés existent. Veuillez vérifier cette question lorsque vous internationalisez votre site Web gatsby pour le référencement.

Hé @wiziple merci beaucoup pour cela, je
Peut-être que je n'ai pas compris, mais avez-vous TOUTES les chaînes d'une langue dans un seul fichier ?
Serait-il possible de diviser le JSON de chaque langue en plusieurs fichiers, peut-être en utilisant la même structure de composants ?

@cant89 Je vois votre point, mais ce n'est actuellement pas possible sans changer le code du plugin. Ou vous pouvez créer un script qui analyse le répertoire src et récupère tous les fichiers de langue des composants. Fusionnez en un seul JSON puis connectez-vous à gatsby develop ou gatsby build .
Une fois que vous avez obtenu tous les fichiers JSON et fusionné en tant qu'objet imbriqué, vous pouvez également le convertir en objet aplati.
https://github.com/yahoo/react-intl/wiki/Upgrade-Guide#flatten -messages-object

Nous avons un bon exemple de configuration pour i18n. https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n. Nous n'avons pas vraiment d'opinion sur les frameworks i18n. Choisissez-en un à votre goût.

Nous avons un bon exemple de configuration pour i18n. https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n. Nous n'avons pas vraiment d'opinion sur les frameworks i18n. Choisissez-en un à votre goût.

Cool, merci, je vais essayer !
Quoi qu'il en soit, le lien sur le fichier readme est cassé, vous voulez probablement dire https://using-i18n.netlify.com/ ?

@wardpeet Votre exemple génère-t-il des chaînes traduites statiques (au moment de la construction) ? Ou génère-t-il le texte pendant l'exécution ?

@monsieurnebo ressemble au temps de construction

@cant89, nous mettons toujours à jour le DNS, donc c'est bientôt pour l'instant en utilisant-i18n.netlify.com/ est le bon lien.

@monsieurnebo c'est au moment de la construction. Il crée une copie de votre site Web pour chaque langue afin que tout puisse être construit de manière statique. Cela signifie que votre site Web reste rapide car tout n'est qu'un fichier .html.

Je ne sais pas où demander cela, mais un peu pertinent. l'un de ces plugins prend-il en charge les pathPrefix gatsby ?

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.

Hmm intéressant, je pense que le premier a généralement plus de sens, car le pathPrefix fait en sorte que votre domaine soit domain.com/prefix donc changez la racine lorsque vous avez installé Gatsby dans un sous-répertoire, si vous ne l'installez pas sur un sous-répertoire, vous n'en avez pas besoin, si vous utilisez un sous-répertoire en changeant le préfixe pour qu'il soit après la langue, le casserait.

Maintenant, la question se pose, pourquoi utilisez-vous le pathPrefix en premier lieu ?

Réf : docs pathPrefix

Salut,

La plupart des discussions ici portent sur la façon d'i18n un site gatsby. Mais il y a une différence entre avoir un POC fonctionnel et avoir un système optimisé prêt pour la production.

Si vous souhaitez en savoir plus sur le fractionnement de code et les fichiers i18n, et pourquoi la plupart des solutions de ce fil ne sont pas optimisées, vous trouverez ce problème utile