People searching termbase priority, multiple glossaries CAT tool, rank termbases, working termbase priority, client glossary above general glossary, or how to choose between competing terminology suggestions are dealing with a problem that appears only after a translation environment becomes rich: the CAT tool has several termbases, and more than one resource recognizes the same source expression.
A fast translation workflow needs termbase priority. The editor should surface the terminology with the strongest project authority first: client-approved vocabulary above general reference terms, product terminology above broad domain glossaries, current project decisions above legacy suggestions. Modern CAT tools often let project managers rank termbases and designate one resource as the target for new entries. The interface may still show several matches, but the order should reflect trust.
This article owns one narrow reader job: configure and interpret termbase ranking so the right terminology appears first when several glossaries compete. It is different from extracting terms, quick-adding new terms, or checking glossary compliance. Those workflows create or enforce terminology. Priority decides which resource gets the first claim on translator attention.
Quick answer
Rank termbases by authority and relevance.
A simple hierarchy might be:
- current client-approved glossary;
- current product/project termbase;
- approved domain glossary;
- legacy client glossary;
- general reference termbase.
Set the project’s working termbase deliberately for new entries.
Then audit the translation results pane:
Are the first suggestions usually the terms you actually want?
If not, fix priority.
Why terminology competition costs time
One source term appears.
The editor shows:
- three target equivalents;
- from three termbases;
- all plausible;
- no obvious authority.
The translator stops.
They inspect resource names.
They search client instructions.
They pick one.
This can happen hundreds of times.
The cost is not the terminology lookup itself.
The cost is repeated resource arbitration.
Termbase priority externalizes that arbitration.
Similarity does not equal authority
Termbase suggestions may all be exact lexical matches.
The conflict is not about matching.
It is about governance.
Example source:
account holder
Termbase A: current banking client glossary. Termbase B: general legal glossary. Termbase C: legacy marketing glossary.
All recognize the phrase.
Only one may be approved for the current project.
Ranking should encode that difference.
Build a terminology authority ladder
Ask of each termbase:
- Who owns it?
- Is it current?
- Is it client-approved?
- Does it match the product?
- Does it match the domain?
- Is it curated or imported?
- Is it reference-only?
- Can translators write to it?
Use the answers to rank.
Tier 1: current client master
This is usually highest authority when the client has explicitly approved terminology.
Its suggestions should appear first.
But even client masters can contain:
- outdated entries;
- domain ambiguity;
- regional variants.
Priority reduces search cost.
It does not eliminate context checks.
Tier 2: project/product termbase
A project working glossary may contain the latest local decisions.
If a new product release has terminology not yet promoted to the client master, the project resource may deserve very high priority.
This depends on governance.
The important thing is that the ranking reflects the current truth.
Tier 3: domain reference
A technical glossary can be useful when client resources are silent.
Examples:
- medical terminology;
- engineering;
- legal;
- finance.
Reference resources should support decisions without overriding client preferences.
Tier 4: legacy resources
Legacy glossaries can provide historical evidence.
They should not dominate current suggestions if terminology has changed.
Lower rank keeps them available without letting them consume first attention.
Tier 5: broad general glossaries
These can help with uncommon terms.
They are usually weakest for project-specific naming.
Keep them lower.
Worked example 1: product rename
Old product termbase:
Control Center
New product glossary:
Operations Hub
Source uses a product concept that historically mapped to Control Center.
The new client resource should rank above legacy.
If not, translators will repeatedly see and perhaps select the obsolete name.
Priority reduces terminology regression.
Worked example 2: domain versus client preference
General medical glossary uses one accepted translation.
Client glossary deliberately uses a patient-friendly alternative.
Both are linguistically valid.
Client preference controls this project.
Rank client glossary first.
The domain glossary remains useful for definitions and related terms.
Worked example 3: local project decision
During translation, the team resolves a new component name.
It is quick-added to the project working termbase.
The client master does not yet contain it.
If working TB ranks below a general glossary, the editor may keep presenting the generic term first.
High project priority makes the new validated decision visible immediately.
Worked example 4: regional variant
Termbases:
- Spanish (Spain);
- Spanish (Mexico);
- global Spanish.
Project target is Mexico.
Rank locale-specific terminology first.
A global term may be acceptable.
A Spain-specific term may sound wrong or violate client policy.
Locale is part of authority.
Designate one working termbase
When several termbases are attached, decide where new entries go.
Do not let quick-add write randomly into whichever resource was attached first.
A designated working TB provides:
- one capture location;
- easier review;
- cleaner promotion;
- fewer duplicates.
Priority and write target are related but not identical.
One resource can rank highest for reading while another receives new project entries.
Read priority and write priority
Think of two questions:
Read priority
Which resource should appear first in suggestions?
Write target
Where should new terms be stored?
A client master may be read-only but highest priority.
A project working TB may be the writable target.
This architecture is often sensible.
What happens when two high-priority termbases conflict?
Do not simply trust the first.
Investigate:
- client scope;
- product;
- date;
- domain;
- locale;
- entry metadata.
Priority is a default routing rule.
A real conflict may indicate resource maintenance is needed.
Duplicate source terms across resources
A duplicate is not always a problem.
The same source concept can legitimately exist in:
- client master;
- project working TB;
- domain reference.
But if target suggestions differ, translators need a clear rule.
Rank and metadata should explain authority.
The result-pane attention budget
The translation results pane has limited visual space.
If high-value terminology is buried below:
- old entries;
- generic entries;
- irrelevant languages;
the translator pays a navigation tax.
Priority is partly interface design.
Put the evidence most likely to be used where the eye reaches first.
Termbase priority versus TM priority
Both rank linguistic resources.
They solve different things.
TM priority ranks sentence-level bilingual history.
Termbase priority ranks concept-level lexical resources.
Do not assume the same hierarchy must apply.
A legacy TM may be weak while the legacy client termbase remains authoritative, or vice versa.
Termbase priority versus glossary compliance
Compliance checks whether the target uses the required terminology.
Priority helps the translator choose that terminology before an error occurs.
One is preventive suggestion.
One is verification.
Good workflows use both.
Termbase priority versus term extraction
Extraction finds candidate source terms.
Priority decides which existing resource supplies the preferred target.
Again, different layer.
Failure mode 1: attachment order accidentally becomes authority
A general glossary was attached first.
The tool treats it as highest rank.
Translators assume top result means approved.
Project terminology drifts.
Never let arbitrary setup order silently define terminology governance.
Failure mode 2: master resource outranks current project decision
Client master has not yet been updated.
Project working TB contains the latest approved release terminology.
If master always wins, old terms keep resurfacing.
Priority must be able to reflect temporary project authority.
Failure mode 3: writable general TB captures client terms
Quick-add sends new client terminology into a broad personal glossary.
Later unrelated projects see it.
Set the working target correctly.
Scope matters.
Failure mode 4: too many equal-priority resources
The editor displays five suggestions with no useful ordering.
If everything is priority one, priority means nothing.
Create tiers.
Failure mode 5: hiding useful legacy evidence completely
A legacy term may explain old source references or historical documents.
Do not necessarily remove it.
Lower rank or mark it deprecated.
Keep evidence without giving it current authority.
Use metadata to strengthen ranking
If termbase entries include:
- client;
- product;
- domain;
- project;
- date;
translators can judge conflicts faster.
The resource name itself should also be meaningful.
“TB_04” is weak.
“ClientX_ProductY_Master_2026” is informative.
Clear resource names save time
Name termbases so translators can infer scope immediately.
Useful elements:
- client;
- product;
- language;
- status;
- year/version.
Avoid extremely long names, but make provenance visible.
Review termbase priority at project setup
Before translation:
- list attached TBs;
- identify owner;
- rank by authority;
- set working target;
- confirm locale;
- test one known term.
This takes minutes.
It can save hours of repeated ambiguity.
Test with a known conflict
Choose a source term that exists in several resources.
Open a sample segment.
Check suggestion order.
If the intended project term does not appear first, adjust before work begins.
A live test is better than trusting configuration screens.
Priority after importing a new glossary
A new client glossary arrives mid-project.
Attach it.
Then reassess ranking.
Do not assume the new resource automatically becomes first.
Rerun a known conflict test.
Priority after terminology migration
If project terms are promoted into master, you may no longer need the working TB to outrank it.
Clean duplicates.
Rebalance.
Resource hierarchy can change as the project matures.
Priority after product branching
Product A and Product B diverge.
A once-shared glossary is no longer sufficient.
Create product-specific termbases or metadata.
Rank based on current product.
Otherwise identical source words can produce wrong product naming.
Multi-client translator setup
Freelancers may maintain:
- personal general TB;
- client TBs;
- domain TBs.
For each job, client TB should generally outrank personal resources.
The personal glossary is support, not authority.
This protects client voice.
Enterprise setup
Large organizations may have:
- corporate master;
- business-unit glossary;
- product glossary;
- project working TB.
The correct hierarchy may be:
project/product > business unit > corporate > external reference.
Or corporate may override everything for brand terms.
Define rules by terminology class.
Different classes can have different authority
One termbase hierarchy may not perfectly represent:
- brand names;
- legal terms;
- technical components.
If the tool cannot rank by class, use:
- separate termbases;
- forbidden terms;
- metadata;
- notes.
Priority is a coarse control.
Use richer governance where needed.
Priority and forbidden terms
A high-priority termbase can include forbidden alternatives.
This helps the system show:
- use X;
- avoid Y.
Lower-priority glossaries may still contain Y historically.
Forbidden flags make the decision explicit.
Priority and case-sensitive brands
A brand resource can rank high and use strict case matching.
Now the editor recognizes the exact brand form without flooding ordinary text.
Priority and matching rules combine.
Priority and polysemy
Source term:
charge
Different TBs:
- finance;
- electrical engineering;
- legal.
Ranking by project domain prevents irrelevant senses from appearing first.
This is where resource scope produces direct speed.
Use a domain-switch test
If one project contains multiple domains, termbase priority can change by file group.
For example:
- legal annex;
- technical manual;
- marketing summary.
If the CAT tool supports resource profiles per job, adjust.
If not, rely more heavily on metadata and context.
Measure priority quality
Sample 100 source term hits.
Ask:
Was the first suggestion the one eventually used?
Track roughly.
If top-hit usefulness is low, ranking is poor.
Possible causes:
- wrong hierarchy;
- stale resources;
- ambiguous terms;
- bad matching.
Fix upstream.
Measure conflict rate
How often do translators see competing terms?
A high conflict rate suggests:
- duplicate resources;
- poor scoping;
- legacy contamination;
- terminology migration incomplete.
Priority helps, but cleanup may be needed.
Measure override rate
If translators repeatedly skip the first termbase result, the top resource may not deserve top rank.
Use behavior as evidence.
Priority and onboarding
New translators often trust the first suggestion more than experienced translators.
A correct hierarchy is therefore a quality control.
It makes the easy choice more likely to be the approved choice.
Priority and review
Reviewers can identify which resource should have prevented a terminology error.
If a wrong term came from a lower-priority TB but appeared first due to setup, fix ranking.
Do not blame the translator for a systematically misleading interface.
Priority and working/master promotion
After project terminology is reviewed and promoted to master:
- remove obsolete working entries;
- update rank;
- keep provenance.
This prevents permanent resource duplication.
Priority and client feedback
Client says:
Use target B.
Update the authoritative resource.
If B only exists in a lower-priority project TB, the editor will keep showing A first.
A client correction should change both entry and resource hierarchy when necessary.
A termbase-priority worksheet
For each TB:
Name: Owner: Scope: Locale: Status: current / legacy / reference. Read priority: high / medium / low. Writable: yes/no. New-entry target: yes/no. Known risks: old terms, mixed domain, etc.
This turns resource setup into an explicit map.
The simplest workable hierarchy
For many projects:
- current project/client;
- current domain;
- legacy client;
- general.
That alone can remove much suggestion noise.
When priority is not enough
If two resources contain contradictory authoritative terms, the problem is governance.
Resolve:
- which term is current;
- which scope applies;
- whether one entry should be deprecated.
Do not hide a real policy conflict under ranking.
Transfer: search-result ranking
The mechanism resembles search.
A result can be relevant but not authoritative.
Good ranking combines:
- relevance;
- trust;
- context.
Termbase priority does the same for terminology.
Transfer: reference management
Researchers rank evidence:
- primary source;
- official standard;
- review paper;
- general website.
All can be useful.
They do not deserve equal weight.
The deeper principle: move authority into the interface
If the project already knows which terminology source is most authoritative, the translator should not reconstruct that hierarchy in every segment.
Configure the editor so high-trust terminology appears first.
That converts organizational knowledge into interaction design.
The result is faster translation because the first visible suggestion is more often the right one.
Advanced practice: rank by task, not prestige
A corporate master glossary may sound more authoritative than a project termbase.
But authority is contextual.
If a current product release has an approved new feature name not yet merged into corporate master, the project TB should outrank the older corporate entry for this task.
Priority should answer:
Which resource is most likely to contain the right term for this project today?
Not:
Which resource has the grandest name?
Build priority from four signals
A useful termbase ranking can combine:
Scope
Does it belong to this client/product/domain?
Currency
Is it current?
Approval
Has terminology been reviewed?
Specificity
Is it more specific than general reference resources?
Rank higher when all four are strong.
Worked example 5: corporate master versus regulatory glossary
A pharmaceutical client uses a corporate marketing term.
A regulatory submission requires the official regulator term.
Which resource wins?
It depends on document type.
For the regulatory file, regulatory terminology may outrank marketing master.
This shows why one project can attach different termbase profiles to different file groups.
Worked example 6: engineering project with supplier glossary
Client master says:
housing
Supplier component glossary says:
enclosure
The supplier’s component drawing specifically defines the part as “enclosure.”
Which target should be used?
If the current document describes that supplied component, supplier/product evidence may be more specific.
Priority is not just ownership.
It is relevance to the actual object.
Worked example 7: merger creates two brand glossaries
Company A and Company B merge.
Both termbases remain active.
Source “service plan” has different target brand wording.
Until terminology governance completes, rank the new merger/project glossary above both legacy brand TBs.
Keep old resources low for historical documents.
Worked example 8: project glossary contains temporary workaround
Project TB uses a temporary label because software UI is not yet updated.
Client master has the future official label.
Which comes first?
For current release, project term may be operationally correct.
For next release, priority should change.
Time is part of scope.
Termbase priority and document type
One project can contain:
- legal terms;
- UI labels;
- marketing copy;
- technical descriptions.
A single hierarchy may not serve all.
If the platform supports job-specific TB assignments, tailor them.
If not, use strong entry metadata and clear notes.
Priority and concept domains
A term such as “bond” can belong to:
- finance;
- chemistry;
- construction.
A broad client termbase may contain several entries.
Domain-specific resources can reduce ambiguity.
Rank the domain resource when its subject matches the file.
Priority and resource size
A large termbase is not automatically better.
A small product glossary may be far more useful than a 100,000-term general database.
Size is not authority.
Priority and automatic terminology insertion
If predictive typing or automatic term suggestions pull from several TBs, ranking affects what appears at the cursor.
Bad priority can therefore accelerate the wrong term.
Resource order becomes a productivity and quality setting.
Priority and termbase matching rules
A high-priority TB with fuzzy matching can overwhelm lower resources.
Before lowering another TB, check whether the top one is simply matching too broadly.
Priority and matching must be tuned together.
Priority and forbidden terms
Suppose top client TB marks a legacy term forbidden.
Lower legacy TB still offers it as preferred.
If the interface surfaces both, translators may be confused.
Consider:
- lowering legacy;
- removing obsolete entry;
- clear forbidden labeling.
A real deprecation should be encoded strongly.
Resource naming convention
Adopt a predictable naming pattern:
Client_Product_Domain_Status_Locale
Example:
Acme_PumpTech_Master_de-DE
This helps translators read provenance instantly.
Names are part of usability.
Working termbase naming
Mark working resources clearly:
Acme_PumpTech_WORKING_de-DE
Now nobody mistakes provisional entries for master.
Visual clarity reduces accidental promotion.
Legacy naming
Mark legacy explicitly:
Acme_Legacy_2019_REFERENCE
Do not rely on memory.
The resource name itself can lower human trust appropriately.
Read-only protection
Authoritative termbases can be read-only for translators.
This prevents accidental edits while still ranking high.
New entries go to working TB.
This separation is common because reading authority and write authority differ.
Priority when master is unavailable
If an online master resource is temporarily unavailable:
- do not silently promote general TB as equal authority;
- note degraded resource state;
- translate cautiously;
- queue terminology questions.
Availability should not rewrite governance.
Priority and offline packages
Offline work may include only some resources.
Ensure the exported package preserves intended terminology hierarchy as much as possible.
If it cannot, brief the translator.
The visible suggestion order may change offline.
Priority and vendor handoffs
When work goes to an external vendor, provide:
- resource names;
- ranking policy;
- working TB destination;
- forbidden terms.
Do not assume the vendor’s CAT environment will reconstruct your hierarchy automatically.
Priority after reviewer changes
A reviewer repeatedly chooses a lower-priority term over the top result.
Investigate.
Possible explanations:
- top TB stale;
- reviewer preference wrong;
- file domain mismatch;
- target term ambiguous.
Behavior is diagnostic.
Priority after client feedback
If client repeatedly overrides top suggestions, update authoritative resources.
Do not accept permanent human workarounds.
A resource hierarchy should learn.
A priority regression test
Maintain five or ten known conflict terms.
After project setup:
- open sample;
- check which term appears first.
After adding/removing TBs:
- rerun.
This catches accidental rank changes quickly.
Priority and QA severity
A term from top client TB may be mandatory.
A term from lower reference TB may be optional.
QA can reflect this.
Do not treat every glossary hit as equal obligation.
Priority and locale fallback
If locale-specific TB has no entry, global TB can provide fallback.
Hierarchy can behave like:
Mexico Spanish → Global Spanish → General domain.
This is a clean model.
Priority and terminology maturity
Early project:
- project working TB highest for new terms.
Later:
- reviewed terms promoted to master.
After promotion:
- master regains top rank;
- working TB holds only unresolved/new terms.
Priority evolves with maturity.
Duplicate cleanup after promotion
Once working entries are promoted, remove or archive duplicates.
Otherwise translators may see two identical suggestions and wonder whether they differ.
Clean resources simplify the interface.
Priority and concept ownership
Some terminology is owned by:
- legal;
- engineering;
- marketing;
- product.
If resource governance reflects ownership, priority can route conflicts to the right domain.
This is stronger than a single global “client glossary.”
A conflict escalation rule
If two top-priority resources disagree and neither scope clearly wins:
- do not guess;
- mark query;
- use temporary project decision if necessary;
- resolve owner;
- update resource.
Priority should reduce routine ambiguity.
It should make exceptional ambiguity visible.
Priority and search
Project search can reveal which term is already used in current translated files.
This can help decide between resources when terminology migration is incomplete.
Current project consistency is evidence.
Not necessarily authority, but evidence.
Priority and TM suggestions
A TM match may contain a term that conflicts with top termbase.
Which wins?
Usually current terminology should override old sentence history if governance says so.
The translator may edit the TM match accordingly.
This is another reason termbase priority matters.
Priority and pre-translation
Pre-translated targets may contain old terminology.
High-priority termbase and glossary QA can catch it.
Resource hierarchy is useful even when target text already exists.
Priority and machine translation
MT may generate a valid synonym that conflicts with client terminology.
A high-priority termbase can guide post-editing and QA.
Do not rely on MT to infer client glossary authority unless integrated explicitly.
Priority as cognitive compression
A good hierarchy compresses a complex organizational fact:
client product terminology beats generic glossary.
into one interface effect:
correct term appears first.
This is why priority is more than housekeeping.
It reduces repeated human reasoning.
A two-minute priority audit
At project start:
- list TBs;
- mark high/medium/low authority;
- confirm top result with one known term;
- confirm working TB;
- proceed.
Simple.
High leverage.
A mature termbase stack
A mature project stack may look like:
Top: current client/product approved. Second: reviewed project working. Third: domain standard. Fourth: legacy reference. Bottom: broad general.
The exact order changes by project.
The principle is clarity.
Advanced practice: use priority profiles for different document classes
A large client can need more than one termbase order.
For example:
Marketing profile
- brand/product glossary;
- campaign/project glossary;
- general corporate glossary;
- domain reference.
Legal profile
- legal-approved glossary;
- current client master;
- jurisdictional reference;
- general glossary.
Technical profile
- product/component termbase;
- engineering master;
- client corporate;
- external domain reference.
The resources may be the same. Their order changes because the reader job changes.
This is more precise than forcing one hierarchy across every file.
Priority and project templates
If you use recurring CAT project templates, save the intended termbase hierarchy inside the template where the platform supports it.
Then each new project starts with:
- correct resources;
- correct order;
- correct working termbase.
This removes setup drift.
However, review the hierarchy whenever a new product, client glossary, or regulatory resource is introduced.
Templates should encode stable decisions, not freeze history.
Priority and emergency terminology updates
A client sends an urgent terminology change halfway through the day.
Do three things:
- update the authoritative entry;
- ensure that resource still ranks above conflicting sources;
- search the current project for the old target.
If a legacy glossary continues to outrank the update, translators may reintroduce the deprecated term after the correction.
Terminology change is therefore both an entry problem and a hierarchy problem.
Priority and partially overlapping resources
Two termbases may not be true competitors.
One contains:
- UI labels.
Another contains:
- legal terms.
If their scopes barely overlap, ranking is less important.
Do not overengineer priority where resources are naturally distinct.
Focus on overlap zones.
Priority and language direction
A multilingual termbase may have stronger coverage in one direction than another.
For example, a global TB may be authoritative for English→German but only reference for English→Japanese.
Priority can be language-pair-specific.
Do not assume one resource rank applies to every target language.
Priority and master-resource governance
An authoritative master termbase should have:
- clear owner;
- update process;
- release/version policy.
If nobody knows who owns it, high priority creates false confidence.
The interface should not give first place to an unmanaged resource simply because it is called “Master.”
Authority needs governance behind it.
Priority and shared cloud resources
Online termbases can update during a project.
A term that was second yesterday may become top today after a new entry is added.
This is useful.
It also means translators should understand that suggestion order can change.
Major terminology updates should be communicated.
Priority and locked terminology
Some organizations treat specific term classes as non-negotiable:
- product names;
- regulatory labels;
- legal defined terms.
These can live in a high-priority locked/read-only resource.
The working termbase captures new material without threatening them.
This creates structural protection around core terminology.
Priority and experimental language
A campaign may test new wording.
Keep experimental terms in a lower or clearly marked project resource until approved.
Do not let experiments outrank stable master terminology accidentally.
When approved, promote and rerank.
Priority and reviewer specialization
A legal reviewer may need a legal glossary to surface first.
A marketing reviewer may need brand voice terminology first.
If the system supports user or workflow-step resource profiles, use them.
Otherwise, provide quick guidance on which source controls which term class.
Priority and external standards
An external standards glossary can be highly authoritative for standardized terms but irrelevant elsewhere.
Rank it high in files governed by the standard.
Rank it lower in marketing material.
Authority is conditional.
Priority and termbase health
A high-priority resource with many duplicates, unclear preferred terms, and stale variants will still create noise.
Ranking cannot repair poor content quality.
Before elevating a resource, sample:
- duplicates;
- preferred status;
- forbidden flags;
- currentness.
High priority should be earned.
Priority and missing results
If top termbase has no entry, the next resource should provide fallback.
That is normal.
Priority is not exclusion.
A strong hierarchy gives you graceful degradation:
best evidence first, weaker evidence next.
Priority and UI color coding
Some tools visually distinguish termbase sources.
Learn those colors/labels.
Fast translators can recognize:
- client master;
- working project TB;
- reference TB;
without opening metadata every time.
Tool literacy converts interface signals into speed.
Priority and terminology notes
If a lower-priority term is sometimes required, add usage notes explaining scope.
Example:
Use “plan” in consumer UI; use “scheme” only in statutory documents.
Now ranking and notes work together.
The editor shows the common term first while preserving exceptional guidance.
Priority and reviewer disagreement
Two reviewers keep preferring different resource outputs.
Do not resolve the conflict by changing ranking back and forth.
Clarify:
- document type;
- concept scope;
- authoritative owner.
Then update the glossary architecture.
Priority should express a resolved policy, not substitute for one.
A priority-change checklist
Whenever you change TB order:
- test known conflict;
- test client brand;
- test domain term;
- test new working term;
- verify quick-add destination;
- run one glossary QA sample.
This catches configuration mistakes before scale.
Measure time saved by priority
You do not need formal metrics.
Notice:
- fewer clicks to open term details;
- fewer skipped first suggestions;
- fewer reviewer terminology changes.
If none improves, hierarchy may not be doing useful work.
The maturity path
Early terminology setup:
- many equal resources;
- unclear ownership.
Mature setup:
- scoped resources;
- explicit rank;
- one working TB;
- clean promotion path;
- low conflict.
Priority is one visible marker of terminology-system maturity.
Final priority check: the first result should usually be defensible
At the end of setup, test five known terms from different classes:
- brand;
- product;
- technical;
- legal;
- general.
For each, ask whether the first termbase result is the one you could defend to the client or reviewer.
If not, investigate whether the problem is:
- resource order;
- stale entry;
- broad matching;
- wrong domain;
- wrong locale.
A priority stack is healthy when the top result is not merely convenient but usually aligned with project authority. That is what turns ranking into real speed rather than cosmetic ordering.
Keep the hierarchy understandable to every translator
A ranking that only the project manager understands is fragile. Put the hierarchy in the project brief or template in one short line, such as:
Client master → project working TB → domain reference → legacy reference.
Now translators can interpret the results pane without guessing why one suggestion appears above another. Clear ranking turns invisible configuration into shared working knowledge and reduces the chance that someone overrides the correct top result simply because the resource order looks arbitrary.
Priority should reduce hesitation
The practical test is simple: when the same source concept appears again, does the translator need less time to decide which terminology source controls it? If the answer is yes, priority is working. If the results pane still forces repeated comparison of equivalent resources, the hierarchy is not yet expressing the project’s authority clearly enough.
A good ranking makes the normal decision obvious and the exceptional conflict visible.
One last ranking rule
If two resources are equally current and equally authoritative, prefer the one with narrower project scope. Specificity usually lowers ambiguity. Keep the broader resource as fallback rather than forcing the translator to compare both at every occurrence.
Summary
Termbase priority helps people translate quickly by ranking multiple terminology resources according to project authority and relevance.
The reliable workflow is:
classify resources → rank client/project terms above general references → set one working TB for new entries → test known conflicts → review ranking when resources change
Priority does not make the first suggestion automatically correct.
It makes the interface reflect what the project already knows.
That reduces repeated arbitration.
Frequently asked questions
What is termbase priority?
It is the ranking order used when several terminology resources are attached to the same translation project.
Why does priority matter?
Multiple termbases may recognize the same source term with different target suggestions. Priority helps the most authoritative result appear first.
Which termbase should be highest?
Usually the most current and project-specific approved resource, such as a client or product glossary.
What is a working termbase?
It is the designated resource where new project terminology is captured during translation.
Can the highest-priority termbase be read-only?
Yes. A client master can rank highest for suggestions while a separate working TB receives new entries.
Should legacy glossaries be removed?
Not always. They can remain useful as lower-priority historical evidence.
What if two high-priority termbases conflict?
Investigate scope, date, client, product, and entry metadata. A real conflict may require terminology governance rather than ranking.
Is termbase priority the same as TM priority?
No. TM priority ranks segment-level translation memory. Termbase priority ranks concept-level terminology resources.
How do I test priority?
Choose a source term that exists in multiple termbases and confirm that the intended project-approved suggestion appears first.
Can priority improve quality?
Yes. It makes approved terminology easier to select and reduces the chance that general or obsolete variants dominate attention.
Internal-link opportunities
- How People Translate Quickly | Quick-Add Terminology — for sending new project terms into the right working resource.
- How People Translate Quickly | Termbase Matching Rules — for controlling recognition within each resource.
- How People Translate Quickly | Glossary Compliance — for enforcing terminology after selection.
- How People Translate Quickly | TM Metadata Prioritization — for the analogous ranking problem at segment level.
- Master Art of Translation | The Terminology System — for broader terminology governance.