People searching for lock segments in a CAT tool, locked translation segments, protect approved translation, prevent translators from editing confirmed segments, lock pre-translated matches, or translation workflow segment locking are usually trying to solve a workflow problem rather than a language problem: how do you stop trusted material from being reopened, altered, rechecked, or accidentally damaged when the real work is elsewhere?
In modern CAT workflows, segment locking can make selected translation rows non-editable or restrict who can change them. Locked segments may be created after pre-translation, approval, review, quality checks, or project-management decisions. Used carefully, locking turns a large project into a clearer queue: translators see the work that still needs attention while approved or protected material stays out of the way.
The productivity value is not that locked translation is magically correct. The value is change control. A 101% context match, reviewed legal clause, approved UI label, or validated client boilerplate may not need another translator to touch it. Locking preserves that decision and prevents duplicate effort. But locking too early can freeze stale terminology, hide contextual mistakes, or make later updates harder. The dominant reader job here is therefore narrow: protect genuinely trusted segments without confusing “protected from editing” with “proven correct forever.”
Quick answer
Lock a segment when the project has a strong reason to prevent ordinary editing.
The fast workflow is:
identify trusted segment class → verify authority → lock → exclude from ordinary drafting queue → unlock only when a real change condition occurs
Good candidates may include:
- approved context matches;
- client-validated boilerplate;
- protected legal text;
- reviewed recurring strings;
- non-editable reference material;
- completed segments after a controlled stage.
Poor candidates include:
- ambiguous exact matches;
- unreviewed machine translation;
- fuzzy matches;
- content likely to change;
- segments whose terminology is still unsettled.
Locking protects workflow state.
It does not create linguistic certainty.
What a locked segment does
Depending on the CAT platform and user role, locking can:
- prevent editing;
- restrict editing to project managers or reviewers;
- remove the segment from ordinary confirmation requirements;
- change visual appearance;
- exclude the segment from some QA or workflow stages;
- protect pre-translated material;
- preserve approved text during team work.
The details vary.
The important behavior is that a locked segment no longer behaves like ordinary editable text.
That changes how human attention is allocated.
Why editable text attracts unnecessary work
When translators see editable text, they tend to evaluate it.
That is usually good.
But in large projects, the same approved material may be repeatedly:
- reread;
- rephrased;
- “improved” stylistically;
- reconfirmed;
- questioned;
- accidentally changed.
Suppose 10,000 words are already client-approved and only 2,000 words are new.
If all 12,000 words remain equally editable, the project interface invites attention to the wrong places.
Locking can make the workflow reflect reality:
10,000 words protected 2,000 words active
The project becomes cognitively smaller.
Locking is a routing mechanism
Think of a locked segment as a routing decision.
The project is saying:
“Ordinary translators do not need to spend time here unless the segment is deliberately reopened.”
That can be useful after:
- pre-translation;
- review;
- terminology approval;
- client validation;
- legal approval;
- engineering approval.
A lock is therefore part of workflow design.
It decides which role is allowed to revisit which text.
Locking versus confirming
These concepts should remain separate.
Confirming
Usually means the translator or reviewer accepts a segment at a workflow stage.
The segment may still remain editable.
Locking
Restricts change.
A confirmed segment can be unlocked.
A locked segment may already be confirmed.
The distinction matters because a team may want:
- confirmed but editable;
- confirmed and locked;
- pre-translated but editable;
- protected reference text that is locked without normal translation work.
Status and edit permission solve different problems.
Locking versus pre-translation
Pre-translation fills target text automatically from resources.
Locking determines whether that filled text can be edited.
A project can:
- pre-translate without locking;
- pre-translate and confirm;
- pre-translate and lock;
- lock manually after human review.
The strongest automation should be reserved for the strongest evidence.
Do not treat pre-translation and locking as one automatic pair.
Worked example 1: approved 101% context matches
A software update contains thousands of strings.
The client-approved TM returns 101% context matches for unchanged strings.
The project manager verifies the resource and configuration.
Those high-context matches are:
- pre-translated;
- confirmed;
- locked.
Translators see only:
- changed strings;
- new strings;
- ambiguous exact matches;
- fuzzy matches.
This can create major speed gains because human review is concentrated where context changed.
The key is the trusted TM.
If the TM were stale, locking would amplify the problem.
Worked example 2: ordinary 100% matches remain editable
The same project finds ordinary exact matches with different context.
These are inserted but not locked.
Why?
Because identical source text can require a different translation in a new context.
The translator reviews them quickly.
Some remain unchanged.
Some are adapted.
This is a useful trust distinction:
101% approved context match → protected 100% exact match without context → reviewable
The exact thresholds vary by project.
The principle is evidence-proportional locking.
Worked example 3: approved legal boilerplate
A legal department provides an approved bilingual clause that must not be altered by ordinary linguists.
The clause is imported into several contracts.
Locking prevents:
- stylistic rewriting;
- terminology changes;
- accidental deletion;
- well-intentioned “improvement.”
If legal later approves a new clause, an authorized user unlocks and updates it.
Here locking reflects governance authority.
The reason is not merely match percentage.
Worked example 4: repeated UI label
A product team has validated the target name of a feature.
The exact label appears in 200 strings.
The project can protect the label at the terminology level or lock complete approved strings where appropriate.
The translator should not spend time inventing alternatives.
However, if the same words appear in ordinary prose rather than as the exact UI label, the prose segment should remain editable.
Lock the approved object.
Do not freeze unrelated language because it looks similar.
Worked example 5: machine translation that should not be locked
A project pre-translates new content with MT.
The output is fluent.
The PM locks it to “save time.”
Translators cannot correct:
- omissions;
- wrong terminology;
- altered certainty;
- hallucinated relationships.
This is a misuse of locking.
The workflow has confused generated text with approved text.
Machine output can be a useful draft.
It should be locked only if a separate quality-control process genuinely supports that decision.
Worked example 6: locked segment after final review
A translator completes a section.
Reviewer 1 checks it.
Reviewer 2 proofreads it.
The project marks the segment final and locks it.
Now later work cannot casually reopen the segment.
This can be useful in long projects where different teams work asynchronously.
The lock creates a stable checkpoint.
Worked example 7: terminology change forces unlock
Halfway through a project, the client changes a required term.
Previously locked segments contain the old term.
The project must:
- identify affected locked segments;
- unlock the relevant set;
- update terminology;
- run QA;
- re-review if needed;
- lock again.
This is why locking requires a change-management plan.
A lock should be reversible when project truth changes.
Worked example 8: locked numbers hide an update
An annual report reuses a sentence:
Revenue increased by 12%.
The wording matches last year.
The number changes to 8%.
If the segment was locked based on textual reuse without recognizing the number change, the result is wrong.
Match logic and lock rules must treat numbers carefully.
Protected text should not prevent legitimate source updates.
What makes a segment lock-worthy
A strong candidate usually has several of these properties:
- source is unchanged;
- context is unchanged;
- target was reviewed;
- terminology is current;
- project authority approved it;
- locale is correct;
- structural elements are valid;
- risk of accidental editing is higher than benefit of another review.
A weak candidate lacks those conditions.
Lock-worthiness is not one score.
It is a trust decision.
Use a locking hierarchy
You can design several levels of protection.
Level 0: ordinary editable
New or uncertain content.
Level 1: confirmed but editable
Reviewed enough for progress tracking, but changes remain allowed.
Level 2: role-restricted
Only reviewers or project managers can change it.
Level 3: fully protected
Ordinary project work should not touch it.
This hierarchy is more flexible than one universal “lock everything approved” rule.
Why locks can increase translator confidence
A clean queue reduces hesitation.
If trusted segments are locked, translators know:
“I am expected to work on what remains editable.”
They spend less time wondering:
- Should I review this exact match?
- Is this clause already approved?
- Am I allowed to change this label?
- Did someone else finalize this?
Workflow state becomes visible.
That can make translation faster and psychologically clearer.
Why locks can reduce consistency drift
Long projects involve multiple linguists.
Without protection, each person may “improve” approved wording differently.
Locked segments resist stylistic drift.
This is especially useful for:
- legal boilerplate;
- regulatory statements;
- UI labels;
- product claims;
- standardized warnings;
- approved support macros.
However, locking should protect approved consistency, not arbitrary legacy language.
Locking and QA
Some systems allow locked segments to be excluded from QA.
That can save time if the segments are already validated.
It can also hide new project-wide issues.
Suppose the client changes a forbidden term.
If locked segments are excluded from terminology QA, the old term may survive.
A safer policy depends on the reason for the lock.
For example:
- structural QA may still run on locked content;
- new terminology QA may include locked content;
- ordinary proofreading may skip it.
QA scope should reflect current risk.
Locking and terminology updates
A strong workflow keeps a record of why segments are locked.
If terminology changes, the project can identify which locked material may be affected.
Without that traceability, locking creates hidden technical debt.
A locked segment should not become invisible knowledge.
It should remain searchable and auditable.
Locking and source updates
When source text changes, the lock should be reconsidered.
The workflow should ask:
- Did the source segment change?
- Did the source context change?
- Did a tag change?
- Did a number change?
- Did an identifier change?
- Did the segment move to another function?
A source update can invalidate the reason for the lock.
The project should not preserve a stale protection state merely because the target was trusted yesterday.
Locking and context matches
Context matches are natural candidates for selective locking because they provide stronger evidence than ordinary exact matches.
But context-match logic can still fail if:
- IDs are reused incorrectly;
- source structure changes;
- TM is stale;
- locale differs;
- terminology changes.
Therefore the lock decision should combine context score with resource authority.
Locking and TM penalties
Suppose one TM is known to be low quality.
A match from that memory should not receive the same lock treatment as a match from a current approved client TM.
This is where TM penalties and resource priority matter.
Locking sits downstream from trust configuration.
If match ranking is poor, lock automation will be poor.
Locking and reviewer roles
In team environments, not everyone needs the same permissions.
A useful division might be:
Translator
Can edit ordinary segments.
Reviewer
Can edit translated and confirmed segments.
Project manager
Can lock or unlock protected segments.
This creates controlled escalation.
The translator does not need authority to alter every approved clause.
The PM does not need to manually edit ordinary prose.
Role design reduces accidental scope creep.
Failure mode 1: locking because the match score looks high
A 100% match is automatically locked.
Context differs.
The target is wrong.
The problem is not the lock feature.
The problem is shallow trust logic.
High textual similarity is only one part of lock-worthiness.
Failure mode 2: locking old translation memory
A legacy TM contains obsolete target terms.
Pre-translation retrieves exact matches.
The project locks them.
Now the old terminology is harder to correct.
Lock only from resources whose authority is current.
Failure mode 3: locking before terminology stabilizes
The project begins while the client is still deciding key terms.
Segments are locked too early.
Every terminology update triggers mass unlocking.
The workflow creates avoidable administration.
Delay strong protection until high-impact decisions stabilize.
Failure mode 4: locking unreviewed MT
Fluent machine output is protected before human review.
Errors become harder to see and harder to fix.
Generated text should remain editable unless a validated automation process specifically justifies locking.
Failure mode 5: locking too much
The project manager wants a clean queue.
They lock every confirmed segment.
Later, translators need to adjust cross-sentence cohesion.
The necessary context is frozen.
Locking can damage discourse-level editing if applied too aggressively.
Protect stable units.
Leave room for legitimate revision.
Failure mode 6: locking too little
The project has thousands of client-approved strings.
Everything stays editable.
Multiple translators repeatedly tweak them.
Consistency declines.
Review time grows.
Sometimes under-locking is as inefficient as over-locking.
Failure mode 7: locks without reason codes
Six months later, nobody knows why a segment is locked.
Was it:
- legal approval?
- context match?
- client instruction?
- engineering protection?
- accidental project setup?
Unexplained locks create friction.
Where practical, document the lock rationale at the project or rule level.
Failure mode 8: locked segments hidden from global change
A new brand term must replace an old one.
Search or QA excludes locked rows.
The old name remains.
This is dangerous.
Locked should mean protected from ordinary editing.
It should not mean invisible to project-wide audits.
Failure mode 9: unlocking without re-locking
A reviewer unlocks a segment for one correction.
The segment remains editable afterward.
Later someone changes it again.
If the reason for protection still exists, restore the lock after the controlled change.
Build a lock policy before scaling
For recurring projects, define:
- who can lock;
- who can unlock;
- which match types qualify;
- which resources qualify;
- whether locked content is included in QA;
- what happens after terminology changes;
- what happens after source updates;
- how exceptions are documented.
This prevents ad hoc protection decisions.
A conservative lock policy
For high-risk content:
- no automatic locking of ordinary exact matches;
- lock only approved 101% context matches from trusted TM;
- keep numbers and warnings reviewable;
- include locked segments in global terminology QA;
- require authorized unlock for legal changes;
- relock after approved correction.
This policy emphasizes control.
A high-throughput lock policy
For low-risk repetitive internal content:
- pre-translate exact/context matches;
- auto-lock stable approved strings;
- exclude them from ordinary translator queue;
- keep MT and fuzzy matches editable;
- run periodic global QA across all segments;
- unlock only when source or terminology changes.
This policy emphasizes throughput.
Lock by category, not by convenience
Useful lock categories include:
- approved legal boilerplate;
- exact unchanged UI labels;
- validated context matches;
- protected system variables;
- final reviewed sections.
A bad category is:
“Everything that already has target text.”
Target presence is not evidence.
The lock audit
Before work begins, sample locked segments.
Check:
- source identity;
- context;
- terminology;
- locale;
- numbers;
- tags;
- resource provenance.
After work finishes, sample again.
Ask whether any change condition should have invalidated the lock.
This audit protects the system from false confidence.
Measure lock value
Track:
- percentage of project locked;
- edit attempts avoided;
- accidental changes prevented;
- number of necessary unlocks;
- errors found inside locked content;
- time spent managing locks.
A lock policy is successful when it removes more unnecessary work than it creates in administration and hidden risk.
The unlock rate
A useful metric is:
What percentage of locked segments later had to be unlocked?
A high unlock rate may indicate:
- locking too early;
- unstable terminology;
- weak match trust;
- frequent source changes;
- overly broad rules.
A low unlock rate with low error rate suggests the policy is well calibrated.
Locking and change windows
Some projects have phases.
Example:
Phase 1
Terminology is fluid.
Avoid strong locks.
Phase 2
Core terminology stabilizes.
Lock approved recurring material.
Phase 3
Final review.
Lock completed sections progressively.
Phase 4
Client change window.
Unlock only affected segments.
This staged approach makes locking respond to project maturity.
Locked segments as checkpoints
A lock can represent a checkpoint:
“This text has passed the required stage and should not drift.”
Checkpoints are useful in:
- large manuals;
- multi-file websites;
- annual reports;
- long legal projects;
- game localization;
- enterprise software.
They prevent earlier completed work from becoming unstable while later sections are still moving.
Locking and collaboration
In collaborative translation, one person may work in a segment while another reviewer is active.
Locks can prevent conflicting edits.
But they can also block legitimate collaboration.
Use them to protect finalized work, not as a substitute for communication.
Temporary edit locks and permanent approval locks solve different problems.
Know which one your tool provides.
Locking and external approvals
Sometimes approval occurs outside the CAT tool.
A client signs off on a spreadsheet or email.
The approved segments should then be marked or locked inside the translation workflow.
Otherwise the approval exists only in human memory.
The project interface should reflect external authority where possible.
Locking and auditability
High-stakes projects may need to show:
- which text was protected;
- when it was protected;
- who could alter it;
- when it was reopened.
Lock history can support governance.
However, auditability should not become bureaucracy for low-risk work.
Use control proportional to consequence.
Locking and short ambiguous strings
Do not lock short strings merely because they repeat.
Words such as:
- Back
- Open
- Close
- Home
- Apply
- Run
are context-sensitive.
Strong structural context is especially important before protecting them.
If the source package lacks context, keep them reviewable.
Locking and cross-sentence cohesion
A translation may be correct sentence by sentence but awkward across a paragraph.
If every earlier segment is locked, a reviewer cannot adjust:
- pronoun repetition;
- lexical cohesion;
- paragraph rhythm;
- topic progression.
For long-form prose, use fewer locks.
For isolated UI strings, locking can be more aggressive.
Text type matters.
Advanced practice: use lock tiers
If the platform supports only one lock state, use metadata or comments to simulate tiers.
For example:
- protected-current — approved and expected to remain fixed;
- protected-legal — change only with legal approval;
- protected-context-match — auto-reused, reopen on source/context change;
- protected-client — direct client wording.
This improves later change management.
Advanced practice: connect lock rules to change triggers
A lock should have an implicit invalidation rule.
Examples:
Approved context match
Unlock if source or context changes.
Brand terminology
Unlock if brand glossary changes.
Legal boilerplate
Unlock only after legal instruction.
UI label
Unlock if feature name or screen function changes.
Reviewed section
Unlock if upstream source revision affects it.
This makes protection dynamic rather than permanent.
Advanced practice: protect against reviewer overreach
A reviewer may prefer a different style but lack authority to change approved client wording.
Locked segments can make those boundaries explicit.
This reduces:
- review ping-pong;
- subjective rewriting;
- accidental contract changes;
- approved-phrase drift.
The lock encodes governance into the editor.
Advanced practice: do not hide locked context
Even when a segment is non-editable, translators may need to read it for context.
A good workflow keeps locked rows visible enough to support:
- pronoun resolution;
- terminology;
- discourse continuity;
- list structure.
Protection should not destroy comprehension.
Transfer: source control
Software teams protect stable branches or restrict who can merge changes.
Translation locking has a similar logic.
Not every contributor should be able to alter every approved state.
Change control preserves system integrity.
Transfer: document approval
In regulated document systems, approved sections may be frozen while draft sections remain editable.
Again, the principle is the same:
separate completed state from active state.
This reduces accidental regression.
Transfer: studying
Students can imitate locking mentally.
When a vocabulary term or grammar rule has been verified, stop re-debating it every time it appears.
Treat it as temporarily settled unless new evidence contradicts it.
This preserves attention for unsolved problems.
The deeper principle: protect settled decisions from unnecessary reopening
Translation becomes slow when every decision remains open forever.
If a trusted authority has settled:
- terminology;
- a legal clause;
- a UI label;
- a validated context match;
there is no productivity benefit in repeatedly reopening it.
Locking is a technological expression of a cognitive principle:
Do not spend fresh attention on a decision that is still valid and already settled.
But keep one escape route.
Reality can change.
A good lock protects stability without preventing correction.
Advanced practice: define lock-worthy evidence explicitly
Teams become inconsistent when “trusted” means different things to different people.
One translator may trust anything at 100%.
Another may require reviewer approval.
A project manager may rely on client validation.
A strong workflow defines acceptable lock evidence in advance.
For example:
Lock class A: client-approved
Evidence:
- explicit client approval;
- current target locale;
- approved source version;
- no unresolved terminology.
Lock class B: context-verified TM
Evidence:
- current client TM;
- 101% or stronger context match;
- no competing target;
- current termbase;
- low-risk content.
Lock class C: reviewed project text
Evidence:
- translator confirmed;
- reviewer completed;
- QA passed;
- no open comments.
These classes make lock decisions reproducible.
Advanced practice: maintain a visible reason for every large lock batch
Individual segment comments are not always necessary.
But the project should know why thousands of rows are protected.
A batch reason might be:
Locked because source and context match the approved 2026 client TM.
or:
Locked after legal approval on contract template v4.
or:
Locked after Reviewer 2 completion and final QA.
The reason matters later when someone asks:
Can we safely unlock and update these?
A lock without provenance becomes technical debt.
Worked example 9: client approval after translator review
A translator completes a marketing localization.
The client edits 30 segments and approves the rest.
The PM now locks:
- the 970 approved unchanged segments;
- the 30 client-edited approved segments.
Next month, a regional reviewer opens the project to update three product names.
Without locks, the reviewer could unintentionally rewrite campaign language the client already approved.
With locks, the task becomes explicit:
- unlock affected product-name segments;
- apply authorized change;
- verify;
- relock.
Approval survives project reuse.
Worked example 10: review stage accidentally edits locked boilerplate
A reviewer receives a file containing a legal disclaimer already approved by counsel.
The disclaimer is locked.
The reviewer can read it but cannot “improve” punctuation or style.
This is useful because reviewers often operate under a general instruction to polish language.
The lock communicates an exception:
This text is not part of your editing scope.
The workflow prevents a role conflict before it becomes a content conflict.
Worked example 11: source correction invalidates a lock
A locked warning originally reads:
Do not operate above 80°C.
Engineering corrects the source to:
Do not operate above 70°C.
The target segment must be reopened.
The correct process is not:
“Locked means final.”
It is:
“The condition that justified the lock no longer holds.”
A source-change trigger should override protection.
This keeps locking subordinate to current truth.
Worked example 12: locked segment still needed as context
A translator works on a paragraph where the first two sentences are locked from prior approval.
The third sentence is new and contains:
This process…
The translator must read the locked sentences to understand the referent.
If the tool hides locked rows entirely, translation becomes harder.
A better workflow may:
- keep locked context visible;
- gray or protect it;
- exclude it from active editing;
- allow navigation around it.
Protection should preserve readability.
Worked example 13: selective unlock after global terminology change
A company changes:
customer success manager
to:
customer success lead.
Thousands of locked segments exist.
Do not unlock the entire project.
Instead:
- search locked segments containing the old term;
- review whether each occurrence represents the same role;
- unlock the valid set;
- replace or edit safely;
- run terminology QA;
- relock the corrected set.
This keeps change scope narrow.
Selective unlock is the counterpart of selective locking.
Worked example 14: lock policy differs by file type
A project contains:
- UI strings;
- help-center articles;
- legal terms;
- marketing pages.
The same policy should not govern all four.
UI strings may tolerate aggressive locking of validated labels.
Help-center articles need some paragraph-level freedom.
Legal terms may require approval-based locks.
Marketing copy may require almost no locking beyond protected names and claims.
Lock policy should follow text function.
Locking and task visibility
A large project can appear overwhelming because every segment looks active.
Locking changes the visual psychology of the job.
If 70% is protected, the translator immediately sees that only 30% requires action.
This can improve:
- planning;
- focus;
- progress estimation;
- handoffs;
- review scope.
The benefit is similar to filtering, but stronger.
Filtering changes what is visible.
Locking changes what is editable.
Locking and statistics
Project dashboards may count locked or confirmed segments differently.
Before using progress statistics, understand the workflow logic.
A project can look 90% complete because large amounts were pre-translated and locked.
That may be correct.
Or it may conceal insufficient review.
Progress metrics should reflect genuine process state.
Never let dashboard percentage define quality requirements.
Locking and audit after bulk operations
High-leverage operations such as:
- pre-translation;
- find-and-replace;
- terminology migration;
- import updates;
can affect locked segments indirectly depending on the tool.
After a bulk operation, verify whether locks:
- were preserved;
- were bypassed;
- blocked intended updates;
- excluded affected content.
Do not assume protection behaved as expected.
A small audit is cheaper than discovering silent inconsistencies later.
Use locks to prevent accidental TM pollution
In some workflows, confirming edited segments writes them into the working TM.
If a translator unnecessarily rewrites already approved content, the new variant may enter the memory and create duplicates or conflicts.
Locking can reduce that risk.
It protects not only the current target but also the future resource quality.
Stable approved text remains stable in the TM.
Locking and translation-memory cleanup
If a TM contains conflicting targets, do not use locks to hide the conflict.
Clean the resource.
A bad pattern is:
- obsolete TM produces wrong exact match;
- segment gets corrected manually;
- segment gets locked;
- next project retrieves obsolete TM again.
The lock solved the local symptom.
The memory still causes the problem.
Use local locking and resource maintenance together.
Locking and branch-specific content
Some projects contain content variants for:
- country;
- audience;
- product tier;
- legal jurisdiction.
Do not lock a segment merely because it is approved in another branch.
Approval scope matters.
A phrase approved for Singapore may not be approved for Germany.
A phrase approved for consumer users may not fit enterprise administrators.
Protection should inherit the same scope as the approval.
Locking and dates
Time can invalidate locks even when source text does not change.
Examples:
- annual claims;
- seasonal promotions;
- regulatory dates;
- contact information;
- current office holders;
- product availability.
A locked sentence can become stale because the world changed.
For time-sensitive content, attach review dates or expiry conditions.
This is particularly important for website localization.
Locking and references
A locked target may contain:
- Figure 8;
- Section 3.2;
- Appendix B.
If the source document is restructured, those references may change even if surrounding wording remains similar.
Run cross-reference QA after source updates.
A segment should not stay protected if its factual reference is no longer current.
Use a revalidation trigger list
Common triggers that should force a lock review include:
- source text change;
- source context change;
- identifier change;
- terminology update;
- style-guide update;
- locale change;
- client instruction;
- legal update;
- product rename;
- number/date change;
- structural tag change;
- reviewer rejection.
The project does not need to unlock everything automatically.
It needs to know which protections may no longer be justified.
Use a lock exception queue
If translators encounter a locked segment that appears wrong, give them a clear route:
- flag;
- comment;
- assign;
- request unlock;
- escalate.
Do not force them to ignore the problem because they lack permissions.
A lock should block unauthorized editing.
It should not block error reporting.
This distinction preserves both control and quality.
The cost of unauthorized “fixes”
Without locks, a translator may correct approved content locally.
The change seems harmless.
Later:
- client review sees unexpected wording;
- TM gains a new variant;
- regional versions diverge;
- legal approval no longer matches;
- other files remain unchanged.
A five-second edit creates project-wide inconsistency.
Locking prevents this class of scope violation.
The cost of over-governance
The opposite failure also exists.
Every minor phrase is locked.
Every change requires a PM.
Translation slows under administrative friction.
Reviewers wait.
Simple grammar corrections become tickets.
That is not efficient governance.
Reserve strong restrictions for decisions whose uncontrolled change would be genuinely expensive.
Locking and final delivery
Before export, run a final protection check:
- Are required locked segments still locked?
- Did any last-minute edit reopen them?
- Do locked segments contain unresolved warnings?
- Did terminology changes reach them?
- Did source updates invalidate them?
- Are protected variables and tags intact?
The lock state should match the delivered state.
A lock-policy maturity model
Stage 1: no locks
Everything is editable.
Simple but vulnerable to drift.
Stage 2: ad hoc locks
PMs protect obvious approved content.
Useful but inconsistent.
Stage 3: rule-based locks
Locking follows documented match, approval, and role criteria.
Predictable.
Stage 4: change-triggered governance
Locks are automatically or deliberately re-evaluated when source, terminology, or approval changes.
Robust.
The goal is not maximum maturity for every project.
Use the level justified by project size and risk.
Measure protected-attention savings
A useful productivity estimate is:
How many trusted segments did translators avoid reopening because they were clearly protected?
Multiply by the average seconds that would otherwise be spent:
- reading;
- comparing;
- deciding not to change;
- reconfirming.
Across thousands of segments, small avoided decisions accumulate.
That is the economic case for locking.
Measure administrative overhead too
Count:
- unlock requests;
- relock actions;
- permission problems;
- hidden errors;
- missed global changes.
A policy can save translator time while creating PM overhead.
The best system minimizes total project cost, not only translator clicks.
Train teams on what a lock means
Everyone should know:
Locked does not mean “never wrong.”
It means:
“Do not edit through the normal path because the project has a stronger reason to protect this state.”
If a problem is found, escalate it.
This shared interpretation prevents two extremes:
- blind trust;
- casual circumvention.
The ideal locked project
In a well-designed project:
- trusted segments are protected;
- uncertain segments remain editable;
- translators can read all needed context;
- QA can still audit relevant risks;
- change triggers are known;
- exceptions have an escalation path;
- unlocking is rare but possible.
The lock system fades into the workflow.
People spend time on language, not permissions.
Summary
Segment locking helps people translate quickly by protecting genuinely trusted target text from accidental editing, repeated review, stylistic drift, and unnecessary reconfirmation. It is most useful when the project can clearly identify approved or high-confidence segment classes.
The fast workflow is:
establish trust → lock selectively → route translators to editable work → keep locked content auditable → unlock when a defined change condition occurs → revalidate → relock if appropriate
Locking is not proof of correctness.
It is change control.
Used well, it makes the project interface reflect what the team actually knows: some text is settled, some text is still active, and human attention should concentrate on the active part.
Frequently asked questions
What is a locked segment in a CAT tool?
A locked segment is a translation row whose editing is restricted or prevented according to project permissions or workflow rules.
Why lock translation segments?
To protect approved or trusted text, reduce accidental changes, prevent duplicate review, and focus translators on work that still requires decisions.
Is locking the same as confirming?
No. Confirmation marks a workflow state. Locking restricts editing. A segment can be confirmed but still editable.
Should 100% TM matches be locked automatically?
Not necessarily. Exact source text can appear in different contexts. Resource trust and contextual evidence should control the decision.
Are 101% context matches good lock candidates?
They can be stronger candidates because context also matches, especially when the TM is current and approved. High-risk content may still require explicit review.
Should machine translation be locked?
Usually not before appropriate human or automated validation. Fluent generated text is not equivalent to approved text.
Can locked segments still contain errors?
Yes. Locking protects whatever is there. If the target is wrong, the lock preserves the wrong target.
Should locked segments be excluded from QA?
Sometimes, but global terminology, number, tag, or project-wide changes may still need to include them. QA scope should reflect risk.
What happens when terminology changes?
Affected locked segments should be identified, unlocked, updated, verified, and relocked if the protection reason still applies.
How do I know if my lock policy is too aggressive?
A high unlock rate, many hidden errors, blocked discourse edits, or frequent project-wide exceptions suggest the policy is too broad or applied too early.
Internal-link opportunities
This article can connect naturally to other eduKateSG translation owners:
- How People Translate Quickly | Pre-Translation — for populating trusted matches before deciding which should be protected.
- How People Translate Quickly | Context Matches — for distinguishing strong contextual reuse from ordinary exact-text matches.
- How People Translate Quickly | Live QA Warnings — for deciding which checks should still include locked material.
- How People Translate Quickly | TM Penalties and Match Thresholds — for making sure low-trust memories do not generate lock-worthy-looking matches.
- How People Translate Quickly | Version Diffing — for detecting source changes that may invalidate locked target text.
- Master Art of Translation | The Translation Memory System — for the broader reuse and governance architecture.