How People Translate Quickly | File Import Scope: Decide What Comments, Tracked Changes and Hidden Text Actually Enter the Translation Queue

A fast translation workflow can lose hours before the first sentence is translated if the wrong material enters the project. CAT tool file import settings, file parsing options, tracked changes translation, Word comments, hidden text translation, and other rules for translatable content scope decide what the translation tool sees as real work. If those settings are wrong, translators can spend time translating deleted text, reviewer notes, hidden rows, obsolete slides or technical metadata—or, worse, fail to translate content that was supposed to ship.

The primary query family is practical: how to translate tracked changes, import comments into a CAT tool, translate hidden text in Word, CAT tool DOCX filter settings, spreadsheet hidden rows translation, file import options for translation, and what content gets imported for localization. The dominant reader job is not file-format theory. It is to determine, before full production begins, which parts of a source file should become target-language segments, which parts should remain context, and which parts should stay outside the queue.

That decision belongs before translation. A CAT tool does not experience a Word, Excel or PowerPoint file the way a human reader does. The importer parses document structures and decides whether each object becomes translatable text, a protected tag, a comment, metadata, context or nothing at all. People translate quickly when they control that boundary deliberately instead of discovering the import rules halfway through the project.

Quick Read

Before translating a complex source file, define the translation scope at import.

A reliable preflight asks:

Is the deliverable supposed to represent the final accepted text, or preserve editorial history?
Should tracked insertions and deletions be accepted, rejected, preserved or translated as tracked changes?
Are comments instructions for translators, content for end users, or material to ignore?
Should hidden text, hidden rows, hidden sheets or hidden slides be translated?
Do headers, footers, text boxes, notes, alt text, captions and field results belong in scope?
Are there strings that should be visible as context but not editable as target text?
Does the importer expose a representative word count and segment sample?
Can a small test file be exported back to the native format without losing required structures?

The mechanism is simple:

native file → import filter → content classification → translation queue → export reconstruction

The import filter is therefore not a boring technical step. It is the gatekeeper for human attention.

Why Import Scope Is a Speed Problem

Imagine receiving a 120-page DOCX policy document containing tracked edits from three reviewers. Some deletions remain visible. Comments include questions such as “Legal: confirm whether this clause applies in Singapore.” Several sections are hidden because they are templates for future use. The document also contains headers, footers and text boxes.

If the project is intended to translate only the final approved reader-facing policy, importing everything can create thousands of unnecessary words. The translator may unknowingly translate deleted clauses, internal comments and hidden boilerplate.

Now reverse the mistake. Suppose the comments contain actual customer-facing tooltip text that must appear in the localized product, or the hidden text is intentionally hidden only until a user performs a certain action. Ignoring those objects can create missing translation at delivery.

Both failures originate from the same assumption: that “open the file in the CAT tool” is equivalent to “understand what the file contains.”

It is not.

The fastest translators reduce this ambiguity before production begins.

The Core Mechanism: A File Contains More Than Visible Body Text

A source file is a structured container. Human readers usually focus on the rendered page, slide or worksheet, but translation software sees document objects.

A DOCX file may contain:

ordinary paragraphs;
headings;
table cells;
headers and footers;
footnotes and endnotes;
text boxes and shapes;
hyperlinks;
comments;
tracked insertions and deletions;
hidden text;
document properties;
field results;
captions;
alt text;
content controls;
index or table-of-contents material.

An XLSX workbook can contain:

visible cells;
formulas;
comments or notes;
sheet names;
hidden rows and columns;
hidden worksheets;
chart labels;
data-validation messages;
named ranges;
embedded objects.

A PPTX presentation can contain:

slide text;
speaker notes;
hidden slides;
master-layout text;
chart labels;
alt text;
grouped objects;
comments;
embedded spreadsheet content.

A translation filter must decide what to do with these structures. Different CAT platforms use different names and defaults, but the conceptual choices recur.

Four Possible Treatments for Any Content Object

It helps to classify file content into four operational states.

1. Translate

