Preview before you ship

Goal: see how your interface holds up in another language before a single real translation exists. kapi fills every string with a longer, accented stand-in — load it into your UI and the labels that clip, the buttons that overflow, and the hard-coded strings (the ones that stay plain) are immediately visible. No API key, no waiting, no cost. Output defaults to the qps pseudo-locale, so no real target language is needed.

Try it right here — drop a file (or pick the JSON or Word sample) and kapi runs pseudo-translate in your browser:

Loading the interactive lab…

Desktop

Pseudo-translation is a quick tool — no project needed:

1. Open Toolbox, pick the pseudo-translate tool, and choose your source catalog.
2. Adjust the shape in the config form — prefix/suffix markers and expansion padding to simulate how much longer real translations run.
3. Run it and load the output file into your UI; anything un-accented was hard-coded instead of pulled from the catalog.

In a project, add qps as a target locale and pseudo-translation rides the normal flow — output lands on the language path like any locale.

Agent (Claude)

Fold it into the layout question you actually have:

Pseudo-translate our locale catalog and check which strings exceed 40 characters after expansion.

The assistant runs the tool, then sizes the result (kapi check --max-chars, kapi stats) and reports the strings likely to clip — a layout-risk review, not just a file transform.

CLI

One command; the output path is a name you choose:

kapi pseudo-translate messages.json -o messages.pseudo.json

Tune with --prefix, --suffix, and --expansion-percent — the full flags are in the pseudo-translate reference. In a project, run it with no file argument to cover the recipe's declared content, or as the gap-filler step after content-memory leverage — see Reuse what you've translated.

Next

• Reuse what you've translated — pseudo-translation as the visible-gap step.
• Quality checks — the broader check families.