Verbose localePrefix does not redirect to the custom prefix

[c-tuck]

Description

With the following config for middleware:

const i18nMiddleware = createMiddleware({
    locales: ['en-US', 'en-GB'],
    defaultLocale: 'en-US',
    localePrefix: {
        mode: 'always',
        prefixes: {
            'en-GB': '/uk'
        }
    },
    localeDetection: false,
});

Rewrite works as expected when hitting /uk. However when I navigate to /en-GB it redirects to the default locale (/en-US/en-GB) when I would expect it to redirect to the custom prefix of /uk.

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/c-tuck/next-intl-redirect-bug-verbose-prefixes

Reproduction description

Steps to reproduce:

1. Open reproduction
2. Navigate to /en-GB
3. Observe the redirect to /en-US/en-GB instead of redirect to /uk

Expected behaviour

Locales with custom prefixes should redirect to its custom prefix instead of redirecting to the default locale.

[amannn]

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.

[c-tuck]

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?

[amannn]

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?