fix(i18n): review fallback system

[ematipico]

Changes

This PR closes #9108

The was a big flaw in the logic of the fallback, so I went back, and restored how the routes were stored before the introduction of the fallback logic.

The new change involves the introduction of fallbackRoutes as part of the RouteData object, very very similar to how we do it for redirectRoutes.

Although, now the generation of the pages is different, and each RouteData could create more than one page (itself + fallbackRoutes), hence I create a generator function called eachRouteInRouteData, which returns all the routes we need to create.

EDIT:

In SSR, the middleware already has the logic for doing the redirect, although we need to tell it somehow. So I updated the logic of app/index.ts.

The match function now considers' fallbackRoutes' when matching a route. However, when returning a Response, we set a status code 302 because we want the fallback to apply.

Example:

• Fallback it to en
• Request a /it/blog/article route
• We match the route /en/blog/article, because it contains a fallback route that has a pathname that matches /it/blog/article
• We then return a 302 status code. The middleware catches the status code and returns a redirect to /en/blog/article

Testing

I added a new case where we check the presence of a hoisted script.

The other rests should still pass.

Docs

[changeset-bot]

🦋 Changeset detected

Latest commit: 517ffa3

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ematipico]

Now we loop over all the routes: the main ones and the fallback routes associated to it

[ematipico]

We chain all the generated routes all together

[ematipico]

The only relevant change is that the whole logic is inside this loop now, and instead of doing pageData.route, we pass the route from this loop