Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support localePrefix setting per domain #1055

Closed
markoleavy opened this issue May 6, 2024 · 9 comments · Fixed by #1391
Closed

Support localePrefix setting per domain #1055

markoleavy opened this issue May 6, 2024 · 9 comments · Fixed by #1391
Labels
area: routing contributions welcome Good for people looking to contribute enhancement New feature or request has-workaround

Comments

@markoleavy
Copy link

markoleavy commented May 6, 2024

Is your feature request related to a problem? Please describe.

It would be really useful being able to configure a localePrefix preference per domain, in the domain config objects.

Describe the solution you'd like

Being able to declare a prop inside the domain object and that overrides the default behavior would fix this issue.

export default createMiddleware({
  defaultLocale: 'en-US',
  locales: ['en-US', 'fr-FR', 'en-GB', 'de-DE', 'it-IT']
  domains: [
    {
      domain: 'www.mywebsite.it',
      defaultLocale: 'it-IT',
      localePrefix: 'as-needed',
      locales: ['it-IT']
    },
    {
      domain: 'www.mywebsite.com',
      defaultLocale: 'en-US',
      localePrefix: 'always',
      locales: ['en-US', 'fr-FR', 'en-GB', 'de-DE']
    }
  ]
});

Describe alternatives you've considered

As explained in discussion #1030, at the moment is possible to use an empty string as default locale to get kind of a "always" behavior while "as-needed" is selected in main config.
This is not a documented feature, and might break in the future.

See also: #1055 (comment)

@markoleavy markoleavy added enhancement New feature or request unconfirmed Needs triage. labels May 6, 2024
@amannn amannn added contributions welcome Good for people looking to contribute and removed unconfirmed Needs triage. labels May 7, 2024
@amannn amannn changed the title localPrefix option in DomainConfig Support localePrefix setting per domain May 7, 2024
@amannn
Copy link
Owner

amannn commented Jun 4, 2024

Prefixes can also be customized with #653, this should be taken into account when this is being worked on (see also #609).

@amannn
Copy link
Owner

amannn commented Jun 4, 2024

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.

Would that be an option for your use case @markoleavy?

@george-roussos
Copy link

Hi, I am trying to use this workaround for the time being, but I am having no luck. Specifically, we have some domains that do not have a locale prefix and a general domain which routes based on prefixes. So I tried something like:

export const domains: DomainsConfig<(typeof locales)["en-GB"]> = [
  {
    domain: "test.domain.it",
    defaultLocale: "" as "it-IT",
    locales: ["it-IT"],
  },
  {
    domain: "test.domain.fr",
    defaultLocale: "" as "fr-FR",
    locales: ["fr-FR"],
  },
}

export const navigation: any = {
  locales: locales["en"],
  pathnames,
  localePrefix: "as-needed",
};

The domains array only includes the special domains. Am I doing something wrong?

@amannn
Copy link
Owner

amannn commented Oct 1, 2024

While working on #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 think the solution really is to have separate builds for each domain if you have this requirement.

I've now addressed this in a section here: Can I use a different localePrefix setting per domain?

This note is currently included in a prerelease of the docs and will be released as part of #1391.

EDIT: As discussed in #789 (reply in thread), an internal structure like app/[domain]/[locale] would theoretically enable static rendering for this use case. Still, it comes with additional work necessary on the user side, due to this, I currently tend to favor independent deployments by domain anyway.


@george-roussos It looks like you might be looking for localePrefix: 'never'?

@AdamQuadmon
Copy link

Due to this, I think the solution really is to have separate builds for each domain if you have this requirement.

should we use App Router setup without i18n routing to work with separate builds?

@amannn
Copy link
Owner

amannn commented Oct 4, 2024

@AdamQuadmon Sorry, I don't quite understand your question. The discussion in this issue is about having a different localePrefix per domain. If there's a locale prefix, you'll use the setup with i18n routing. See also the section I've linked to in my comment above.

@AdamQuadmon
Copy link

Sorry, I don't quite understand your question.

Sorry, I'm mixing up different topics and making confusion.

Initially I was investigating why localePrefix: 'never' was not respected in my configuration with different domains.

Reading this last comment of yours I thought that having separate builds were a better solution for SEO and other routing issues.

So I thought I could mix the two solutions: separate builds with no routing for dedicated SEO domains and routing solution for a catch all domain.

The scenario is

  • example.com - builds only english for seo
  • it.example.com - builds only italian for seo
  • app.example.com - builds all the languages for the app

maybe nextjs multi-zones can separate better the SEO from the APP?

@amannn
Copy link
Owner

amannn commented Oct 4, 2024

Initially I was investigating why localePrefix: 'never' was not respected in my configuration with different domains.

Hmm, not sure either—feel free to open an issue if you have a minimal reproduction!

But yes, building the app separately by domain and using the setup without i18n routing is definitely also an option for your case!

@amannn
Copy link
Owner

amannn commented Oct 21, 2024

Closing as discussed in #1055 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: routing contributions welcome Good for people looking to contribute enhancement New feature or request has-workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants