Docs · Features
Glossaries and terminology
The terminology authority: the list of terms that must be translated a particular way, or must not be translated at all, enforced rather than merely suggested.
What it does#
Some words are not negotiable: a product name, a legal term, a UI string that has to match the software exactly. Translation memory remembers whole sentences; the glossary enforces individual terms. A glossary belongs to a customer, carries a status of draft or approved, only an approved glossary is usable in a workflow, and covers one or more language pairs. A term can carry a target translation, or be flagged do-not-translate to stay in the source language.
Two things happen when a glossary applies to a step: matching terms are added to the translation prompt as approved terminology, and the output is checked against those terms afterward. The check is what actually enforces the rule: a correction that would introduce a new violation is discarded rather than shipped.
Getting started#
- Create a glossary for the customer.
- Add its language pairs.
- Add terms: by hand, by importing a CSV or TBX file, or by extracting candidates from a real document and accepting the good ones.
- Approve it. An unapproved glossary is invisible to every workflow step.
- Pick it from the glossary dropdown on a Translate step in the workflow builder.
glossary module create "Acme Terms" --customer 7
glossary module add-term 3 "dashboard" --target-term "tableau de bord"
glossary module set-pairs 3 --pair en-US:fr-FR
glossary module approve 3
Works with#
- Workflows: a Translate step can pin one approved glossary covering its pair; its terms go into the prompt and are checked afterward.
- Memory: the glossary is the terminology authority and takes precedence over both the style guide and memory.
- Documents: terms are extracted from documents, and glossary violations are flagged on a document's segments during translation.
- Translation memory: when a remembered sentence contains a term that has since changed, the glossary wins and the segment is flagged for review.
- Engines: term extraction is a real model call and is spend-capped; offline, the deterministic mock still proposes candidates.
Current limits#
A glossary must be approved and cover a step's language pair before that step can use it; if it is missing from the dropdown, one of those two is the reason.
Editing an approved glossary's content reverts it to draft, so a step using it stops picking up new terms until it is re-approved.
Term metadata, part of speech, definition, notes, is organizational only; it never reaches a translation prompt.
Exporting to TBX is lossy: senses, usage examples and notes are CSV-only.
Term extraction from a document intentionally over-proposes candidates for you to prune; expect to reject a fair number of suggestions.
Pinning an unapproved glossary to a step does not run the step without a glossary: it falls through to the project's own pins and its auto-attached glossaries instead, so the step may quietly translate against a glossary you did not choose.