Jan Amann

My main concern with this currently is that the `locale` is returned asynchronously, in case routing APIs are used in combination with this feature. Looking through all the options we...

For the record, navigating to a locale root works as expected:  So as far as I understand the issue, this is about the location...

I've refactored the middleware handling somewhat in #1086 and have added a test for your use case. Should work in the future after the PR is merged!

Oh that's a good idea with `no-restricted-imports`, even easier to manage! Being able to provide a customizable message is certainly possible with ESLint, but you'd have to configure at least...

The same issue has been discussed in https://github.com/amannn/next-intl/discussions/1009 and https://github.com/amannn/next-intl/discussions/955. A potential solution is discussed in https://github.com/amannn/next-intl/discussions/1009#discussioncomment-9261306. In case someone is interested in implementing this, I'd be happy to review...

Related: After working on https://github.com/amannn/next-intl/pull/1086, I could imagine that entries for a given locale could be partial objects, where the internal route is used as a default in case not...

Oh cool, thanks a lot for sharing your implementation!

Prefixes can also be customized with https://github.com/amannn/next-intl/issues/653, this should be taken into account when this is being worked on (see also https://github.com/amannn/next-intl/issues/609).

As a side note, this can currently be realized by running a separate build for each domain and providing a different config for `localePrefix` e.g. based on an environment parameter....

While working on https://github.com/amannn/next-intl/pull/1316, I realized that setting a different `localePrefix` per domain is unfortunately not really possible while keeping the ability to render pages statically. Due to this, I...