amannn/next-intl

defaultLocale of domain ignored if defaultLocale set at top-level

cleverlight opened this issue · 2 comments

Description

For domain-based routing, I think defaultLocale at the top-level is overriding the defaultLocale at the domain level, which I'm convinced is the wrong way around based on the documentation.

I've made a repo (a fork of next-intl) to demonstrate this using the example-app-router example. By the way thanks for your work on next-intl. It's brilliant!

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/cleverlight/next-intl/blob/bugreport-defaultLocale-undefined/examples/example-app-router/src/middleware.ts

Reproduction description

Steps to reproduce:

  1. Clone reproduction URL (repo), branch bugreport-defaultLocale-undefined
  2. curl -IL localhost:3000
  3. Redirect goes to /en, when it should go to /de

These steps can be further extended to demonstrate the correct behaviour if defaultLocale is not set at the top-level:

  1. Comment line 5 in middleware.ts (// defaultLocale: 'en',)
  2. curl -IL localhost:3000
  3. Redirect goes to /de as expected

I suspect the problem is inheritance in the structure generally. You'll note in my example that I had to define locales in each domain. These too should be inheritted from the top-level, but if they're not explicitly set in each domain, an undefined redirect loop occurs:

  1. Comment line 13 in middleware.ts (// locales)
  2. curl -IL localhost:3000
  3. Redirect goes to /undefined/undefined/undefined/undefined/...

Expected behaviour

The documentation states:

2. If the host of the request is configured in domains, the defaultLocale of the domain is used

I would expect top-level defaultLocale or locales to be used if they're not defined in the domains: [] entry.

Thanks for the great bug report—you're absolutely right! I've got a local reproduction and will look into a fix.

I checked version 3.11.3 this morning and the fix looks good for all my test cases. Thank you for the speed of release to npm!