Efficient Language Routing and Translation Management for 1000+ Pages

[HasancanCakicioglu]

Hello, I’m working on a large-scale Next.js project and I had a question about handling translations efficiently.

Let’s say we have over 1,000 pages, and each page supports 40 languages. This would result in a very large set of JSON translation files.
I'm wondering if there's a way to import only the translation file related to the current page.

For instance, on the route /en/math/sum, is it possible to import only sum.json from the messages directory, instead of loading all translations?
As the project scales, I’m concerned that loading unnecessary translation data could impact both RAM usage and performance.

---

My second concern is related to path localization in Next.js, particularly the use of the pathnames object for managing localized routes.

With thousands of pages and 40 languages, the pathnames configuration can grow extremely large. Since this object is used to define custom localized paths per route, I’m wondering if its size could lead to performance issues, such as:

• Slower routing
• Higher memory usage
• Increased response times

Is there a recommended strategy for managing such a large pathnames structure in a scalable way?

---

Thanks, I don't have much knowledge about Next.js, so any advice or best practices would be appreciated!

[amannn]

Thanks for the question!

A few notes:

each page supports 40 languages

The number of languages doesn't matter when you're using next-intl, as messages are split by language. E.g. ethereum.org supports 69 languages.

we have over 1,000 pages

Is that 1000 routes as in /one/page.tsx, /two/page.tsx, or including resolved values for dynamic segments (e.g. /blog/[slug]/page.tsx) serving a variety of pages? The latter naturally uses significantly less translations if they can be reused across variants.

How many translations do you expect to have in total?

But to answer your question, currently, on the server side, all translations are loaded into memory. But then, for the client side, you can be more selective.

I have a loose idea in my mind that would allow being more selective with server-side messages too, e.g. with a pattern like this:

// i18n/request.tsx

export default getRequestConfig(() => {
  // ...
  return {
    messages(namespace) {
      // Load messages depending on the `namespace`
      // that is being passed to `useTranslations`.
    }
  };
});

I haven't practically heard of issues with the current approach yet, but this could be a potential improvement for the future that might be beneficial for really large apps.

For pathnames, the story is a bit similar. Is it really thousands of actual routes, or merely variations with resolved dynamic slugs? If you need to maintain such a huge number of routes, maybe you're better off with storing localized slugs in a CMS or similar.