React-i18next: nextjs example 404 responses

[Enalmada]

When I run the nextjs example I get these 404 in my network tab:

It flickers in quick and then goes away when enableSubpaths is true. You need to set "Preserve log" in the chrome inspect settings to be able to see it.

[jamuhl]

the second one is no problem...that is just a translation that was missed -> adding that or setting saveMissing on i18n.init would remove that one.

the first one - idk....looks like a wrong route - why that gets triggered - idk?

[Enalmada]

I don't think the first one is a translation. It is a bit clearer when I try hitting the "page2" link. It seems like the flow is to try and fetch the next.js static javascript powering the page from the directory with the prefix and then it is appears like it is doing the right one twice:

I am just guessing and likely totally wrong...that the /en/page2 is being rendered in some state where the browser sees the link preload tags in it <link rel="preload" href="/_next/static/development/pages/page2.js" as="script"/> and then something is "redirecting" to the right page.

I dont have any idea about the second file. I can do a GET http://localhost:3000/static/locales/en/unknownGetReported.missing.json in my browser and it works. I am totally guessing again but perhaps the post needs the "en" part of the path in this case but it is being stripped off?

[jamuhl]

that's what i said...the second one is a translation - the first idk.

ok so you got the cause - related to preload on a false route. Not sure how to fix it...as i not even implemented the subpath stuff

@isaachinman do you have an idea?

[Enalmada]

@jamuhl ah sorry you are right i got the order wrong...I should go to sleep. Note that "saveMissing: true" seems to be set in options of i18n.js and the problem POST 404 doesn't happen when enableSubpaths is set to false.

[jamuhl]

@Enalmada no problem...the problem is i got no idea how to solve this - i just know the basics of next.js - so no idea how to manipulate those preloads.

[isaachinman]

@Enalmada Next time, please provide a full bug report, including the exact steps to reproduce. It took me some time to track this down because of incomplete reporting.

In general, both of these network errors are related to language subpaths, and are trivial. The 404 to en.js and the 404 to en/page2.js are categorically different, actually.

Page requests are made automatically by NextJs on navigation, and since we're nesting the same page at many different routes, we need to handle that ourselves. For example, we might have:

src/pages/contact-us.js

Hosted at:

example.com/contact-us
example.com/de/contact-us
example.com/nl/contact-us

When you hit one of the non-default language subpaths, NextJs automatically looks for that page by name verbatim, eg en/page2.js.

We can fix that by removing subpaths from all _next routes, and sending a 301. Note that this prevents the 404, but _will not save a roundtrip_. As far as I know, there's no way to prevent the NextJs router from making this request. If @jamuhl wants to proceed with this approach, I can submit a PR immediately.

In regards to the 404 on en.js - I think this subpathsOnNonDefaultLanguageOnly flag adds some complexity and is realistically something probably very few people would use (for SEO reasons). It falls well outside the scope of an "example". If @jamuhl agrees, it should be removed from this example and simply be always true.

[isaachinman]

In fact, if you check out the NextJs parameterized-routing example, the approach is more or less identical - this is where I drew inspiration from.

Perhaps someone from the NextJs team would be willing to take a quick look at this, as I'm sure I'm missing something obvious.

[isaachinman]

@timneutkens

[jamuhl]

@isaachinman personally in my projects i would prefer:

example.com/en/contact-us
example.com/de/contact-us
example.com/nl/contact-us

over

example.com/contact-us
example.com/de/contact-us
example.com/nl/contact-us

but might only be me...idk.

[isaachinman]

@jamuhl To clarify, we're talking about the default language not being behind a subpath, not specifically English. Are you saying you would dev a web application with _only_ language subpaths, and no "naked" paths? If that's a genuine use case, we can consider including it. This "example" is indeed creeping in scope though, and I wonder how much confusion these config options will cause.

[jamuhl]

@isaachinman yes with en i mean default language...i personally prefer routes to be consistent /{lng}/something but like said, that is just me...not common sense...

[isaachinman]

The example currently has the subpathsOnNonDefaultLanguageOnly option, and is only hindered by that 404 in some cases. There's no 301 hacky-fix for that, so we'd only be able to prevent the 404 if we find a way to prevent these extraneous NextJs route calls.

[Enalmada]

Thank you @jamuhl and @isaachinman for looking into this and for getting Next team to give their advice on how to prevent extraneous NextJs route calls. Probably the only thing worse than console errors are extraneous route calls no one is aware are happening so they don't get the attention they deserve to be removed for good. I don't want any new users to decide against react-i18next because of errors in console of example code so I think the time is well spent. Sorry the initial report was incomplete...as someone generally on the receiving end of insufficient bug reports I feel very bad not being clearer about how to reproduce.

[isaachinman]

@Enalmada To be as clear as possible, this is _an example provided for your benefit_, is entirely demonstrative, and was developed in our free time. It holds no reflection on react-i18next core, and holds no claim of perfection. These examples are very hard to develop and maintain, as they require deep knowledge of multiple projects, not just react-i18next.

We have heard your report. _Feel free to submit a PR yourself_, or else allow us some time to deal with it.

[isaachinman]

I posted on the NextJs Spectrum instance here, asking if any of their contributors could take a look at our example source code and give some recommendations.

I also came across next-routes, which looks like it might do exactly what we have hand rolled here. Not sure how it would relate to intercepting route changes and comparing against locale, though. @jamuhl Let me know if you have any thoughts about that.

[jamuhl]

@isaachinman next-routes looks very promising - will need to have a deeper look - but reusing it over inventing our own solution would be preferable

[timneutkens]

I wouldn't recommend using next-routes as it ships a route map of every possible route in the app.

[isaachinman]

@timneutkens Can you explain why that is a drawback? Do you mean that it breaks codesplitting?

[isaachinman]

Ah, I see your point here:

https://github.com/zeit/next.js/issues/2833#issuecomment-414919347

I will take some time to look into this approach next week, hopefully. Thanks @timneutkens!

[timneutkens]

🙌 feel free to dm me if you have specific questions

[isaachinman]

This is related to my comment here. We need to rethink this example, and potentially remove the language subpaths entirely. A full rewrite should solve these 404 issues.

[isaachinman]

Fixed with #613.