The object becomes a normal source segment and expects a target-language equivalent.

2. Context only

The translator can see the material but it is not part of the deliverable translation. A reviewer comment, string identifier or developer note may fit here.

3. Protect or preserve structurally

The object must survive round-tripping but should not be rewritten as ordinary target text. Tags, formulas and field codes often belong here.

4. Exclude

The object is intentionally outside the project. Examples might include obsolete tracked deletions, internal notes or hidden archival worksheets—provided the client confirms they are not needed.

Thinking in these four states is more precise than asking merely, “Should I import comments?” A comment might need translation, contextual visibility or exclusion depending on its function.

Worked Example: A Contract with Tracked Changes

Suppose a legal team sends a DOCX agreement with Track Changes turned on. The file contains the original clause:

The supplier shall provide monthly reports within ten business days.

A reviewer has deleted “ten” and inserted “five”. Another reviewer has added a comment: “Confirm whether five business days is operationally feasible.”

What should the translator translate?

There is no universal answer.

If the instruction is translate the final proposed contract, the intended source may be the sentence with the change accepted: “The supplier shall provide monthly reports within five business days.” Translating the deleted “ten” wastes time and risks reintroducing obsolete meaning.

If the instruction is translate the redline so both parties can review changes bilingually, the tracked deletion and insertion may need to remain tracked in the target document. The translator now has to preserve revision history rather than flatten it.

If the comment is merely internal lawyer-to-lawyer discussion, it may be context only. If the client explicitly wants all comments translated for a multilingual negotiation team, it becomes translatable content.

The file is identical in all three cases. The required import scope is different.

That is why scope must come from the deliverable intent, not from the software default.

Step 1: Define the Deliverable State Before Opening the CAT Tool

Ask what the target file is meant to represent.

Useful descriptions are concrete:

final clean document with all source changes accepted;
bilingual redline preserving tracked additions and deletions;
translation of visible slide content only;
workbook including hidden instructional sheets;
public-facing document excluding reviewer comments;
complete localization package including alt text and accessibility labels.

Avoid vague instructions such as “translate the Word document.” That describes the container, not the content boundary.

When a client or internal stakeholder cannot articulate the expected state, create a small inventory and state your proposed assumption explicitly in the project notes. In unattended or pre-production preparation, flag the decision for approval rather than silently choosing a destructive interpretation.

Step 2: Prefer the Native Source File When Native Structure Matters

A PDF can show what a document looks like, but it often hides the structural information needed to control tracked changes, comments, hidden text, speaker notes, formulas or text boxes.

If a native DOCX, XLSX or PPTX exists, it usually offers a better foundation for translation because the importer can identify document objects rather than reconstructing them from rendered pages.

PDF remains valuable as a visual reference. For some projects it may be the only source available. But converting a complex review document to PDF before translation can erase precisely the distinctions that determine scope.

The speed lesson is not “never translate PDF.” It is “do not throw away useful structure before the translation system has classified it.”

Step 3: Decide How to Treat Tracked Changes

Tracked changes create multiple possible source states inside one document.

A robust workflow distinguishes at least these intentions:

accept changes before translation when only the final revised content matters;
reject changes before translation when the pre-edit version is the required source;
preserve/import tracked changes when revision history itself is part of the deliverable;
pause for clarification when the document contains unresolved competing edits.

Some CAT tools and file filters can import tracked changes and later reconstruct them. Others may offer simpler accept/reject behaviour. The exact capability must be checked for the chosen tool and file type.

The dangerous workflow is accidental mixing. If some changes are accepted manually, some are imported as revisions and others disappear during conversion, the translator no longer knows which source state is authoritative.

Practical check: create a three-change test

Before importing a large redline, create or identify a short sample containing:

one insertion;
one deletion;
one replacement.

Import it with the intended settings, inspect the segments and export the sample. Confirm that the target document represents the required revision state.

This ten-minute test can prevent hours of translating the wrong text history.

Step 4: Classify Comments by Function

Comments are especially dangerous because they look like language but may not be content.

A comment can be:

