Gatsby: Gatsby . के साथ वेबसाइटों का अंतर्राष्ट्रीयकरण करने के लिए एक आधिकारिक मार्गदर्शिका जोड़ें

I18next को GatsbyJS के साथ उपयोग करने के बारे में

लेकिन मुझे नहीं लगता कि i18next "स्थिर तरीका" है।

ब्लॉग पोस्ट के बारे में, मेरे पास ये प्रश्न/आरक्षण थे:
https://twitter.com/semdubois/status/930389055388508160

https://github.com/angeloocana/gatsby-plugin-i18n है लेकिन इसकी कई सीमाएँ हैं और इसे अधिक गतिविधि/ध्यान नहीं मिल रहा है। इसे गैट्सबी रेपो में स्थानांतरित करने में मदद मिल सकती है। मुझे भी एक उचित समेकित समाधान पसंद आएगा।

मैं जेएस लिंगुई पर भी ठोकर खाई और यह आशाजनक प्रतीत होता है, खासकर वी 2 के साथ।

मैं भी यह पता लगाने की कोशिश कर रहा हूँ। पोस्ट पर i18next पद्धति का उपयोग करना सबसे सुविधाजनक है और सहज महसूस करता है, लेकिन मेरे पास दो प्रश्न रह गए हैं ....

1. मैं gatsby-plugin-i18n समाधान जैसी भाषाओं के लिए विभिन्न मार्कडाउन फ़ाइलों को कैसे शामिल कर सकता हूं?

2. क्या यह सामग्री के स्थिर प्रतिपादन को पूरी तरह से त्याग देता है?

FYI करें @angeloocana

react-intl का उपयोग करके इस समय हम इसे कैसे संभालते हैं, इसका एक संक्षिप्त सारांश मैं लिखूंगा। यह ऐप अभी तक उत्पादन में नहीं है, इसलिए हमें अभी भी इस सेटअप के साथ कुछ समस्याएं मिल सकती हैं, हालांकि ऐसा लगता है कि यह अभी तक ठीक काम कर रहा है।

हम अपनी लगभग सभी सामग्री (जो हमारे Wordpress ब्लॉग से माइग्रेट की गई थी) को Contentful में gatsby-source-contentful प्लगइन का उपयोग कर रहे हैं, हालांकि, पहले हम इस डेटा को JSON फाइलों में ला रहे थे और परिवर्तित कर रहे थे और gatsby-source-filesystem प्लगइन का उपयोग किया था (हमने /en/blog/... जैसे फ़ोल्डर संरचना का उपयोग किया था। /de/blog/... ), इसलिए इससे कोई फर्क नहीं पड़ता कि कोई कंटेंटफुल का उपयोग कर रहा है या नहीं, जब तक कि प्रत्येक नोड अपने स्थान को जानता है।

हम यह भी बटन लेबल, कुछ लिंक या स्थैतिक सामग्री है कि Contentful से नहीं आती है जैसे कुछ पाठ है, लेकिन में अनुवाद किया है Transifex बजाय और JSON फ़ाइलों को रेपो में जमा हो जाती पर सिंक किए गए। इस भाग के लिए हमें कुछ i18n लाइब्रेरी का उपयोग करने की आवश्यकता थी और react-intl का उपयोग करने का निर्णय लिया, सिर्फ इसलिए कि मैं इसे पहले से जानता हूं और मुझे पता है कि यह दिनांक और संख्या स्वरूपण को भी संभालता है। यहां बताया गया है कि हम इसे कैसे सेट करते हैं: https://github.com/gatsbyjs/gatsby/issues/3830#issuecomment -362710469। तब हम उपयोग कर रहे हैं उदाहरण के लिए intl.formatMessage जब मेटा टैग और <FormattedMessage /> , <FormattedDate /> आदि टेम्पलेट में घटक उत्पन्न करते हैं।

@szimek अगर मैं आपको सही ढंग से समझता हूं तो आपके पास react-intl घटक टेक्स्ट अनुवाद को संभालना है, जबकि पोस्ट पेज निर्देशिका के तहत हार्डकोडेड मार्गों में हैं?

इसका मतलब यह होगा कि हार्डकोडेड मार्ग केवल वही हैं जो स्थिर रूप से प्रस्तुत किए जाते हैं? और i18n अंतर घटक अनुवाद गतिशील रूप से प्रस्तुत किए जाते हैं?

@deltaskelta मुझे यकीन नहीं है कि मैं आपका प्रश्न समझता हूं।

इस समय हमारे पास कोई कस्टम क्लाइंट-साइड रूटिंग नहीं है (जैसा कि यहां बताया गया post पृष्ठ बनाते समय (हम gatsby-pagination प्लगइन के थोड़े संशोधित संस्करण का उपयोग करके स्थानीय-विशिष्ट और पृष्ठांकित index और category पृष्ठ भी उत्पन्न करते हैं), हम निम्नलिखित कोड का उपयोग करना:

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

भले ही आपने जेएस अक्षम कर दिया हो, मेटा टैग सहित सभी सामग्री सही भाषा में प्रस्तुत की जाती है।

हमारी ओर से, हम कुछ सुधारों के साथ i18next का उपयोग कर रहे हैं

मुख्य सिद्धांत निम्नलिखित हैं:

• स्थान .json फ़ाइलों के रूप में उपलब्ध हैं और निर्माण के दौरान बस /dist/ निर्देशिका में चले गए हैं।
• हम एक एकल पृष्ठ पर काम कर रहे हैं जो onCreatePage ( gatsby-node.js ) का उपयोग करके उतने ही स्थिर संस्करण तैयार करेगा जितने हमारे पास भाषाएं हैं।
• पृष्ठ जानकारी (जैसे पथनाम) एक फ़ाइल में केंद्रीकृत हैं।

स्थानों

अनुवादों को अधिकतर पृष्ठ द्वारा समूहीकृत किया गया है, प्रति पृष्ठ एक नाम स्थान (= JSON फ़ाइल) + एक वैश्विक फ़ाइल (शीर्ष लेख / पाद लेख जैसे साझा पाठ के लिए)।

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

अफसोस की बात है कि स्थानीय संशोधनों पर कोई हॉट-रीलोडिंग नहीं है

i18अगला

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

और जहां पथ हमारे पृष्ठों के हमारे भविष्य के संस्करणों (भाषाओं) के पथनाम हैं।

पेज बनाएं

ऊपर दिए गए उदाहरण के साथ, यहां हमारा लक्ष्य होम और प्रोजेक्ट पेजों का 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();
  });
}

