Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first time translating does not work using switchLocalePath() #378

Closed
miteyema opened this issue Jul 23, 2019 · 11 comments · Fixed by #437
Closed

first time translating does not work using switchLocalePath() #378

miteyema opened this issue Jul 23, 2019 · 11 comments · Fixed by #437

Comments

@miteyema
Copy link

Version

v6.0.0

Reproduction link

https://github.com/miteyema/nuxt-i18n-demo

Steps to reproduce

What is expected ?

  • URL changes to /nl
  • page is translated in Dutch
  • URL changes to /fr
  • page is translated in French
  • URL changes to /
  • page is translated in English

What is actually happening?

  • URL changes to /nl
  • page is NOT translated in Dutch and stays in English
  • URL changes to /fr
  • page is translated in French
  • URL changes to /
  • page is translated in English

Additional comments?

Please see the following GIF below to see the problem in action:
problem.gif

This bug report is available on Nuxt community (#c267)
@ghost ghost added the cmty:bug-report label Jul 23, 2019
@rchl
Copy link
Collaborator

rchl commented Jul 23, 2019

That seems to be due to not getting set-cookie header in first page response. I don't know netlify, is that something that you have to configure (allow)? It's either netlify blocking the cookie or preventing it from being sent somehow or code of this module doesn't go the right path for some reason...

@miteyema
Copy link
Author

miteyema commented Jul 25, 2019

@rchl Thanks for the reply.

I have the same problem if I test my project locally.
Steps to reproduce:

The app behaves the same locally as on Netlify, i.e. the bug described above.
So I guess it's code of the module, do you have any idea what can be the problem?

@rchl
Copy link
Collaborator

rchl commented Jul 25, 2019

That would explain it. Statically generated page can't respond with a cookie header. It will only work when running on a node server.

I don't have time to look into it more now, I guess it might be fixable in some way and if not, it should be documented better.

@miteyema
Copy link
Author

@rchl Thanks for the reply, it gave me an idea for a quick fix in my case.
The following line seems to solve my problem for npm run generate

detectBrowserLanguage: false

Can you point me to the code regarding the cookie header, maybe I can have a look at the problem?

@rchl
Copy link
Collaborator

rchl commented Jul 25, 2019

The very initial load of the page sets the cookie here https://github.com/nuxt-community/nuxt-i18n/blob/5aeab8bd7f4b05ce3b05558eedf1150f58c19514/src/templates/middleware.js#L117

But I think middlewares are only ran on generating pages so the code has no chance of triggering when loading static pages...

@MLDMoritz
Copy link

detectBrowserLanguage: false

this fixed a big issue with memory leakage for me too.

@rchl
Copy link
Collaborator

rchl commented Sep 4, 2019

This bug is caused by Nuxt not invoking middleware for initial request (see this comment for more info: nuxt/rfcs#28 (comment)). It can most likely be worked around by moving some part of the code to the plugin.

@miteyema
Copy link
Author

miteyema commented Sep 5, 2019

@rchl Thanks again for having looked at the bug I was having!

@rchl rchl closed this as completed in #437 Sep 5, 2019
rchl added a commit that referenced this issue Sep 5, 2019
When generating static files with `nuxt generate` (with default
`universal` mode), initial load of the URL doesn't trigger middleware.

Nuxt triggers middleware in those cases for initial load:

 - universal (server: yes, client: no)
 - spa (server: --, client: yes)
 - universal+generate (server: --, client: no)
 - spa+generate (server: --, client: yes)

Due to middleware not triggering on initial load, browser language
wasn't detected and cookie was not set, which later caused failure to
update locale on navigating to route from other locale. That's because
detection happened on second navigation and overridden target route's
locale.

To fix, trigger language detection from the plugin first.
For some cases that means that middleware will attempt to trigger
detection again but it will be short-cut early as cookie will already
be there or target locale will already be set.

Also cleaned up some imports and unused variables in middleware and
plugin (more cleanup is possible).

Resolves #378
@JuliaUsanova
Copy link

JuliaUsanova commented Nov 26, 2019

that kind of settings worked for me:

detectBrowserLanguage: {
          // If enabled, a cookie is set once a user has been redirected to his
          // preferred language to prevent subsequent redirections
          // Set to false to redirect every time
          useCookie: true,
          // Cookie name
          cookieKey: 'i18n_redirected',
          // Set to always redirect to value stored in the cookie, not just once
          alwaysRedirect: false,
          // If no locale for the browsers locale is a match, use this one as a fallback
          fallbackLocale: 'en'
        }

@supakornkim
Copy link

i am facing this issue, may i know how to fix this?
detectBrowserLanguage : false .... not work
set option for detectBrowserLanguage also not work.

Thanks

@danilsdf
Copy link

@supakornkim Also have this problem, if you have found the solution, please let me know. Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants