Possible to use multiple message files per one locale?

[Doesntmeananything]

Looking at the Messages section of the docs, it's not quite clear if it's possible to use multiple message files per one locale.

What I'm wondering is if it's possible to do something like this:

── messages
    └── en
        ├── login.json
        └── dashboard.json
    └── fr
        ├── login.json
        └── dashboard.json

Would this require additional middleware customization? And I'm not sure how that would work with TypeScript and passing namespaces to useTranslations(), e.g. useTranslations('dashboard').

Thanks!

[amannn]

I'm currently working on a major docs update and have added a section that should hopefully answer this: Messages configuration ("How can I split my messages into multiple files?").

Feel free to have a look! If you have any feedback, please let me know in #351

[amannn]

On a related note, there's now a VSCode integration for next-intl which helps to streamline the management of translations in large files: VSCode integration docs.

[lhguerra]

I saw the linked docs but still don't have a clue on how to split the locale into several files. What am I missing?

[IngEoGeoBuk]

Hi. There!
I also tried to split my messages into multiple files, but it doesn't work,
recurring an error 'Error: No messages found. Have you configured them correctly?' when use useMessages() into layout.tsx

My code: https://github.com/IngEoGeoBuk/nextjs14-next-intl-tutorial/tree/split-multiple-files
(plz check the branch name 'split-multiple-files')

I modified only i18n.ts and json messages files.
middleware.ts and layout.tsx, next.config.mjs are same as https://next-intl-docs.vercel.app/docs/getting-started/app-router

How to solve it? Thank you.

[IngEoGeoBuk]

Hi. There! I found the answer.

change i18n.ts like this

import { notFound } from "next/navigation";
import { getRequestConfig } from "next-intl/server";

// Can be imported from a shared config
const locales = ["en", "ko"];

export default getRequestConfig(async ({ locale }) => {
  if (!locales.includes(locale as any)) notFound();

  const about = await import(`../messages/${locale}/about.json`);
  const home = await import(`../messages/${locale}/home.json`);
  const room = await import(`../messages/${locale}/room.json`);
  return {
    messages: {
      ...about,
      ...home,
      ...room,
    },
  };
});

[SalahAdDin]

locales as any?

[viclafouch]

On my side, I use an another strategie, and it's working well, but instead of "json" file, it's ts extension.

Here my folder structure:

// fr/common.fr
export default {
  hello: 'Bonjour'
} as const

// fr/index.ts
import common from './common'

// "common" will be used as a namespace
export default { common }

// global.d.ts
// Use type safe message keys with `next-intl`

type Messages = (typeof import('./locales/en'))['default']

declare interface IntlMessages extends Messages {}

// index.ts (no need changes when you add a namespace file)
import { notFound } from 'next/navigation'
import { getRequestConfig } from 'next-intl/server'
import { locales } from '@i18n/config'

export default getRequestConfig(async ({ locale }: { locale: string }) => {
  if (!locales.includes(locale)) {
    notFound()
  }

  const messages = await import(`./locales/${locale}/index.ts`)

  return {
    messages: messages.default,
    timeZone: 'Europe/Vienna',
    now: new Date()
  }
})

Hope it helps !

[bracebrace008]

json is better, can be intergrated to another none js project

[SalahAdDin]

@bracebrace008 @Doesntmeananything It does not work right with types.

[dogukankaynar]

Below I explain the way I found in the json structure in a Type safe way
Our folder structure:




messages
├── login
│   ├── en.json
│   └── tr.json
└── profile
    ├── en.json
    └── tr.json

// i18n.ts

import { getRequestConfig } from 'next-intl/server'


export default getRequestConfig(async ({ locale }) => {
  const loginMessageImport = await import(`./messages/login/${locale}.json`);
  const loginMessages = loginMessageImport.default;
  
  const profileMessageImport = await import(`./messages/profile/${locale}.json`);
  const profileMessages = profileMessageImport.default;
  //Importing other language files ..


// Combine all messages into a single object

  const messages = {
    ...loginMessages,
    ....profileMessages,
    // Add messages from other language files here
  };

  // Return merged messages
  return messages;

});

