Prefix strategy 404 error on initial load (static)

Version

nuxt-i18n: 6.13.1 nuxt: 2.13.3

Nuxt configuration

mode:

• universal with static render

Nuxt-i18n configuration

i18n: {
    strategy: 'prefix'
}

With target: "static" in nuxt.config.js

Reproduction Link

CodeSandbox: https://codesandbox.io/s/nuxt-nuxt-i18n-base-template-8boev?file=/nuxt.config.js:123-143

Another Demo: https://present-feet.surge.sh Github: https://github.com/divine/i18nuxt-redirect-bug-master

Steps to reproduce

Change strategy to prefix and target to static.

What is Expected?

Index page after that it should redirect to detected language prefix.

What is actually happening?

Initial load shows 404 error after that redirection happens.

Similar issues are https://github.com/nuxt-community/i18n-module/issues/700 , https://github.com/nuxt-community/i18n-module/issues/677 https://github.com/nuxt-community/i18n-module/issues/491.

---

@rchl

Note that next version of Nuxt will do some command renaming again (deprecate the export command) so might be better to wait for that before taking a look

In my opinion it has nothing to do with the export command (see codesanbox or github repo) and I don’t think that waiting might help, if there is an issue that might need a fix upstream (nuxtjs) it’s better to report it now.

Thanks!

[violoncelloCH]

Yes, a new issue would be preferred.

#822

@violoncelloCH yeah, that was the main issue I was having.

Hosting services returns 404 error code after that redirection happens not something that makes sense for main path route.

exactly… on Apache/Nginx one could generate some fancy redirection rules which would try to redirect every non-prefixed route to it’s (default) prefixed variant and try if this one is found before returning a 404, but this gets quickly quite complicated. Also, I’ve no idea if redirects like this are even possible on Netlify and the likes…

[violoncelloCH]

okay, will do so…

well, I set the 200.html (or 404.html in my case) as ErrorDocument, so on any not found route the webserver returns the general fallback with status code 404. Therefore I think it makes sense to have those routes generated so they are served with status code 200. (And in case of mode: universal, target: static it also means that those routes are even displayed on a browser without / with disabled javascript as they are rendered directly as html/css whereas the generic fallback always needs js to be executed)