Translate with your AI

Goal: the same content in other languages: only the text changes; keys, tags, and structure round-trip back intact. In a project the verb is kapi up: it catches every target language up to its ship gate and parks 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 before it fans out: content below the project's source_gate holds (source_not_ready) for a source review rather than being translated into every language, so a defect in the source is fixed once rather than 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 parks. Progress is per-file and live.
2. Watch coverage climb. Rows move toward their gate as translations land; anything a machine can't decide parks for review.
3. Review the parked units. 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 a run parks work into: every language in one list, one unit 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 parked; for a single document it translates block by block and lands the result through the faithful round-trip. 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; park the rest
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

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.