Gå til hovedinnhold

What gets translated

Goal: decide what actually needs translating before anything goes out in another language. Three outcomes, one pass: sensitive material stays on your machine (Redaction), anything you've already translated comes back for free (Content memory), and every language is held to the same bar as the source (Checks). Each job runs ad-hoc on any file; a kapi project makes the pass repeatable and lets reuse accumulate in a project-local content memory and terms store.

  1. See what goes out. Open a file from a content collection: the Blocks view is exactly the text a translation run works on; everything else is structure the round-trip preserves. Only blocks are translated.
  2. Protect and reuse. Under Toolbox → Flows, put redact and recycle steps ahead of translate in the project's flow: sensitive spans become placeholders before any provider is called, and memory matches fill first, so a run pays only for what's new.
  3. Hold every language to the bar. Bind the voice profile in Project Settings and commit the term list the recipe binds (kapi terms import writes it; Context → Terms shows it); the Checks view then reports terminology and quality findings per block, and a locale doesn't reach its ship gate past a failing check.

In a project

In a kapi project the same pass runs against the recipe's declared content and locales: kapi run prepare with no file argument resolves the sources from the project, and the content memory and terms store it builds are the project's own. For the model behind this (each step a non-destructive overlay on one settled source) see Content preparation.

Next