DeepL Glossaries: What They Fix, What They Don’t, and How to Test Them

The short answer

Yes: DeepL offers glossaries for selected source and target languages, and you can use them across its translator, apps, integrations and API surfaces. But “glossary” does not mean “replace this exact string with that exact string in every output.” DeepL says entries are adapted to target-language grammar rather than applied as literal search-and-replace, while a user’s real-world report describes a glossary behaving unexpectedly for a one-word entry. The useful answer is therefore conditional: use a glossary to steer domain terminology, then test the actual language pair, surface, content and release version that your team uses. Do not treat the feature as a guarantee of legal, financial, medical or brand-safe translation.

This guide gives you a release test you can run without trusting a vendor score: a small terminology fixture, a risk-weighted review rubric, and a versioned decision record. It is for localization leads, product teams, and buyers evaluating a workflow. It is not a claim that a particular service has passed the tests below. No live DeepL translation run was conducted for this article.

The decision behind the search

A buyer asking whether a glossary “ensures consistency” is usually trying to answer a different operational question: can we publish translated pages, contracts, product screens, or help content without finding that a preferred term drifted between contexts?

There are at least four distinct decisions hidden in that question:

1. Can the product store a preferred term for a language pair?
2. Does the feature apply in the specific translation surface and plan we use?
3. Does the output use the preferred term in our sentence, file, locale and model configuration?
4. Is that output acceptable for the intended use after linguistic, factual, visual and legal review?

A positive answer to the first question does not settle the next three. DeepL’s help page describes glossaries as term and short-phrase preferences, lists supported languages and surfaces, and says entries adapt to the target language’s grammar. That is a useful feature description, not a quality warranty for any one document. It also notes integration dependencies: a third-party plug-in may need to implement support, and the provider may take time to do so. DeepL’s glossary help page

The public search-result gap is practical. Documentation explains how to add preferences; users still ask whether a glossary will enforce an exact output. A Stack Overflow question describes a user expecting a one-word English-to-German entry to behave like a literal mapping, then seeing a grammatically changed form instead. That is a single user report, not a measured defect rate or proof that the feature is broadly unreliable. It does identify the important test: distinguish a desired lemma from an exact protected string, and test context rather than assuming the two are equivalent. The reported API glossary question

The source page this guide expands is a field report on DeepL in production. This article does not repeat a general product review; it isolates one buyer decision the broader field report cannot settle by itself: how to verify that a glossary-backed workflow meets a named terminology and release requirement.

What a glossary can reasonably do

A glossary is a terminology control, not a complete translation policy. It tells a system that certain source expressions have preferred target-language equivalents. The system may still have to decide how those terms fit the sentence, grammar, style and context.

DeepL explicitly says its entries are adapted to grammatical rules in languages with inflection; it says the behavior is not search-and-replace and that users do not need to enter plural or inflected forms for the listed cases. That statement is important because it changes the acceptance criterion. If your requirement is “use the same concept with grammatically appropriate morphology,” the feature may be a useful control to test. If your requirement is “the output bytes must contain this exact string, capitalization and all,” a grammar-aware glossary alone is not a sufficient invariant.

A glossary also cannot decide whether the source text is clear, whether a term is legally correct, whether a target phrase is appropriate for a country, or whether a document preserved layout and numeric meaning. The protocol below deliberately separates linguistic review, visual inspection, functional checks and market-specific controls because a terminology check only covers one narrow slice of quality.

The four-level control model

Use four separate layers rather than asking one feature to provide a blanket guarantee.

This separation is not bureaucratic decoration. It makes failure diagnosable. If a glossary entry is absent, fix configuration. If the output contains an unacceptable form, tighten or reclassify the rule. If the term is correct but the sentence changes the legal meaning, escalate linguistic or subject-matter review. If the test passed last month but a plug-in changed, rerun the fixture against the new configuration.

Start by classifying the term

Do not put every word that sounds important into one undifferentiated list. For each item, choose the policy that matches the risk.

Preferred terminology

Use this for a domain term where a particular target-language expression is preferred, but normal grammar may change the surface form. Record the concept, preferred lemma, forbidden alternatives, usage note, language variant, and an example sentence. A glossary may help steer the term, but the reviewer still decides whether the inflected form is correct.

Protected strings

Use this for names, product labels, legal identifiers, codes, brand spellings, command names, or tokens whose exact characters must survive. Mark them as “must remain exact,” not merely “preferred translation.” Keep a separate automated exact-string check. For high-risk text, do not rely on model instructions alone; preserve or substitute the string in the product pipeline where feasible, then verify it in the final artifact.

