Closed jitendravyas closed 7 years ago
Yeah, as Maxime said, there's nothing special about Gatsby here for building multi-language sites. Perhaps one day someone will create a Gatsby multi-lang plugin which will streamline the process but it should be quite doable now.
On Wed, Jun 8, 2016 at 2:29 AM Maxime Thirouin notifications@github.com wrote:
I think it's up to you. You can use something like react-intl https://github.com/yahoo/react-intl and your own data. For example http://putaindecode.io/ is a multilingual website (not build with gatsby but phenomic - but the way to handle this remains the same) and "just" have 2 yaml files with same keys for dynamic parts. Nothing really specific to the generator you will use.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gatsbyjs/gatsby/issues/308#issuecomment-224537451, or mute the thread https://github.com/notifications/unsubscribe/AAEVh_htEqWXE9s9in-l4fb6RWKrNPgoks5qJouOgaJpZM4IsNkc .
Was there any specific part that you're struggling with?
Contentful has provisions for multi-lingual content. might be an interesting way to go https://www.contentful.com/features/
although I myself am still trying to get my head around how to integrate it with Gatsby!
although I myself am still trying to get my head around how to integrate it with Gatsby!
The possible solution could be to create a contentful-loader
for webpack. A relatively unknown feature of webpack is that loaders can be requested without the underlying resource:
var entries = require('contentful?query=/entries!')
Notice that ''
goes after the !
.
btw just created the first [gatsby] tag for you on github
http://stackoverflow.com/questions/37816952/how-to-handle-contentful-content-data-in-gatsby
@Maxhodges nice! Put a quick answer over there. Thanks for doing that. I don't have enough Stackoverflow cred to make new tags so hadn't been pushing people there. Probably time to start doing that as questions about Gatsby start to tick up.
One quick single-page, "gatsby-only" solution I used for a site with multiple languages is to use YAML files for your language data like:
acn/pages/
├── _template.jsx
├── en
│ └── index.yaml
├── es
│ └── index.yaml
└── index.yaml
Then, use the wrappers/yaml.js
to wrap each data file with your page component(s):
const { data } = this.props.route.page
return (
<DocumentTitle title={`${data.title || config.siteTitle}`}>
<LandingPage>
data={data}
/>
</DocumentTitle>
)
For multiple pages, maybe there is a way to incorporate the _template.jsx
? But I think _template.jsx
currently wraps the wrappers, so that might be a problem worth solving in Gatsby 1.x/2.x...
Up Up.
Have a look here: https://github.com/gatsbyjs/gatsby/issues/688#issue-209287346
I can make it work on develop but unable to build at the moment trying to solve that problem, then it should be fine and working great I think. (improvable of course)
Conversation seems finished up. Cleaning up and closing.
Don't know if this is a good place to ask about this(since it's closed).
I've been in discussions regarding google indexing pages using client i18n solutions such as react-i18next
and I've yet to understand this properly.
I'll use gatsby-plugin-i18n
to achieve SEO friendly routes such as /en/
, which leaves the actual translations up to me to decide on a library.
If I follow the official gatsby blog post regarding i18n I'm left with a solution that fetches translations after the initial page load, which I assume is problematic from a SEO standpoint(I'm only talking about the localized strings, not the routes). Is this true, and if so, how would I go about solving it?
Discussions I've found:
If I follow the official gatsby blog post regarding i18n I'm left with a solution that fetches translations after the initial page load, which I assume is problematic from a SEO standpoint(I'm only talking about the localized strings, not the routes). Is this true, and if so, how would I go about solving it?
you can check is it working or not via. https://www.google.com/webmasters/tools/googlebot-fetch?pli=1
it actually depends on what are you trying to build. my current approach is using react-intl
and gatsby-plugin-i18n
together. so i keeping the content of the pages in gatsby-plugin-i18n
and for everything else in react-intl
.
so all my menu/footers translated via react-intl
@Necmttn does your site has a "default language"?
I'm willing to use the gatsby-plugin-i18n
but it obligates to use url/lang/route
. I was thinking in use url/route
for my default language and url/lang/route
only for other languages. There's a discussion about it ( that I've posted ) here:
https://github.com/angeloocana/gatsby-plugin-i18n/issues/27
@ThiagoMiranda Yeah, mine does.
basically
when you open http://necmttn.io/
it redirects to your browser default language.
if your browsers default language is not the language I'm translated. it falls back to default English.
@Necmttn but you couldn't get rid off the /$language/route
, right?
yeah.. it's redirects to /$language/route eventually.
Storyblok's headless CMS is based on a folder structure which means you can just create a content folder for each language and generate paths like en/home, de/home, en/blog/article ...
Following a how to: www.storyblok.com/tp/gatsby-multilanguage-website-tutorial
I recently added a default Gatsby starter with features of multi-language url routes and browser language detection. (demo)
Features:
Localization (Multilanguage) provided by react-intl.
Automatic redirection based on user's preferred language in browser provided by browser-lang.
Support multi-language url routes within a single page component. That means you don't have to create separate pages such as pages/en/index.js
or pages/ko/index.js
.
Based on gatsby-starter-default with least modification.
I think it's up to you. You can use something like react-intl and your own data. For example http://putaindecode.io/ is a multilingual website (not build with gatsby but phenomic - but the way to handle this remains the same) and "just" have 2 yaml files with same keys for dynamic parts. Nothing really specific to the generator you will use.