Automatic LLM Translations

[christian-egger-augedo]

Problem Description

Really love lingui and use it in all my projects!

One things that has bugged me since the advent of AI coding tools such as Cursor: I feel like those IDEs really struggle with translating the .po files (super slow because they usually do it line by line, wonky translations and also incomplete translations when adding many translations at the same time).

I find it especially funny because GPTs originally built by Google were meant to be this new way of translating languages and now in the whole development cycle the only thing that I do manually is writing translations.

I wrote some python script for myself that takes .po files, parses missing translations + cleverly adds existing translated strings as context and then automatically translates all missing strings. And now using lingui is SO much fun again.

So I was wondering: Is this something you'd be interested in having added to the lingui CLI scripts?

Proposed Solution

Add a standard CLI script, just like compile and extract. It could be called translate.

In my script i use gpt-4o to do the translations. In theory we could make it model agnostic, however I'm also a big fan of keeping it simple.

Requirements to run the script:

• To run the script, the users need a OPENAI_API_KEY env variable.
• python3 (or whatever runtime we want to use to implement this - honstely haven't looked into how your other CLI commands are implemented)

Alternatives Considered

Everyone can obviously ask ChatGPT and the likes to build this script from scratch and just run it locally in their repos. That's the way I do it right now.

Additional Context

No response

[andrii-bodnar]

Hi @christian-egger-augedo, thank you for the suggestion!

This is a great idea! The automatic translation feature you described is already offered by the third-party CLI companion tool Linguito: https://github.com/antropia-studio/linguito. Linguito provides a linguito translate command that uses a configurable LLM to automatically fill in missing .po strings, often including an option for interactive review.

Please take a look at this and let us know what you think.

[christian-egger-augedo]

Linguito looks great. Thanks for pointing it out. Its also interesting to see how they do their translations!

I personally think (for what its worth lol) that the translate should be part of lingui itself. AI in development has really landed and I feel like it is to be considered as part of our standard workflows these days. And while linguito brings that functionality, it also adds other things that are already part of lingui.

• the linguito check essentially does the same as lingui extract (that will also tell you about any missing translations)
• the linguito format does some formatting + removes empty translations (which is done by the --clean flag already in lingui).

So aside from the translate i don't think it adds a lot of inherent value but rather provides a different interface to interact with lingui. Which other people surely find valuable!! Im a big fan of keeping my web-dev stack as slim as possible, having been traumatized of create-react-app and the likes.

And to me it feels very natural to have the three

1. lingui extract
2. lingui translate
3. lingui compile

because translate bridges the other two commands as a natural part of the workflow.

With that being said, I just want to present my opinion but don't mean to push it onto anyone, especially not being part of the project!

If you don't agree with it, feel free to close the issue! 🚀

[andrii-bodnar]

Yes, having that capability out-of-the-box definitely makes the experience feel more natural and intuitive.

I was also thinking about a similar enhancement that involves the OPENAI_API_KEY configuration, specifically for the extract command. We could use AI to automatically generate a helpful comment for the string based on its location and context in the code. This feature should improve the context provided to both AI and human linguists, leading to higher-quality translations.

On a side note, I just noticed a recent message in our Discord server. Someone posted about a different tool they created for AI translation of message catalogs - you can find the message here.

[TasseDeCafe]

Personally, I didn't need everything that linguito does: I just wanted Claude to go through my missing translations, translate them, and insert them in the .po files. So I asked Claude to extract only what I needed from the Linguito codebase, and I ended up with this script:

https://gist.github.com/TasseDeCafe/b6d314af7e0990404ec782b3cfb49d57

You'll need to install those dependencies if you don't already have them:

• @ai-sdk/anthropic
• ai
• gettext-parser
• zod

For this script to work, you also need to:

• set your ANTHROPIC_API_KEY. I use Doppler for that.
• adapt the const projectRoot to point to your project root. My script is nested in /packages/i18n/scripts, so adapt it accordingly.

This way, I can add this command in my package.json:

"translate": "doppler run -- node scripts/translate-missing.mjs"

and run it in a pre-push Husky hook, which completely automates translations.

[andrii-bodnar]

I have suggested a new RFC regarding AI integration in Lingui: #2392. Any feedback is welcome!

[chegger]

Ended up copying my own translation script to various projects, so I just extracted it published it as an NPM package:

https://www.npmjs.com/package/lingui-translate

Its super easy to use, basically just do npx lingui-translate and it will auto translate all locales in src/locales via gpt-5.4!

Maybe someone finds it useful - I'll be using it for my projects!

(note: my work github account is the christian-egger-augedo account above)

[arvida]

Found this looking into a Lingui issue, seems worth mentioning since a few people here are building their own AI translate step.

One thing to have in mind is that plurals work differently in Lingui than in the rest of the gettext world. Classic gettext/.po has msgid_plural and indexed slots. Lingui's po format doesn't do that, the ICU string is inline in a single msgstr:

msgid "{count, plural, one {# item} other {# items}}"
msgstr "{count, plural, one {# item} other {# items}}"

So you have to rewrite the categories inside the ICU string to the target locale's CLDR set. English one/other into Polish needs four branches: one, few, many, other etc. Many times it fails quietly, like ask a model to "translate this, preserve the ICU" and you often get back valid ICU with the english categories translated word for word. Nothing errors, then the wrong branch start to show up.

[MurzNN]

Hmm, thanks for the details! So, maybe then create an issue to fix this quirk in Lingui, to make it work as the rest of the world?

[arvida]

So I looked into it a bit more now and found there is already a formatter for this, po-gettext. It writes msgid_plural with indexed msgstr[0] / msgstr[1] instead of the ICU inline, so I guess this is the way to align the behaviour if you need that, sorry for making it sound like it's not possible!

Looks like there is a reason it is not the default, the docs say it "should only be used when using ICU plurals in PO files is not an option" since nested/multiple plurals in one message can't be expressed as gettext plurals and won't be output correctly.

Can be worth knowing which formatter a project is on before pointing an AI translate step at it 😊