Examples include a SKU, a product feature label that must match the interface, a registered organization name, a variable placeholder such as {account_id}, or a warning code. A protected string may appear inside punctuation or grammatical text, but the character sequence should remain intact. Decide in advance whether capitalization, spacing, trademark symbols, and plural suffixes are permitted.

Do-not-translate terms

A term may remain in the source language, but that is not the same as merely preferring a translation. Record whether it must remain unchanged, whether case can vary, and whether a localized explanation may accompany it. Validate the exact source string in the final output.

Context-dependent alternatives

Some source terms have different meanings in different product areas. “Charge,” for example, can mean a fee, a battery action, or a legal accusation. A single global mapping can create a worse error than leaving the term uncontrolled. Split the glossary by domain, add a contextual note, or require human review where the source is ambiguous.

Build a fixture before production use

The reusable asset in this guide is a small, synthetic acceptance fixture—not an empirical benchmark. It contains 12 hand-written test cases across four policy classes: three preferred terms, three inflected-context examples, three protected strings, and three ambiguity or formatting cases. The cases are intended to be copied and adapted; they were not submitted to DeepL or another translation service, and no accuracy rate, success percentage or comparative performance is claimed. That exclusion matters: a test definition is useful, but it is not a measurement of how a model performs.

Create one fixture per important language pair and product surface. Include the source sentence, policy class, expected invariant, acceptable variants, unacceptable result, severity and reviewer note. Do not use a single short phrase for all cases. A system may handle a glossary differently in a full document, editor, API integration or third-party CAT tool, so the fixture must match the route that will ship.

These examples are synthetic. A real organization must replace “Atlas,” “KYC-7,” the example amount, and every target-language expected form with approved material. The fixture does not prescribe translations. It tests invariants, not whether a specific French, German, Italian or Japanese phrase is correct.

Write acceptance criteria before translation

For every fixture row, write a rule that a reviewer can apply without guessing what “consistent” means. A weak criterion says “the terminology should be correct.” A useful criterion says: “The approved target concept must appear; grammatical inflection is allowed if a native reviewer confirms it; no unapproved synonym may appear in a legally operative clause.”

For protected strings, define exactness mechanically. Does the placeholder need to be byte-for-byte identical? Can a product name be followed by a plural suffix? Are curly and straight apostrophes equivalent? Does a currency amount permit locale-specific grouping separators while preserving the numeric value? If you leave these questions implicit, two reviewers may reach different results and both believe they followed the glossary.

Give each criterion four fields:

1. Expected invariant: what must stay true.
2. Allowed variation: what is acceptable and why.
3. Forbidden outcome: what triggers a failure.
4. Disposition: who can approve a deviation and what evidence they need.

For example, a trademark may require exact capitalization, while a common technical term may permit case or gender changes. A financial term may be allowed to inflect but not to change the underlying concept. A disclaimer may require both terminology and legal review. Make the rule narrower when the consequence of an error is higher.

Run the same test at the right boundary

Testing the glossary in a browser while production uses a document plugin does not prove the production path works. DeepL’s support documentation lists multiple platforms but warns that third-party plug-ins are not developed by DeepL and may take time to implement support. Therefore record the full path: service surface, plan, source and target language codes, model or generation setting if exposed, file type, glossary identifier or selected glossary name, integration version, and date.

Then replay the fixture using the same boundary that will be released. For an API, capture request parameters with credentials redacted. For a desktop or web translator, save the exact glossary selection and source text. For a CAT tool, record the plug-in and connector versions. For document translation, inspect the returned file, not only a copied paragraph. Layout, headers, hyperlinks, footnotes, numeric formatting and protected tokens can fail outside the extracted text.

A product update should not be assumed harmless. The DeepL documentation describes feature scope and integration ownership; it does not promise that outputs will be bit-for-bit stable across all future models, plans or interfaces. Treat a service, connector, glossary, language pair or plan change as a test-triggering configuration change.

A practical offline checker for hard invariants

The code below is intentionally not a translation engine and does not call DeepL. It demonstrates how to separate two kinds of assertions: protected strings that must survive exactly, and preferred terms that should be flagged for human review when absent. This checker is conservative: it reports presence and absence, but it cannot establish translation quality, grammatical validity, legal meaning or whether an approved inflected variant is acceptable.

Use it as a starting point for a local test harness, not as a production-complete linter. In a real pipeline, normalize Unicode deliberately, define case rules per term, handle locale-specific morphology, and test the final rendered file. Do not silently auto-correct high-risk text.

