Allow Custom Message ID Generation and Include IDs in .po Files

[aliechti]

Currently, Lingui automatically generates message IDs based on the message content, but there is no way to customize this behavior or explicitly output the IDs in .po files.

Use Case

1. Migrating from Existing Systems: Many applications already have predefined message IDs that need to be preserved when transitioning to Lingui. Without the ability to define custom ID generation logic, migration becomes significantly more difficult.
2. Backend-Based Translations: In some systems, translations are not bundled with the frontend but are instead stored and managed dynamically in a CMS or backend system. The frontend knows the message ID, but since the .po file (which is initially sent to translators and set up in the backend system) does not contain the ID, the backend has no way to match texts to their corresponding IDs. This makes backend-driven translation handling impossible.

Proposed Solutions

• Allow users to define a custom function for generating message IDs.
• Ensure that .po files explicitly include the generated ID alongside the translation.

[timofei-iatsenko]

That is going against of ideology of gettext and PO files and not going to be implemented. But there are solutions for both problems:

Migrating from Existing Systems

You can use an explicit id on the Trans component or t function. However, i strongly encourage you to not mix "natural language based" translations with "id" based translations. This case is supported but will lead to complicated flow in the future. https://lingui.dev/guides/explicit-vs-generated-ids

Backend-Based Translations

This usecase is quite common and there is are proven solution for this. Say your backend is responding with a bunch of error codes, create a map in your FE code with translations for this error codes

const errorMessages = {
  'WRONG_CREDENTIALS': msg`Incorrect login or password`,
  'ACCOUNT_BLOCKED': msg`Your account is blocked, please contact your manager`, 
}

const response = backendRequest()

if (response.error) {
   const message = i18n.t(errorMessages[response.error.id] || msg`Unkown Error`);
}

Let me know if you have any questions regarding this or you have a use case which is not covered by this two solutions.

[aliechti]

Thank you for your response. I appreciate the suggestions, but I believe they don't fully address the issues I raised. Let me clarify:

On Migration from Existing Systems
Some applications already use specific logic to generate IDs that match backend processes. This logic is similar to Lingui's approach of generating IDs from messages, just with different formats or lengths. I don’t see how allowing customization of this logic contradicts gettext or .po file ideology—it’s still based on the message content, just in a different format.

Manually defining IDs is not a feasible solution for large projects where IDs can (and should) be consistently generated programmatically. It’s essentially the same principle you recommend but adapted to existing systems' needs.

On Backend-Based Translations
I think there’s been a misunderstanding. The .po file is used in the backend to handle translations that exist only on the frontend. The process works as follows:

1. The backend already has texts it can translate on its own.
2. For texts exclusive to the frontend, the backend relies on .po files to know these translations exist.

If the .po file doesn’t explicitly include the message IDs, the backend has no way to map the frontend-only texts, especially when it can’t replicate Lingui's ID generation logic (or a custom one, as suggested). This results in a critical gap: translations that exist only on the frontend cannot be integrated properly into the backend workflow.

[timofei-iatsenko]

Got your point. Unfortunately, making generating lingui ids configurable is not the way to go. IDs is generated by macro and macro exists in two versions, one for the babel another for swc written in rust. I'm keeping them in sync in terms of available features. That means if I want to make the id generation process configurable, the same feature should land for a rust version as well.

This poses a problem because for the JS version we can allow passing a function for greater flexibility, but for rust version we could not (rust is not executing js, and rust code should be compiled first).
The other way to make it configurable is to provide some pre-defined tokens to configure the id, such as sha256:5, but I also don't like this idea.
It will greatly increase complexity of the package which is used to generate message ids, also will increase it's size (some people use this package in runtime to match lingui behavior). And in the end of the day could not be flexible enough to match your backend behaviour.

There are many moving parts in the lingui: babel macro, swc macro, extractor, compiler and runtime code. They all should be in sync in terms of the configuration to work properly. That's why in some cases i prefer convention to configuration, because too much flexibility will result in numerous of misconfigured setups and frustration from consumers.

If you work only with js version of macro you can monkey patch the package which generates ids, so it would match your backend logic.

[aliechti]

Thank you for the detailed explanation and for clarifying the technical limitations. I completely understand the challenges of maintaining consistency across both the JS and Rust versions, as well as the complexity added by making ID generation configurable.

Given these constraints, I'll move forward with formatjs for this specific use case, as it aligns better with my requirements. I still greatly appreciate Lingui's approach and will continue to use it for other projects where these particular needs don't arise.

Thanks again for taking the time to address this!