fix: exclude unprefixed routes for strategy prefix

[BobbieGoede]

🔗 Linked issue

• Inconsistent handling of Accept-Language header #2524
• With strategy prefix, unprefixed routes are accessible #2131

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

@kazupon
What is the intended behavior for projects with redirectOn: 'root' when accessing an unprefixed (non existant in this case after this change) route like /about, should it return a 404? Right now this still redirects to the default language route, relevant issue: #2524.

Let me know if there are specific cases are missing tests for this change!

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[kazupon]

What is the intended behavior for projects with redirectOn: 'root' when accessing an unprefixed (non existant in this case after this change) route like /about, should it return a 404? Right now this still redirects to the default language route

as your mention,redirects to the default language route. this befavior is from nuxt-i18n v7.
we should be fixed.

[divine]

Hello,

Does it handle correct redirection from /about to /fr/about with Accept Language or Cookies already set?

Thanks!

[kazupon]

Does it handle correct redirection from /about to /fr/about with Accept Language or Cookies already set?

Thanks feedback!

@BobbieGoede
From this feedback, we need a test with a pattern of cases for cookies and navigator.languages.

[BobbieGoede]

@divine

Does it handle correct redirection from /about to /fr/about with Accept Language or Cookies already set?

You need to set detectBrowserLanguage.redirectOn to 'all' for this to work, this should already work work without this PR. Relevant #2524 (comment).

@kazupon

From this feedback, we need a test with a pattern of cases for cookies and navigator.languages.

As described above this seems to already work with the correct configuration.

as your mention,redirects to the default language route. this befavior is from nuxt-i18n v7.

After giving it more thought, I suppose it makes sense to redirect to a localized catch all route rather than responding with a plain 404 response. Hmm 🤔 not entirely sure what would be the best approach. I believe this PR should at least resolve #2131.

[divine]

You need to set detectBrowserLanguage.redirectOn to 'all' for this to work, this should already work work without this PR. Relevant #2524 (comment).

I'll check but just make sure this won't create a regression later.

After giving it more thought, I suppose it makes sense to redirect to a localized catch all route rather than responding with a plain 404 response.

Returning 404 doesn't make sense, it's like returning 404 error code on the root path / then redirect to /en/.

You might be surprised but the old version had this problem and a lot of pages were duplicated in search engines. The reason behind this is that i18n module for Nuxt didn't handle correctly SEO. So redirecting to the correct page according to the language header or fallback locale it's what should resolve the duplicate problem.

Only in 2020 SEO feature was integrated correctly, I'm not sure why my contribution silently lost but there are PRs with the reasoning and explanation behind it so I'd expect at least this should work like the previous version which logic was fixed.

Thanks!

[rudolfbyker]

I believe this PR should at least resolve #2131.

I tested this, and the unprefixed routes are still available. In fact, I can't see any difference after applying the changes from this PR. EDIT: The unprefixed routes are gone, but for some reason I still get redirected from /foo to /en/foo instead of the expected 404 on /foo (since foo is not a language).

[BobbieGoede]

@rudolfbyker
You probably have a catch all route set up, I think removing that would result in 404 response on these routes. Maybe as a workaround you could detect redirects to the catchall page, and ensure a 404 response if this is from a nonexistent page?

[rudolfbyker]

I double checked, and I definitely do not have a catch-all route. See my updated example with explanation at #2524 (comment) . Thanks for your time.

[rudolfbyker]

This PR is good. It removes the unprefixed routes as intended. #2524 seems to be a separate issue.