अब हमारे पास प्रत्येक पृष्ठ के दो संस्करण हैं, एक कस्टम पथनाम के साथ (हमारे पृष्ठों की जानकारी फ़ाइल से)। आपने देखा होगा कि हम प्रत्येक पृष्ठ पर pathContext माध्यम से एक language जानकारी pathContext । इस मान का उपयोग प्रत्येक पृष्ठ पर सही भाषा प्रदर्शित करने के लिए किया जाएगा।

सही भाषा प्रदर्शित करें

हम पृष्ठों के लिए रिएक्ट क्लास का उपयोग कर रहे हैं, निम्नलिखित डेकोरेटर स्वचालित रूप से वर्तमान पृष्ठ की भाषा जानते हैं और यदि आवश्यक हो तो 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 {
// ...

Pfew, अब आपको केवल i18next के अनुवाद फ़ंक्शन का उपयोग करना है।

निष्कर्ष

एक एकल स्रोत फ़ाइल जो बिल्ड के दौरान जितने आवश्यक हो उतने संस्करण उत्पन्न करती है
👍 आसान पृष्ठ आउटपुट प्रबंधन
पहले कुछ प्रयास, लेकिन फिर सब कुछ आसान हो जाता है

लोकेशंस के लिए कोई हॉट-रीलोड नहीं

मुझे लगता है कि यह वास्तव में "जीवन का स्थिर तरीका" नहीं है ... लेकिन यह सबसे अच्छा है जिसे हम अभी प्राप्त करने में कामयाब रहे हैं।

मुझे यह देखना अच्छा लगेगा कि आप इस बारे में क्या सोचते हैं और आप लोग इसे कैसे प्रबंधित करते हैं।

पुनश्च. पोक @szimek , यही मैं आपको कुछ दिन पहले यह दिखाना चाहता था :)

मैं @angeloocana के https://github.com/angeloocana/gatsby-plugin-i18n + React-intl का उपयोग कर रहा हूं और यह उपरोक्त विधियों की तरह जटिल नहीं है, लेकिन कुछ सीमाएं हैं (रेपो मुद्दे देखें) और मैं हूं रिएक्ट-इंटल के बारे में इतना खुश नहीं है। @tricoder42 के https://github.com/lingui/js-lingui को आजमाना पसंद करेंगे, अभी समय नहीं मिला है।

@monsieurnebo deletePage ठीक पहले createPage चलाने का लक्ष्य क्या है? मुझे आपका समाधान पसंद है और मैंने इसे लागू करने का प्रयास किया है, लेकिन मुझे कुछ त्रुटियां हैं।

• मैं या तो मिल गलत pathContext.language का उपयोग किए बिना deletePage

• या जब मैं आपके उदाहरण की तरह deletePage शामिल करता हूं तो मुझे बिल्ड त्रुटि मिलती है। (यह कहता है TypeError: Cannot read property 'id' of undefined जब बिल्ड run graphql queries स्टेज पर

यह अब तक का सबसे अच्छा समाधान है जिसे मैंने देखा है।

@deltaskelta आपको इसे पसंद करते हुए

deletePage का उपयोग गैट्सबी द्वारा डिफ़ॉल्ट पेज के निर्माण को रद्द करने के लिए किया जाता है। यदि आप इसे नहीं जोड़ते हैं, तो आपको अपने कस्टम पृष्ठ और डिफ़ॉल्ट पृष्ठ मिलेंगे।

इस लाइन के साथ और इसके बिना अपनी public निर्देशिका की जाँच करें, आप अंतर देखेंगे;)

आपकी त्रुटियों के बारे में, बिना कोड के अनुमान लगाना कठिन है। क्या आप अपने कोड के साथ एक भंडार बना सकते हैं? मैं इसे तब देख लूंगा।

संपादित करें: क्या आप एक उदाहरण से दिलचस्पी लेंगे?

ओह, यह डिलीटपेज कॉल से संबंधित नहीं था। जब से मैंने आपके उदाहरण को संशोधित किया था, यह पेज ऑब्जेक्ट को कॉपी न करने का मुद्दा था। थोड़ी देर के लिए जेएस से दूर रहने के बाद मैं हमेशा ऑब्जेक्ट कॉपी करने के साथ ठोकर खाता हूं;)

@monsieurnebo मैं आपके समाधान के साथ खेल रहा हूं और ऐसा लगता है कि आपको अभी भी react-i18next एचओसी के साथ लिपटे सभी घटकों को घटक में कुछ भी प्रस्तुत करने के लिए जावास्क्रिप्ट की आवश्यकता है ...

क्या आप पुष्टि कर सकते हैं कि क्या यह आपके अंत में काम कर रहा है?

संपादित करें: बीटीडब्ल्यू मैंने एक उदाहरण के आपके उल्लेख को याद किया, यदि आपके पास समय है तो मुझे एक पूर्ण उदाहरण देखना अच्छा लगेगा।

@deltaskelta जब मेरे पास कुछ खाली समय होगा तो मैं एक उदाहरण दूंगा :)

@monsieurnebo क्या आप पुष्टि कर सकते हैं कि आपकी विधि HTML में स्ट्रिंग्स को स्थिर रूप से प्रस्तुत नहीं करती है और जावास्क्रिप्ट की आवश्यकता होती है?

हाँ, इसलिए यह पूरी तरह से "जीवन का स्थिर तरीका" नहीं है

मुझे एक प्लगइन पसंद आएगा जो इसके बजाय स्थिर टेक्स्ट उत्पन्न करता है।

ओह, अच्छा। एक स्थिर रेंडर जिस तरह से मुझे जाने की ज़रूरत है ...

