Why Terminology Is Inconsistent Across Translation Projects

Project A shipped "widget." Project B, same client, same source term, shipped "gadget." Both packages passed QA. Nobody opened a TM-conflict ticket, because the full source segments were not the same. The concept was. Three months later the UI, the help, and the legal addendum disagree, and the client asks which glossary you are actually using.

This is a different ticket from conflicting TM entries (same source segment, two targets in one memory) and from duplicate segments (same pair stored twice). Those workflows clean one database. They do not explain why two approved jobs used two approved words.

This page is a diagnostic for LSP leads, in-house localization PMs, and terminology owners who already have TMs and termbases and still see drift across projects. It is not a vendor feature list.

What “inconsistent across projects” means

Teams mix four objects:

  • Cross-project term drift. The same concept, in different segments and jobs, was confirmed as different target wording. Each file can look internally consistent.
  • TM conflict. One source segment, two targets, in one memory. Resolve it on the conflicts guide.
  • Source-side inconsistency. The author used two source terms for one concept. memoQ’s target-to-source terminology check can flag identical targets with different sources. Fix the source if you can; do not paper it over in the termbase.
  • Intentional variant. Locale, product line, audience, or forbidden-for-this-brand wording. These need a domain or customer field — not a second unofficial glossary.

If you only run a conflict filter on the master TM, you will miss most term drift. The segments are not identical. The terms are.

How the second wording gets approved

1. Each project verifies a different termbase — or none

Terminology QA is scoped to the resources attached to this project. A vendor copy, a PM’s spreadsheet imported “just for this job,” or a leftover client TB from 2023 will pass its own check and still disagree with the account standard.

RWS documents that Studio’s Terminology Verifier uses one termbase — and for cloud engines, only the first cloud termbase in the translation engine. Extra MultiTerm bases attached for lookup do not get verified. memoQ QA “Check for consistent use of terminology” uses the project’s term bases. If the authoritative list is not in that list, the check is silent.

2. Preferred exists. Forbidden does not.

A termbase that lists the new preferred term and leaves last year’s wording as an unmarked synonym will not fail a deliverable. Translators see both hits. Reviewers pick the one that “sounds like the TM.”

Trados’s Check for terms which may have been set as forbidden only works when the termbase has a term-level picklist (often a field named Type) and you map the forbidden value in Verification Settings. memoQ needs the term marked forbidden and Warn if forbidden term is used enabled — optionally even when there is no source equivalent, and optionally in the source segment so the warning goes back to the client.

If those fields are empty, QA has nothing to fire on.

3. The TM inserts last year’s term before anyone looks at the term hit

A 100% or high-fuzzy match is a full segment. It can contain a deprecated product name and still look “already translated.” The linguist confirms. The termbase hit, if anyone noticed it, loses to leverage.

This is why “we have a termbase” and “the TM keeps us consistent” are not the same claim. Reuse spreads a decision. It also spreads the wrong one with full confidence.

4. QA ran on this package, not on the account

memoQ can warn on missing terms (3091), extra terms (3092), forbidden terms (3093 / 3097), and inconsistent translations (3100 / 3101). Trados can check non-usage of the target term, forbidden values, and missing target equivalents. Both run against the current files.

They will not compare Project B to Project A from last quarter. A variant that is consistent inside each package is invisible to intra-file QA.

5. Vendors keep the real list locally

The client exports a TB. Each vendor imports it once, then maintains a private sheet for “terms we actually use.” The next RFP starts from a different snapshot. Nobody owns the merge. This is governance, not a missing plugin.

How to detect it across jobs

Do not start in the TM editor’s conflict filter. Start with the terms.

  1. Pick the 30–50 highest-frequency concepts — product names, UI strings, regulated labels — not the whole TB.
  2. Concordance every preferred form and every known deprecated form in the shared TM. You are looking for both, in recent projects, not for identical source segments.
  3. Compare bilingual exports from the last N jobs against one term list (preferred + forbidden). A bilingual QA tool or a term-check on each export will show a variant that no single project QA reported.
  4. Diff the termbases themselves. Same source concept, different target, no forbidden flag: that is the next drift, not a historical curiosity.
  5. Check what the verifier actually used. In Studio, confirm which termbase is first. In memoQ, confirm the QA profile and which TBs are assigned. A lookup-only TB does not count.

