Is loading translations per page a good practice / solution ?

[RomainGueffier]

Hi !

Thanks for latest version 🚀 of Next Intl, so much easier to use with Next 13+ new RSC !
Usage and documentation is really good, almost all questions I had while refactoring code were anticipated by doc. And 👍🏼 for i18n-ally extension suggestion.

However, while working on a large Next JS marketing website, with 4 locales translations over 40+ static pages and dynamic blog, I was wondering if importing all translations file in i18n.ts file is good for performances.

To have better translations organisation and avoid git conflicts nightmares between developer working in same translation file, I divided original translation file across multiple files "1 per page".

So I had 2 solutions:

1. import all these differents file in i18n.ts.
2. import one translation file per page.

As solution 2 is not supported by Next Intl as much as I search in repo, here my question / idea...

Why not load a translation only on the page using it ?

Idea

I can keep i18n.ts to import global translations shared in all pages.

Here is my solution ⬇️, I would like and advice on it, is it good practice, will it really improve performances on a full static / ISR website / dynamic page ?

import { cache } from 'react'
import {
  type NamespaceKeys,
  type NestedKeyOf,
  createTranslator,
  useLocale,
} from 'next-intl'
import useHook from 'next-intl/react-server/useHook'

/**
 * Inspired by createTranslator
 * difference is that we need to pass a second param which 
 * is the relative path to a translation file
 */
const getPageTranslator = cache(
  async <
    NestedKey extends NamespaceKeys<
      IntlMessages,
      NestedKeyOf<IntlMessages>
    > = never,
  >(
    locale: string,
    path: string, // todo improve types by inspecting `src/locales/*` dir
    namespace?: NestedKey
  ) => {
    const messages = (await import(`@/locales/${locale}/${path}.json`)).default
    return createTranslator<NestedKey>({ locale, messages, namespace })
  }
)

/**
 * Inspired by useTranslations
 * instead of load messages from i18n import, it loads from translation file path
 */
export const usePageTranslations = <
  NestedKey extends NamespaceKeys<
    IntlMessages,
    NestedKeyOf<IntlMessages>
  > = never,
>(
  path: string,
  namespace?: NestedKey
) => {
  const locale = useLocale()

  return useHook('useTranslations', getPageTranslator(locale, path, namespace))
}

/**
 * Inspired by useMessages
 * load page messages to be passed down into client provider for example
 * @todo add namespace and improve return type
 */
export const usePageMessages = (path: string) => {
  const locale = useLocale()

  async function loadMessages() {
    return (await import(`@/locales/${locale}/${path}.json`))
      .default as Messages // For now I still load all types in `Messages / IntlMessages interface`
  }
}

Usage example :

# src/locales/en/about-page.json
{
  "hero": {
    "heading": "About us",
  },
  "counter": {
    "increment": "Increment counter"
  }
}

RSC example

// src/app/[locale]/contact/page.tsx
import { usePageTranslations } from 'next-intl'

export default function HeroPage() {
  // (path, namespace)
  const t = usePageTranslations('about-page', 'hero')
  
  return <section><h2>{t('heading')}</h2></section>
}

Client example

// src/components/Counter.tsx
'use client'
import { useTranslations } from 'next-intl'
import { useState } from 'react'

export default function Counter() {
  // (path, namespace)
  const t = useTranslations('counter')
  const [count, setCount] = useState(0)
  
  return <div><button>{t('increment')}</button></div>
}

⬆️ Wrapped by ⬇️

// src/components/CounterSection.tsx
import { usePageMessages } from 'next-intl'

export default function CounterSection() {
  // (path)
  const messages = usePageMessages('about-page')
  
  return (
    <NextIntlClientProvider messages={messages}>
      <Counter />
    </NextIntlClientProvider>
  )
}

Questions

• I'm surprised RSC components are able to use react use() hook, did I get usage right by using your useHook logic ?
• Imagine this usage with thousands of translations and 40+ translations files: will it improves, degrades or keep unchanged performances / server memory usage ?

Conclusion

I have also create a custom i18n-ally configuration regex for VSCode to support hooks that I can share if interested in.

Thanks in advance for your advice !

[amannn]

Hey, thank you for the kind words—glad to hear if next-intl works well for you!

However, while working on a large Next JS marketing website, with 4 locales translations over 40+ static pages and dynamic blog, I was wondering if importing all translations file in i18n.ts file is good for performances.

I understand your concern, but on the practical side, I have yet to see an app where providing messages on the server side in an atomic way poses a performance problem.

In case we run into such a situation, I think we could enable further splitting of translations by overloading the messages property that is configured in i18n.ts:

// i18n.ts

import {getRequestConfig} from 'next-intl/server';
 
export default getRequestConfig(async ({locale}) => ({
  // (proposal)
  messages(namespace) {
    return namespace.startsWith('auth.')
    ?  (await import(`../messages/auth/${locale}.json`)).default
       (await import(`../messages/shared/${locale}.json`)).default
  }
}));

This API is a bit more involved and potentially the user has to call cache at appropriate places, therefore this is currently not implemented. I'm keeping this in mind as a consideration in case a real need for this use case arises.

For the apps I've seen so far, providing all messages in one go on the server side was absolutely fine.

Hope this helps!

[RomainGueffier]

Glad that you answered quicky ⏩ @amannn
I'm fine with importing all in getRequestConfig then.
At least this custom solution was working in my project, and it helped me understand more how to use use and cache from react canary, and how Next Intl's new server api works as sharing a server 'state' between pages.

Also I notice 🤔 my idea is making the lib API more complex which makes me bend for your default behavior if there is no real advantages to this solution.

Thanks 🫡