Message extraction

[martinsnajdr]

Hello,

what's the recommended approach to extract messages from the source code and generate the JSON automatically?

Thank you.

[godfrednanaowusu]

why is this not a priority, large projects need this

[amannn]

Right, I agree there's some limitation—i18nAlly is only supported in VSCode and JetBrains. If you're using other editors, extraction currently needs to be done manually.

I'm happy to use this discussion to see if there's more interest from the community in this. I guess this could be implemented via a Babel / SWC plugin, but there might be some edge cases which are somewhat tough to support. For now, I don't have priorities to pursue this. I guess this could also be implemented in userland if someone has a strong need.

[ReesMorris]

We ended up implementing a (rather hacky) solution to mimic the react-intl extraction method after one of our en.json files hit 3,000+ lines. It was becoming practically impossible to maintain.

Essentially we wrapped useTranslations in a custom useIntl hook, exposing it as formatMessage which accepts a defaultMessage and description, e.g:

formatMessage({
  defaultMessage: '{first} et al.',
  description: 'Multiple authors'
}, { first })

These two values get hashed to generate an id which is what next-intl is told the key is for the JSON entry. To populate the JSON file we run i18n which is a custom script to extract all strings out of the formatMessage declaration. We pretty much did the same for getTranslations as well.

Here's a Gist of the above, but use at your own peril as it's definitely not optimised (e.g. hashing every single string at runtime, and having to run i18n to update the JSON files), but we've had no complaints about it. Would be great to see something similar baked in at some point down the line, though.

[vasanthid]

@amannn I'm also interested in a CLI command feature that can scan all files, extract strings, and place them in the correct language files, similar to what's offered by i18next-parser.

Our project, a Next.js 14 app router without i18n routing, is quite extensive and might expand further as we work with distributed teams. We're currently assessing i18n libraries and were leaning towards next-intl, but the absence of an extraction tool might lead us to consider other options.

I have a couple of questions:
a) Could you suggest any tools or methods for automating the extraction process in large projects, aside from VS Code plugins?
b) Is there a possibility that this feature could be given priority in the future?

[trangcongthanh]

@amannn At my work, we have dedicated translation teams for each project. Some of them are 3rd party services, so we can't give them access to our codebase to translate our app. It's not just a limitation for developers because of the editor plugin; it also blocks our ability to outsource the translation to other teams 😿.

[amannn]

@trangcongthanh The JSON files that next-intl typically operates with can be uploaded to any translation management system, making it possible for other project members like translators to collaborate (see for example: Localization management with Crowdin).

[michalpulpan]

👋
Since this was a required feature for our project and we really like usability of the next-intl, I decided to write a simple script for this functionality this morning.
Feel free to check it out, I tested it on our project and it seems to work fine. However, for the first run, make sure to backup your messages folder (even though script creates timestamped backups).

The structure of messages in our project looks like this: messages/{LOCALE}/{NAMESPACE}.json:

.
└── messages/
    ├── cs/
    │   ├── blog.json
    │   └── common.json
    ├── en/
    │   ├── blog.json
    │   └── common.json
    └── de/
        ├── blog.json
        └── common.json

So feel free to adjust it to your use-case.

[vasanthid]

@michalpulpan That's great. Thank you so much. I'll test it and let you know.