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#

  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

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#

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.