an instruction to the translator;
an unresolved source-author query;
a legal-review discussion;
copy that will later be surfaced to end users;
a QA note;
a note that must be translated for multilingual reviewers;
metadata that should not leave the internal team.

Do not assume comments are always excluded or always translatable.

A useful classification is:

instruction → context end-user copy → translate internal obsolete discussion → exclude multilingual review discussion → translate or preserve according to the brief

If the CAT tool can import comments as annotations rather than segments, that is often ideal for translator instructions because the information remains visible without inflating the translation queue.

Step 5: Decide What Hidden Text Means in This File

Hidden content is not necessarily irrelevant content.

In Word, hidden text may represent template guidance, conditional passages, author notes or content revealed under certain publishing conditions. In Excel, hidden rows and sheets can contain lookup labels, instructions, archival data or strings that a software process later exposes. In PowerPoint, a hidden slide may simply be omitted from the current presentation—or may be an appendix that still needs localization.

The word hidden describes display state, not business importance.

Ask why the material is hidden.

If it is hidden because it is obsolete, exclusion may be correct. If it is hidden because it is conditionally displayed, localization may still be required. If nobody knows, flag it rather than guessing.

Step 6: Check Headers, Footers and Repeating Objects

Repeated document furniture is easy to overlook because human readers stop noticing it.

Headers and footers can contain:

confidentiality labels;
document titles;
department names;
revision status;
copyright statements;
customer-service information;
page labels.

A filter may import them once, repeatedly or not at all depending on structure and settings. Confirm how repetition is handled so the translator does not waste time translating the same footer dozens of times or accidentally omit it.

The same check applies to PowerPoint master text and repeated worksheet labels.

Step 7: Inspect Text Boxes, Shapes, Alt Text and Accessibility Content

Text outside the main paragraph stream is a frequent source of “the translation is finished, but the file is not localized” failures.

Text boxes may contain callouts or important warnings. Shape labels may be part of diagrams. Image alt text may be required for accessibility. Chart labels may communicate actual data meaning.

For each object type, decide whether the project requires:

translation;
preservation only;
contextual visibility;
exclusion.

Accessibility text deserves particular care. It may be invisible in the normal page view but essential to screen-reader users. A visual preflight alone will not always reveal it.

Step 8: Treat Spreadsheet Scope as a Separate Inspection Problem

Spreadsheets combine language with executable structure.

The translator may see a visible table, but the workbook can contain hidden columns, helper sheets, formulas and validation messages. A CAT tool’s spreadsheet filter may expose options for sheet names, comments, hidden rows or hidden sheets.

Before translating, inventory:

visible sheets;
hidden sheets;
visible text cells;
formulas with literal text;
comments/notes;
worksheet names;
hidden rows and columns;
charts and labels;
validation messages;
protected or locked regions.

Do not translate formulas as prose. Do not assume a hidden sheet is irrelevant. Do not assume every text-bearing cell is customer-facing.

The project brief should decide what the translated workbook must do, not merely what it must look like.

Worked Example: A Product-Configuration Workbook

Imagine an XLSX file with five worksheets.

Overview is visible and customer-facing.
Options is visible and contains product labels.
Lookup is hidden and contains English values used in dropdowns.
Internal QA is hidden and contains tester notes.
Archive 2024 is hidden and obsolete.

A naive visible-only import translates Overview and Options but leaves dropdown labels in English because they come from Lookup. The delivered workbook looks partly translated when users interact with it.

A naive all-hidden-content import translates all five sheets, including hundreds of irrelevant tester notes and obsolete archive rows.

The correct scope is more selective: translate the visible customer sheets and the hidden lookup labels that feed the interface; exclude internal QA and archived material unless the client requests them.

This is what scope control means: not “more content” or “less content,” but the correct content.

Step 9: Inspect Slide Notes and Hidden Slides in Presentations

Presentation files add a distinction between what the audience sees and what the presenter needs.

Speaker notes may be:

essential scripts for presenters;
internal production instructions;
source citations;
reminders that should not be translated;
full narration text that absolutely must be translated.

