Share translations between pages and avoid redundant rsc payloads

[gkielwasser]

Can we have common translations that are shared accross pages and translations that are dedicated to page?

The shared layout would load the common translations and the page would load their dedicated extra translations.

While the following code enables translations, when navigating between pages that share the same layout, common translations are repeatedly requested. These common translations are included in each page RSC payload.

Is there a recommended pattern to prevent common translations from being included in each page's RSC payload once the shared layout is retrieved on the client side?

/[lang]/layout

import { getMessages, unstable_setRequestLocale } from 'next-intl/server'

export async function loadAllTranslations(){
  return getMessages()
}

export async function loadCommonTranslations(){
  const allTranslations = await loadAllTranslations()
  return extractCommonTranslations(allTranslations)
}

export async function loadTranslations(namespaces:string[]){
  const allTranslations = await loadAllTranslations()
  return extractNamespacesFromTranslations(allTranslations)
}

export async function loadPageTranslations(namespaces:string[]){
  return {
   ... await loadCommonTranslations(),
   ... await loadTranslations(namespaces)
  }
}

export default async function LangLayout(props: {
  params: { lang: string }
}) {

  unstable_setRequestLocale(props.params.lang)
  const commonTranslations = await loadCommonTranslations()
	
  return <NextIntlClientProvider messages={commonTranslations}>
	{children}
  </NextIntlClientProvider>
})		

/[lang]/layout/page-1 | /[lang]/layout/page-2

export default async function Page({params}: { params: { lang: string } }) {
  unstable_setRequestLocale(params.lang)
  const pageTranslations = loadPageTranslations(['ns-1','ns-2'])
  
  return <NextIntlClientProvider messages={pageTranslations }>
	{children}
  </NextIntlClientProvider>
})  

Here after we have loaded the "page-1" and we do a transition to the "page-2", page-2 rsc paload will contains the common translations. I would like that it contains only the one related to the "page-2"

In case we use a client shared layout, the common translations would be exclusively in the layout and won't be asked going to another page. But then, how can we populate the provider?

'use client'
export default async function LangLayout(props: {
  params: { lang: string }
}) {
  // We cannot call getMessages() here because it is not supported in Client components
  const commonTranslations = ...
	
  return <NextIntlClientProvider messages={commonTranslations}>
	{children}
  </NextIntlClientProvider>
})		

[amannn]

Interesting question! I tried this in the App Router example and while I can reproduce this in production, I somehow don't see this behavior in development. In development, it seems like Next.js doesn't refetch the RSC payload for Client Components that are returned from a shared layout.

I'm wondering if this is a bug in Next.js. Maybe this could be raised on the Next.js side, ideally with a reduced reproduction that doesn't use next-intl but only passes data to a Client Component in shared layout.

[gkielwasser]

I have created this ticket Next.js side.

In the meantime, if it is "by design" that the RSC payload includes server data from all route segments, do you have any hints to solve this use case with next-intl patterns?

It doesn't look very project-specific to have common translations that won't be loaded on each transition. I haven't found a way around this except by using full server components, which is not an option for my application. Even with extensive caching that is use to build those rsc payloads, caching a large amount of redundant data will incur significant costs.

[amannn]

Fantastic bug repro, thanks a lot @gkielwasser! I've subscribed to the ticket and will follow along there.

Any chance you could move more translations to the server side in the shared layout, by passing already processed results of t invocations to Child Components? See Passing translations to Client Components in the next-intl docs.

Apart from that, I can't think of a good solution unfortunately. Except for lazy loading translations from a REST endpoint on the client side, but that defeats SSR. Solving this in Next.js internally really seems necessary to me, thanks again for pointing this out!

[gkielwasser]

We are migrating a large application to the app router. While we have started to migrate translations from bottom to top to preprocess them on the server, we still have a large set of common translations that are currently "stucked" in client components.

Given Vercel's new pricing, I've become very particular about what gets written/read in the cache with the app router. Until now I really thought layout concept was part of the solution to those dupicate data.

Our application bill has mainly increased because we continually write or read from the cache the same set of common translations across all our pages. It makes our cached pages very heavy for nothing from my point of view. A single user session could request them many times. While disabling Next.js Link prefetching would help decrease this, it would also slow down access to pages.

This is currently a major blocker for our application. I really hope there will be progress in the right direction on the Next.js side with this ticket. :)

[gkielwasser]

The response from Next.js on the issue ticket is quite deceptive.
I still have the impression that anyone using NextIntlClientProvider at a high level segments, or more generally in a segment that is shared across multiple pages (for instance in a layout), should be concerned with this issue of data redundancy.

It indeed generate undesirable growth of:

• cache writes and storage size
• cache reads
• bandwidth usage
• browser latency

Feel free to join the discussion created on the Next.js side.