3nvi / gatsby-intl

A collection of gatsby packages to easy the mundane tasks of i18n support
Other
28 stars 6 forks source link

Wish: make gatsby-plugin-intl compatible with "no SSR" scenarios (using deleteOriginalPages: false) #3

Closed EricCoteReact closed 4 years ago

EricCoteReact commented 4 years ago

This is what your project is built to do: http://asdf.com/page : activates some SSR code that rewrites the url to the right language http://asdf.com/en/page : The page in English http://asdf.com/fr/page : The page in French

But this is what my project requires: http://asdf.com/page : The page in English. http://asdf.com/fr/page : The page in French http://asdf.com/en/page : I don't need that page (but it's okay if an English page is returned)

French visitors will see the English page if they go directly to the default homepage. This is by design: they will have to click on a link to get to the French version. (If they go through a search engine, chances are that the French page /fr/page will be the page recommended.)

Using the deleteOriginalPages: false configuration, I mostly got what I needed. Thank you! Yay!

But there are some issues. The biggest one is gatsby-plugin-intl. This project uses Helmet to create link alternate hrefLang elements that are using the "ssr". But there are some problems:

1. It's using the wrong links:

The Link elements that are generated are compatible with the SSR way of doing things.

<link rel="canonical" href="http://asdf.com/en/" >
<link rel="alternate" href="http://asdf.com/" hreflang="x-default" >
<link rel="alternate" href="http://asdf.com/en/" hreflang="en" >
<link rel="alternate" href="http://asdf.com/fr/" hreflang="fr" >
<meta property="og:locale" content="en" >

But this is what I'd need to have:

<link rel="canonical" href="http://asdf.com/" >
<link rel="alternate" href="http://asdf.com/" hreflang="en" >
<link rel="alternate" href="http://asdf.com/fr/" hreflang="fr" >
<meta property="og:locale" content="en" > 

a) I don't need a x-default language. b) The default language doesn't need the /en/ routing

2. There's no way to specify the host in "no-ssr" scenarios.

gatsby-browser.js is wrapping gatsby-ssr.js. And the latter is using constants.js, which initializes the host name to localhost :8080 in "no SSR" scenarios. This is wrong. There should be a way to specify the host name in the gatsby-config file.

Take a look at the documentation for gatsby-plugin-robots-txt.

Using siteUrl works very well. (I was sure it didn't when I originally tried it. My bad!)

3. The links are not generated on first load

The links are not generated when I first get to the page. I need to follow a routing link first to generate the links in the Dom. This means that search engines won't get the headers.

EricCoteReact commented 4 years ago

An other alternative would be to have an option to disable the "Helmet" code generated by gatsby-plugin-intl. (Either an option called "noHelmet", or just disable when deleteOriginalPage:false)

That way, I'd just have to generate the helmet code myself in my own project. That would probably be the easiest workaround.

3nvi commented 4 years ago

Hey there,

there are a lot of stuff to answer, so I'll try my best.

That way, I'd just have to generate the helmet code myself in my own project.

That isn't what I would want for this project.

  1. It's using the wrong links

I agree that the default language doesn't need the /en/ only if deleteOriginalPages is false. If it's true, then you have to have it. If you feel like it, you can create a PR to fix that or I'll create an issue to do it myself soon.

From the official webmaster docs

Consider adding a fallback page for unmatched languages, especially on language/country selectors or auto-redirecting homepages. Use the the x-default value. This value is optional, but recommended, as a way for you to control the page when no languages match.

Can you help me understand why you do not want a fallback for when the language doesn't match? It will help me see the way forward

  1. There should be a way to specify the host name in the gatsby-config file.

I'm confused, doesn't siteUrl help? From the docs:

  • siteUrl: The URL of your site that's used when creating SEO tags. Defaults to the environment variable

and the related source code

  1. The links are not generated on first load

Are you still talking about a "no SSR" option? Cause the links should be there from gatsby build. Can you elaborate so that I can understand your use case and find out where the potential bug is?

Thanks!

EricCoteReact commented 4 years ago

Ok, here are few things:

  1. I was wrong. Using siteUrl works very well. (I was sure it didn't when I originally tried it. My bad!) I modified my original comment at the top to remove my comment.

  2. x-default is mostly for scenarios where you have a page where the users chooses the language. It doesn't use a specific language (for example, a home page that shows up flags.) This is not my scenario.

  3. I'll have to document this more. I'll give you more info later this week.

3nvi commented 4 years ago

@ReactAcademyCa sorry to bring this up again, but I'm trying to close all related issues with the repo.

Is there a chance you can let me know the problems you are facing to see if something can be done from the package's side?

Thanks in advance

P.S. With regards to your last comment:

x-default is mostly for scenarios where you have a page where the users chooses the language. It doesn't use a specific language (for example, a home page that shows up flags.) This is not my scenario.

I still don't consider, adding an x-default, to be an issue. Worst case if you ever don't support a language, this will trigger

3nvi commented 4 years ago

Closing due to inactivity. Feel free to re-open or file a different issue for future wishes and/or enhancements