मैं सोच रहा था, चूंकि आपके gatsby-node में अधिकांश पृष्ठों के लिए संदर्भ पहले से ही भाषा के नाम के साथ पारित हो चुके हैं, तो यह बहुत कठिन नहीं होगा कि वे प्रत्येक पृष्ठ के लिए ग्राफ़िकल प्रश्नों में संदेश कुंजी मांगें और उन्हें इस तरह से पास करें, लेकिन यदि संभव हो तो मैं एक i18n टूल का उपयोग सभी तरह से करूंगा ...

@szimek react-intl बिल्ड चरण पर अनुवाद कैसे प्रस्तुत कर रहा है और किसी जेएस का उपयोग नहीं कर रहा है?

जैसा कि उल्लेख किया गया है, जहाँ तक मैं देख सकता हूँ Gatsby-plugin-i18n स्थिर पाठ उत्पन्न करता है। क्या आपने इसका उदाहरण देखा?

@deltaskelta ठीक है, सभी अनुवाद निर्माण समय के दौरान उपलब्ध हैं (इसीलिए मैं कई लेआउट का उपयोग कर रहा हूं), इसलिए यह "बस काम करता है" ™️;) मुझे उम्मीद है कि यह v2 में काम करता रहेगा ... मैं एक नमूना ऐप तैयार कर सकता हूं यदि आप चाहते हैं। मैंने वास्तव में अभी तक gatsby-plugin-i18n नहीं देखा है, क्योंकि मैं सामग्री के साथ काम कर रहा हूं, फाइलों के साथ नहीं।

मैंने विवरण नहीं पढ़ा है, लेकिन यहाँ gatsby-plugin-i18n + सामग्रीपूर्ण कॉम्बो के बारे में एक चर्चा (या बल्कि एक मोनोलॉग) है: https://github.com/angeloocana/gatsby-plugin-i18n/issues/31

@szimek मुझे एक उदाहरण में बहुत दिलचस्पी होगी। @sedubois मुझे पता है कि gatsby-plugin-i18n भी स्थिर पाठ उत्पन्न करता है, लेकिन मैं यह नहीं देखता कि जादू कहाँ होता है जो i18next में पूरी तरह से स्थिर फ़ाइलों को उत्पन्न करने के लिए गायब है ....

मुझे लगता है कि मैं देख सकता है क्यों अब ... आप गुजर रहे हैं react-intl के माध्यम से संदेश pathContext में gatsby-node प्रस्तुत करना दौरान?

संपादित करें: यदि यह मामला है (जो समझ में आता है), तो उपयोग की गई i18n लाइब्रेरी "कुछ हद तक" अप्रासंगिक है क्योंकि कोई संदर्भ के माध्यम से संदेशों को पारित कर रहा है और स्थिर रूप से प्रतिपादन कर रहा है जो एक शुद्ध गैट्सबी सेटअप है और i18n lib केवल विशेष मामलों को संभाल रहा है जैसे कि जेएस के साथ तिथियां और बहुवचन।

i18next और react-intl दोनों के आगे के परीक्षण पर ऐसा लगता है कि i18next के अनुवाद एचओसी को लोड करने के लिए जावास्क्रिप्ट की आवश्यकता होती है, इसलिए भले ही संदेशों को संदर्भ के माध्यम से पारित किया गया हो और स्थिर रूप से प्रस्तुत किया गया हो, अनुवाद एचओसी का कोई भी उपयोग चलाने के लिए जावास्क्रिप्ट की आवश्यकता वाले पूरे घटक को प्रस्तुत करेगा।

दूसरी ओर, react-intl का FormattedMessage घटक, एक डिफ़ॉल्ट संदेश प्रस्तुत करता है (जो इसे दिए गए संदर्भ के आधार पर आधारित हो सकता है) और निर्माण पर एचटीएमएल में स्थिर रूप से प्रस्तुत करता है।

डिज़ाइन के अनुसार मुझे लगता है कि i18n का अधिक प्राकृतिक एकीकरण प्रतिक्रिया-इंटल के साथ होगा यदि आप HTML में स्थिर रूप से प्रदान किए गए अनुवाद प्राप्त करना चाहते हैं। अगर मैंने आपके द्वारा उपयोग किए जा रहे प्रवाह को गलत समझा है तो कृपया मुझे सुधारें

@mattferderer का यहाँ सही विचार था, लेकिन मुझे लगता है कि इसे थोड़ा https://github.com/gatsbyjs/gatsby/issues/3830#issuecomment -362715706

लेआउट पृष्ठों से पहले प्रस्तुत किए जाते हैं, इसलिए एकाधिक लेआउट बनाए बिना createPages फ़ंक्शन से संदर्भ के माध्यम से संदेशों को पारित करने का कोई तरीका नहीं है (अगर मैं यहां गलत हूं तो मुझे सुधारें)। तो फिर, i18n को सबसे आसान बनाने के लिए मुझे लगता है कि लेआउट को केवल children() कॉल करना चाहिए और फिर प्रति भाषा प्रभाव अलग-अलग लेआउट gatsby-node अलग-अलग पथ-प्रति-भाषा बनाकर पूरा किया जाएगा। pages/index से अनुक्रमणिका पृष्ठ जो संदर्भ के माध्यम से संदेश पारित किए जा सकते हैं

संपादित करें: रामबल के लिए खेद है, लेकिन यह सब स्पष्ट हो गया और मुझे इसे कहीं रिकॉर्ड करना पड़ा

EDIT2: मैं निश्चित रूप से ऊपर गलत हूं, हेडर और फुटर को लेआउट में जाने की जरूरत है, मुझे नहीं पता कि कई लेआउट बनाए बिना उन्हें संदेश कैसे प्राप्त करें। एकमात्र अन्य तरीका जो मैं सोच सकता हूं कि यूआरएल को विभाजित करना और लोकेल के लिए रेगेक्सिंग करना होगा ... लेकिन ऐसा करने के लिए एक हैकी चीज की तरह लगता है