Prevention: set these on the account, not the package

  1. One writable authoritative termbase per account (or per product line, if the variants are real). Attach it to every project. Vendor copies are read-only snapshots with a date.
  2. Mark forbidden / deprecated in the field the verifier reads. A preferred-only list is a suggestion, not a check.
  3. Enable the checks: Studio — non-usage of the target term, forbidden values, missing target equivalent. memoQ — consistent use of terminology (source-to-target for enforcement; both ways if you also want source-author drift), plus forbidden-term warnings.
  4. After a term change, treat old TM units as stale. Batch-update, penalize, or move them to a reference TM. Do not wait for linguists to override 100% matches.
  5. Write the decision: preferred form, forbidden forms, domain, date, who approved. Put it in the TB, not in Slack.
  6. Re-run the 30–50 term list across recent exports when you onboard a vendor or change a product name — not only inside the live package.

What this usually is not

  • “The TM is corrupt.” The memories are storing what each project confirmed. The missing object is a shared term decision.
  • “We need to allow multiple translations.” That setting is for competing full-segment targets. It makes term drift harder to see. Use the conflict workflow for those rows.
  • “QA is broken.” The QA ran on the TB you attached. If that TB was the vendor copy, the green report is honest and still wrong for the account.
  • “Add another glossary to this project.” Studio will still verify the first cloud termbase. A second list that is not verified is how the last variant survived.

Fixes that help — and fixes that do not

Help:

  • One account termbase, attached and verified, on every project
  • Forbidden flags the verifier is configured to read
  • Studio / memoQ terminology checks actually enabled in the project template
  • Stale-TM policy after a term change
  • A short cross-project term audit on high-frequency concepts

Do not help, or help only once:

  • Cleaning TM conflicts and calling the terminology problem solved
  • A project-local glossary that is not the account TB
  • Hoping 100% matches are terminologically current
  • Running QA only on the package you are about to invoice

The limit a termbase cannot repair

A termbase answers one question: for this source designation, which target designation is allowed? It does not know why the reviewer changed a confirm last year, or whether this chapter is the product-line exception. You can have a perfectly enforced TB that still ships the wrong wording because the TM supplied a full sentence and nobody asked.

That is why we built Aquilla around living memory instead of a term list plus string lookup. Suggestions come from the project’s own work and the team’s documented translation philosophy — including which designations the team has been using on purpose. You can still run a conventional termbase and TM. This page exists because that workflow is real, and cross-project term drift has mechanical causes.

Summary: cross-project terminology checklist

  • ☐ Separate term drift from TM conflicts (identical source segments) and from exact-pair duplicates
  • ☐ Confirm one writable account termbase is attached and is the one the verifier uses
  • ☐ Mark deprecated variants forbidden in the field Studio / memoQ actually reads
  • ☐ Enable non-usage, forbidden, and (memoQ) consistent-use checks on the project template
  • ☐ After a term change, update or quarantine matching TM units — do not rely on linguists to override 100% matches
  • ☐ Concordance preferred and deprecated forms across the shared TM
  • ☐ Re-check the 30–50 highest-frequency terms against recent bilingual exports, not only the live package
  • ☐ If stored translations themselves conflict, use the conflict workflow
  • ☐ If the TM’s units look generally untrustworthy, audit the TM

FAQ

Why is terminology inconsistent across translation projects?

Usually because each project verifies a different termbase, deprecated variants are not marked forbidden, 100% TM matches insert old wording, and terminology QA only runs on the current package. The same concept can be approved three ways without any one TM showing a conflicting entry.

Is this the same as a translation memory conflict?

No. A TM conflict is the same full source segment stored with two targets. Cross-project terminology inconsistency lives inside different segments and jobs. Cleaning conflicts does not fix it.

Why did both projects pass terminology QA and still disagree?

Each job passed against the termbase it had attached. Studio verifies one termbase (the first cloud termbase). A second glossary used for lookup is not verified. Intra-file QA cannot see last quarter’s deliverable.

Does a translation memory keep terminology consistent?

It reuses whatever was confirmed. After a term change, that reuse is how the old wording returns. Treat the TM as leverage, not as the termbase.

Related Resources