People searching translation consistency check, same source different target translation, same target different source, CAT tool inconsistency QA, translation consistency QA, or how to find inconsistent translations before delivery are usually dealing with a deceptively simple failure: the project contains repeated or near-repeated language, but equivalent situations no longer receive equivalent treatment.
Modern CAT and TMS quality-assurance systems continue to expose consistency checks because inconsistency is not always visible while translating one segment at a time. A translator may make a strong decision on page 3, forget it on page 47, accept an older fuzzy match on page 86, and discover only at delivery that the same source sentence now has three targets. The reverse can happen too: two genuinely different source sentences may collapse into one identical target, erasing a distinction the source intended.
This article has one dominant reader job: use source-target consistency checks to locate repeated translation decisions that deserve human comparison before delivery. It is not a general QA-profile guide, not a translation-memory cleanup manual, and not a synonym policy. The mechanism is narrow: detect suspicious equivalence patterns, distinguish legitimate variation from accidental inconsistency, repair the real errors, and preserve justified exceptions.
Quick answer
A practical consistency-QA workflow is:
- run the project-wide consistency check after substantial translation exists;
- review “same source, different target” warnings as candidate inconsistency;
- review “different source, same target” warnings as possible loss of distinction;
- compare context before normalizing anything;
- identify whether the variation is intentional, contextual, grammatical, or accidental;
- fix only the genuinely inconsistent occurrences;
- update terminology, translation memory, or project guidance if the problem is systemic;
- rerun the check after global repairs;
- keep justified exceptions documented or intentionally ignored;
- finish with a final project-level consistency sweep.
The key rule is:
consistency is not sameness; it is stable treatment of the same meaning under the same relevant conditions.
Why segment-by-segment work hides inconsistency
A translator normally sees one active segment at a time.
That is efficient for drafting.
It is weak for cross-document memory.
Suppose the source sentence appears in four files:
Restart the controller after calibration.
The translator produces:
- Restart the controller after calibration.
- Reboot the controller after calibration.
- Restart the control unit after calibration.
- Restart the controller once calibration is complete.
All four may be understandable.
But if the product glossary fixes “controller” and the style guide fixes “restart,” only one form may be project-compliant.
The problem is not visible inside one segment.
It becomes visible only when the four targets are compared as a set.
Consistency QA creates that comparison.
Two major inconsistency patterns
Most automated consistency checks focus on two relationships.
Same source, different target
The source string is identical, but targets differ.
This may indicate:
- inconsistent terminology;
- inconsistent phrasing;
- old TM influence;
- translator drift;
- reviewer preference;
- legitimate context difference.
Different source, same target
The source strings differ, but the target is identical.
This may indicate:
- a distinction was lost;
- a fuzzy match was accepted without editing;
- two source variants are genuinely synonymous;
- the target language naturally neutralizes the distinction.
Neither pattern is automatically wrong.
Both deserve comparison.
Same source, different target is not always an error
Consider the source:
Open
Occurrence A is a button.
Occurrence B is a status meaning “not closed.”
Occurrence C is a verb in an instruction.
The source text is identical.
The target may need three different forms.
A mechanical “make all targets identical” correction would create errors.
Therefore the consistency check should be treated as a candidate finder, not an automatic normalization engine.
Context is the deciding variable
For every warning, ask:
- same product?
- same screen?
- same grammatical role?
- same referent?
- same audience?
- same document type?
- same definition?
- same time period?
- same legal context?
If relevant context is the same, different targets become more suspicious.
If context differs, variation may be correct.
Worked example 1: product terminology drift
Source:
control panel
Targets across project:
- control panel;
- control console;
- operator panel;
- command panel.
The current termbase specifies one approved target.
This is real inconsistency.
Repair:
- search all occurrences;
- confirm context is equivalent;
- normalize to approved term;
- correct TM entries if needed;
- rerun terminology and consistency QA.
The warning revealed a terminology governance problem.
Worked example 2: grammatical variation
Source:
New
The word appears before nouns with different gender or case in the target language.
Targets differ morphologically.
This is legitimate.
If the consistency checker works on exact target strings, it may still flag the variation.
Mark or ignore the warning appropriately.
Do not force grammar to satisfy a simplistic QA rule.
Different source, same target can be more dangerous than it looks
Suppose source A:
The user may cancel the request.
Source B:
The user must cancel the request.
Target for both is identical.
The distinction between permission and obligation disappeared.
This is a serious meaning error.
A different-source/same-target check can expose it quickly.
Worked example 3: lost number distinction
Source A:
Maximum pressure: 40 bar.
Source B:
Maximum pressure: 60 bar.
Targets are identical and both say 40 bar.
The second segment probably came from an unedited fuzzy match.
Consistency QA is not primarily a number checker, yet it can still expose the duplicated target pattern.
The dedicated number-verification check should catch it too.
Layered QA is valuable because different checks can detect the same dangerous defect from different angles.
Step 1: run consistency checks when enough translation exists
Running consistency QA after only ten translated segments gives little value.
Running it only after final export may be late.
Useful times include:
- mid-project after repeated terminology has stabilized;
- after reviewer changes;
- before delivery;
- after a global terminology migration.
The exact cadence depends on project size.
For a 500-word email, final check may be enough.
For a 200,000-word multi-translator project, periodic checks are better.
Step 2: sort by frequency and consequence
If the QA result contains hundreds of warnings, do not review them randomly.
Prioritize:
- high-frequency source strings;
- safety or legal language;
- product names;
- numbers and units;
- terms in current glossary;
- UI labels;
- ordinary stylistic variation.
One corrected high-frequency inconsistency can repair dozens of segments.
Step 3: compare the full source-target set
Do not judge only two rows when the source occurs twenty times.
Filter or search all occurrences.
Look for clusters.
Example:
18 occurrences use target A.
2 use target B.
That pattern suggests B may be accidental.
But do not assume majority equals correctness.
The minority may occur in a different context.
Use the pattern as evidence, then inspect context.
The majority trap
Historical error can dominate the majority.
If an old TM used wrong term B for years, 95% of occurrences may contain B.
The current approved term is A.
Consistency QA shows dominant consistency, but the project is consistently wrong.
Therefore consistency is not a substitute for authority.
Check terminology policy.
Step 4: use source context identifiers where available
Structured content may expose:
- key;
- path;
- screen;
- string ID;
- document section.
These identifiers help decide whether identical source strings are functionally identical.
Example:
menu.file.open
versus
ticket.status.open
The visible source is “Open.”
The key reveals the distinction.
A good consistency review uses all available context, not just characters.
Step 5: distinguish lexical variation from semantic variation
Targets may differ because of:
- synonym choice;
- sentence structure;
- grammar;
- tone;
- meaning.
Not all variation deserves the same response.
Lexical variation
“begin” versus “start.”
May be style issue.
Structural variation
“Press Save” versus “Select Save.”
May reflect UI convention.
Grammatical variation
Case or gender difference.
May be mandatory.
Semantic variation
“may” versus “must.”
Potentially critical.
Review severity should follow meaning.
Step 6: normalize only when the project has a reason
Normalization needs a basis.
Good reasons:
- termbase;
- style guide;
- product UI;
- approved prior decision;
- legal requirement;
- client preference.
Weak reason:
I personally like target A more.
Consistency QA should reduce accidental variation, not erase all stylistic flexibility.
Style consistency versus translation consistency
A literary translation may legitimately vary repeated wording for rhythm.
A regulated manual may require near-identical repeated instructions.
The project’s purpose determines how much lexical variation is acceptable.
Do not import industrial consistency rules into creative writing automatically.
Do not import creative flexibility into safety instructions automatically.
Step 7: watch fuzzy-match contamination
A common cause of different-source/same-target inconsistency is an accepted fuzzy match.
Source changes slightly.
Old target is inserted.
Translator confirms without editing.
Now target ignores the new distinction.
This is why many QA systems also flag unedited fuzzy matches.
The two checks reinforce each other.
Worked example 4: condition removed
Old source:
If the alarm is active, disconnect power.
New source:
If the alarm is inactive, disconnect power.
Old target reused unchanged.
The translation now says the opposite condition.
Text similarity was high.
Meaning risk was higher.
Consistency comparison plus fuzzy-diff review can expose the problem.
Step 8: treat short strings as high-context warnings
Short strings generate many valid consistency variations.
Examples:
- Run;
- Home;
- Current;
- Record;
- Charge;
- Apply.
Before normalizing short strings, inspect:
- UI location;
- key;
- screenshot;
- developer note;
- part of speech.
Shorter source does not mean simpler translation.
It often means more hidden context.
Step 9: compare punctuation and capitalization separately
Targets may differ only by:
- period;
- colon;
- capitalization;
- quote marks.
Some QA tools treat those as different targets.
Decide whether that difference is meaningful.
For UI labels, capitalization may be governed by style.
For sentences, punctuation variation may reflect source context.
Do not waste high-level linguistic review on noise if the rule is clear.
Case-sensitive product strings
Product names and trademarks may require exact case.
Example:
eSIM
ESIM
eSim
All may be understood by a reader.
Only one may be approved.
Consistency checks can support brand correctness.
Step 10: investigate reviewer-induced inconsistency
A reviewer may improve selected occurrences but not all repetitions.
Example:
Reviewer changes 5 of 30 “log in” strings to “sign in.”
Now the project is inconsistent.
The reviewer intended a global policy change but applied it locally.
After review, rerun consistency and terminology checks.
Revision can create new inconsistency.
Step 11: investigate multi-translator divergence
Team project:
Translator A uses A.
Translator B uses B.
Translator C uses C.
If the decision is important, do not wait until final review.
Run periodic consistency checks and share the decision.
Update the termbase or style note.
Team consistency should be created during production, not manufactured only at the end.
A consistency decision log
For high-impact repeated strings:
| Source | Approved target | Context | Reason |
|---|---|---|---|
| Sign in | target A | UI button | current product UI |
| Open | target B | ticket status | noun/status |
| Open | target C | command | verb |
This small table explains intentional variation.
Intentional inconsistency is not contradiction
Sometimes the same source needs different targets because source is underspecified.
The project should preserve the difference deliberately.
That is not inconsistency in quality terms.
It is context-sensitive translation.
The QA system sees strings.
The translator sees functions.
Step 12: use “ignore” states responsibly
If the tool lets users ignore a consistency warning, use it when:
- variation is legitimate;
- context is documented;
- project policy supports it.
Do not ignore because:
- warning list is long;
- deadline is near;
- you do not want to investigate.
An ignored warning should mean:
reviewed and accepted.
Not:
unseen.
Ignored warnings should survive workflow appropriately
If reviewer stage reruns QA, decide whether ignored warnings remain ignored.
Some systems preserve ignored status across workflow steps.
Others do not.
Know the project behavior.
A legitimate exception should not create repeated friction at every stage.
Step 13: rerun after global replacement
Suppose you normalize term B to A across project.
Rerun consistency QA.
Why?
Because global replacement can create:
- wrong-context replacement;
- accidental capitalization;
- duplicated punctuation;
- partial word changes.
One correction can introduce another inconsistency.
Verification closes the loop.
Consistency QA and cross-file project search
Cross-file search finds occurrences of a term or string.
Consistency QA finds suspicious source-target relationships automatically.
Use both.
Workflow:
QA flags source S → cross-file search shows all S occurrences → inspect contexts → normalize or preserve exceptions.
The tools solve different parts of the task.
Consistency QA and translation memory
Project consistency can be correct while TM is inconsistent.
If the project is repaired but TM still contains conflicting targets, future jobs may reintroduce the problem.
For important corrections:
- fix current project;
- inspect working/master TM under governance;
- remove or penalize bad entries.
Do not let history keep reseeding inconsistency.
TM inconsistency is a separate maintenance job
The project check asks:
Are current targets coherent?
TM cleanup asks:
Does historical reusable data contain contradictory entries?
Related, but not identical.
Keep ownership boundaries clear.
Consistency QA and terminology
Terminology compliance checks a known approved term.
Consistency QA can discover a recurring variation before the team realizes it is a terminology problem.
Example:
three target variants for “emergency stop.”
If project decides one must be approved, promote it into termbase.
QA reveals candidate governance gaps.
Consistency QA and spellcheck
Spellcheck may flag one variant as unknown.
Consistency check may show four spellings.
Termbase may specify one.
Together they triangulate the problem.
Layered QA works best when each layer has a distinct job.
Failure mode 1: normalize every warning
Result:
legitimate context differences destroyed.
Repair:
- inspect context;
- preserve exceptions.
Failure mode 2: ignore all short-string warnings
Result:
real UI inconsistency survives.
Repair:
- use keys/screenshots.
Failure mode 3: choose majority target automatically
Result:
historical wrong form wins.
Repair:
- check authority.
Failure mode 4: fix project but not resource
Result:
bad TM restores old inconsistency next project.
Repair:
- update governing resource.
Failure mode 5: reviewer creates partial migration
Result:
half old term, half new term.
Repair:
- rerun QA after review.
Failure mode 6: false positive flood
Result:
translators ignore warnings.
Repair:
- tune case, punctuation, segmentation, or scope.
Failure mode 7: same target hides source distinction
Result:
meaning collapsed.
Repair:
- inspect modal verbs, numbers, conditions, negation.
Failure mode 8: stylistic variation treated as semantic error
Result:
over-editing.
Repair:
- define style tolerance.
A three-question warning triage
For each inconsistency warning:
Is the source meaning/function actually the same?
If no, different targets may be correct.
Is there a project authority for the target?
If yes, follow it.
Would a reasonable reader infer a different meaning from the variants?
If yes, fix.
This triage is fast and robust.
High-risk tokens
When different source strings share same target, pay extra attention to differences involving:
- not;
- no;
- may;
- must;
- can;
- cannot;
- before;
- after;
- above;
- below;
- minimum;
- maximum;
- numbers;
- units;
- percentages;
- dates.
Tiny token difference can carry the whole meaning.
Consistency QA for legal text
Repeated legal clauses may need stable wording.
But defined terms and context can change.
Review:
- clause identity;
- jurisdiction;
- defined parties;
- obligation language.
Do not normalize legal text merely because it looks similar.
Consistency QA for medical text
High-risk distinctions include:
- dose;
- route;
- frequency;
- contraindication;
- patient group.
Same-target/different-source warnings deserve high priority.
Consistency QA for software UI
Useful for:
- button labels;
- menu names;
- statuses;
- repeated messages.
But identical short source may have different UI functions.
Use key and screenshot context.
Consistency QA for marketing
Apply more lightly.
Brand terminology should remain stable.
Creative phrasing may vary legitimately.
The QA policy should separate brand-controlled terms from expressive language.
Consistency QA for educational content
Repeated instructions often benefit from stable wording:
- choose the correct answer;
- explain your reasoning;
- compare your result.
But age level or assessment type can change target register.
Context remains important.
Measure inconsistency rate carefully
You can track:
- warnings per 1,000 segments;
- real issues;
- legitimate exceptions;
- recurring source strings.
A falling real-issue rate may show better terminology control.
A falling warning count may also simply reflect disabled checks.
Measure precision.
Warning precision
Useful concept:
real inconsistency warnings / total inconsistency warnings
If precision is very low, tune the check or project scope.
A high-signal consistency check earns attention.
Build a “known exception” list
For recurring products, document source strings that legitimately vary.
Example:
Open
- button → target A
- status → target B
Future reviewers understand why warning is expected.
This reduces repeated debate.
Consistency and source quality
Sometimes inconsistency originates in source.
Example:
same concept appears as:
- user account;
- account;
- profile;
- customer account.
Target inconsistency may mirror source inconsistency.
Do not silently normalize if distinction could be intentional.
Raise source governance issue where needed.
Source pre-editing can reduce target inconsistency
Cleaner controlled source produces cleaner translation.
If authors use stable terms, translators receive stronger reuse and fewer ambiguous duplicates.
Translation productivity begins upstream.
A mid-project consistency routine
For long projects:
- run check;
- sort high-frequency warnings;
- resolve product terminology;
- update termbase;
- notify team;
- continue translation.
This prevents inconsistency from multiplying.
A final consistency routine
Before delivery:
- run full QA;
- inspect same-source/different-target;
- inspect different-source/same-target;
- prioritize high-risk content;
- compare all occurrences;
- repair systemic resources;
- rerun;
- document justified exceptions.
A worked team scenario
Three translators work on 60 files.
Midweek check finds:
- 42 variants of “service request”;
- 18 variants of “sign in”;
- 7 same-target warnings involving “may/must.”
The language lead:
- confirms approved terminology;
- updates termbase;
- sends one project note;
- normalizes current project;
- asks translators to rerun live QA.
By Friday, review does not have to rediscover these issues.
Consistency QA moved correction upstream.
How consistency saves time
At first, checking warnings looks like extra work.
But it prevents:
- repeated reviewer corrections;
- client terminology disputes;
- global last-minute search;
- TM pollution;
- inconsistent future reuse.
The speed gain appears across the whole lifecycle.
The deeper principle: compare decisions as sets
Translation often feels sequential.
Sentence 1.
Sentence 2.
Sentence 3.
Consistency QA changes the unit of analysis.
It asks:
How did we treat all occurrences of this problem?
That set-based view reveals patterns no single segment can show.
Professional speed comes partly from switching between:
- local sentence view;
- global pattern view.
Build a consistency baseline before the team scales
If a project will involve several translators or a long release cycle, establish a baseline early.
Choose a representative set of recurring source strings and decide:
- approved target;
- context notes;
- known exceptions;