People searching CAT tool segment filters, filter untranslated segments, translation workflow, translation productivity, confirmed and unconfirmed segments, or how to translate faster in a CAT tool are often working inside a document that is visually larger than the work that actually remains. A file may contain 2,000 segments, but perhaps only 180 are untranslated, 40 have comments, 23 contain errors, and 12 need a second look. Scrolling through all 2,000 keeps finished work in the translator’s field of attention even though most of it no longer deserves active thought.
A fast translation workflow turns that large document into a smaller working queue. Segment filtering lets the translator hide finished, locked, irrelevant, or already-approved material and display only the subset that matches the current job: untranslated segments, unconfirmed segments, repetitions, comments, QA errors, machine-translated output, a particular file, or another meaningful status. The mechanism is simple: reduce the visible search space so attention lands on work that can still change.
This is how people translate quickly without treating a CAT editor as a long electronic scroll. They use status, filters, search, and workflow state to make the next action obvious. The document remains complete in the background, but the working view becomes intentionally narrow.
Quick answer
To translate faster in a CAT tool, do not keep every segment visible for every task. Filter the document according to the work you are doing now. Translate the untranslated queue. Review the unconfirmed queue. Resolve the comments queue. Check the error queue. Inspect high-risk or machine-generated segments separately when appropriate. Reset filters before final delivery so no hidden segment is accidentally ignored.
The core loop is:
define the task → filter the queue → work the queue → clear the state → switch views → run a whole-document final check.
Why the full document is often the wrong working view
A complete document is useful for context.
It is not always useful for execution.
Imagine a 70-page manual with:
- 1,800 segments;
- 1,250 already confirmed;
- 260 exact repetitions;
- 180 untranslated segments;
- 45 segments with open comments;
- 37 segments containing QA warnings;
- 28 locked strings;
- several headings that contain only product codes.
If the translator scrolls the complete grid, every row competes visually with the rows that actually need work.
This creates several forms of friction:
- searching for where to resume;
- checking status icons repeatedly;
- reopening finished segments accidentally;
- losing track of comments;
- moving through locked or non-translatable material;
- mistaking visual completion for actual workflow completion.
A filter converts a broad document into a task-specific list.
That is not merely interface convenience. It is attention routing.
The working-set principle
Computing systems often perform better when the active working set is smaller than the total dataset.
Human work has a similar practical constraint.
A translator can know that 2,000 segments exist while actively reasoning about only a small subset.
The working-set principle is:
Show the translator only the material needed for the current operation, while keeping the full document recoverable for context and final verification.
This does not mean context should disappear. It means context and task execution should not be confused.
You may need the neighboring source sentence to understand a line. You do not need 1,799 unrelated finished lines to remain in the active queue.
Filtering is not the same as deleting
A filter changes the view, not the document.
That distinction is important.
The hidden segments still exist.
They may still contain:
- unresolved issues;
- wrong status;
- critical errors;
- accidental blanks;
- stale translations;
- comments;
- repetitions affected by later terminology changes.
This is why filters must be treated as temporary lenses.
A translator should be able to answer:
- What is hidden?
- Why is it hidden?
- What condition will make it visible again?
- When will I return to the full document?
If the answer is unclear, the filter can become a blind spot.
The five most useful translation queues
CAT tools differ, but the most useful filters usually correspond to a small number of work states.
1. Untranslated queue
This is the clean drafting queue.
It contains segments that still need target text.
Use it when the primary job is forward translation.
The advantage is psychological as well as practical. Every visible segment requires the same basic action: translate it.
There is less status interpretation.
2. Unconfirmed queue
A target text may exist without being confirmed or approved.
This queue asks a different question:
Is this translation ready to move to the next workflow state?
The translator or reviewer can focus on incomplete approval rather than re-reading everything.
3. Comment or issue queue
Questions, client notes, reviewer comments, and unresolved issues should not be scattered invisibly through a long document.
Filter them together.
Now the task is not “translate the file”.
It is “close the open issues”.
That job is much easier to measure.
4. Error queue
QA systems may detect:
- missing numbers;
- punctuation mismatches;
- terminology deviations;
- tag problems;
- capitalization differences;
- empty targets;
- repeated spaces;
- inconsistent translations.
Filtering the detected-error queue converts a general review into a repair list.
5. Source or input-type queue
Some CAT tools can distinguish segments by translation source, such as:
- manual translation;
- machine translation;
- translation-memory match;
- updated source;
- imported translation.
That allows review depth to follow provenance.
A 100-percent approved match may deserve a different check from a fresh machine-generated draft.
Worked example 1: a partially translated project
You open a project that another translator worked on yesterday.
The file contains 900 segments.
You know:
- 620 are confirmed;
- 110 contain approved repetitions;
- 170 are not complete.
Weak workflow:
Start at segment 1 and scroll until you find unfinished work.
Better workflow:
Filter to untranslated or unconfirmed.
Now the active queue is approximately 170 segments.
The project has not become smaller, but the work problem has.
After completing the queue, reset the filter and confirm that no unexpected statuses remain.
Worked example 2: reviewer comments
A reviewer leaves 32 comments in a 2,500-segment project.
Without filtering, the translator jumps between notifications or scrolls the entire file.
With a comment filter, the 32 segments become a dedicated queue.
That queue can be processed systematically:
- terminology comments;
- source questions;
- style preferences;
- genuine errors;
- client decisions.
The translator may discover that ten comments are actually one repeated problem. Solving the pattern once can close multiple items.
The filter has not merely accelerated navigation. It has revealed structure in the feedback.
Worked example 3: QA after a terminology change
The client changes “account owner” to “workspace administrator”.
The project contains hundreds of strings.
After the terminology update, you want to inspect places where the old term might remain.
A source or target text filter can isolate occurrences.
You can then:
- verify that the phrase has the intended sense;
- update appropriate segments;
- avoid changing unrelated uses;
- check grammar around replacements;
- confirm the affected queue.
This is faster and safer than reading every line hoping to notice the old term.
Worked example 4: numbers-only and code-heavy segments
A technical file includes many segments containing:
- serial numbers;
- product codes;
- paths;
- identifiers;
- URLs;
- variables.
Some are intentionally non-translatable or locked.
If the CAT environment allows them to be excluded, hide them from the normal drafting queue.
The benefit is not that these elements do not matter.
The benefit is that they need a different job:
preserve and verify, not linguistically translate.
Mixing them into the prose queue forces the translator to switch mental modes repeatedly.
One queue, one dominant action
A strong filtering rule is:
Every filtered queue should have one dominant action.
Examples:
- Untranslated → translate.
- Unconfirmed → verify and confirm.
- Comments → resolve.
- Errors → repair.
- Repetitions → check propagation.
- High-risk terms → verify.
- Machine-generated → post-edit according to the brief.
If a filtered view contains five unrelated jobs, it is not reducing complexity enough.
The point is not to create sophisticated filters.
The point is to make the next action obvious.
Why status discipline matters
Filters are only as reliable as the underlying statuses.
If translators leave completed segments unconfirmed, the unconfirmed queue becomes noisy.
If unresolved items are confirmed prematurely, the confirmed queue becomes misleading.
If comments are not closed when resolved, the issue queue becomes stale.
This leads to a general rule:
workflow state should describe reality.
A segment marked complete should genuinely be complete according to the current stage.
A segment that still needs action should remain visibly unfinished.
Status is not decoration. It is machine-readable workflow memory.
Confirming too early
Premature confirmation creates false completion.
A translator may confirm a segment because the sentence “looks fine”, even though:
- the official term has not been checked;
- a placeholder is still provisional;
- the source reference is unresolved;
- a reviewer question remains;
- a number has not been verified.
Now the filter hides the segment from later unfinished queues.
The interface says done.
Reality says not done.
This is more dangerous than leaving the item visibly open.
Never let filters hide risk
Filtering can increase speed because it removes irrelevant material.
It can also hide exactly the segment you needed to see.
Common dangerous cases include:
- a locked segment with outdated translation;
- a confirmed segment affected by a later terminology change;
- a machine-translated segment treated as approved automatically;
- an ignored QA warning that should be reconsidered;
- a segment outside the translator’s assignment that provides essential context;
- a hidden repetition whose context differs.
The cure is not to avoid filters.
The cure is to use them with reset points.
The reset-point rule
At defined stages, return to the full document.
Useful reset points:
- end of first draft;
- after terminology changes;
- before reviewer handoff;
- before final QA;
- before export;
- after resolving all comments;
- after any bulk operation.
The full-document view asks:
What did the filtered queue prevent me from seeing?
This recovers context and catches status errors.
Filter stacking
Many CAT tools allow several conditions at once.
For example:
- unconfirmed;
- contains a number;
- has an error;
- not locked.
This can create a powerful high-priority queue.
But stacking filters carelessly can create the opposite problem.
Suppose you filter:
- confirmed;
- errors only.
If the system refuses confirmation when a critical error exists, those segments may never appear because the conditions are mutually incompatible.
Or suppose you filter:
- untranslated;
- machine translation source.
If machine-generated target text means the segment is technically “translated”, the view may be empty even though you expected post-editing work.
The lesson:
understand what each status means in the specific platform.
Do not treat filter labels as universal.
The funnel strategy
A useful workflow is to narrow from broad to specific.
Funnel 1: draft completion
Show:
- untranslated;
- assigned to you;
- editable.
Complete that queue.
Funnel 2: unresolved state
Show:
- unconfirmed;
- comments;
- issue flags.
Close open decisions.
Funnel 3: technical QA
Show:
- detected errors;
- number mismatches;
- tags;
- terminology warnings.
Repair deterministic issues.
Funnel 4: risk review
Show:
- high-risk terms;
- machine-generated or fuzzy-match content;
- manually flagged segments.
Apply deeper judgment.
Funnel 5: reset
Show the whole document.
Run final checks.
This sequence turns one enormous project into several smaller jobs.
Filtering and translation triage
Translation triage classifies work by difficulty and consequence.
Segment filtering gives the interface a way to isolate classes of work.
For example, triage might identify:
- terminology-heavy segments;
- high-risk instructions;
- repeated UI labels.
If the CAT tool supports tags, comments, filters, or search, those groups can become separate queues.
Triage answers:
What kind of work is this?
Filtering answers:
Show me only that kind of work.
They support each other without being the same method.
Filtering and two-pass translation
Two-pass translation separates fast drafting from precise verification.
Filters can make the separation operational.
Pass 1:
- show untranslated segments;
- draft quickly;
- leave marked uncertainties open.
Pass 2:
- show unconfirmed, flagged, commented, or error-bearing segments;
- verify deliberately.
Final:
- reset filters;
- inspect the complete document.
The tool now reflects the cognitive structure of the method.
Failure mode 1: forgetting a filter is active
This is one of the most common practical problems.
A translator finishes a filtered queue and thinks the project is finished.
But hundreds of hidden segments remain.
Always maintain visible awareness of active filters.
Before declaring completion:
- clear all filters;
- inspect total segment counts;
- check project progress;
- run a whole-document QA or completion view.
A filtered view is a temporary workspace, not proof of project completeness.
Failure mode 2: filtering by the wrong stage
In multi-stage workflows, “confirmed” may mean different things.
A segment may be confirmed in:
- translation;
- editing;
- proofreading;
- client review.
The next stage may still require action.
Know which workflow state the filter represents.
Otherwise, you may hide segments that are complete for one person but not for the project.
Failure mode 3: treating locked as correct
Locked means “not editable under the current rules”.
It does not automatically mean “linguistically correct forever”.
A segment may be locked because:
- it was approved;
- it came from an import;
- a manager protected it;
- it belongs to another supplier;
- it is non-translatable;
- a workflow stage controls it.
If a locked segment creates a serious inconsistency, do not silently ignore it. Escalate through the project process.
Failure mode 4: creating too many saved filters
Saved searches can become clutter.
If every tiny scenario has a named filter, the translator spends time deciding which filter to use.
Keep a small set of high-value views.
For many workflows, five or six are enough:
- TO TRANSLATE;
- TO CONFIRM;
- COMMENTS;
- ERRORS;
- HIGH RISK;
- ALL.
The best tool configuration reduces choices rather than multiplying them.
Failure mode 5: reviewing only what the tool can detect
A QA filter can show technical errors.
It cannot guarantee that the translation preserves meaning.
The following may pass automated checks:
- wrong interpretation;
- unnatural phrasing;
- incorrect tone;
- mistranslated sarcasm;
- missing implication;
- overconfident claim;
- wrong referent with matching grammar.
Filtering supports review.
It does not replace reading.
Build a queue hierarchy
Not all queues deserve equal priority.
A practical priority order might be:
Priority A: blocking
- untranslated;
- critical errors;
- unresolved source ambiguity;
- required client query.
Priority B: project consistency
- terminology warnings;
- comments;
- repetitions;
- fuzzy matches needing review.
Priority C: polish
- style suggestions;
- minor punctuation;
- optional rewrites.
This prevents a translator from spending twenty minutes polishing a low-risk queue while critical incomplete segments remain elsewhere.
The completion equation
Do not define completion as:
I reached the bottom.
Define it as:
Every required workflow state has no remaining actionable items.
For example:
completion = no untranslated + no required unconfirmed + no open critical issues + no unresolved comments + final whole-document verification.
The exact equation changes by project.
The concept is powerful because it converts completion from a feeling into a set of observable states.
Filters for machine translation post-editing
Machine translation changes the queue structure.
A file may technically have target text everywhere.
The untranslated filter therefore shows nothing.
But the human job is not finished.
Useful post-editing queues may include:
- machine-generated input source;
- unconfirmed segments;
- low-confidence or fuzzy matches;
- segments with terminology warnings;
- high-risk content;
- strings with numbers or placeholders.
The lesson is that “target text exists” is not the same as “human work is complete”.
Status should represent the actual quality stage.
Filters for translation memory matches
Exact and high-percentage matches can save time, but match percentage is not truth.
A repeated sentence may appear in a different context.
A fuzzy match may be structurally useful but semantically dangerous.
A context match may still be outdated after a product change.
Use match-source filtering to allocate review depth, not to eliminate judgment automatically.
Possible strategy:
- exact approved matches → light consistency check;
- high fuzzy matches → focused edit;
- low matches → treat as new translation;
- sensitive content → full verification regardless of percentage.
Filters for collaborative projects
Large projects often split work among translators, revisers, and project managers.
Filters can isolate:
- your assigned segments;
- another user’s revisions;
- segments changed after a date;
- comments from a reviewer;
- work in a particular stage.
This reduces coordination overhead.
Instead of asking:
Where did the reviewer change things?
you can display the revision queue.
Instead of asking:
Which segments still need my response?
you can display comments assigned to your stage.
The interface becomes a shared state machine.
Filters for long documents with repeated terms
Suppose a 40,000-word manual contains the term “safety interlock” 96 times.
A terminology decision changes halfway through the project.
Search or filter every affected occurrence.
Now the translator can:
- inspect each use;
- update only true matches;
- reject false matches;
- confirm consistency;
- reset the view.
This is safer than global blind replacement and faster than rereading 40,000 words.
Filtering creates a review surface for one decision.
Filters for numbers, dates and units
Some tools can isolate segments containing numbers.
That can support a dedicated factual-data pass.
Check:
- number preserved;
- decimal separator;
- thousands separator;
- unit;
- conversion policy;
- date order;
- range;
- inequality;
- percentage;
- currency.
A separate numeric queue is especially useful when the translation is otherwise stylistically strong but factual drift would be costly.
Use search and filters together
Search answers:
Where does this text occur?
Filters answer:
Which segments belong to this workflow state?
Together they are more powerful.
Example:
Filter to:
- unconfirmed segments.
Then search:
- “controller”.
Now you see only unresolved uses of “controller”, not every approved historical occurrence.
Or filter to:
- error-bearing segments.
Then search:
%.
Now you can inspect percentage-related technical errors quickly.
This is progressive narrowing.
A daily translator filter routine
Before starting:
- clear all filters;
- check project totals;
- identify today’s job;
- apply the smallest useful filter.
During drafting:
- work one queue;
- keep unresolved items visibly flagged;
- avoid opening unrelated queues mid-flow.
At a natural break:
- save or confirm;
- check queue count;
- resolve blocking comments;
- switch filters deliberately.
Before ending:
- clear filters;
- inspect remaining states;
- leave an explicit restart point.
This makes resumption easier because the project state is legible.
What to do when filtering hides context
Sometimes a filtered queue shows isolated segments with too little surrounding material.
Do not force translation from the narrow view.
Options:
- temporarily reveal neighboring segments;
- open document preview;
- inspect a screenshot;
- open the source file;
- search related text;
- reset the filter briefly.
The rule is:
narrow execution, widen interpretation.
You can work from a small queue while still consulting broad context.
The difference between queue size and difficulty
A queue of 20 segments can be harder than a queue of 200.
Do not estimate time only by count.
Twenty unresolved legal conditions may require more attention than 200 repeated product descriptions.
Filters make workload visible, but they do not measure cognitive cost automatically.
Combine queue size with:
- domain familiarity;
- risk;
- repetition;
- source quality;
- terminology stability;
- review requirements.
Measure whether filters actually help
For several projects, track:
- time spent scrolling;
- number of accidental reopenings;
- time to locate comments;
- number of unresolved segments found late;
- number of status mistakes;
- time from “draft complete” to delivery.
A filtering system is valuable if it reduces navigation and omission without creating hidden-state failures.
If filters increase confusion, simplify them.
Advanced technique: work by exception
Mature workflows increasingly treat ordinary, trusted cases as background and human attention as an exception resource.
Examples:
- locked non-translatable strings need no linguistic drafting;
- exact approved repetitions may need less attention;
- critical QA errors need more;
- unresolved comments need direct action;
- novel or high-risk content needs deeper review.
Filtering supports exception-based work.
The translator is not reading everything with identical intensity.
The translator is asking:
What still differs from the expected safe state?
That is a powerful model for speed.
The ethics of exception-based review
Exception-based work must be used carefully.
If the system’s “safe” category is unreliable, hiding it can magnify mistakes.
A workflow that auto-confirms low-quality machine translation would make exception filtering dangerous.
Therefore, the baseline must deserve trust.
Use filtering to reduce redundant attention only where:
- the state definition is meaningful;
- the source of translation is known;
- QA rules are appropriate;
- final sampling or whole-document verification remains.
Efficiency should come from evidence, not optimism.
A practical filter checklist
Before applying a filter:
- What exact job am I doing?
- Which segments should appear?
- Which segments will disappear?
- Could hidden content affect meaning?
- Does this platform define the status the way I think it does?
While working:
- Is the queue still homogeneous?
- Are new issues being marked?
- Is completion state being updated honestly?
- Am I missing context because the view is too narrow?
Before finishing:
- Have I cleared the filter?
- Are any comments still open?
- Are any required segments unconfirmed?
- Are critical errors unresolved?
- Did terminology changes affect hidden segments?
- Has the complete file received a final check?
Transfer beyond translation
The queue principle appears everywhere.
Email:
- unread;
- needs reply;
- waiting;
- archived.
Software bugs:
- open;
- blocked;
- fixed;
- needs review.
Student revision:
- unknown;
- unstable;
- mastered;
- revisit.
Editing:
- structural;
- factual;
- stylistic;
- proofing.
The general idea is to stop treating a large collection as one undifferentiated workload.
State creates smaller queues.
Queues make action legible.
Build filters around decisions, not around interface features
CAT tools often expose many filter controls. That does not mean every available control deserves a permanent place in your workflow.
A better design starts from recurring decisions.
Ask:
- Which work do I repeatedly need to isolate?
- Which mistakes are easiest to repair as a group?
- Which statuses determine handoff?
- Which segments have different review requirements?
- Which hidden states create the most expensive surprises?
Then build the smallest set of views that answers those questions.
For example, a software-localization translator may need:
- untranslated editable strings;
- strings with placeholders;
- strings over the character limit;
- reviewer comments;
- terminology errors.
A book translator may need something different:
- untranslated;
- unresolved names;
- chapter-specific comments;
- repeated terminology;
- final proofing flags.
The correct filter system follows the work, not the software menu.
Use queue counts as feedback
A filtered queue is not only a workspace. Its size is a diagnostic signal.
Suppose you begin with:
Think of filtering as queue design
Segment filtering is fastest when the translator stops thinking of the document as one long list of segments and starts thinking of it as several work queues.
A project may contain:
- untouched segments;
- machine-translated segments awaiting review;
- confirmed segments;
- segments with terminology warnings;
- segments changed since the previous version;
- segments containing numbers;
- segments with comments;
- high-risk segments marked for second review.
These are not equally urgent and do not require the same cognitive mode.
Filtering creates a temporary queue containing only the work that belongs to the current pass.
The underlying document remains complete. The visible workspace becomes narrower.
That distinction matters because filtering is not deletion. It is attention control.
Build filters around verbs
A useful way to design a filter is to name the action you are about to perform.
Instead of asking:
What can I hide?
Ask:
What am I doing right now?
Examples:
Translate → show untranslated segments. Review terminology → show segments containing flagged or recurring terms. Verify numbers → show segments containing digits, units or numerical QA warnings. Check changes → show modified segments only. Resolve comments → show segments with comments or discussion. Finalize → show unconfirmed, warning-bearing or edited-after-review segments.
The verb keeps the filter tied to a reader job.
A filter with no action behind it is merely a different view.
Worked example: a 12,000-word update
Imagine a manual with 12,000 words, but only 1,800 words changed from the previous release.
Without filtering, the translator scrolls through the entire project, visually distinguishing old from new work.
With a changed-segments filter, the active queue contains only the 1,800 words requiring attention.
After translation, the translator switches to a QA queue containing:
- changed segments with numbers;
- changed segments with terminology warnings;
- changed segments with comments;
- any unchanged segment whose context was affected by the modification.
The project is still 12,000 words.
The active decision set is much smaller.
That reduction is the productivity gain.
Worked example: terminology cleanup
Suppose the project contains two target equivalents for the same source term.
A global visual scan is inefficient.
Instead:
- search the source term;
- filter to all occurrences;
- sort or inspect target variants;
- determine whether the source sense is the same in each occurrence;
- update the appropriate subset;
- remove the filter;
- continue normal work.
Filtering turns a document-wide consistency problem into a bounded queue.
Worked example: numbers and units
A translator wants a dedicated verification pass for numbers.
Filter segments containing digits, percent signs, currency symbols, measurement units or QA warnings.
Now each visible segment belongs to the same mental mode:
- compare source and target values;
- check decimal separators;
- verify unit conversion policy;
- check dates and times;
- inspect ranges;
- confirm that minus signs and inequalities survived.
This is faster than alternating between stylistic editing and numerical verification sentence by sentence.
The brain does not need to change task type constantly.
Use filters to reduce mode switching
Translation work contains different cognitive modes.
Drafting asks: what does this mean and how should it be expressed?
Terminology review asks: is the same concept named consistently?
Numerical QA asks: did factual symbols and quantities survive?
Comment resolution asks: what did the reviewer mean and how should the issue be addressed?
These modes compete when mixed.
Filtering supports batching.
A good queue contains tasks similar enough that the previous decision helps prepare the next one.
Do not hide context needed for meaning
Filtering can create tunnel vision.
If you show only segments containing a search term, the translator may lose the neighboring sentences that determine sense.
Use filtered views to locate work, then expand context when necessary.
For example, a source term such as “charge” may appear in financial, electrical and legal senses. A filter finds occurrences efficiently. Context decides which occurrences belong together.
The rule is:
filter for location; restore context for interpretation.
Use a filter stack, not one permanent filter
Complex projects often need several successive views.
A practical sequence might be:
- untranslated segments;
- changed segments;
- terminology warnings;
- comments;
- numbers and units;
- unconfirmed segments;
- final all-segments scan.
Each filter answers a different question.
Do not leave one filter active simply because it was useful thirty minutes ago.
An old filter can hide new problems.
Create a visible “filter active” habit
One of the easiest filtering mistakes is forgetting that a filter is active.
The project appears complete because the screen contains no more visible segments, while hidden work remains.
Use a habit:
Before declaring a pass complete, ask:
What is currently hidden?
If the CAT tool displays an active-filter indicator, pay attention to it.
Before delivery, return to an unfiltered or deliberately comprehensive view.
Filtering should narrow attention temporarily, not narrow the definition of done.
Failure mode: over-filtering
A translator adds so many conditions that only a handful of segments remain.
This can be useful, but it can also remove the context required to understand why those segments were flagged.
If the queue becomes cryptic, relax the filter.
A good filtered view reduces noise without destroying the structure of the work.
Failure mode: filtering by target text when source sense differs
Suppose you search the target for one word to replace it everywhere.
That may collect unrelated source concepts that happen to share the same target word.
Before bulk editing, inspect the source side.
Segment filtering and safe find-and-replace are related but distinct. Filtering finds candidate work. It does not prove that all candidates deserve the same change.
Failure mode: filtering out confirmed segments too early
Confirmed segments can still provide context for untranslated material.
If hiding them makes pronouns, headings, lists or terminology harder to interpret, keep them visible while muting their visual emphasis instead of removing them entirely.
The fastest view is not always the sparsest view.
Filter by risk, not only status
Status filters such as translated/untranslated are useful, but risk-based filters can be more powerful.
Examples include:
- segments with negative words such as “not,” “except” and “unless”;
- segments containing numbers;
- segments with legal modal verbs;
- segments containing warnings;
- segments with low-confidence machine translation;
- segments changed after review.
A risk filter creates a targeted verification queue.
This is especially valuable when a small subset of the text carries disproportionate consequences.
Filter by change history
In iterative projects, the question is often not “what is untranslated?” but “what changed since the last trusted state?”
Use version or modification filters where available.
Review:
- newly added segments;
- source-edited segments;
- target-edited segments;
- segments reopened after approval;
- segments affected by termbase changes.
This prevents full-document re-review when only a bounded subset changed.
Segment filtering for post-editing
Machine-translated projects may contain thousands of segments with varying quality.
Instead of reading them in a single undifferentiated stream, filtering can isolate:
- empty outputs;
- outputs with untranslated source words;
- outputs containing numbers;
- terminology violations;
- segments with low quality-estimation scores where supported;
- unusually long or short target segments;
- segments with tags or placeholders.
The human reviewer can then run specialized passes.
This does not replace full semantic review when the project requires it. It makes recurring mechanical risks easier to locate.
Segment filtering for students
Students can simulate the technique without CAT software.
Use highlighting or notes to create temporary queues:
- sentences with unknown vocabulary;
- sentences with difficult grammar;
- sentences containing connectors;
- sentences already translated but not checked;
- sentences with names, dates or numbers.
Work one queue at a time.
The exercise teaches that a long passage contains different kinds of problems.
A filter audit before delivery
Before final delivery, run a filter audit.
Ask:
- Which filters did I use?
- Could any filter have hidden unresolved work?
- Are there unconfirmed segments?
- Are there comments or warnings left?
- Did changed segments receive the required review?
- Did I return to a full-project view?
- Does the visible completion state match the actual project state?
This audit is short but important.
A filter is useful precisely because it hides things.
Therefore the final workflow must deliberately unhide what matters.
Measure filter value
For a repeated project type, compare how many irrelevant segments you inspect during each pass.
If a number-verification pass requires scrolling through 2,000 ordinary prose segments to find 100 numerical ones, filtering has obvious value.
If creating the filter takes longer than checking the handful of relevant segments, skip it.
The practical equation is:
time saved by reduced scanning + reduced mode switching > time spent building and managing the filter
That is the condition under which filtering is a speed technique.
Transfer: spreadsheets, code and research
The principle extends beyond translation.
In a spreadsheet, filters isolate rows requiring one action.
In code review, searches and issue labels isolate changed or risky files.
In research, database filters narrow papers by date, method or topic.
The common mechanism is queue reduction.
You are not changing the underlying dataset.
You are changing which items demand attention now.
That is why segment filtering can make a large translation project feel smaller without pretending that the hidden work does not exist.