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

Server language detection not working in Safari (dependency update needed) #682

Closed
timonkbd opened this issue Apr 15, 2020 · 11 comments · Fixed by #683
Closed

Server language detection not working in Safari (dependency update needed) #682

timonkbd opened this issue Apr 15, 2020 · 11 comments · Fixed by #683

Comments

@timonkbd
Copy link

Describe the bug

Safari is sending the Accept-Language in a lowercase manner (e.g. en-us). Because the current used version of i18next-express-middleware detects this string as en- instead of en the sever language detection is not working as expected.

Occurs in next-i18next version

4.2.1

Additional context

This issue has been discussed here and got fixed in i18next-express-middleware@1.7.1. Is it possible to bump the dependency to a recent version? Thanks!

@isaachinman
Copy link
Contributor

@timonweber Presently, this line creates a type clash between next-i18next and i18next-express-middleware, preventing that upgrade.

Any good with TS? Feel like contributing?

@timonkbd
Copy link
Author

@isaachinman Not good enough probably, I’m still learning. But I guess you solved that issue already by yourself. Thank you very much for the fast action! 🙂

@Kenpa
Copy link

Kenpa commented Apr 21, 2020

It's still not working for me after updating to 4.3.0 😞

@isaachinman
Copy link
Contributor

@Kenpa Can you create a reproducible example? @timonweber Is the issue resolved on your end?

@Kenpa
Copy link

Kenpa commented Apr 21, 2020

I just updated to 4.3.0, run next server.js (custom server), and still got english content instead of french in Safari... Works fine in Chrome and Firefox

@timonkbd
Copy link
Author

@isaachinman Sorry for the late reply. Unfortunately the problem is still present on my end. But I had a deeper look into it and it seems that this issue is not only related to the casing of the language string but also to the presence of a region code.

For example: When I configure an app with a default language of en and a subpath for both en and de I getting a redirect to /en when I send Accept-Language: de-DE. But when I send Accept-Language: de the redirection correctly points to /de. That’s odd because when I manually test the original regex of i18next-express-middleware everything gets detected as expected.

So this issue seems to be not only present in Safari, but in every client where the only parameter in Accept-Language contains a region code. For example: Chrome sends Accept-Language: de-DE,de so the second option is successfully matched.

But maybe this issue should be addressed to i18next-express-middleware directly, sorry for the inconvenience.

@isaachinman
Copy link
Contributor

Check the configuration options. Specifically, load: languageOnly.

@timonkbd
Copy link
Author

@isaachinman Sorry, I totally missed that option! I tested it again and yes, everything is working as expected after the update. Both Accept-Language: de-DE and Accept-Language: de-de are correctly pointing to /de.

Thanks again! 🙂

@Kenpa
Copy link

Kenpa commented Apr 23, 2020

@isaachinman Sorry, missed that option too! Works fine now! Just one thing that seems odd to me in Safari: when i try to get the current language with i18n.language, it also returns me the region, en-US, instead of only en in Chrome and Firefox

@isaachinman
Copy link
Contributor

Please raise any questions like that via StackOverflow, or via the relevant i18next repository.

@ricamgar
Copy link

ricamgar commented Jan 16, 2022

Hi @timonweber @isaachinman, could you please explain where to put that option to get the right language? We're having the same behaviour, when getting de-de is setting the language to the default en instead of de... Thanks!

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.

4 participants