Set locale after the request
#1748
-
Is your feature request related to a problem? Please describe.Currently I have a database with a table called Now on the page level for the view I request my Drizzle ORM to get the project based on the Describe the solution you'd likeThe solution I am proposing is to give Describe alternatives you've consideredNow what I've tried is: Attempt #1const getProject = async () => {
/** Fetch from ORM */
return Promise.resolve({ locale: 'en' });
};
export default async function Page() {
const project = await getProject();
return <NextIntlClientProvider locale={project.locale}></NextIntlClientProvider>;
}Attempt #2const getProject = async () => {
/** Fetch from ORM */
return Promise.resolve({ locale: 'en' });
};
export default async function Page() {
const project = await getProject();
const messages = await getMessages({ locale: project.locale });
// I am using v4 so this is now redundant but still tried it
return <NextIntlClientProvider locale={project.locale} messages={messages}></NextIntlClientProvider>;
}In another communication channel you've referred to the upcoming rootParams feature in Next.js. Now that would also work if that function can be called in However I have my doubts since the |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
That's an interesting structure.
Are there other pathnames in the project too? My initial thought is if you have other pathnames, that you could use a middleware to route to a structure like this: You could fetch the locale from your database based on the project ID in the middleware and then rewrite to hide the So possibly a custom middleware and The attempts you've shared above should also work, but note that they only provide the locale and messages for Client Components. An approach based on reading Does that help? |
Beta Was this translation helpful? Give feedback.
-
|
I'll move this over to a discussion for the time being! I really, really want to get rid of |
Beta Was this translation helpful? Give feedback.
-
|
@amannn Thanks for your quick and inclined response (as usual 🙂)! I totally understand your reasoning about getting rid of File structureA little extra backgroundIt's good to clarify that I don't have No (proper) access to
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @amannn hereby a friendly reminder 🙂. Maybe you have some pointers or additional tips on how to achieve this? |
Beta Was this translation helpful? Give feedback.
-
|
Hey, sorry man—I'm really a bit swamped with work currently!
It sounds a bit like you could use either a In this example, you could read the top-level |
Beta Was this translation helpful? Give feedback.
-
|
I understand and I really appreciate the time you take to respond to your community, I think a lot of maintainers could learn from that! Once I again 🙏🏻 Your suggestion would work if all the projects were multi-tenant but unfortunately they're not. Some may still live on Feels quite fragile, any last tips or remarks on that approach? If not that's okay, understand you're quite busy! Keep up the good work 💪🏻 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the kind words, I try to help when I can! Hmm, I see your concerns! It seems like it takes some intricate logic to unify the routing patterns to support both custom domains and IDs in your middleware. But generally, looking at other middleware examples it's quite common to include logic that introduces conditions based on pathname patterns. So all in all, I think this might be fine. But I only have a limited understanding of your app, this is just my outside perspective.
That's probably the only part I'd reconsider. If you can pass the locale to a header, you could also use it as a route segment instead. In the latter case, you can leverage caching from Next.js via Hope this works out for you! |
Beta Was this translation helpful? Give feedback.
Thanks for the kind words, I try to help when I can!
Hmm, I see your concerns! It seems like it takes some intricate logic to unify the routing patterns to support both custom domains and IDs in your middleware. But generally, looking at other middleware examples it's quite common to include logic that introduces conditions based on pathname patterns. So all in all, I think this might be fine. But I only have a limited understanding of your app, this is just my outside perspective.
That's probably the only part I'd reconsider. If you can pass the locale to a header, you could also use it as a route segment instead…