Hidden slides may contain backup material used during questions. Master slides may contain recurring labels. Charts can include labels that are stored in embedded workbooks.

A presentation-localization brief should therefore say whether the deliverable includes slide text only, slide text plus notes, or the complete deck including hidden slides and accessibility elements.

Step 10: Compare Import Word Count with a Content Inventory

Word count is not truth, but it is an excellent anomaly detector.

Before translation begins, compare the CAT-tool analysis with a rough expectation from the source. If a 50-page report imports only 800 words, something may be missing. If a simple 20-page document imports 30,000 words, hidden or duplicated content may have entered the queue.

Do not expect counts from Word, a CAT tool and another platform to match exactly. Segmentation, fields, repeated content and counting rules differ. Use the comparison to trigger inspection, not to demand numerical identity.

Useful questions include:

Why is the imported volume much larger than visible body text?
Did comments become translatable segments?
Were deleted tracked changes imported?
Did headers repeat on every page?
Were hidden sheets included?
Are text boxes missing?

An unexplained word-count jump is often cheaper to investigate before translation than after invoicing, review or delivery.

Step 11: Inspect a Segment Sample from Every Content Zone

Do not inspect only the first ten segments. The first page may contain ordinary body text while all the difficult structures appear later.

Choose samples from:

body paragraphs;
tables;
comments;
tracked changes;
headers and footers;
text boxes;
hidden content;
spreadsheet sheets;
speaker notes;
alt text if included.

The sample should prove that every required content class enters the project with the intended treatment.

Step 12: Run a Small Round-Trip Test

After confirming import scope, export a short test file.

This step connects to the separate “Round-Trip File Tests” article in this series, which focuses on the export-validation mechanism in depth. Here the purpose is narrower: verify that your scope choices survive reconstruction.

Check whether:

tracked changes remain tracked when required;
excluded comments stay excluded;
translated comments remain comments if required;
hidden content retains the intended state;
formulas still function;
slide notes remain notes;
document structure is intact.

A correct import that cannot be exported correctly is not a production-ready workflow.

Failure Mode: Translating Reviewer Comments as if They Were Public Copy

This can waste substantial time and create confidentiality risk.

Internal comments may contain names, negotiations, unresolved legal discussion or blunt editorial language never intended for readers. If the importer turns them into ordinary target segments, translators may assume they belong in the deliverable.

The practical defense is to classify comments before import and inspect how the tool represents them.

Failure Mode: Dropping Comments That Were Supposed to Help the Translator

The opposite failure also occurs.

A developer may attach a comment explaining that “Home” means a dashboard tab, not a physical residence. If comments are stripped entirely, the translator loses context and may choose the wrong target.

Context can speed translation even when it is not translatable content.

Failure Mode: Translating Deleted Text

Tracked deletions are historical evidence, not necessarily current source.

If a contract contains a deleted paragraph of 500 words and the project requires only the clean final version, translating that paragraph creates pure waste. Worse, a reviewer may later mistake its translation for live contractual text.

Confirm the revision state before analysis and pricing.

Failure Mode: Accepting Changes That Needed to Remain Visible

A team receives a redline for bilingual negotiation, accepts all changes to simplify import, and only later learns that the target document was supposed to show exactly what changed.

The translated wording may be accurate, yet the deliverable has lost its legal or editorial function.

Translation quality includes document function, not just sentence accuracy.

Failure Mode: Ignoring Hidden Content Because Nobody Can See It

Hidden content can still become visible through software behaviour, filtering, publishing conditions or later editing.

The right question is not “Can I see this now?” It is “Can an intended user or process expose this later?”

If yes, localization may still be required.

Failure Mode: Translating Hidden Internal Data Because It Exists

Inclusion can be as harmful as omission. A workbook may contain internal QA notes, archived product names or staff-only comments that should never enter a customer-facing localization process.

Import scope is a permissions and purpose decision as much as a technical one.

Failure Mode: Converting to PDF Too Early

