localePrefix doesn't support "es-US" prefixed locale

[karolkarolka]

Description

While implementing the prefixes for [locale] segment, I've found that the es-US locale (and probably other unsupported ISO 639-1 standard language codes locales, tho es-US is widely used) can't be prefixed. The routing object with supported locales and prefixes specified as localePrefix will respond with 404 in the middleware setup. Other defined locales in the config will be fine, they will be prefixed and server will respond with 200 HTTP code, except for es-US. It seems like it is replaced with the nearest ISO standard lang code resolved for the build environment. In this case, the response's NEXT_LOCALE cookie header will resolve to es-US -> en-US, which is wrong, I should be able to prefix all locales specified in my next-intl config. I believe createIntlMiddleware(routing) needs to be patched.

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/karolkarolka/next-intl-es-us-prefix-bug

Reproduction description

Steps to reproduce:

1. Open reproduction
2. Navigate to /us/es
3. The server will respond with GET /us/es 404

Expected behaviour

Expected behaviour:
es-US locale should be prefixed with /us/es. locale in getRequestConfig(async ({ locale }) should be es-US. The path /es/us should resolve to / home directory.

Actual behaviour:
es-US locale cannot be prefixed properly. locale in getRequestConfig(async ({ locale }) isen-US. The path /es/usresolves to 404 not found.

[amannn]

Thanks for the report! I can confirm the issue and have found that this is caused by the overlapping /us segment. If /us/es is requested, then the /us prefix matches and the actual pathname that's called internally is /en-US/es.

This is definitely a bug, we need to support matching more specific prefixes in case there's an overlap.

I'll look into this, should hopefully have a fix this week!

[amannn]

Hmm, I had a first shot at this in #1343, but it seems like there's still a piece missing. Having a second look, can't be much …

[amannn]

Ok, it's fixed now in [email protected] ✌️

[karolkarolka]

Thanks @amannn 👌🏽