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.

Terms match whole words in every script written with spaces, so a term never matches inside a longer word. Chinese, Japanese, Thai, Lao, Khmer and Myanmar terms match anywhere in the text, since those scripts do not separate words.

Longest match wins. When a shorter term occurs only inside a longer matched term (trail inside the do-not-translate Colorado Trail), the shorter term is neither sent to the engine nor checked for that segment, across every glossary the step uses. An occurrence outside the longer term is still sent and checked.

MultiTerm and Trados termbases. Export the termbase from MultiTerm as MultiTerm XML (or TBX) and import it like any termbase. MultiTerm XML (UTF-16 is fine), the TBX 2002 default dialect, TBX-Basic and TBX v3 are read, with definition, subject, part of speech, context and notes mapped. Forbidden or deprecated terms are kept as do-not-use terms and never used as the required translation. The import reports each entry as imported, merged into an existing term, or skipped with the reason. Glossary imports also take .xlsx and .tsv spreadsheets.

Any approved glossary can be pinned to a workflow step. A pinned glossary is used only for runs whose languages its pairs cover, and the run log says when one was skipped.

Getting started#

1. Create a glossary for the customer.
2. Add its language pairs.
3. Add terms: by hand, by importing a CSV, TBX, MultiTerm XML or spreadsheet 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#