@KyleAMathews v2 में केवल एक लेआउट है, हम पथ या भाषा कुंजियों की एक सरणी के आधार पर संदर्भ के माध्यम से रूट लेआउट घटक को i18n संदेश जैसे डेटा कैसे पास कर सकते हैं?

यदि यह किया जा सकता है, तो i18n को कार्यान्वित करना आसान होगा, लेकिन मैं यह नहीं देख सकता कि एकाधिक लेआउट किए बिना इसे कैसे किया जाए

@deltaskelta हम जो कर रहे हैं उसका एक उदाहरण यहां दिया गया है: https://github.com/szimek/gatsby-react-intl-example। यह दिखाता है कि अलग-अलग पोस्ट कैसे प्रस्तुत करें, प्रत्येक लोकेल के लिए इंडेक्स पेज कैसे बनाएं, react-intl घटकों का उपयोग कैसे करें, शीर्षक सेट करने के लिए react-intl injectIntl HOC का उपयोग कैसे करें (या कोई अन्य मेटा टैग) intl.formatMessage सहायक आदि का उपयोग करके अनुक्रमणिका पृष्ठों के लिए।

उत्पन्न पृष्ठ हैं:

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

वास्तविक ऐप में हम gatsby-pagination संशोधित संस्करण का उपयोग कर रहे हैं, क्योंकि मूल संस्करण लेआउट विकल्प का समर्थन नहीं करता है। हम प्रत्येक पोस्ट के लिए post_id फ़ील्ड भी सेट करते हैं जो हमें उसी पोस्ट के अनुवाद खोजने की अनुमति देता है, उदाहरण के लिए इस डेमो ऐप के मामले में, दोनों पोस्ट में समान post_id ।

बीटीडब्ल्यू। मुझे अभी-अभी एहसास हुआ कि हमें प्रत्येक भाषा के लिए अलग-अलग साइटमैप बनाने की आवश्यकता होगी, ताकि स्विफ्टटाइप (हम जिस खोज इंजन का उपयोग करते हैं) को पता चले कि हमें कौन से पृष्ठ मिले हैं।

@deltaskelta संक्षेप में आपके पास प्रत्येक भाषा के लिए पृष्ठ घटक होंगे और फिर प्रति भाषा एक लेआउट घटक होगा। यहाँ एक तरीका है जिससे आप ऐसा कर सकते हैं।

// 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 टेम्पलेट्स की आवश्यकता होगी? :)

उपरोक्त इसे करने का सबसे अनुकूलित तरीका है। यदि प्रत्येक लेआउट घटक इतना भिन्न नहीं है, तो आप उन्हें एक लेआउट घटक में संयोजित कर सकते हैं और फिर किस भाषा के सक्रिय होने के आधार पर लेआउट स्विच कर सकते हैं।

मैंने विवरण नहीं पढ़ा है, लेकिन यहाँ gatsby-plugin-i18n + सामग्रीपूर्ण कॉम्बो के बारे में एक चर्चा (या बल्कि एक एकालाप) है: Angeloocana/gatsby-plugin-i18n#31

@sedubois , हाहा, हाँ। सारांश: यह काम कर रहा है और इस पीआर के माध्यम से गैट्सबी डॉक्स में gatsby-starter-contentful-i18n स्टार्टर रेपो शामिल है: https://github.com/gatsbyjs/gatsby/pull/4138

उपरोक्त अन्य समाधान में रुचि रखते हैं, विशेष रूप से यह समुदाय प्लगइन की तुलना कैसे करता है: एसईओ, आदि।

@mccrodp आपका समाधान मेरे जैसा ही दिखता है, मुख्य अंतर यह है कि gatsby-plugin-i18n लिए आपको layout विकल्प को स्पष्ट रूप से पास करने की आवश्यकता नहीं है createPage , लेकिन यह आपके लिए करता है पर्दे के पीछे। हालाँकि, यह अभी भी कई लेआउट का उपयोग कर रहा है;)

मैं @KyleAMathews सुझाव के साथ गया हूँ और एक components/Layout है जो i18n lib का उपयोग करता है और मेरे 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>
  );
};

मुझे इस कोड को साफ और पुनर्गठित करना है क्योंकि मैंने यह साबित करने के लिए जल्दी किया कि यह काम कर सकता है और मैं इसे बाद में फिर से देखने जा रहा हूं ... मुझे आशा है कि इससे आपको इसका सार मिल जाएगा

मैंने एक गैट्सबी स्टार्टर बनाया जो संदेशों का अनुवाद करने के लिए जेएस-लिंगुई का उपयोग करता है:
https://github.com/dcroitoru/gatsby-starter-i18n-lingui

वास्तविक ऐप में हम गैट्सबी-पेजिनेशन के एक संशोधित संस्करण का उपयोग कर रहे हैं, क्योंकि मूल संस्करण लेआउट विकल्प का समर्थन नहीं करता है। हम प्रत्येक पोस्ट के लिए पोस्ट_आईडी फ़ील्ड भी सेट करते हैं जो हमें एक ही पोस्ट के अनुवाद खोजने की अनुमति देता है, उदाहरण के लिए इस डेमो ऐप के मामले में, दोनों पोस्ट में एक ही पोस्ट_आईडी होगी।

@szimek क्या कोई मौका है कि आप अपना संशोधित गैट्सबी-पेजिनेशन साझा कर सकें? मैं इसे देखने के लिए बहुत उत्सुक हूं क्योंकि मैं स्वयं भी इसी तरह की समस्या का सामना कर रहा हूं।

@martynhoyer My पैच का विलय कर दिया गया है, इसलिए मैंने gatsby-pagination के मूल संस्करण पर वापस स्विच किया। आपको क्या समस्या है?

नमस्ते @sgoudie
मैं इस ट्यूटोरियल का उपयोग कर रहा हूं: https://www.gatsbyjs.org/blog/2017-10-17-build-i18n-with-gatsby/ लेकिन मुझे अपना कोई भी locales/{lang}/*.json नहीं मिल रहा है। क्या किसी के पास कोई सुराग है?