Teams sometimes create a PDF “to make the file easier” before translation. This can flatten comments, tracked changes, text boxes, form fields and other native structures into rendered appearance—or make them disappear entirely.

If structure matters, keep the native file through the parsing stage and use PDF as visual reference when useful.

Failure Mode: Translating Field Codes or Technical Tokens

Documents contain machine-readable elements that can look like text.

Field codes, formulas, placeholders, XML-like tags, references and identifiers may need to remain untouched even while their displayed results are translated. A good CAT filter normally protects much of this structure, but custom files and conversions can expose dangerous tokens.

If changing a string could break the document, determine whether it should be protected before translators see it as editable prose.

Failure Mode: Changing Import Rules Halfway Through Production

Suppose a project starts with comments excluded. Halfway through, someone decides comments must be translated and reimports the file with a different filter. Segment IDs, counts and synchronization can change. Completed work may become difficult to reconcile.

This is why import scope belongs in preflight. Late scope changes are sometimes unavoidable, but they should be treated as controlled project changes rather than silent settings edits.

Failure Mode: Assuming the Default Filter Is the Correct Filter

Defaults are designed to be generally useful, not to understand your client’s intent.

A default may ignore comments because most projects do not translate them. Another tool may import them. Hidden worksheet behaviour may differ. Track-change handling may depend on a checkbox or file-filter version.

Read the relevant current documentation and test a sample. “The software usually does X” is not enough for a complex deliverable.

A Practical File-Scope Preflight Checklist

Before the first full import, record the following.

Deliverable

What should the final file represent: clean final, redline, complete multilingual review package, visible content only, or another explicit state?

Revision history

Should tracked additions and deletions be accepted, rejected, preserved or translated as revisions?

Comments

Are they target content, translator context, internal notes or excluded material?

Hidden content

Which hidden text, rows, columns, sheets or slides can later become user-visible?

Repeating structures

Are headers, footers, master objects and repeated labels imported once and reused appropriately?

Non-body objects

Are text boxes, charts, alt text, captions, notes and accessibility labels in the correct scope?

Protected structure

Are formulas, fields, identifiers, tags and placeholders protected from accidental translation?

Analysis

Does the imported word count roughly agree with the expected content inventory?

Sample

Have representative segments from every object class been inspected?

Export

Has a small round-trip proved that the selected scope can be reconstructed in the required native format?

If these ten areas are understood, the translator begins with a queue that reflects the actual job.

Worked Example: Training Manual with Internal Author Notes

A company translates a training manual in Word. Visible text is 18,000 words. The file also contains 4,000 words of comments from instructional designers, including suggestions for future versions.

The first import includes comments as translatable text, producing a 22,000-word analysis. Because the translator assumes the analysis represents approved scope, they begin translating comments too.

A preflight would have revealed that the comments are internal design discussion. They should remain available to the localization manager as reference but should not become target segments.

Removing them from the translatable queue saves approximately 18% of the apparent word volume—not by translating faster, but by refusing to manufacture unnecessary translation work.

Worked Example: Accessibility Text in a Public Report

A public report contains polished visible copy and dozens of charts. The visual labels are translated, but image alt text is not imported by the selected filter configuration.

Sighted reviewers sign off because the file looks complete. Screen-reader users later encounter English descriptions inside an otherwise translated document.

The failure is not linguistic skill. It is an import-scope omission.

This example is why “invisible” must never be equated automatically with “unimportant.”

Worked Example: PowerPoint with Speaker Notes

A sales deck has 60 slides but only 2,500 visible words. Every slide also contains detailed speaker notes used by regional presenters. The localization request says “translate the deck for our sales teams.”

If the workflow imports slide text only, the visible deck is localized while the presenter script remains in the source language. If it imports all notes automatically, however, it may also translate internal production comments mixed into the notes.

A short content inventory reveals two note types. Presenter script should be translated. Production notes beginning with a standardized marker such as [INTERNAL] should be excluded or separated before translation.

The right solution comes from understanding the objects, not from picking “include notes” or “exclude notes” blindly.

