Support dynamic locale in static generation server component

[devrsi0n]

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

Currently, I didn't find a way to support dynamic locale in static generation server component.

Here is my scenario:
I have a complex nextjs app, it includes multi-tenant sites /app/blog/[domain], dashboard /app/dashboard and landing page /app/root.

In a multi-tenant route /app/blog/[domain], user can choose a locale (en/jp) from site settings. After reading the doc, I found that in server components, all messages are read from i18n.ts. However, without other params, I can't get site settings inside i18n.ts, thus I can't setup locale for that route.

Describe the solution you'd like

We can inject messages directly into server components, so useTranslations won't error Could not resolve xxx in messages for locale en.

Describe alternatives you've considered

I'm converting all server components to client components to leverage NextIntlClientProvider to read the right messages. It's not very ideal IMO. We lost all benefits of server components.

[devrsi0n]

Hey @amannn would you mind take a look? Thanks in advance

[amannn]

Hey! I've been on vacation for a few weeks, sorry for the late reply.

Is there a [locale] segment somewhere in your pathname? If yes, this might be a duplicate of #1107. If not, you should be able to derive a locale from the domain by reading this in i18n.ts (see: Setup without i18n routing: i18n.ts).

Does that cover your use case?

[devrsi0n]

Hey @amannn thanks for the reply. Unfortunately, I can't read domain from i18n.ts, because it'll convert /app/blog/[domain] into SSR (reading headers in this case), but we need static generation here. Is it possible to inject messages into the message source of useTranslations when SSG? Thus we don't need i18n.ts at all.

[amannn]

How do the public pathnames look like to the user? Is [domain] visible? Is there a [locale] segment, or does a domain only support a single locale? Can you provide an overview of how pathnames look like to the user and what needs to be matched internally?

There was a very similar case discussed here: #1107 (comment) (see the note with the adapted x-middleware-rewrite header). This turned out to work for a user. Maybe this is helpful to you!

Is it possible to inject messages into the message source of useTranslations when SSG?

I don't think that's possible, no. i18n.ts is always consulted to load i18n config for Server Components.

[devrsi0n]

@amannn Sorry for the delay. Yes, the domain only support one single locale, we don't have [locale] or anything similar in the path, we save the locale to a db and read it when SSG. I took a glance of the issues you mentioned, I don't think read db in middleware is ideal, the latency would be unacceptable...

[amannn]

I see. If SSG is mandatory anyway, you could consider using unstable_setRequestLocale to pass a locale depending on a domain to next-intl. You need to ensure that this is consistently called in each layout and page before any calls to next-intl happen.

Ideally you'd be able to return a locale based on a [domain] segment in i18n.ts, but Next.js currently doesn't support that (see #663).

[amannn]

One more thought: You do have an infinite number of domains, is that correct? Otherwise the domains configuration setting from next-intl should already support your use case well.

[amannn]

I'm going to close this issue, as this is mostly covered in #1107.