मेरा विन्यास:
gasbty-node.js
```javascriptexports.onPostBuild = () => {
कंसोल.लॉग ('स्थानों की प्रतिलिपि बनाना')
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

@ थियागो मिरांडा मैं उसी मुद्दे का सामना कर रहा था, तब मुझे एहसास हुआ कि gatsby develop पोस्टबिल्ड पर कॉल नहीं करता है, केवल 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" />

फिलहाल, जैसा आपने कहा, उन पंक्तियों को हर टेम्पलेट में कॉपी करें।

मैं केवल प्रतिक्रिया/जावास्क्रिप्ट के साथ विकास करना शुरू कर रहा हूं लेकिन मैंने i18n का समर्थन करने के लिए जो कुछ भी देखा है वह बहुत जटिल था। यहाँ सबसे आम उपयोग के लिए मेरा अपना काम है: बुद्धिमान-स्टार्टर

लाइव रीलोड, SEO फ्रेंडली और डिफ़ॉल्ट भाषाएं url में कुंजी का उपयोग नहीं करती हैं।
सभी .js पेज सभी भाषाओं के लिए जेनरेट किए जाते हैं।
त्रुटियों को रोकने के लिए सभी भाषाओं के लिए सभी लेआउट और .md बनाए जाने चाहिए।
LangSelect और Link घटक i18n स्मार्ट हैं।

यदि आप मेरी मदद कर सकते हैं और मुझे समझा सकते हैं कि मैं अपने कोड और शैली को कैसे सुधार सकता हूं तो मैं आभारी रहूंगा।

@ टॉम-पिचौड, मेरा मानना ​​​​है कि चूंकि आप पृष्ठ घटकों के माध्यम से संदेश नहीं भेज रहे हैं, इसलिए उन्हें वहां स्थिर रूप से प्रस्तुत नहीं किया जाएगा।

gatsby-node में मार्कडाउन i18n सेटअप वैसा ही दिखता है जैसा लोग यहां कर रहे हैं, लेकिन मैं उत्सुक हूं कि क्या आप अपने पेज घटकों पर जावास्क्रिप्ट अक्षम के साथ स्थिर प्रतिपादन प्राप्त कर रहे हैं?

हाँ, मुझे स्थिर प्रतिपादन मिलता है, वैसे भी मेरा उद्देश्य यही था, i18n-react चाल है!

@TomPichaud क्या आपके लिए यह साझा करना संभव होगा कि आपके द्वारा उल्लिखित i18n- प्रतिक्रिया कैसे है ?

एक चीज जो मुझे नहीं मिल रही है, वह है अनुवादित संदेशों को लोड करने के लिए बाहरी पैकेजों की वास्तविक आवश्यकता (बहुवचन और रिश्तेदारों के अलावा, शायद)।

स्थिर सामग्री वाली एक साधारण साइट के लिए मैं बस प्रत्येक भाषा 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()
  })
}

फिर, वास्तविक पृष्ठ पर, मैं ग्राफ़िकल के फ़िल्टर का उपयोग करके सामग्री को क्वेरी करने के लिए संदर्भ में लोकेल का उपयोग करता हूं।

मान लें कि मेरे पास /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 फ़ाइलों में छवियां (हालांकि हमें सापेक्ष पथ के साथ एक नया NodeField बनाने की आवश्यकता है ताकि Gatsby का फाइल सिस्टम इसे प्राप्त कर सके)

क्या यह ज्यादातर मामलों के लिए पर्याप्त नहीं है?

मैं अभी भी परीक्षण कर रहा हूं और उत्पादन में इसका कोई उपयोग नहीं किया है, लेकिन मैं स्थानीय लिंक जैसे कुछ लंबित मुद्दों को हल करने के लिए लोकेल के लिए प्रतिक्रिया के संदर्भ एपीआई का उपयोग करने के बारे में सोच रहा हूं

@pbrandone यह मेरे लिए एक अच्छा तरीका प्रतीत होता है। मुझे लगता है कि कुछ ऐसा ही आधिकारिक तौर पर प्रलेखित किया जाना चाहिए।

सभी इनपुट के लिए धन्यवाद, यहां चर्चा की गई विचारों की मात्रा स्पष्ट रूप से अच्छी तरह से प्रलेखित i18n समर्थन की मांग को दर्शाती है।

@pbrandone क्या इसका मतलब है कि आपको इस क्वेरी में IndexPage में किसी भी बच्चे के घटकों द्वारा उपयोग की जाने वाली सभी चाबियों को स्पष्ट रूप से निर्दिष्ट करना होगा और प्रोप के माध्यम से सभी घटकों में अनुवाद पास करना होगा?

इसके अलावा, मैं बहुवचन नियमों और सापेक्ष तिथियों का उपयोग करता हूं, इसलिए मुझे वैसे भी अतिरिक्त लोकेल विशिष्ट डेटा लोड करना होगा: /

हालांकि, मैं मानता हूं कि आधिकारिक दस्तावेज होना बहुत अच्छा होगा कि साधारण मामलों के लिए बिना किसी पुस्तकालय के i18n कैसे करें और फिर इसे सबसे लोकप्रिय पुस्तकालयों के साथ कैसे करें।

@szimek ठीक है, इस मामले में हाँ।

प्रतिक्रिया-इंटल (या कोई अन्य 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 डेटा को ग्राफ़िकल की शक्ति के साथ क्वेरी और ट्रांसफ़ॉर्म करने में सक्षम होंगे।
उदाहरण के लिए, ग्राफ़िकल दृष्टिकोण के साथ, हमारे पास उन JSON फ़ाइलों में छवियों के लिए पथ के साथ कुछ कुंजियाँ हो सकती हैं, जो प्रति स्थान अलग-अलग छवियों को लोड कर सकती हैं और फिर भी उन पर gatsby-image का उपयोग करने में सक्षम हो सकती हैं।
और फिर उन JSON फ़ाइलों को संपादित करने के लिए netlify CMS जोड़ें

Gatsby v2 को ठीक से नहीं देखा है, लेकिन स्पष्ट रूप से एक StaticQuery घटक है जो हमें बाल घटकों में क्वेरी करने की अनुमति देता है (अगर मैं गलत हूं तो कोई मुझे सही करेगा!)

अगर ऐसा है, तो हम लोकेल को कहीं भी उपलब्ध कराने के लिए एक रिएक्ट कॉन्टेक्स्ट बना सकते हैं और फिर लोकेल फ़िल्टरिंग के साथ प्रत्येक घटक में आवश्यक कुंजियों को क्वेरी कर सकते हैं।

@pbrandone आप सही हैं, यह उस तरह से स्थिर रूप से प्रस्तुत करता है। मुझे अतीत में इसका परीक्षण करना और असफल होना याद है, लेकिन इससे पहले कि मुझे गैट्सबी कैसे काम करता है, इसकी एक अच्छी समझ थी, मेरे पास गैट्सबी ब्राउज़र में मेरा react-intl सेटअप हो सकता है जो ऐसा लगता है कि यह जावास्क्रिप्ट के बिना प्रस्तुत नहीं हो सकता है। मेरा समाधान अब आपके जैसा दिखता है

@KyleAMathews मैं अपने पेज को react-intl सेटअप और ग्राफ़िकल प्रश्नों के साथ एक समस्या है।

मैंने पहले बताया था कि मैं Gatsby v1 - https://github.com/szimek/gatsby-react-intl-example में भाषा डेटा लोड करने के लिए भाषा-विशिष्ट लेआउट का उपयोग कैसे करता हूं 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 विकल्प के रूप में पास कर रहा हूं, लेकिन ग्राफ़िकल क्वेरी में है भाषा-अज्ञेय घटक, क्योंकि यह __ बिल्कुल सभी भाषाओं के लिए समान है__ (यह locale पर निर्भर करता है, लेकिन मैं इसे context में पास कर रहा हूं)। मैं इन सभी भाषा-विशिष्ट घटकों में ठीक उसी क्वेरी को दोहराने से बचना चाहूंगा।

कोई विचार इसे कैसे हल करें? क्या मैं इस क्वेरी को एक चर में निकाल सकता हूं? जब मैंने इसे आजमाया, तो गैट्सबी ने क्वेरी और टुकड़े के नाम समान होने की शिकायत की ...

मैंने हाल ही में बहु-भाषा url मार्गों और ब्राउज़र भाषा का पता लगाने की सुविधाओं के साथ एक डिफ़ॉल्ट Gatsby स्टार्टर जोड़ा है। (प्रदर्शन)

गैट्सबी-स्टार्टर-डिफॉल्ट-इंटल

विशेषताएं:

• प्रतिक्रिया-इंटल द्वारा प्रदान किया गया स्थानीयकरण (बहुभाषा)।

• ब्राउज़र-लैंग द्वारा प्रदान किए गए

• एकल पृष्ठ घटक के भीतर बहु-भाषा url मार्गों का समर्थन करें। इसका मतलब है कि आपको pages/en/index.js या pages/ko/index.js जैसे अलग पेज बनाने की जरूरत नहीं है।

• कम से कम संशोधन के साथ गैट्सबी-स्टार्टर-डिफॉल्ट पर आधारित।

@wiziple धन्यवाद! यह वाकई दिलचस्प लग रहा है। मुझे नहीं पता था कि आप ऐसा कुछ कर सकते हैं: https://github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L38 ;) उम्मीद है, यह अभी भी काम करता है वेबपैक 4 में...

क्या यहां उसी तरह लोकेल डेटा लोड करना संभव है https://github.com/wiziple/gatsby-starter-default-intl/blob/master/src/i18n/withIntl.js#L6 ? हम 6 (जल्द ही 7 भाषाओं) का समर्थन करते हैं, इसलिए यह बहुत अच्छा होगा यदि मैं केवल उसी को लोड कर सकूं जिसके लिए मैं पेज बना रहा हूं। यदि यह संभव नहीं है तो यह कोई बड़ी बात नहीं है - सौभाग्य से, ये स्थानीय डेटा फ़ाइलें अपेक्षाकृत छोटी हैं।

मुझे यह भी देखना होगा कि आप इन पृष्ठों को कैसे उत्पन्न करते हैं, क्योंकि मेरे मामले में प्रत्येक पृष्ठ का सभी भाषाओं में अनुवाद नहीं किया जाता है (कोई एक "स्रोत" भाषा नहीं है), इसलिए onCreatePage साथ समाधान शायद काम नहीं करेगा मेरे मामले में।

उम्मीद है, यह मेरी समस्या को हर भाषा-विशिष्ट पृष्ठ घटक में समान ग्राफ़िकल क्वेरी के साथ हल करेगा।

@szimek
मेरे द्वारा प्रबंधित वेबसाइट में 14 भाषाएँ हैं और प्रत्येक भाषा फ़ाइल 12-15 KB की है। मुझे पूरा यकीन है कि हमें SEO डेटा जेनरेट करने के लिए बिल्ड टाइम पर प्रत्येक भाषा राउटर के लिए सही भाषा प्रदान करने की आवश्यकता है। तो मुझे यकीन नहीं है कि मैं सभी भाषाओं को प्रदान किए बिना इसे कैसे संभाल सकता हूं।

मैं समझता हूं कि कभी-कभी प्रत्येक पृष्ठ को सभी भाषाओं में अनुवादित करना कठिन होता है। आप onCreatePage में gatsby-node.js कुछ अपवाद प्रदान करके इसे हल करने में सक्षम हो सकते हैं। मेरे मामले में, मैंने भाषा राउटर की परवाह किए बिना अनुवादित भाषा की पेशकश न करके बस हल किया। आप स्टार्टर README.md से प्रोडक्शन पर शोकेस वेबसाइट पा सकते हैं और इसके प्रदर्शन की जांच कर सकते हैं।

@wiziple बहुत बहुत धन्यवाद!

मैंने अनुवाद के लिए गतिशील require चाल के साथ आपके withIntl घटक का उपयोग किया है (मुझे नहीं पता कि इसका उपयोग करने के लिए कोई नुकसान है या नहीं) और ऐसा लगता है कि यह बहुत अच्छा काम करता है। इसने उस समस्या को हल कर दिया जिसके साथ मैं संघर्ष कर रहा था - एक ही ग्राफ़िकल क्वेरी को एकाधिक भाषा-विशिष्ट पृष्ठ घटकों में कैसे प्रबंधित करें - सभी भाषाओं के लिए एक पृष्ठ घटक होने से।

@wiziple रेपो शेयर के लिए धन्यवाद। मुझे सही रास्ते पर ले आया

लिंगुई एक बेहतर विकल्प प्रतीत होता है। मुझे नहीं लगता कि @dcroitoru को एक बेहतरीन उदाहरण के लिए उचित पहचान मिली है। इसे Gatsby 2.0 में धकेलने के लिए बस थोड़े से प्यार की जरूरत है

मैं मानता हूं कि लिंगुई वास्तव में वास्तव में अच्छा है, हालांकि अभी भी एक पूर्ण स्टार्टर की जरूरत है, गैट्सबी के नवीनतम संस्करण के साथ, लेकिन लिंगुई के साथ भी। उल्लिखित स्टार्टर अनौपचारिक है और पिछली बार जब मैंने जांच की थी तो कुछ सुविधाएं गायब थीं (उदाहरण के लिए फ्लाई पर लिंगुई संकलन चलाने के लिए लोडर का उपयोग करना)। लिंगुई के लेखक @tricoder42 ने कहा कि जब लिंगुई v3 (जो जल्द ही प्रतीत होता है) के बाहर होने पर वह दस्तावेज़ीकरण प्रदान करेगा।

एनबी: मैंने देखा है कि एक सीएमएस (डाटोसीएमएस) को एकीकृत करने के बाद i18n लाइब्रेरी की मेरी आवश्यकता कम हो गई है, लेकिन मुझे अभी भी कुछ स्ट्रिंग्स के लिए लिंगुई की आवश्यकता है जो सीएमएस में अपनी जगह नहीं पाते हैं और बहुवचन और संभवतः बाद में अन्य चीजों के लिए भी मैं निश्चित रूप से इसे मेरे कोडबेस में रखना चाहते हैं।

किसी भी तरह मेरे मामले में गैट्सबी-प्लगइन-आई18एन के अस्तित्व ने चीजों को काफी भ्रमित कर दिया क्योंकि यह गैर-रखरखाव है, एक भ्रमित नाम है, और जेएस-लिंगुई और सीएमएस जैसे इन अन्य वास्तव में अच्छे समाधानों से ध्यान खींचता है जिसे मैंने लिया था जबकि एक साथ पता लगाने और इकट्ठा करने के लिए।

बस आप लोगों की मदद के लिए यह स्टार्टर बनाया है: https://github.com/smakosh/gatsby-starter-i18n
लेख: https://dev.to/smakosh/implement-i18n-to-a-gatsby-site-5ala

मैंने प्रतिक्रिया-अंतर्राष्ट्रीय एकीकरण के साथ दो अंतर्राष्ट्रीयकरण उदाहरण बनाए हैं

पहला उदाहरण जेएस विखंडू में केवल वर्तमान अनुवादों को बंडल करने पर केंद्रित है (कुछ ऐसा जो मुझे अन्य प्लगइन्स में नहीं मिला जो मैंने चेक किया था)।

दूसरा उदाहरण दिए गए पृष्ठ/भाषा संयोजन के लिए केवल अनुरोधित अनुवाद प्रदान करने के लिए गतिशील प्रश्नों का उपयोग करने पर ध्यान केंद्रित करता है।

उम्मीद है, यह उदाहरण किसी के लिए उपयोगी होगा।

https://github.com/gatsbyjs/gatsby/issues/3853#issuecomment -395432693 (यद्यपि थोड़ा अधिक गहराई में) के साथ एक त्वरित माध्यम पोस्ट भी बनाया (और इसे यहां पोस्ट करना भूल गया)।

https://blog.significa.pt/i18n-with-gatsby-528607b4da81 रुचि रखने वालों के लिए

30 दिनों की निष्क्रियता के बाद पुराने मुद्दे बंद हो जाएंगे। यह मुद्दा 20 दिनों से शांत है और इसे पुराने के रूप में चिह्नित किया जा रहा है। इस मुद्दे को खुला रखने के लिए यहां उत्तर दें या "बासी नहीं" लेबल जोड़ें!

हेलो दोस्तों, लगभग एक साल हो गया है

मैंने हाल ही में नया गैट्सबी प्लगइन गैट्सबी-प्लगइन-इंट्ल जारी किया है जो आसानी से आपकी गैट्सबी वेबसाइट को एक अंतरराष्ट्रीयकरण ढांचे के रूप में बॉक्स से बाहर कर देता है।

डेमो: https://gatsby-starter-default-intl.netlify.com

• आउट ऑफ़ बॉक्स अंतर्राष्ट्रीयकरण-ढांचा react-intl द्वारा संचालित

• ब्राउज़र में उपयोगकर्ता की पसंदीदा भाषा के आधार पर स्वचालित पुनर्निर्देशन का समर्थन करें

• एकल पृष्ठ घटक में बहु-भाषा url मार्गों का समर्थन करें। इसका अर्थ है कि आपको pages/en/index.js या pages/ko/index.js जैसे अलग पृष्ठ बनाने की आवश्यकता नहीं है।

• जैसा कि आप में से कुछ लोगों ने ऊपर सुझाव दिया है, अब यह निर्माण समय के दौरान केवल वर्तमान भाषा को बंडल करता है।

साथ ही, मैं यह उल्लेख करना चाहता हूं कि कई i18n उदाहरण/शुरुआत वास्तव में क्लाइंट साइड पर प्रस्तुत किए जाते हैं। यह जांचने का सबसे अच्छा तरीका है कि ऐप को एसएसआर के रूप में प्रस्तुत किया गया है या नहीं, स्रोत कोड देख रहा है और जांच कर रहा है कि स्थानीयकृत ग्रंथ मौजूद हैं या नहीं। जब आप SEO के लिए अपनी gatsby वेबसाइट का अंतर्राष्ट्रीयकरण करते हैं, तो कृपया इस मामले की दोबारा जाँच करें।

हेलो दोस्तों, लगभग एक साल हो गया है

मैंने हाल ही में नया गैट्सबी प्लगइन गैट्सबी-प्लगइन-इंट्ल जारी किया है जो आसानी से आपकी गैट्सबी वेबसाइट को एक अंतरराष्ट्रीयकरण ढांचे के रूप में बॉक्स से बाहर कर देता है।

डेमो: https://gatsby-starter-default-intl.netlify.com

• आउट ऑफ़ बॉक्स अंतर्राष्ट्रीयकरण-ढांचा react-intl द्वारा संचालित
• ब्राउज़र में उपयोगकर्ता की पसंदीदा भाषा के आधार पर स्वचालित पुनर्निर्देशन का समर्थन करें
• एकल पृष्ठ घटक में बहु-भाषा url मार्गों का समर्थन करें। इसका अर्थ है कि आपको pages/en/index.js या pages/ko/index.js जैसे अलग पृष्ठ बनाने की आवश्यकता नहीं है।
• जैसा कि आप में से कुछ लोगों ने ऊपर सुझाव दिया है, अब यह निर्माण समय के दौरान केवल वर्तमान भाषा को बंडल करता है।

साथ ही, मैं यह उल्लेख करना चाहता हूं कि कई i18n उदाहरण/शुरुआत वास्तव में क्लाइंट साइड पर प्रस्तुत किए जाते हैं। यह जांचने का सबसे अच्छा तरीका है कि ऐप को एसएसआर के रूप में प्रस्तुत किया गया है या नहीं, स्रोत कोड देख रहा है और जांच कर रहा है कि स्थानीयकृत ग्रंथ मौजूद हैं या नहीं। जब आप SEO के लिए अपनी gatsby वेबसाइट का अंतर्राष्ट्रीयकरण करते हैं, तो कृपया इस मामले की दोबारा जाँच करें।

अरे @wiziple इसके लिए बहुत बहुत धन्यवाद, मैं
हो सकता है कि मुझे बात समझ में न आई हो, लेकिन क्या आपके पास सिर्फ एक फाइल में एक भाषा के सभी तार हैं?
क्या घटकों की समान संरचना का उपयोग करके, प्रत्येक भाषा के JSON को अधिक फ़ाइलों में विभाजित करना संभव होगा?

@ cant89 मैं आपकी बात gatsby develop या gatsby build में हुक करें।
एक बार जब आप सभी JSON फ़ाइलें प्राप्त कर लेते हैं और एक नेस्टेड ऑब्जेक्ट के रूप में मर्ज हो जाते हैं, तो आप इसे एक फ़्लैटन ऑब्जेक्ट के रूप में भी परिवर्तित कर सकते हैं।
https://github.com/yahoo/react-intl/wiki/Upgrad-Guide#flatten -messages-object

हमारे पास i18n के लिए एक अच्छा उदाहरण सेटअप है। https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n। हम वास्तव में i18n ढांचे पर कोई राय नहीं रखते हैं। बस अपनी पसंद के हिसाब से एक चुनें।

हमारे पास i18n के लिए एक अच्छा उदाहरण सेटअप है। https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n। हम वास्तव में i18n ढांचे पर कोई राय नहीं रखते हैं। बस अपनी पसंद के हिसाब से एक चुनें।

बढ़िया, धन्यवाद, मैं कोशिश करने वाला हूँ!
वैसे भी रीडमी पर लिंक टूटा हुआ है, शायद आपका मतलब https://using-i18n.netlify.com/ है ?

@wardpeet क्या आपका उदाहरण स्थिर अनुवादित तार (बिल्ड टाइम पर) उत्पन्न करता है? या यह रनटाइम के दौरान टेक्स्ट उत्पन्न करता है?

@monsieurnebo बिल्ड टाइम जैसा दिखता है

@ cant89 हम अभी भी डीएनएस को अपडेट कर रहे हैं, इसलिए यह अभी के लिए जल्द ही तैयार है-i18n.netlify.com/ सही लिंक है।

@monsieurnebo यह निर्माण के समय पर है। यह प्रत्येक भाषा के लिए आपकी वेबसाइट की एक प्रति बनाता है ताकि सब कुछ स्थिर रूप से बनाया जा सके। इसका मतलब है कि आपकी वेबसाइट तेज रहती है क्योंकि सब कुछ सिर्फ एक .html है।

सुनिश्चित नहीं है कि यह और कहां पूछना है लेकिन थोड़ा प्रासंगिक है। क्या इनमें से कोई भी प्लगइन गैट्सबी के 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.

हम्म दिलचस्प, मुझे लगता है कि पूर्व आमतौर पर अधिक समझ में आता है, हालांकि पथप्रिफ़िक्स आपके डोमेन को domain.com/prefix बनाने की तरह है, इसलिए जब आप एक उपनिर्देशिका में Gatsby स्थापित करते हैं, तो रूट को बदलना, यदि आप इसे स्थापित नहीं करते हैं एक उपनिर्देशिका जिसकी आपको आवश्यकता नहीं है, यदि आप उपसर्ग को बदलने वाली उपनिर्देशिका का उपयोग करते हैं, तो भाषा इसे तोड़ देगी।

अब सवाल आता है कि आप पहले स्थान पर pathPrefix का उपयोग क्यों कर रहे हैं?

संदर्भ: पथप्रीफिक्स डॉक्स

नमस्ते,

यहाँ अधिकांश चर्चाएँ इस बारे में हैं कि कैसे एक गैट्सबी साइट को i18n करें। लेकिन POC के काम करने और एक अनुकूलित उत्पादन तैयार प्रणाली होने के बीच अंतर है।

यदि आप कोड विभाजन और i18n फ़ाइलों के बारे में अधिक पढ़ने में रुचि रखते हैं, और इस थ्रेड में अधिकांश समाधान अनुकूलित क्यों नहीं हैं, तो आपको यह समस्या उपयोगी लगेगी