Structuring messages by component name

[amannn]

In the docs, we recommend structuring messages by component name.

Components are the main concept for code reuse in React apps and we can piggyback on that for message reuse.

It’s a constraint, but I believe it results in a simpler mental model with a guarantee to know which message is used where. Also, this results in somewhat shorter message keys in components.

Since this is entirely optional, I'd be curious about how many people use this pattern, if you've encountered problems, or if you prefer an entirely different pattern and why.

[ThePatriczek]

I like the pattern. So I have an idea, what about structuring files for messages inside folder of a component and load it dynamically to the config (somehow)? @amannn

Something like this

Now you can use multiple files per locale (https://next-intl-docs-git-docs-app-router-first-next-intl.vercel.app/docs/configuration#messages), but I think it could be imported to the config (and also types) automatically (hierarchically) by some pattern (e.g. **/specificFolderName/*.json)

[ThePatriczek]

I wrote simple generator for this problem

configGenerator.js

const fs = require('fs');
const path = `${process.cwd()}/app`;
const files = [];

const fillFiles = function (path, files) {
    fs.readdirSync(path).forEach(function (file) {
        const subpath = path + '/' + file;

        if (fs.lstatSync(subpath).isDirectory()) {
            fillFiles(subpath, files);
        } else if (subpath.includes(`messages`) || subpath.includes(`_messages`)) {
            files.push(path + '/' + file);
        }
    });
};

fillFiles(path, files);

const getRelativePathAfterAppDir = (file) => {
    return file.split('app/')[1];
};

const mergedFiles = [
    ...new Set(
        files.map((file) => {
            const fileName = file.split('/').pop();
            const fileExtension = fileName.split('.').pop();
            // replace file name with index
            return file.replace(fileName, `\${locale}\.${fileExtension}`);
        })
    ),
].reverse();

const generateConfigFile = () => {
    fs.writeFileSync(
        `${process.cwd()}/app/i18n/i18n.generated.ts`,
        `export const getGeneratedMessagesConfig = async ({ locale }) => {
    ${mergedFiles
        .map((file, index) => {
            const path = getRelativePathAfterAppDir(file);
            return `const file${index} = (await import(\`./${path}\`)).default;`;
        })
        .join('\n    ')}
        
    return {
        messages: { 
            ${mergedFiles
                .map((file, index) => {
                    return `...file${index}`;
                })
                .join(',\n            ')},
        },
    };
};
`
    );
};

generateConfigFile();

i18n.generated.ts

export const getGeneratedMessagesConfig = async ({ locale }) => {
    const file0 = (await import(`./_messages/${locale}.json`)).default;
    const file1 = (await import(`./[locale]/table/_components/LeftPanel/messages/${locale}.json`)).default;
        
    return {
        messages: { 
            ...file0,
            ...file1,
        },
    };
};

typesGenerator.js

const fs = require('fs');
const path = `${process.cwd()}/app`;
const files = [];

const fillFiles = function (path, files) {
    fs.readdirSync(path).forEach(function (file) {
        const subpath = path + '/' + file;

        if (fs.lstatSync(subpath).isDirectory()) {
            fillFiles(subpath, files);
        } else if (subpath.includes(`messages`) || subpath.includes(`_messages`)) {
            files.push(path + '/' + file);
        }
    });
};

fillFiles(path, files);

const getRelativePathAfterAppDir = (file) => {
    return file.split('app/')[1];
};
const generateTypesFile = () => {
    fs.writeFileSync(
        `${process.cwd()}/i18n.generated.d.ts`,
        `${files
            .map((file, index) => {
                const path = getRelativePathAfterAppDir(file);
                return `type file${index} = typeof import('@/${path}');`;
            })
            .join('\n')}\ndeclare interface IntlMessages extends ${files
            .map((file, index) => `file${index}`)
            .join(', ')} {}\n`
    );
};

generateTypesFile();

i18n.ts

import { getRequestConfig } from 'next-intl/server';
import { getGeneratedMessagesConfig } from './i18n.generated';

export default getRequestConfig(async (args) => {
    const generatedMessagesConfig = await getGeneratedMessagesConfig(args);

    return {
        ...generatedMessagesConfig,
    };
});

i18n.generated.d.ts

type file0 = typeof import('@/[locale]/table/_components/LeftPanel/messages/cs.json');
type file1 = typeof import('@/[locale]/table/_components/LeftPanel/messages/en.json');
type file2 = typeof import('@/_messages/cs.json');
type file3 = typeof import('@/_messages/en.json');
declare interface IntlMessages extends file0, file1, file2, file3 {}

[amannn]

Oh wow, that's really cool—thank you for sharing this! If that works well for you, it's definitely ok!

Personally, I find it helpful to have a single large messages file, since it appears easier to integrate with translation management systems to me and also the IDE workflow can be streamlined.

[ThePatriczek]

That integration with VSCode is awesome, unfortunately I use WebStorm, are you planning create integration for the Jetbrains IDE either? @amannn

[ThePatriczek]

In my opinion it’s important to leave files together inside the component. I always prefer package by "feature" (component) based project organization, so I have component that has own style, hook, graphql fragment and "view" (jsx) and now also translations inside the same folder. @amannn

[amannn]

Sure, that's definitely a valid approach if it's helpful to you!

It seems like i18n ally is supported in JetBrains IDEs too, yes: https://i18nally.org/. Support has still yet to land though!

[RaenonX]

Redirected from #425.

I like the idea of structuring the message by component name I think it would be critical to keep this optional instead of required.

One of the reasons to keep it optional instead of required is because my app uses some translation that is shared across components/pages. Taking my game info app as an example, the translation of an item must be the same in the same locale, but these items could show up in different pages, so there's no point making them into separate translations.

[heloineto]

I don't like this pattern because it makes refactoring component (renaming, splitting into smaller components, etc...) a big pain.

Also it's ackward if I have the same text for two different components.

[heloineto]

I would really like to have an option to put the translations like so:

import { useTranslations } from 'next-intl';

export default function Page() {
  const t = useTranslations();

  return <div>{t({ en: 'Title', de: 'Titel' })}</div>;
}

The advantages of this patterns are:

1. It's composable
2. No need create names for the strings
3. No need to jump trough files
4. Plays very nicely with Gihub Copilot (This is huge for me)

Disadvantages are:

1. Takes more space on the component (even more if the app supports a lot of languages)
2. Takes more memory for client components

[markomitranic]

One of the things I learned (from others, but also the hard way) working for years with large translation codebases is that you should never (with some global exceptions) reuse translations across components or pages.

I absolutely love the idea proposed here as a developer, it just feels right. I have, however, worked with enough translators and translation software, to know that:

1. As your system grows, you will move away from translation files to a cloud based translation saas
2. Translators want all of their stuff in the same place, they also love having the context of the usage of the component on page (or pages).

Both of this seem nearly impossible with the proposed setup :(