Save Proven Import Decisions for Repeated Work

Once a complex recurring file type has been tested, the import decisions can be captured in the project setup.

For example:

DOCX policy template: accept tracked changes, import translator comments as context, include headers/footers and alt text, exclude hidden template guidance;
XLSX product workbook: include visible sheets plus Lookup, exclude Internal QA, preserve formulas;
PPTX training deck: translate slides and speaker script, exclude production-note markers.

This can then feed a project template, but the concepts should remain separate. A project template reuses a known configuration. File import scope determines whether that configuration represents the correct content boundary in the first place.

Reusing a bad scope decision faster is not an improvement.

Transfer: Import Scope Is Really an Information-Boundary Problem

The deeper lesson applies beyond translation.

Whenever software ingests a complex document, it must decide which parts count as data, instructions, metadata, context or noise. Search indexes decide what to crawl. AI systems decide what goes into a prompt. Data pipelines decide which fields enter a model. Publishing systems decide which metadata reaches readers.

Translation import is one instance of the same boundary problem.

People work quickly when the boundary is explicit because they do not repeatedly ask, “Does this belong here?” The decision has already been made at the system edge.

Practical Check: Ask “Who Will See This Object?”

When unsure whether a file object belongs in the translation queue, ask three questions.

Who can see it now? An end user, editor, lawyer, developer, presenter, nobody by default?

Who might see it later? Could a hidden sheet feed a dropdown? Could a hidden slide be unhidden? Could alt text be read aloud? Could comments be delivered to a multilingual reviewer?

What happens if it stays untranslated? Nothing? Minor inconsistency? Broken functionality? Accessibility failure? Legal confusion? Internal embarrassment?

These questions turn a technical checkbox into a reader-and-function decision.

Build a One-Page Scope Matrix for Complex Jobs

When a project contains several document object types, verbal instructions become difficult to remember. A one-page scope matrix is faster because it turns each object class into an explicit decision.

A simple matrix can use four columns: object type, treatment, reason, and verification. For a DOCX legal project it might say: body text — translate — reader-facing agreement — inspect normal segments; tracked insertions/deletions — preserve as revisions — bilingual redline required — export sample; comments — context only — internal lawyer instructions — confirm comments remain attached but untranslated; headers/footers — translate — part of delivered document — inspect first and last pages; hidden template text — exclude — not part of current contract — compare source inventory.

For an XLSX localization project, the same matrix might specify visible labels, hidden lookup sheets, comments, sheet names, formulas and validation messages separately. The matrix prevents the team from hiding ten different decisions inside one vague phrase such as “translate the workbook.”

It also improves handoff. A project manager can review the scope without understanding every CAT-tool checkbox. A translator can see why a content type is absent from the queue. A reviewer can distinguish an intentional exclusion from a missed string. If a client changes one decision, the team can identify exactly which import rule must change.

The matrix should remain small. Its purpose is not to document the entire file format. Include only object types that could materially affect scope or delivery.

Reconcile Scope with Pricing and Scheduling Before Translation Starts

Import scope affects more than linguistic workflow. It changes volume, deadline, reviewer effort and sometimes confidentiality exposure.

Suppose a project was quoted on 15,000 visible words, but importing comments and hidden sheets produces 24,000 translatable words. There are only three sensible possibilities: the additional content is genuinely required and the project scope changes; it is not required and should be excluded; or nobody yet knows and the job should not silently proceed on an assumption.

A translator who begins first and asks later can create awkward disputes. The client may say the comments were never meant to be translated. The translator may have spent hours on them. Conversely, excluding required hidden content to keep the quoted volume low can produce an incomplete deliverable.

For recurring clients, recording import-scope assumptions alongside quotations and project templates makes future jobs much faster. The team can say, for example, “Our standard DOCX policy scope includes body text, tables, headers, footers and accessibility text; reviewer comments are context only; tracked changes must be resolved before import unless a redline is requested.” New projects then need only identify exceptions.

