Glossaries

A glossary is the approved way to translate specific source terms. It is how you stop the same concept from being rendered three different ways in three different languages — “account” becoming cuenta in one screen and perfil in the next.

Glossaries are term-level. For segment-level reuse (full phrases), see Translation Memory.

When to use them

Build a glossary as soon as you see:

• The same product-specific concept translated inconsistently across screens
• Brand names being translated when they should be kept as-is
• Compliance or legal requirements around specific wording
• Domain terminology (medical, legal, financial) where the “natural” translation is wrong in your context

If you have a handful of UI strings and no specialist vocabulary, skip glossaries until you hit one of the above.

The model

A glossary contains concepts. A concept has:

• Source term — the term in your source language
• Definition — plain-language description of what it means in your product (translators rely on this)
• Target terms — one or more per target language, each with a type
• Part of speech, subject, case sensitivity, non-translatable flag — metadata that controls matching and QA

Target term types

Type	Meaning
Preferred	Use this translation
Admitted	Acceptable alternative
Deprecated	Was used, do not use anymore
Forbidden	Never use this translation

The editor surfaces the preferred term first and flags violations of the other types.

In the editor

When a translator opens a key, Comvi scans the source text for glossary hits and:

• Highlights matched source terms inline
• Shows preferred translations in the glossary panel
• Runs QA checks with configurable severity (see below)

This is passive — the translator decides what to type. Glossary hits don’t auto-apply to the target value.

QA checks

Per project you can tune severity:

Check	Default	Fires when
Forbidden term used	Error	A forbidden target term appears
Deprecated term used	Warning	A deprecated term appears instead of the preferred one
Missing glossary term	Warning	A required glossary term is absent from the translation
Non-translatable term changed	Warning	A non-translatable source term (e.g. brand name) was rewritten
Case mismatch	Info	Casing differs from the glossary definition

Errors can block save if strict mode is enabled in project QA settings; warnings and info do not block.

With machine translation

Glossary behaviour depends on provider type — this is the most important thing to know.

Provider type	How the glossary is applied
LLM providers (OpenAI, Anthropic)	Glossary terms are injected into the prompt with preferred translations. The model is instructed to honour them. Reliable but not guaranteed — review critical terminology.
Classical providers (Google, DeepL, Amazon, Azure)	Terms are not sent to the provider. They appear as hints to the human reviewer in the editor.

Caution

Classical neural providers (Google, DeepL, etc.) have their own proprietary glossary APIs, but Comvi does not integrate with them. If you need enforced glossary terms during bulk MT, either use an LLM provider or post-process classical output with a find-and-replace pass before review.

This is a deliberate product choice: classical glossary APIs differ per provider, add cost, and often silently fail on morphology. The consistent, predictable story is “hints for humans, prompt injection for LLMs”.

See Machine Translation for the broader provider picture.

Creating a glossary

1. Open glossaries

   Either Organization Settings → Glossaries (for shared terminology) or Project Settings → Glossaries (for project-specific terms).

2. Create

   Name the glossary, set its source language (must match the project that will use it), optional description. Save.

3. Add concepts

   For each term, fill in the source term, definition, and at least the preferred translation for each target language. Set metadata (subject, non-translatable, case-sensitive) as needed.

Tip

Every project is created with a default glossary automatically. You can start adding terms to it immediately — no setup needed.

Multiple glossaries per project

A project can have several glossaries assigned, each with a priority. Typical layered setup:

• Organization glossary — brand names, company-wide conventions, compliance terms
• Project glossary — terminology specific to this product surface
• Domain glossary — e.g. legal, medical, financial vocabulary shared by relevant projects

When terms collide across assigned glossaries, higher-priority glossary wins for the editor’s preferred-translation display and for LLM prompt injection.

Import / export (CSV)

Glossaries exchange via CSV. Export produces one CSV with concepts, terms, and metadata. Import asks you to map your CSV columns (source term, definitions, per-language targets, term type) to Comvi’s fields and previews the result before committing.

Use this to seed a glossary from a spreadsheet your terminology team already maintains, or to hand terminology back to a stakeholder for review.

Best practices

• Definitions matter more than you think. A translator seeing “dashboard” needs to know if that’s the product’s main home screen, a widget panel, or a BI report — same English term, different correct translation.
• Start with brand and product-specific nouns. Verbs and adjectives are harder to get consistent at the term level; rely on tone instructions for MT and reviewer judgement for those.
• Use non-translatable liberally for brand. It prevents well-meaning MT from translating product names.
• Mirror glossary scope to team scope. Organization-level for stuff every project must agree on; project-level for stuff one team owns.

Limits

• Glossary with classical MT providers is hints-only — not enforced by the provider.
• Case-sensitive matching is opt-in per concept.
• CSV is the only exchange format today (no TBX).

Troubleshooting

The glossary isn’t enforcing during bulk MT

You are probably on a classical provider. Switch the batch to an LLM provider, or review MT output manually — the hints surface in the editor.

Terms aren’t matching in the editor

Check the source language of the glossary matches the project’s source language. Check the concept’s case-sensitive flag if the source text uses different casing. Morphology (plurals, verb forms) is exact-match only — “dashboard” matches but “dashboards” doesn’t unless both are concepts.

Two glossaries have conflicting preferred terms

Priority decides the winner. Check Project Settings → Glossaries for the priority order.

Related

Machine Translation How LLM prompt injection and classical hint-only behaviour work end-to-end.

Translation Memory Segment-level reuse — longer matches than single terms.

Translations Where glossary highlights and QA checks surface.