Glossaries and terminology

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#

1. Create a glossary for the customer.
2. Add its language pairs.
3. Add terms: by hand, by importing a CSV or TBX file, or by extracting candidates from a real document and accepting the good ones.
4. Approve it. An unapproved glossary is invisible to every workflow step.
5. 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

Terminology and interchange#

Beneath the flat source-to-target grid, a glossary is organized around concepts. A concept groups every term that means one thing across locales and synonyms, and a homonym, one spelling with two meanings, becomes two concepts that share a source spelling. Each term under a concept carries a status of preferred, admitted, deprecated, or forbidden; an audience, meaning any subset of human, machine translation, and AI models; a term type such as full form or acronym; and grammatical detail. Only preferred and admitted terms are offered as translations, and a deprecated or forbidden term is kept on record so it can point at what to use instead. Reading concepts, exporting them, and the concept-aware import are always available; the concept and term editor itself is off by default this release and an administrator turns it on from Settings.

Two per-pair controls tune enforcement. Case sensitivity decides whether a term must match the source capitalization exactly. Do-not-translate is a tri-state you can set, clear, or leave unset per language pair, so a term that must stay in the source language for one pair can still be translated in another. When you widen the set of language pairs, the missing per-pair bindings are created automatically for every concept that has a usable source and target, and the response reports how many bindings it added.

Export defaults to TBX-Basic version 3 in the DCA style. Standard fields map to the TBX-Basic vocabulary; house fields that TBX-Basic has no category for, such as do-not-translate, audience, forbidden or superseded status, and case sensitivity, ride a documented private namespace, so a strict TBX-Basic validator treats them as foreign extensions while a consumer that understands the extension reads them. A strict-portable option drops the extension fields and emits a clean instance that validates with no findings, at the cost of those fields. For a fully lossless round trip, including every concept, term, status, audience, term type, and each pair's bindings, use the concept-aware .glossary.json format. A strict import validates against the bundled TBX schemas and refuses the first finding; otherwise findings are warnings.

Importing a plain TBX file loads it as flat per-pair entries. The concept-preserving TBX import, which would rebuild every language, synonym, sense, and data category from a TBX file, is not yet available: it is reserved for a later release and is refused before any file is parsed, pointing you at the standard import. To move a full termbase between installs in the meantime, round-trip it through .glossary.json, which carries every locale itself.

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#