// global.d.ts

type LoginMessages = typeof import("./messages/login/en.json");
type ProfileMessages = typeof import("./messages/profile/en.json");
// Importing other language files ..

// Create a new type by combining all message types
type Messages = LoginMessages & ProfileMessages;

declare interface IntlMessages extends Messages {}

[SalahAdDin]

It is failing for me:

But if we directly define the locale, it works:

The same happens when using my old configuration:

[SalahAdDin]

Using as works:

[SalahAdDin]

@amannn what do you think about this?

[amannn]

Sure, looks ok!

[SalahAdDin]

I mean, it does not solve the typing issue.

[victorvianaom]

Hi @amannn , thanks for the great work.
For the app router, given a locale, every page will receive the same messages?
Is it possible to send diferent namespaces per route like we do for the pages router?

[amannn]

Yep, you can, but unfortunately this is arguably a bit more involved with the App Router: https://next-intl-docs.vercel.app/docs/environments/server-client-components#option-3-providing-individual-messages.

There's work happening on an automated way to do this in the future: #1 🤞

[victorvianaom]

Thanks for the response @amannn ! I understood the intricacies of it.

[Christian-Hoeller]

I have created this config in the pages router for a more dynamic approach

Function that loads the config

// i18n.ts

const translationsConfig = [
  {
    page: "index",
    files: ["index", "pricing"],
  },
];

export const loadLangFiles = async ({ page = "index", locale = "en" }) => {
  const translationFilesNames = translationsConfig.find(
    (item) => item.page === "index",
  )?.files;

  if (!translationFilesNames)
    throw new Error(`Translation configuration for ${page} does not exist!`);

  const translationObjects = await Promise.all(
    translationFilesNames.map((file) =>
      loadLangFile({
        file,
        locale,
      }),
    ),
  );
  return Object.assign({}, ...translationObjects) as IntlMessages;
};

export const loadLangFile = async ({ file = "index", locale = "en" }) => {
  return await import(`../messages/${locale}/${file}.json`);
};

Use in your page like this:

// index.ts

export async function getStaticProps(context: GetStaticPropsContext) {
  return {
    props: {
      messages: await loadLangFiles({}),
    },
  };
}

TypeSafety:

// global.d.ts

type IndexMessages = typeof import("../messages/en/index.json");
type PricingMessages = typeof import("../messages/en/pricing.json");

type Messages = IndexMessages & PricingMessages;

declare interface IntlMessages extends Messages {}

[HPouyanmehr]

You can also use next-intl-split if you like to separate everything properly, at the end of the day it'll merge all translations into a single messages json and you can use the namespace as well.

[aramix]

@HPouyanmehr How can it be used with next-config.mjs

[brandanking-decently]

@amannn what is the likely hood of something like next-intl-split being baked into the package. Would be great to have something like this directly that can also generate the correct types for the useTranslation hook

[SalahAdDin]

@amannn what is the likely hood of something like next-intl-split being baked into the package. Would be great to have something like this directly that can also generate the correct types for the useTranslation hook

I agree with you; @amannn what do you think?

[amannn]

next-intl is currently agnostic to how you load your messages: It can be a single file, you can fetch from an endpoint, use multiple files etc. I think this approach gives a lot of flexibility to developers, and I currently don't intend to change this part. It's really cool that packages like next-intl-split can exist for developers who really like this approach! 🙂

[SalahAdDin]

next-intl is currently agnostic to how you load your messages: It can be a single file, you can fetch from an endpoint, use multiple files etc. I think this approach gives a lot of flexibility to developers, and I currently don't intend to change this part. It's really cool that packages like next-intl-split can exist for developers who really like this approach! 🙂

You have an excellent point.