> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Translate a corpus with a pinned glossary description: >- Pin one language pair and one glossary version, keep every target segment aligned to its source, and route ambiguous segments to a person instead of letting the run guess. route: /docs/compute/examples/translation page_id: docs-compute-examples-translation page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Localization teams translating a defined corpus voice: D reader_question: How do I translate a corpus consistently and review only what needs a person? primary_action: Run a twelve-segment translation test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-translation-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## 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: ```text 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: ```text 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 `. 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 --input ./translation-fixture/segments.csv`. The quote authorizes nothing. 5. Approve the quote separately, submit with `lithi batch submit`, then track with `lithi status `. 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](/docs/compute/workflows/quality-presets). 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](/docs/compute/results/failures-abstentions-disagreements). Nothing is written back into your content system automatically. You import the accepted rows when your reviewer says they are ready.