microapps / gatsby-plugin-react-i18next

Easily translate your Gatsby website into multiple languages
MIT License
121 stars 72 forks source link

Default language not working as expected #89

Closed AnderUstarroz closed 2 years ago

AnderUstarroz commented 3 years ago

Summary of the issue

Default language not working as expected. Default language is set to Spanish (es), but the root page gets redirected to English (en)

Expected behavior

✅ When visiting the index page http://mysite.com/ it should load the page normally using the default language Spanish (es)

Current behavior

❗ When visiting the index page http://mysite.com/ it gets automatically redirected to http://mysite.com/en/

Setup details

The allowed languages for the site are:

Version used:

    "gatsby": "^3.10.1"
    "i18next": "^20.4.0"
    "react-i18next": "^11.11.4"
    "gatsby-plugin-react-i18next": "^1.1.1"

Gatsby configuration:

{
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `${__dirname}/locales`,
        name: `locale`,
      },
    },
    {
      resolve: `gatsby-plugin-react-i18next`,
      options: {
        localeJsonSourceName: `locale`,
        defaultLanguage: "es",
        languages: ["es", "fr", "en"],
        siteUrl: `http://mysite.com/`,
        i18nextOptions: {
          interpolation: {
            escapeValue: false,
          },
          keySeparator: false,
          nsSeparator: false,
        },
      },
    },

...
...
}    
peterschwarzdev commented 3 years ago

I am having the same issue, is the latest version of the plugin broken?

chenxizhang commented 3 years ago

same issue here, and very confusing about that

chenxizhang commented 3 years ago

In my case, I tested this scenario

  1. I have two languages, en and zh, en is the default language
  2. I loaded the page into browser, and confirmed the navigator.language will be en-us, but the page will load the "zh" resources, not "en"
chenxizhang commented 3 years ago

@peterschwarzdev @AnderUstarroz

I think I found the root cause, the plugin will store the language setting in the localstorage and then try to re-use it in the future, so if you test the page in one language, then even you change language of your browser, it will remain the old one.

You can see the code here

https://github.com/microapps/gatsby-plugin-react-i18next/blob/c6dabc14200a68003f7b02f934fa47bacabf539f/src/plugin/wrapPageElement.tsx#L49

I understood why use localstorage, but I think sessionstorage will be a better choice here.

As a workaround, On the top of the page, you can add this code to remove the localstorage first.

if (typeof window !== "undefined") { window.localStorage.removeItem("gatsby-i18next-language"); }

chenxizhang commented 3 years ago

I've created a pull request here https://github.com/microapps/gatsby-plugin-react-i18next/pull/91

AnderUstarroz commented 3 years ago

Hey @chenxizhang thanks for debugging, but I am not sure that is the root question of the issue, because I was continuously deleting LocalStorage but still when I was calling http://mysite.com/ (with empty LocalStorage) I was being redirected to http://mysite.com/en/ so it seems that when you set some default language instead of English (but having English as an available language) somehow defaults to English. 🤷‍♂️

Nonetheless If I remove "en" from the list of available languages, it works as expected:

// File: gatsby-config.js

{
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `${__dirname}/locales`,
        name: `locale`,
      },
    },
    {
      resolve: `gatsby-plugin-react-i18next`,
      options: {
        localeJsonSourceName: `locale`,
        defaultLanguage: "es",
        languages: ["es", "fr"],    <--- Removed "en" from the list
        siteUrl: `http://mysite.com/`,
        i18nextOptions: {
          interpolation: {
            escapeValue: false,
          },
          keySeparator: false,
          nsSeparator: false,
        },
      },
    },

...
...
}    
chenxizhang commented 3 years ago

You can try to add en-ES or es-ES to the "languages" setting @AnderUstarroz

Elhamne commented 3 years ago

I have the same issue! My supported languages are fa and en, I want fa to be the default.

@chenxizhang I've tried your solutions but they didn't work for me :(

I know it's ridiculous, but I think the plugin choose the first language in locales folder alphabetically!!

tigressbailey commented 3 years ago

How did it go?

nextlevelshit commented 2 years ago

Guys, sorry to say, but read the docs...

Setting a defaultLanguage means that you will render this language, when the user navigates to root /. Instead of navigating him/her to /${defaultLanguage} it will show the index page with your choice.

It is super tricky to be honest. I am also struggling with many side effects, but the developers have done stuff intentionally. And pushing such PR like @chenxizhang did is a huge provocation. At least you could have stuck to the code style convention. Instead of reading the documentation you're pushing such heavily unreflected changes to all of us? C'mon, you can do a better job!

If you want to gain full control of your client routes, you will probably need to implement a gatsby-node.js file or add a router into your pages/index.js for instance. If you want to know more, I am available for help.

AnderUstarroz commented 2 years ago

I still think that is quite reasonable expecting that defining defaultLanguage actually takes you to the default language on the site, or at least doesn't redirect you somewhere else 🤷‍♂️

whitedwarf2000 commented 2 years ago

Hi @AnderUstarroz , I have added generateDefaultLanguagePage: true and redirect: false to options and it work for me

psykzz commented 2 years ago

In my case, I tested this scenario

  1. I have two languages, en and zh, en is the default language
  2. I loaded the page into browser, and confirmed the navigator.language will be en-us, but the page will load the "zh" resources, not "en"

This is due to the downstream of browser-lang. I've raised a PR to fix the issue there in hopes to get it merged upstream here, but have yet to see any progress.

Additionally i've raised an issue here to try and move away from browser-lang, either of these options could solve that problem.