How to handle redirects with additional segments before locale?

[Maclay74]

Hello.

I'm working on a website that needs to have a region segment before locale and handle redirects accordingly.
Like /page or /en/page/ should lead to /us/en/page.

It might work with new custom prefixes, but the problem is, we get region from the web server, so.. we need to somehow set the correct one. Moreover, region doesn't affect our language, we can have /es/es-mx (don't ask, I know, I know).

So, how should I handle redirects in this case? I am looking at this docs section but can't figure out how to handle it in links, for example.

[HappyEmu]

I'd love to know that as well. I wanted to move an existing app over to NextJS and its URL structure comprises a [country] dynamic segment before the [locale] segment. I see no way to do that at the moment.

[HappyEmu]

@amannn
Yeah that looks promising, hope they get that into stable soon 🙏 . Seems like this is necessary to properly handle arbitrary params in front of a [locale] segment.
And yes, if I understood correctly, in my case I cannot use custom prefixes. I will need access to [country] and my country-locale combinations are arbitrary (not adhering to Intl standards, e.g. CH-en), so I couldn't infer them (like in the example here https://next-intl-docs.vercel.app/docs/routing#locale-prefix-custom-read-prefix)

[amannn]

I will need access to [country] and my country-locale combinations are arbitrary (not adhering to Intl standards, e.g. CH-en), so I couldn't infer them

Just to make sure we're on the same page: Custom prefixes only require that internal pathnames use a valid locale, the external ones can be completely arbitrary.

On top of that, you can use private extensions on a locale to encode arbitrary information:

If you’d like to encode custom information in the locale, you can use arbitrary private extensions, denoted by the -x- prefix (e.g. en-US-x-usd).

My current understanding is that the only use case that's currently not supported with custom prefixes is when you have an unknown, infinite number of arbitrary prefixes. For other cases I think you should have quite some flexibility.

Is that the case in your project? Or am I missing something?

[HappyEmu]

No, you are right, I don't have an infinite number of arbitrary prefixes. Regrettably, I stopped reading before the private extensions paragraph, which would presumably solve my problem. I just need to be able to extract the country from the locale that is exposed by useLocale() and I should be able to do that using the private extensions 👍

Thank you so much for your help 🙏

Just from a conceptual point of view, it would still be much nicer to have the routes actually stay [country]/[locale]. If that NextJS PR could enable that, I'm all for it 😄

[amannn]

That sounds great! 🙌

Just from a conceptual point of view, it would still be much nicer to have the routes actually stay [country]/[locale]. If that NextJS PR could enable that, I'm all for it 😄

Yep, I agree!

I also mentioned this discussion in #1107, these seem closely related.

[Maclay74]

Just for the record, custom prefixes won't work for your use case? E.g. /es/es-mx → /es-MX? Your redirects that handle the case for /[country] → /[country]/[locale] can still be used on top.

Yea, we tried that. We looped over regions and languages generating those prefixes. It worked, but poorly. Our webserver couldn't process so many alternative links in header, so we had to disable them and other stuff. But the main issue with this approach is that there is no way to control what locale is passed to Intl. And if it's es-mx-MX or something like that, than it throws an error.

As a side note, the Next.js team is working on vercel/next.js#72837 which I think will allow for a cleaner solution to this situation once it's available :).

Oh, haven't seen this one! Cool!