This is another reason to treat import scope as an editorial and operational decision, not merely a software preference. The parsing settings determine what humans are being asked to translate, what the client is paying for and what the final file promises to contain.

Recheck Scope When the Source File Changes

A validated filter does not guarantee that every later source file has the same structure.

A client may send version two of a document with new comments, newly hidden sheets, inserted text boxes or a different tracked-change state. If the translator simply updates the project and assumes the old scope is still valid, the new object types can slip through unnoticed.

For major revisions, rerun three quick checks: compare file structure, compare import volume and sample any newly introduced object types. Version diffing can tell you what wording changed; file-scope inspection tells you whether the kind of content changed.

This distinction matters. A new 300-word appendix inside ordinary body text is a content revision. A new worksheet that was hidden and feeds customer-facing dropdowns is a scope-structure change. Both add work, but they enter the workflow through different mechanisms.

Fast teams learn to recognize structural change early so they do not discover it during final QA.

Summary

Complex source files contain more language than the visible body text. CAT tool file import settings, tracked changes translation, Word comments, hidden text, spreadsheet hidden content, speaker notes, headers, footers, alt text and other file structures determine what enters the human translation queue.

The fastest workflow does not import everything and hope the translator sorts it out. It defines the intended deliverable state, classifies content objects as translate/context/protect/exclude, configures the filter, checks a representative segment sample, compares analysis volume with expectation and performs a small native-file round trip before production.

The central rule is:

translate the content the deliverable needs—not every string the file happens to contain, and not merely every string that happens to be visible.

When the import boundary is correct, the translation queue becomes smaller, clearer and safer. Human attention is spent on language that actually matters.

Frequently Asked Questions

What are CAT tool file import settings?

They are the options that control how a translation tool parses a source file and decides which objects become translatable segments, context, protected structures or excluded material.

Should tracked changes be accepted before translation?

Only if the deliverable requires the final accepted source state. If the target must preserve a redline or revision history, accepting all changes first may destroy required information.

Can CAT tools translate tracked changes?

Some current CAT tools and document filters support importing or preserving tracked changes in DOCX workflows. Capabilities and settings vary, so test the exact tool and export path before production.

Should Word comments be translated?

It depends on their function. Translator instructions may be context only; internal discussion may be excluded; comments intended for multilingual reviewers may need translation. Classify them before import.

Should hidden text be translated?

Not automatically. Determine why it is hidden and whether an intended user or process can expose it later. Hidden conditional content may need translation; obsolete internal material may not.

What about hidden rows and worksheets in Excel?

Treat them individually. Hidden worksheets may feed visible dropdowns or interfaces, or they may contain internal/archive material. Visibility alone does not determine scope.

Should speaker notes in PowerPoint be translated?

If presenters rely on them, often yes. If they are internal production notes, perhaps not. The project brief should distinguish note functions.

Why compare word count after import?

A surprising count can reveal missing or accidentally included content. It is an anomaly check rather than a demand for exact agreement between applications.

Is this the same as a round-trip file test?

No. Import scope decides what enters the translation queue. A round-trip test verifies that the translated structure can be exported correctly. They are related but separate controls.

Can I save these choices in a project template?

Yes, once they have been validated for a recurring file type and workflow. Reusable settings are useful only when the underlying content-scope decision remains appropriate.

Internal-Link Opportunities

This article can link naturally to eduKateSG articles on source cleanup, project templates, round-trip file tests, spreadsheet safeguards, placeholder protection, segment filtering, QA profiles, version diffing, string context packs and in-context preview.

Useful relationships include:

source cleanup → repairing OCR, broken line breaks and segmentation after deciding what content belongs in scope;
project templates → reusing validated import settings for recurring work;
round-trip file tests → proving export integrity after the import boundary is configured;
spreadsheet safeguards → protecting formulas, IDs and workbook structure during translation;
placeholder protection → keeping machine-readable tokens intact inside imported segments;
segment filtering → isolating selected kinds of imported work after parsing;
in-context preview → checking how translated content behaves in the reconstructed interface or document.