Gå til hovedinnhold

Rule-based checks

A rule-based check is a kind of tool: it reads translated blocks, inspects each one against a set of rules, and reports findings without modifying the content. Findings are recorded as stand-off overlays on the block (see Checks) and surfaced to the CLI, an editor, or a downstream tool, so a check pass slots into any flow as an ordinary stage. neokapi has two approaches: fast deterministic rules, and LLM-assisted review.

Run as a gate, the deterministic checks read translated content against its source and report what broke: a dropped placeholder, a translated do-not-translate term, a term that drifts from the project's terms store. kapi check runs them over a file or a source/target pair and exits non-zero when the gate fails, so CI or an assistant's fix-loop catches the regression.

Outdated recording

The interface has changed since this was recorded. The workflow it demonstrates still applies, but some screens and labels differ from the current release. The recording grades findings as critical or major. kapi check now marks each finding FAILS or REPORTS.

Deterministic rules​

By default, in rules mode, the qa tool runs a battery of deterministic rules over each block, comparing source and target. It needs no API key. It records each finding as a structured issue with a type and whether it fails, and marks whether the block passed. The checks span several concerns:

ConcernExamples of what it catches
WhitespaceLeading/trailing whitespace mismatch, double spaces
CompletenessEmpty target where the source has content, target identical to source
Inline codesMissing or extra inline codes, code order, non-deletable code dropped, non-cloneable code duplicated
PatternsSource patterns (placeholders, numbers) without the expected target counterpart
CharactersCorruption patterns (for example, UTF-8 text decoded as ISO-8859-1)
LengthTarget length outside an allowed ratio of the source, or over an absolute limit
RepetitionConsecutive doubled words in the target

Each check is individually configurable: every rule has a flag, and length checks have thresholds. The schema is declared on the tool's config struct, so the options and their defaults are generated into the Tool Reference.

Run it from the CLI against a bilingual file. The command below parses an XLIFF file and reports its findings as JSON:

kapi exec qa app.xliff --target-lang fr --json

In a flow, qa is a step after translation:

steps:
  - tool: translate
    config: { provider: anthropic }
  - tool: qa
    label: Quality checks

These rule families are all options of the one qa tool: length ratios and absolute character/word limits (--check-max-char-length, --check-absolute-max-char-length, --check-max-words), forbidden or corrupted characters and charset conformance (--forbidden-chars, --required-chars, --check-charset), regex patterns such as printf placeholders (pattern rules in flow config), and the same source translated differently across a batch (--check-target-inconsistency). Terminology has its own validator, term-check. The full set is in the Tool Reference.

LLM-assisted review​

Where the deterministic rules catch the mechanical errors, running qa with an LLM --provider uses that LLM provider to assess qualities a rule expresses poorly (fluency, accuracy against the source, and terminology appropriateness) and attaches its assessment to each block. The built-in translate-qa flow runs translation and then this review in one pass.

kapi run translate-qa -i app.xliff --target-lang fr

Findings travel with the block​

Both kinds of check emit the same core/check.Finding, recorded as a stand-off overlay anchored to the offending runs, as described under Checks. Memory matches, terminology and voice results use the same channel, so one downstream consumer (a report, an editor view, a CI gate) reads every kind of finding from one place.