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

Unprefixed routes are always added in full static mode when strategy is "prefix" #1288

Closed
1 of 2 tasks
reegodev opened this issue Sep 17, 2021 · 11 comments · May be fixed by #2079
Closed
1 of 2 tasks

Unprefixed routes are always added in full static mode when strategy is "prefix" #1288

reegodev opened this issue Sep 17, 2021 · 11 comments · May be fixed by #2079

Comments

@reegodev
Copy link

Version

@nuxtjs/i18n: 7.0.3
nuxt: 2.15.7

Nuxt configuration

  • Applies to a site deployed to a static server (site generated with nuxt generate)
  • Applies to a site deployed to a server with a Node backend

@nuxtjs/i18n configuration

i18n: {
    strategy: 'prefix',
}

Reproduction Link

https://codesandbox.io/s/nuxt-nuxtjs-i18n-base-template-forked-ron65?file=/pages/index.vue

Steps to reproduce

  1. Set target: static in nuxt.config.js
  2. Set strategy: prefix in i18n config

What 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 variable includeUprefixedFallback 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 😄

@rchl
Copy link
Collaborator

rchl commented Sep 17, 2021

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.

@reegodev
Copy link
Author

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

@rchl
Copy link
Collaborator

rchl commented Sep 17, 2021

I would accept a PR to introduce an option (for backward-compatibility enabled by default).

@divine
Copy link

divine commented Sep 17, 2021

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!

@reegodev
Copy link
Author

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.

@stale
Copy link

stale bot commented Jan 8, 2022

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.

@notflip
Copy link

notflip commented Dec 23, 2022

@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?

@dword-design
Copy link

Same issue here! Would be great to have this at least configurable.

@reegodev
Copy link
Author

@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.

@BobbieGoede BobbieGoede added the v7 label Sep 12, 2023
@vettndr
Copy link

vettndr commented Jul 9, 2024

@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.

@BobbieGoede
Copy link
Collaborator

Closing this as v7 is not being actively worked on (critical hotfixes only), if this still applies to v8 and later please open a new issue!

@BobbieGoede BobbieGoede closed this as not planned Won't fix, can't repro, duplicate, stale Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants