Every product with a real brand has words that are not supposed to be translated the way everything else is. A product name that must stay exactly as-is. A legal term with one correct rendering per market. A competitor name your marketing team never wants machine-translated into something unfortunate. Left to a general-purpose AI pass, every one of these is a coin flip: right most of the time, which is exactly what makes the misses expensive. A glossary is how you turn that coin flip into a rule.
What a glossary term actually controls
A Transglot glossary term is more than a word pair. Each entry carries a source term, an optional part of speech and notes for context, a per-locale set of target renderings, and three behavior flags: case-sensitive (match "Pro" but not "pro"), do-not-translate (render verbatim in every locale), and forbidden (this term must never appear in the output at all, useful for deprecated names or terms your legal team has ruled out). Terms also carry a review lifecycle (pending, active, or rejected), so nothing added by AI extraction goes live without a human okaying it first.
- Case-sensitive matching: distinguish a brand name from the common noun it happens to share spelling with.
- Do-not-translate: pin a term to render identically in every target locale.
- Forbidden: block a term from ever appearing in AI output, full stop.
- Per-locale target renderings: give each language its own correct translation for a term, not just a single global mapping.
- Part of speech and notes: extra context that helps a human reviewer (or the AI) apply the term correctly in a sentence.
Project glossaries and a shared org glossary
Terminology usually has two shapes: things specific to one product, and things true across everything your org ships. Transglot supports both. Every project gets its own default glossary automatically, and an organization can also maintain a shared "house" glossary that gets linked to as many projects as you want: your company name, your legal boilerplate terms, and any brand vocabulary that should stay consistent everywhere. When a project glossary and a linked org glossary both define the same term, the project-level definition wins, so a product-specific override never gets silently clobbered by the house style.
How terms actually reach Glossa
The mechanism matters more than it sounds. Glossary terms are injected as structured data alongside each batch of strings being translated, never baked into the shared system prompt, specifically so that prompt caching stays intact across requests. Glossa is instructed to render each matched source term as its specified target, keep do-not-translate terms verbatim, and never emit a forbidden term, using any notes as a hint for register and tone. For very large glossaries, only the terms that actually occur in a given chunk of source text are sent (ranked forbidden-terms-first, then by longest match, capped at 40 terms per chunk by default), so a 2,000-term company glossary does not bloat every single translation request.
Checking the AI actually followed the rules
Telling an AI model to follow a rule and verifying that it did are two different things, so Transglot checks deterministically rather than trusting the model's word for it. After translation, every row is scanned against its expected terms using a purpose-built multi-pattern matcher (an Aho–Corasick automaton, not a loop of regular expressions) that finds every glossary term in a translated string in a single pass, independent of how many terms the glossary has. A forbidden term that slipped through is always flagged as a hard failure, never softened, regardless of settings. A required or do-not-translate term that went missing is flagged as soft under the default warn enforcement mode, or hard under enforce mode; you can also turn enforcement off entirely for a project that does not need it. A hard finding on a machine translation feeds directly into the same corrective retry pipeline that already handles other translation errors: the row is retried on the quality model with the specific glossary miss noted, instead of you finding the mismatched term in production later.
When a term is marked case-sensitive, the deterministic check matches it verbatim: a case-sensitive needle only counts as present if the case matches exactly. This is what lets "Pro" (the plan name) and "pro" (the common adjective) coexist as genuinely different terms without cross-contaminating each other's rules.
Building the glossary without typing every term by hand
Two paths get terms into a glossary. The manual one: CRUD in the web UI, or bulk import/export via CSV or TBX (the ISO 30042 terminology interchange format). Both are glossary-interchange formats, not translation file formats, so they sit alongside your twenty supported translation formats rather than replacing any of them. The CSV export is hardened against formula-injection (a leading =, +, -, or @ gets neutralized on export and safely restored on re-import), and the TBX parser is hardened against XXE and billion-laughs style XML attacks, the kind of detail that matters once a glossary file starts round-tripping between tools and teammates.
The second path is AI-assisted: a deterministic frequency pass first finds candidate terms in your source strings (filtering stopwords and placeholders, requiring a minimum number of occurrences), then an AI significance pass proposes the genuinely meaningful ones. Every AI-proposed term lands as pending, never auto-approved, so a human always reviews and approves or rejects it before it can affect a single translation. Glossary CRUD, enforcement, and CSV/TBX import/export are available from the Starter plan up; AI-assisted extraction is a Team-plan feature, since it spends real Glossa usage to propose terms.
Why this matters more as you scale
A five-string prototype does not need a glossary: you can eyeball every translation. A product with thousands of strings across a dozen locales, refreshed every sprint, absolutely does. The gap between "the AI translated this correctly on average" and "the AI translated this correctly, every time, for the terms that actually matter to your brand" is exactly what a glossary is for, and having it enforced deterministically, not just requested politely in a prompt, is what makes it trustworthy enough to run unattended in CI.
