Translate with your AI

Goal: the same content in other languages, with only the text changed and the keys, tags and structure intact. In a project the verb is kapi up: it catches every target language up to its ship gate and holds back for review what needs a person. For a loose file, kapi translate does one file, one language. The trade-offs behind the model choice live in Choose a translation model; how translation works as a tool in Translation.

The loop settles the source first. Content below the project's translate_after level holds (source_not_ready) for a source review, so you fix a defect in the source once and not once per locale; see Source first.

Desktop

Open your project: the coverage panel shows one row per locale against its ship gate.

1. Bring up to date. Click Bring up to date: kapi runs the project's default flow over every locale short of its gate, looping until each scope ships or waits for review. Progress is per-file and live.
2. Watch coverage climb. Rows move toward their gate as translations land; anything a machine can't decide waits for review.
3. Review the waiting blocks. Open the Review queue from a ship-gate cell; see Review & approve.

For a one-off file with no project, use a quick tool: pick the translate tool, a file, and a target language.

▶

Walkthrough videoPending recording

The review queue where a run leaves the work a person decides: every language in one list, one block in focus with the context behind it, and a decision taken from the keyboard.

View scene script ↗

Agent (Claude)

With kapi connected, ask:

Translate src/locales/en.json into French and German, keep the placeholders intact, and fix anything the checks flag.

The assistant routes the work through kapi so the guardrails apply: approved terms from the terms store, voice profile in the prompt, placeholder integrity checked after. In a project it runs kapi up and reads kapi status for what waits for review; for a single document it translates block by block and writes the result back with the file's structure kept. Either way it finishes by checking, and fixes what the gate flags before telling you it's done.

CLI

In a project: the recipe declares the languages and content, so the whole job is one verb:

kapi up                # catch every locale up to its ship gate; the rest waits for review
kapi up --passes 1     # a single pass (the behavior of the bare 'kapi run')
kapi status            # coverage per locale: informational, never fails

up re-derives coverage from the working tree each pass and runs the flow only for the locales still short of their gate. The project store reuses what you've already translated, so a run only touches what changed; see Reuse what you've translated.

Ad-hoc: one file, one language, flags for everything:

kapi translate -i src/locales/en.json --target-lang fr -o src/locales/fr.json
kapi translate -i guide.md --target-lang de        # documents work the same way

--target-lang takes one language tag, and kapi refuses a list such as fr,de before it reads anything. For several languages, run the command once per language, or declare the languages in a project and run kapi up.

The default engine is an LLM; kapi models setup detects what you already have (a Claude Code sign-in, an API key in the environment, or a local Ollama model) and saves it as the default (Choose a translation model).

Next

• Add languages: the full on-ramp: locales → up → review → gates.
• Estimate a run's cost: size the job first.
• Keep terms consistent: enforce your approved terms.
• Ship gates & CI: kapi check --ship before a release.