const fixture = [
  {
    id: "T01",
    kind: "exact",
    value: "Atlas",
    severity: "high",
  },
  {
    id: "T03",
    kind: "exact",
    value: "{account_id}",
    severity: "critical",
  },
  {
    id: "T04",
    kind: "review-if-missing",
    value: "règlement",
    severity: "high",
  },
  {
    id: "T09",
    kind: "exact",
    value: "KYC-7",
    severity: "critical",
  },
];

const output = "Ouvrez l’espace Atlas. Gardez {account_id}; KYC-7 reste inchangé.";
const findings = [];

for (const test of fixture) {
  const found = output.includes(test.value);
  if (!found && test.kind === "exact") {
    findings.push({ id: test.id, severity: test.severity, status: "FAIL" });
  } else if (!found && test.kind === "review-if-missing") {
    findings.push({ id: test.id, severity: test.severity, status: "REVIEW" });
  } else {
    findings.push({ id: test.id, severity: test.severity, status: "PASS" });
  }
}

console.table(findings);

This tiny example uses substring checks because the lesson is about test contracts, not sophisticated NLP. It would give a false failure if a preferred term legitimately inflects, and it could give a false pass if the protected token appears in a comment rather than user-facing text. A production checker should parse the relevant output fields, distinguish visible content from metadata, and use a language-aware allowlist where morphology is permitted. Keep exact tokens out of automatic rewriting rules: a “fix” that changes a placeholder can break the application.

For batch use, make the report machine-readable. Store input ID, source hash, output hash, exact assertion result, reviewer decision, and tool configuration. Do not include confidential text in a public test fixture. If you need to retain customer material, follow your organization’s retention and access rules.

The review rubric: stop treating one score as quality

A single aggregate score can hide a critical error. A translation with excellent style but a changed account number should not “average out” to a passing result. Use hard gates for exact and high-risk invariants, then use a separate qualitative review for language.

Suggested severity:

• Critical: placeholders, amounts, dates, dosage, legal obligations, identity, privacy or access-control text are missing or changed. Block release.
• High: product names, regulated terminology, warnings, market-specific claims or key user actions violate an approved rule. Block or require named approval.
• Medium: a preferred term is inconsistent in low-consequence copy, but meaning remains clear. Correct and log.
• Low: style or typography differs without changing meaning. Accept only if the style guide allows it.

Each row should be marked Pass, Fail, Review, or Not Applicable. “Review” is not “Pass.” Define who can convert a review to pass, and retain the reason. For an exact-token failure, the default is to block. For a linguistic alternative, a qualified reviewer can accept a grammatically appropriate form and update the test case if the underlying policy changes.

This approach treats functional, visual and linguistic checks as separate release gates. A glossary may help the terminology dimension, but it does not replace visual inspection, functional parity, native-language review, context review or market-specific checks.

Add context, not just a bilingual pair

A term list without context is easy to misapply. For each term, document the domain, part of speech, meaning, approved target, prohibited alternatives, product surface, locale, examples and owner. If one source word has multiple senses, add separate entries only when the product or workflow can disambiguate them. Otherwise mark the word as requiring human review.

A practical record could look like this:

A term with no owner is a latent disagreement. When two teams propose different target forms, do not merge them by majority vote or choose the phrase that appears most often in existing output. Record the decision, rationale, scope, and whether the alternative is valid in another market or context.

Protect documents and personal data before testing

A terminology experiment can involve confidential source text. Do not paste a live contract or customer record into a consumer interface just to test a glossary. First classify the data, confirm the approved service and contract, and use a synthetic fixture whenever possible. Remove personal data and trade secrets from examples unless a controlled test environment has been approved.

For organizations within the UK GDPR scope, the ICO explains that a restricted transfer may arise when personal information is sent or made accessible to a separate organisation outside the UK, and its checklist asks organizations to map data flows and determine who initiates the transfer. The trigger depends on the facts, including legal entity and role; simply using a translation tool does not automatically prove a restricted transfer. But where personal data does flow to a separate overseas entity, the organization should follow the applicable transfer analysis and safeguards. This is UK guidance, not a universal rule for every jurisdiction. ICO’s international-transfer checklist

Separate the content-risk decision from the glossary decision. A glossary can improve terminology steering, but it does not decide whether the service is contractually approved, whether the processing role is lawful, or whether the selected endpoint and retention model match policy. If you cannot answer those questions, test with invented content and get privacy or legal review before processing real text.

