Verbose `localePrefix` does not redirect to the custom prefix about next-intl HOT 3 CLOSED

Thanks for the question, this works as intended in fact.

/en-GB is really an unknown route if you configure a custom prefix like /uk and is treated the same way as e.g. /unknown. If you want to add additional redirects on top, you can compose the middleware accordingly.

from next-intl.

I understand that's the current behavior and I am currently working around it by checking the request url pathname to see if it begins with any of the locale codes mapping to custom prefixes and redirecting to its associated one if it does. I figured since all of that data is provided to next-intl it could handle that check internally.

It was an unexpected behavior given my use case. Would it make sense for this to be the default behavior if we supply a custom user-facing prefix?

from next-intl.

I figured since all of that data is provided to next-intl it could handle that check internally.

It would definitely be possible, that's correct.

I'm a bit hesitant to add it though because:

1. I'd be worried if there could be false positives (even if not likely). By not including a redirect here, users can optionally add this if relevant.
2. Including a redirect here would theoretically be a breaking change (also arguably not likely, but still).
3. I'm unsure how often this would really be accessed by a user. If a redirecting locale prefix is nothing you link to on your website, I can only imagine a user typing in this manually.

Do you have other aspects to this in mind from your perspective?

from next-intl.