[FEATURE] Add Gemini LLM to machine translate

[cjoecker]

It would be great if, instead of using Google Cloud Translate, we could use Gemini for translations.
Additionally, if we have the opportunity to add a context prompt, it would significantly improve the quality of the translations.

Something like
inlang machine translate --project project.inlang --context-prompt ai-i18n-instructions.md

[samuelstroschein]

Yep agree.

I thought about adding a new command like inlang llm translate <options> which uses an openrouter api key to switch between models.

inlang llm translate --model gemini3pro.

A PR is welcome

[samuelstroschein]

@cjoecker or even simpler. prompt a coding agent to build a cli for you with inlang see build your own tool. should be a 10 min task

[ashuvssut]

great idea!

I tried out translategemma:4b model in ollama recently. its fast and translates nicely locally running on my mac mini

[WesHaze]

@cjoecker or even simpler. prompt a coding agent to build a cli for you with inlang see build your own tool. should be a 10 min task

I've tried this and getting the models to respect the variables in a sentences is actually a suprisingly hard problem..

[samuelstroschein]

@WesHaze

I've tried this and getting the models to respect the variables in a sentences is actually a suprisingly hard problem..

Inlang gives you an AST for the messages. You should be able to give the AST to an LLM and let the LLM translate the AST with an explicit prompt to preserve non-text nodes as they are

[WesHaze]

@samuelstroschein Thanks I was sending a custom format instead lol, will see to it that I use that instead later. Also resorted to openrouter most of my issues were resolved when switching to a thinking model (openai/gpt-5-mini) from a non thinking one. It handles contextual information to style the writing well and makes adequate use of loanwords. I am curious if theres an optimal batch size and if seperating request per languages would result in less (thinking) token useage. It did take me more than 10 minutes (and prompts) to create somehting that does an okay job without excessive token use. But I might not be the most stellar promptineer.

I think it's definitely worth considering adding a standard implementation as there is some finesse/nuance involved. Would an implementation need functional parity with the current machine command? Could do with forcing keys under_certain_strings or something like that.

Thank you guys for your work on inlang btw, It's been a breeze working with it.

[samuelstroschein]

I think it's definitely worth considering adding a standard implementation as there is some finesse/nuance involved.

I agree.

Would an implementation need functional parity with the current machine command?

Nope. I would add it as new command like inlang llm translate with no backward compat to machine translate.

Also resorted to openrouter

Which I would also use for the llm translate command. Then ppl can choose their model of choice.

---

If you create a mini cli that loads in inlang project, does the AST stuff, etc. You will have figured out what works and what doesn't. If you then prompt an agent to make a PR to the inlang cli based off of your own cli, it will prob 1 shot it. If it works, I'll happily merge the PR! :)

[samuelstroschein]

Abandoning this feature.

Skills for agents became so good that there no value for this CLI command anymore.

1. Write a skill
2. In the skill explain how the translations should be done
3. Instruct the agent to use the @inlang/sdk for it
4. Done

More context in #4340 (comment)