Separate machine translation from human translation-service standards

Standards can provide a useful boundary, but do not overclaim what they cover. ISO 17100:2015 describes requirements for translation-service processes and resources. ISO’s own summary says that raw machine-translation output plus post-editing is outside the scope of that edition. It also lists a newer ISO/AWI 17100 work item under development, while the 2015 standard is shown as “to be revised.” So do not say that a glossary or an MT workflow is “ISO 17100 compliant” merely because a supplier or reviewer uses a quality checklist. Establish the exact service scope and current standard status first. ISO’s page for ISO 17100:2015 and the work item replacing it

This boundary reinforces the main recommendation: the glossary is one control inside a translation workflow. It cannot stand in for a translation service process, independent review, subject-matter verification or legal approval.

A release protocol you can reuse

Use this protocol for initial evaluation and for material changes. It deliberately distinguishes a feature test from an operational release decision.

1. Freeze the requirement. Write the source and target locale, use case, content class, term policy, exact tokens and stop rules before translating.
2. Build the fixture. Include preferred terms, inflections, protected strings, ambiguous senses, UI labels, numbers, dates and formatting appropriate to the document.
3. Classify data. Use synthetic content unless privacy, legal, security and procurement owners approve the real-data path.
4. Record configuration. Save service, surface, integration or plug-in version, plan, model selection if shown, language pair, glossary identifier, file type, and date. Redact secrets.
5. Run control and treatment. For diagnosis, translate the same fixture once without the glossary and once with it, when the interface allows a fair comparison. Keep all other settings fixed. This is a paired operational check, not a randomized experiment proving general product quality.
6. Score hard gates first. Check exact tokens, numbers, dates, legal clauses, warnings and key UI labels. Any critical failure blocks release.
7. Review linguistic fit. A qualified target-language reviewer checks correctness, naturalness, context, locale, grammar, terminology and cultural fit. A reviewer must be able to see source and target.
8. Inspect rendered artifacts. For files and screens, inspect layout, tables, links, footnotes, forms, line breaks and truncation in the actual product.
9. Record exceptions. Every accepted deviation has an owner, reason, scope and expiration or review trigger.
10. Set a change trigger. Rerun the fixture when the glossary, language pair, model, plan, plug-in, API integration, document type or source taxonomy changes.
11. Approve or reject. Record the decision as approved for a named workflow, approved with restrictions, blocked, or insufficient evidence.
12. Recheck drift. Sample production outputs only under an approved data process; compare them to the same invariants and record incidents without turning anecdotal observations into rates.

Gartner’s public summary on proof-of-concept buying argues that a proof of concept can validate vendor claims and reduce buyer-remorse risk for complex enterprise applications. That supports using a bounded, representative test before rollout; it does not validate any specific translation product or glossary result. Gartner’s proof-of-concept guidance

How to interpret the result

A useful test result is scoped. It should say, “This configuration passed these cases for this language pair and content class on this date,” not, “DeepL is consistent,” or, “The glossary guarantees accuracy.”

Use a decision matrix:

A pass does not mean every possible sentence will pass. A small fixture is a screening tool. It has limited coverage, may not include every grammatical construction, and may miss rare but serious errors. For higher-risk content, add domain-specific examples and involve a subject-matter reviewer. If the text changes regulatory duties, financial obligations, medical instructions or security behavior, translation review is not a substitute for legal, finance, clinical or security approval.

What to do when a glossary appears to be ignored

Start with a reproduction record, not an accusation. Capture the exact source sentence, source and target language, glossary name or ID, platform, plan, plugin, model setting, file type and output. Redact confidential text. Then check, in order:

1. Was the intended glossary selected for this exact request or document?
2. Is the source language explicitly set where the workflow requires it?
3. Does the glossary contain the right language pair and direction?
4. Does the connector support that feature in the current version?
5. Is the source term actually present in the tested context, including punctuation or inflection?
6. Is the target output a legitimate grammatical form under the team’s policy?
7. Did the full output preserve the term but alter layout or surrounding markup?
8. Can the behavior be reproduced with a synthetic minimal example?

The support page notes that third-party plug-ins are maintained by their providers and that feature implementation may lag. That makes the connector version a real diagnostic variable, not an excuse to dismiss a failure. Keep a baseline sample that tests the same term through the native product and the integration route, if both are approved. If the native flow passes and the integration fails, the issue may be in the connector or its configuration; it does not prove the translator itself is at fault.

