Open reegodev opened 2 years ago
I was never fully convinced that we should do it but you can see #805 for more context.
Basically having the fallback makes setup easier for some as you don't have to set up redirects manually at the provider or hosting level. But ultimately that might be the proper way anyway.
Thank you for bringing me context @rchl. I share your doubts about that and i agree that setting up redirects should be up to the user. My current issue is that i have the opposite problem of #805: i'd like for urls without the locale prefix to give 404 instead of redirecting to the same path with the default locale prefixed.
Seeing that everyone has his own opinion on this, what if we make this behaviour configurable? I can make a PR if it sounds interesting
I would accept a PR to introduce an option (for backward-compatibility enabled by default).
setting up redirects should be up to the user.
It's not simply setting up redirects, it's a fallback to correctly show 200 status code and based on the detection do redirection.
Where are you deploying your site @reegodev? If it's a custom web server, then looks fine, otherwise, you'd be getting a 404 error code on the root path that can't be fixed simply.
Thanks!
setting up redirects should be up to the user.
It's not simply setting up redirects, it's a fallback to correctly show 200 status code and based on the detection do redirection.
Where are you deploying your site @reegodev? If it's a custom web server, then looks fine, otherwise, you'd be getting a 404 error code on the root path that can't be fixed simply.
Thanks!
I understand the issue about the 200 status with redirect, but I'd find it only useful for the root url honestly. I don't see why every route without a locale prefix should redirect to the same url with the locale in front, considering i explicitly chose to have the prefix for all the routes. Even if we assume everyone besides me wants this behavior, the problem is that i can't disable it in any way at the moment.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@reegodev How did you end up solving this? I'm using nginx and with the 'prefix' strategy I'm getting 404's when I browse to the root of my website, because there's nothing there. Did you end up implementing a redirect on your server to a certain language?
Same issue here! Would be great to have this at least configurable.
@notflip A long time has passed but if I remember correctly we simply implemented a georedirect on the root URL so that users could land directly on the relevant language.
@reegodev How did you end up solving this? I'm using nginx and with the 'prefix' strategy I'm getting 404's when I browse to the root of my website, because there's nothing there. Did you end up implementing a redirect on your server to a certain language?
Hey @notflip, I'm using nginx too and I'm facing the same problem. I've setted up a redirect to the default locale.
Version
@nuxtjs/i18n: 7.0.3 nuxt: 2.15.7
Nuxt configuration
nuxt generate
)@nuxtjs/i18n configuration
Reproduction Link
https://codesandbox.io/s/nuxt-nuxtjs-i18n-base-template-forked-ron65?file=/pages/index.vue
Steps to reproduce
target: static
in nuxt.config.jsstrategy: prefix
in i18n configWhat is Expected?
There should only be routes prefixed with locale codes
What is actually happening?
There are routes with prefixed locale codes as well as routes with unprefixed locale codes. As you can see, the reproduction link prints all routes and for each page there is the prefixed version, ie: /en/about /es/about but also the unprefixed version: /about
I'd say that with setting the strategy to "prefix" this is an unexpected behaviour, especially considering it only happens in full static mode.
The reason why this happen is this logic: https://github.com/nuxt-community/i18n-module/blob/c710ad18d30dc80c9e71502fbf0e722e596952c7/src/core/hooks.js#L13-L16
When full static mode is active or when
nuxt generate
runs, the variableincludeUprefixedFallback
is set to true which forces the route generation to include the unprefixed version of each route.My question is why is this logic present? I guess there must be a good reason if it's there 😄