Translate a corpus with a pinned glossary

What you get

A translated corpus that stays joined to its source, plus an explicit pile of things a person must decide.

• One target segment per source segment, aligned by your own segment identifier.
• The glossary term applied in each segment, recorded in lithi_evidence.
• Exceptions held apart: ambiguous segments abstain instead of guessing.
• Preserved disagreements where independent checks did not agree on a rendering.

Nothing is silently resolved. If two readings are defensible, you see both.

What you need

One language pair, one glossary version, and twelve segments. Three of them carry the whole test:

segment_id,source_text,context_note
SEG-0001,"Charge the battery before first use",product manual
SEG-0002,"We will charge your account monthly",billing notice
SEG-0003,"Return the unit within 30 days",policy

The glossary is a second file, pinned by version:

term,source,target,do_not_translate
T-01,Compute,Compute,true
T-02,charge (billing),charge (billing),false
T-03,Lithi,Lithi,true

Declare segment_id as your item_id_field. Pin the pair explicitly, such as en-US to pt-BR, in the workflow parameters. Segments one and two share a word with two meanings, so they test whether the glossary is really being used.

Run it

1. Validate locally: lithi dataset validate ./translation-fixture/segments.csv. It checks encoding, empty segments and duplicate identifiers before anything is sent.
2. Read the workflow: lithi workflow explain <workflow-id>. Its parameters carry the language pair, the glossary reference and the ambiguity behavior.
3. Choose a quality preset. Standard checks schema and deterministic rules. Verified adds independent sample checks, which is what catches a glossary term applied inconsistently.
4. Quote it: lithi quote --workflow <workflow-id> --input ./translation-fixture/segments.csv. The quote authorizes nothing.
5. Approve the quote separately, submit with lithi batch submit, then track with lithi status <job-id>.

Pin the glossary version in the run itself. A glossary that changes between runs makes two batches disagree, and you cannot tell which one is right.

Read the result

Open result-manifest.json, then check alignment before you read a single translation.

Every row in data/part-* must carry its segment_id and resolve back to exactly one source segment. Count first: accepted plus failed plus abstained should equal what you submitted.

Then read the exceptions, because that is where the value is. abstentions/part-* holds segments the workflow declined, which is the correct outcome for a genuine ambiguity like segment two. disagreements/part-* holds renderings that independent checks did not agree on. Both are a human review queue, not a fault: what each preset actually proves.

Spot-check three accepted segments against the glossary. A term marked do_not_translate that has been translated anyway means the glossary reference did not resolve.

Where it stops

This produces translations for review. It does not sign off on them, and it does not publish anything.

Fluency is not accuracy, and neither is promised. A confident rendering of a legal clause still needs a qualified reviewer, and this example never removes that step. Route abstentions and disagreements to a person with the source in front of them: how failures, abstentions and disagreements are separated.

Nothing is written back into your content system automatically. You import the accepted rows when your reviewer says they are ready.