The Stack Overflow report is several years old and is a single question with one answer, so it cannot establish current behavior or prevalence. It is still a useful example of why a reproduction must distinguish exact strings from context-sensitive terms. Do not extrapolate from one post to a reliability claim, and do not ignore a local, reproducible failure just because documentation describes the intended feature.

Failure modes that the fixture should catch

• The glossary is selected in the web UI but not passed by the API or plug-in. The result may look like a language-quality failure when the configuration was never applied.
• The wrong language direction is used. A glossary for English-to-German does not automatically establish that a reverse German-to-English map exists.
• The source text is ambiguous. A one-word term without context can be mapped to a plausible but wrong sense.
• A protected name is classified as a preference. The engine may adapt it or alter punctuation where the business rule requires exact preservation.
• The reviewer checks copied text instead of the final file. A text extract can look right while tables, links, footnotes or form labels are corrupted.
• The test validates only one locale. French for France, French for Switzerland and French for Canada are not interchangeable merely because the language label says French.
• A software update changes a workflow boundary. The glossary might remain unchanged while an extension, API call or document integration changes.
• A pass is summarized as a guarantee. A test proves only the cases and configuration it actually exercised.
• A subjective aggregate score hides a critical failure. Block exact-token, numeric and legally meaningful errors before computing any softer linguistic score.
• A synthetic test is presented as production evidence. A test fixture has no service-performance result until someone executes it and records the setup and output.

Limitations and contradictory evidence

The vendor’s documentation says glossaries are designed for terms and short phrases and adapt entries to target grammar. The user report says a user expected a one-word exact mapping and saw an unexpected form. These accounts are not necessarily contradictory: a context-aware, grammar-adapting feature can behave differently from a literal substitution table. But they do disagree with a casual interpretation that “preferred translation” means exact string enforcement.

The report is user-generated, old, and not a controlled test. Its answer cites support guidance, but the answer itself is not an official specification. The official support page is the better source for the feature’s intended behavior; the user report is evidence of the kind of edge case a buyer should test, not a measured estimate of failure frequency.

The broader standards and governance sources also have bounded scope. ISO 17100:2015 is a translation-service standard and explicitly excludes raw MT output plus post-editing from its scope. The ICO’s transfer checklist is specific to UK GDPR and depends on the data flow and legal entities. Gartner’s article is a public abstract promoting a proof-of-concept evaluation approach, not an independent comparison of translation engines. None of these sources establishes that one vendor is better than another.

Checklist before approving a glossary-backed workflow

• [ ] The glossary owner and approval authority are named.
• [ ] Every entry has a language direction, definition, domain and usage example.
• [ ] Terms are classified as preference, protected string, do-not-translate or context-dependent.
• [ ] Exact-string requirements have external checks and explicit character rules.
• [ ] The fixture contains real risk patterns, not only isolated vocabulary.
• [ ] The language pair and market variant match the intended release.
• [ ] The test runs through the actual app, API or plug-in used in production.
• [ ] Configuration and version are recorded without exposing API keys or customer text.
• [ ] Synthetic content is used until privacy and contractual approval are established.
• [ ] Critical failures block release rather than disappearing into an average score.
• [ ] A qualified language reviewer checks meaning and context.
• [ ] Rendered documents and screens are inspected, not just extracted text.
• [ ] Exceptions have an owner, rationale, scope and recheck date.
• [ ] Material changes trigger a repeat test.
• [ ] Approval language names the workflow and its limits; it does not promise universal accuracy.

Bottom line

DeepL does offer glossaries, but a glossary is a control for preferred terminology, not a universal consistency guarantee. The vendor’s own description says grammar may change the form; the real user question shows why teams confuse a preference with exact replacement. Define which strings must remain exact, build a small representative fixture, run it through the actual integration, and block high-risk failures. Then review meaning, locale, layout and data handling separately. Approve only the tested workflow and configuration, and rerun the tests when the system changes.

Sources and scope

• DeepL Help Center: About the glossary — feature definition, language/surface coverage, grammar-aware behavior, storage and integration notes.
• Stack Overflow: Python DeepL API glossary not working — one user’s reproducibility question; anecdotal, not prevalence evidence.
• ISO 17100:2015 — translation-service process scope; raw MT output plus post-editing is excluded from this edition.
• ICO: A brief guide to international transfers — UK-specific test for restricted transfers of personal information.
• Gartner: Use Proof of Concept to Overcome Hype on Enterprise-Application-Related Buying — public abstract supporting bounded buyer-side testing, not a translator comparison.