How to maintain a client glossary across multiple projects and translators
Client glossary management breaks down when nobody owns updates. Here's how to keep your glossaries accurate and consistent across projects.
Client glossary management sounds like a solved problem until you are two weeks into a large project and a junior translator has used five different terms for the same concept, none matching the client's approved list. We've seen this happen with experienced teams, well-structured workflows, and clients who actually provided a glossary at the start. The breakdown rarely comes from negligence. It comes from the gap between having a glossary and genuinely maintaining one across months, projects, and rotating translators.
This article covers how to structure a client glossary that stays useful over time, how to synchronize it across a team, and how to build a process that doesn't depend on someone remembering to check a spreadsheet.
Why client glossary management fails in practice
Most translation teams start a new client relationship by collecting glossary files, importing them into a CAT tool, and moving on. That approach holds for the first project. It starts to fall apart when the client updates their product naming, when a new freelancer joins the team, or when work on that account pauses for six months and then resumes.
The failure modes are predictable. Glossaries sit in a spreadsheet that nobody owns. New terms get added by one translator and never communicated to others. The CAT tool version drifts from the spreadsheet version. A project manager approves a new term in a client email, and the glossary never gets updated.
These aren't abstract process failures. They're coordination failures. A glossary not connected to a clear update process is, in practice, a static artifact that becomes less accurate with every project.
Accepting that a glossary is a living document is the starting point. It needs an owner, a review schedule, and a defined update process, not just an import step at project start. The teams that handle this well aren't necessarily using more sophisticated tools. They've made a structural decision: one named person owns each client glossary, and that ownership comes with specific responsibilities. Everyone else can propose additions, but final decisions run through one person. That single change resolves most of the coordination problems before they occur.
What a working client glossary actually contains
Before talking about maintenance, it's worth being precise about what a production glossary should include. We've seen many glossaries that are technically correct but practically unusable because they're missing the context a translator needs at the moment of decision.
A minimal working glossary entry includes the source term, the approved target term, the language pair, and a domain label. That covers the basic case. But for glossaries that survive across multiple projects and rotating translators, you also need:
- A usage note explaining when the term applies and when it doesn't
- An example sentence showing the term in context -- even one sentence helps substantially
- A "do not use" column for rejected alternatives a translator would otherwise reach for
- The date the entry was added or last modified
The "do not use" column is consistently underused. One of the most common glossary problems we encounter is a translator selecting a plausible synonym that the client explicitly rejected in the past, but that rejection was never captured anywhere. Glossary disputes with clients almost always involve terms that were once acceptable and then changed, not terms that were never discussed.
The modification date matters too. A glossary entry from three years ago that nobody has reviewed is a prompt to verify: is this still the client's preferred term? For long-running accounts, a review of entries older than twelve months frequently surfaces approvals that have since shifted. Terminology evolves in technology, legal, and medical domains in particular, and a glossary that no longer reflects current usage can cause more confusion than no glossary at all.
If your glossary lives in Smartcat, the structured glossary feature allows you to attach definitions and usage notes per term. That's more usable than a flat spreadsheet column, especially for translators working under time pressure who won't open a separate file to check context mid-segment.
How to keep a glossary current as projects accumulate
The update workflow is where most teams lose consistency. New terms come up in every project, client preferences shift, product names change. If there's no defined process for feeding those changes back into the glossary, they accumulate as informal knowledge in email threads, in translator comments, or in a project manager's head.
A straightforward approach is a glossary review checkpoint built into the project closeout process. At the end of each project, whoever ran the QA pass reviews the translation for any terms that required a decision mid-project. If a term was debated, approved by the client, or discovered to be missing, it gets added or updated before the project is marked complete.
This takes five to ten minutes on a typical project. The compounding effect is what makes it worth doing: after a dozen projects, you have a glossary that reflects the client's current preferences rather than their preferences from the first engagement.
For accounts where multiple project managers handle work simultaneously, a single glossary owner becomes non-negotiable. That person approves all additions, resolves conflicts between entries, and handles terminology consultations with the client directly. Shared ownership with no defined decision-maker produces glossaries with conflicting entries, and conflicting entries are worse than gaps because they create the appearance of a decision where none exists.
One pattern that works well: a pending terms tab in the source-of-record spreadsheet where translators and PMs can propose additions during a project. The glossary owner reviews and approves at closeout. This keeps the main glossary clean while still capturing candidates in real time, without requiring any new tooling.
Making the glossary work for multiple translators
A glossary that lives in a project manager's spreadsheet is invisible to the translators who need it. Effective client glossary management across a team requires that the glossary be accessible inside the CAT tool, not in a separate file the translator has to open and search manually while working.
Most modern CAT tools, including Smartcat, allow glossaries to be attached to projects so that approved terms surface as suggestions during translation. This puts the glossary in context, makes it difficult to miss, and doesn't interrupt the translator's flow with a context switch to an external file.
The practical challenge is keeping the CAT tool version synchronized with the source-of-record version. If the source of record is a spreadsheet, you need a defined update step whenever the spreadsheet changes. If the CAT tool is the source of record, you need a defined export step when clients request the glossary file.
One approach that reduces synchronization errors: treat the CAT tool as the primary source of record from the start rather than importing from a spreadsheet. New terms get added directly to the CAT tool glossary. Exports happen from there when clients ask for the file. This works well for teams handling one client in a single CAT tool environment.
Where it gets complicated is freelancers who work in their own tools, or projects that span multiple platforms. In those cases, the spreadsheet as source of record with a mandatory sync step is usually more practical. Making that sync step a checklist item before project start -- not after -- prevents drift from building up unnoticed across multiple cycles. For agencies using Smartcat with multiple translators, attaching the glossary at project level rather than at account level also reduces the risk of translators working with a version that's out of date.
When the client doesn't have a glossary
A significant share of the agencies and freelancers we talk to work with clients who have no glossary at all, not even an informal list. The client has preferred terms, sometimes strong preferences, but nothing documented. Starting from zero is its own problem.
The most efficient approach is building a working glossary from the first project rather than waiting for the client to provide one. During translation, flag terms that required a decision. After delivery, compile those decisions into a structured list and share it with the client for approval. Most clients respond well to this. It shows attention to their terminology and gives them documentation they didn't have before.
The initial glossary from a first project is small, typically thirty to fifty terms. But it provides a foundation. By the third or fourth project, you'll have a glossary that meaningfully reduces per-project decision time and client revision requests. Clients who start with no glossary often end up with more consistently maintained terminology than clients who provided a glossary at the start, precisely because the build-up process forces active decisions about every entry rather than assuming the original list is still accurate.
Building from existing client materials is also viable if the client has published content: product pages, technical manuals, or previous translations they're satisfied with. Running those through a terminology extraction pass surfaces candidate terms that can then be validated with the client directly. This approach works best when the client has a meaningful volume of published content in the source language.
For a broader treatment of terminology workflows, our guide on translation terminology management covers the full scope in more detail.
Using CAT tool glossary features without over-relying on them
CAT tool glossary integration helps, but it has limits worth understanding. Term highlighting works reliably when the exact source term appears in a segment. It catches fewer cases involving multi-word expressions with word order variations, morphologically inflected terms in languages like German or Finnish, or compound nouns that appear in variant forms across the document.
Term suggestions also don't account for context. A source term like "resolution" might have different approved translations depending on whether the document covers display settings, legal disputes, or image quality. The glossary entry can include a usage note, but the translator still has to read it and make the call. CAT tool glossaries support decision-making. They don't replace it.
This matters for maintenance because it means periodically auditing how well the glossary is being applied in practice, not just whether it exists. A QA pass that spot-checks glossary adherence on a sample of segments per project will surface both translator misses and cases where the glossary entry itself is ambiguous or internally conflicting.
For agencies handling specialized content -- legal translation, medical documentation, financial reporting -- a subject-matter expert review of the glossary once or twice a year is worth building into the client relationship schedule. Terminology evolves in specialized fields, and entries that were accurate two years ago may no longer reflect current usage or regulatory language.
If your workflow involves Smartcat bilingual DOCX exports, SnapIntel lets you edit and approve glossary content directly before a translation job starts, which helps keep the active project's glossary context in one place rather than spread across separate files and import steps.
Practical takeaway
Client glossary management is a coordination problem as much as a terminology one. The tools to handle it -- CAT tool glossary features, structured spreadsheets, terminology extraction utilities -- are well established. What breaks down is the process: who owns the glossary, how updates happen, and how translators access current terms when they need them.
If your team handles a client account with more than two projects per year, the minimum viable process is a named glossary owner, a review checkpoint at project closeout, and a single source of record that feeds into your CAT tool before each project starts. That's where to begin, not with a new tool, but with a clear decision about ownership and update frequency. Everything else can be refined from there.