A document gets approved, exported, and sent to a translator, only for the first question to be: “Which of these edits is the final wording?” That small handoff problem can turn into a round of emails, a missed change, or translation work on a version your team has already replaced.
File prep for translation means getting the source content, structure, and context ready before a translator starts work. The aim isn’t to make every file look perfect. The aim is to make the source unambiguous, editable where possible, and easy to understand without a private tour of your project.
What file preparation for translation means¶
Translation file preparation is the process of cleaning, organizing, and contextualizing source files before they go to a translator. A prepared file tells the translator what to translate, which version is authoritative, how the content is structured, and what choices need to stay consistent.
A translator needs more than words. A heading’s role, a table’s layout, a button’s function, and a note about the intended reader can all change how the words should be translated. A file that hides this information may still be technically readable, but it makes the translator guess.
Preparation covers four connected areas:
- Source quality: The text is complete, approved, and free of avoidable spelling errors or ambiguity.
- File structure: Headings, lists, tables, fields, and other elements are marked in a way that makes their relationships clear.
- Project context: The translator knows the audience, purpose, tone, terminology, and relevant constraints.
- Handoff control: The team identifies the final source version and explains how later changes will be handled.
These areas apply to different kinds of content, but the details vary. A Word manual needs clear heading styles and clean revision history. A software resource file needs complete strings, placeholder explanations, and notes on where each string appears. A scanned paper document may need to be made editable before a translator can work with its text.
Microsoft’s documentation localization guidance recommends structured authoring and explains why source structure matters when content is localized. For Word, the basic idea is practical: use styles for headings and recurring elements instead of recreating their appearance by hand.
Microsoft Learn puts it plainly: “At a bare minimum, this means using styles in a Word document instead of formatting everything manually.” (Source)
Styles help distinguish a heading from an ordinary paragraph even when both use similar visual formatting. That structure can make files easier to edit, navigate, and process. Manual bolding or changing font size may make a line look like a heading to a person, but the document may not carry the same clear structural signal.
Preparation doesn’t mean rewriting every source sentence. It means resolving the issues that would force the translator to infer what your team already knows. A short note can answer a question that otherwise leads to a delay: “This is a menu label,” “the user is speaking,” or “the number in brackets is a product code and must not change.”
How to prepare files in practice¶
A reliable handoff starts with a source file the team can stand behind, then adds the context and reference materials needed to interpret it. The sequence below works for Word documents, technical documentation, marketing copy, and many localization projects.
1. Choose the authoritative source¶
Start by identifying the file that represents the approved content. Teams often have a working draft, a version with comments, a file exported for review, and a later version with a slightly different name. A translator shouldn’t have to decide which one is final.
Use a clear filename or project record to identify the source version. If your team uses version control or a document management system, follow that process and tell the translator which file or revision to use. Keep the source itself available so questions can be checked against the approved wording.
The handoff note should also say whether the source is complete. If a section is still being written, label it clearly rather than presenting it as finished content. If a heading or table will change, tell the translator what is still open and whether work should pause on that part.
2. Resolve tracked changes and comments¶
Tracked changes show proposed edits to a document. Before sending a Word file, decide which edits belong in the final text. Accept the changes the team has approved and reject those that should not appear in the source.
Microsoft Support explains that choosing No Markup only hides tracked changes temporarily; revisions become visible again when someone reopens the document (Microsoft Support). Hiding marks is not the same as removing them. A translator who sees the underlying revisions may not know whether to translate the original wording, the proposed wording, or both.
Review comments as well. Remove internal discussion that doesn’t help the translation, but retain a comment if it contains useful meaning or context. If a comment says “shorten this for the app button,” the translator needs to know whether the shortened wording is approved. Move essential instructions into a clear brief or contextual note instead of relying on a comment thread whose status is unclear.
Microsoft recommends using Document Inspector as a final check for items such as tracked changes, comments, hidden text, and personal names in document properties before sharing a Word file (Microsoft Support). The check can help find information that isn’t obvious in the main document view.
3. Check the source text¶
Run spelling and grammar checks before handoff. Fix errors that could change the meaning or create unnecessary questions. Microsoft specifically advises checking spelling and grammar before sending strings to translators in its contextual metadata guidance.
Read for ambiguity too. A word such as “light” can refer to brightness, weight, or a color shade. A compressed phrase such as “account access request” may leave the relationship between the words unclear. Expand or rewrite phrases when the intended meaning isn’t obvious from the surrounding content.
Look for language that depends on context you haven’t shared. “Click here,” “the old version,” and “it will be available soon” may make sense inside your team but not in a file sent on its own. Replace vague references with the name of the relevant feature or add a note explaining the reference.
Consistency also matters. If a product feature has a preferred name, use it consistently in the source and add the approved term to a glossary. If a term is intentionally used in two different senses, mark the distinction. The translator shouldn’t have to guess whether two similar labels refer to the same thing.
4. Preserve document structure¶
Use Word styles for headings and recurring elements. Keep lists as lists, tables as tables, and headings in a hierarchy that reflects the document’s organization. Avoid building structure with repeated spaces, tabs, or manual line breaks when a proper document element can do the job.
A well-structured source is easier to read and update. It also gives a translator more information about how a passage functions. A heading marks a section; a list groups related instructions; a table connects items across rows and columns. Flattening those elements into unstructured text can obscure the relationship between the parts.
Check for content that is present but not visible in the ordinary reading view. Hidden text, comments, text in shapes, and content in headers or footers can be missed when someone reviews only the main body. Decide whether each item should be translated, removed, or retained as non-translatable content, then explain any unusual cases.
For print materials, don’t assume the source page layout will transfer unchanged. Microsoft’s localization guidance notes that localized printed documentation may need a new layout for the target market. Text expansion, language-specific line breaks, and different paper-size conventions can all affect page design.
A file can be grammatically clean and still be difficult to localize if its structure is fragile. A table made from aligned spaces, for example, can fall apart when words change length. Use actual tables and label complex figures or images with notes that identify their purpose.
5. Build a translation brief¶
A translation brief is a short set of instructions that explains the project to the translator. It should answer the questions the source file can’t answer on its own:
- Who will read the translated content?
- What should the content help that reader do?
- Where will the translation appear?
- What tone should it use?
- Which product names, technical terms, and phrases have approved translations?
- Are there character limits, formatting rules, or content that must remain unchanged?
- Who should answer questions about meaning or source changes?
A useful brief is specific, not long for its own sake. “Use a friendly tone” is a start, but “write for new customers using the mobile app; use direct instructions and keep button labels short” gives the translator a clearer target.
Send reference materials that support those instructions. Useful items can include a glossary, style guide, previous approved translations, product screenshots, diagrams, and relevant background documents. Don’t send a large folder without explaining which files matter. A translator can use references more effectively when you identify the authoritative one and say what it is for.
Context notes should clarify the source, not substitute for it. Microsoft’s contextual metadata guidance makes this distinction: metadata can explain how a string is used or what a placeholder means, but it can’t repair unclear source text by itself.
6. Make the handoff easy to verify¶
Send the source file, the brief, and the references together or point to a clearly organized location. Name the files so their roles are obvious, for example, “source,” “glossary,” and “screenshots.” Tell the translator which material is final and which items are background only.
Record the target language and intended locale if the project distinguishes between language variants. Explain any special handling for dates, units, product names, codes, or content that must remain unchanged. If the translation will be checked in a layout or product interface, say how that review will happen.
Keep a record of the handoff. A simple project note can capture the source filename, version, delivery date, and any open questions. The point isn’t to build paperwork for its own sake. The record gives your team a way to identify what was translated if the source changes later.
Prepare Word files, software strings, and scans differently¶
The general rules are shared, but a single checklist won’t cover every file type. The source format affects what the translator can see and what information needs to travel with the text.
Word documents¶
For a Word document, work from the editable source when you have one. Resolve tracked changes, review comments, inspect hidden content, and use Word styles for headings and recurring structures. Keep tables, lists, and captions in their intended format.
Don’t treat a PDF and a Word file as interchangeable just because they look alike on screen. A Word file can contain paragraphs, styles, and table cells that preserve relationships between elements. A PDF may present text as positioned items on a page. If the translator needs to edit or format the result, an editable source can make the task clearer.
If a PDF is the only available file, tell the translator whether it contains selectable text or scanned pages. A scanned PDF is an image of the page, not ordinary editable text. The text must be recognized or transcribed before it can be translated, and marks such as stamps or handwritten notes may need separate attention. For more detail, see how to translate an image PDF and how to convert a scanned PDF to editable Word.
Software strings¶
A software string is a piece of text shown in an interface, such as a button label, notification, or error message. A string’s location and function can determine its translation, so send context with the text rather than a list of isolated phrases.
Microsoft recommends comments that explain where and how a string appears, its use, and the conditions under which it appears. A note can identify a word as a noun or verb, explain whether a message appears after a failed action, or specify a character restriction. Those details help the translator choose wording that fits the interface.
Explain every placeholder. A placeholder is a variable that the software replaces with a value, such as a person’s name, count, or date. A variable called {count} may not tell the translator whether it represents files, messages, or users. Add a plain-language explanation and an example value, and use descriptive names where the format allows them.
Give translators as much control over placeholder order as the system supports. Different languages may require a different word order, so a fixed sequence can make a sentence sound unnatural or become grammatically incorrect. Microsoft’s message formatting guidance explains why translators may need to reorder placeholders and why named placeholders provide more context than generic positional ones.
Avoid constructing a sentence from separate fragments. For example, a system that combines “You have,” a number, and “new messages” may not give a translator enough freedom to create a natural sentence. Microsoft advises writing complete strings instead of concatenating fragments in most cases (message formatting guidance). If a platform requires fragments, provide context and note how they are assembled.
Strings that look identical may also appear in different situations. A label on a button and a heading in a report can need different translations even if the source wording matches. Give each instance enough context to identify its role instead of assuming one translation will fit everywhere.
For practical review of tags and structure in localization files, see how CAT tool file filters preserve tags and structure.
Scans and images¶
A scan or photo needs a different kind of preparation because the page is an image rather than editable text. Check that the text is legible and that the full page is visible. Keep seals, signatures, tables, and handwritten notes in the image if the translator needs to understand their relationship to the printed text.
Tell the translator whether text inside images should be translated, recreated, or left in the original language. Product screenshots may need to be recreated so the localized product is shown, a scheduling consideration noted in Microsoft’s documentation localization guidance.
For a poor-quality scan, identify uncertain areas rather than asking the translator to silently infer missing text. A cropped edge, faint stamp, or blurred date can change the reading. If you can provide a clearer scan or an editable original, include it and explain which version takes priority. This guide to fixing a poor-quality scan before translation covers the source-quality problem in more detail.
When preparation matters most, and when it can stay light¶
The amount of preparation should match the risk and complexity of the content. A short, straightforward message may need only an approved source and a note about audience. A manual, legal document, product interface, or multi-file release usually needs more context because a small inconsistency can spread across the deliverable.
Preparation matters most when the source is changing, when several files share terminology, or when the translation will be published in a designed or interactive format. It also matters when content contains placeholders, labels, screenshots, diagrams, or hidden text. In each case, the translator needs information that isn’t safely recoverable from the words alone.
A translation memory is a database of previously translated segments that can help teams reuse approved translations. Microsoft notes that CAT tools and translation memories can help keep localized content in sync with source revisions (localize documentation). A stable source and clear version record make that alignment easier.
Some tasks don’t need a full brief or a large reference pack. A one-off sentence with no special terminology can be sent with a short note about where it will appear. If the text is self-contained and the audience is obvious, a long explanation may add friction instead of helping.
The useful test is whether a translator would need to guess. If the answer is no, keep the handoff simple. If the answer is yes, add the missing source detail or context before sending the file.
What changes across languages and markets?¶
Translation isn’t just a word replacement exercise. Layout, text order, indexing, line breaks, and print specifications can vary across languages and markets. Microsoft’s localization guidance notes that indexing and sorting conventions differ among languages, and that line- and word-breaking conventions differ in languages including Chinese, Japanese, Korean, and Thai (Microsoft Learn).
Those differences matter when a file includes an index, a tightly constrained interface, or line breaks placed by hand. Don’t force a translator to preserve a source line break if the target language needs a different arrangement. Tell the team which elements are flexible and which must fit a product or print constraint.
Printed materials may need layout work for the target market. Microsoft contrasts ISO 216 paper sizes used in most of the world with inch-based US sizes such as Letter and Legal in its documentation localization guidance (Microsoft Learn). Confirm the target-market specifications for the deliverable instead of treating the source page size as universal.
Screenshots need similar planning. A screenshot of an untranslated product can still help explain where a phrase appears, but it won’t necessarily be suitable for the localized publication. Decide whether the screenshot is reference material for the translator or a final asset that needs to be recreated.
Common file-preparation mistakes¶
Most handoff problems don’t come from obscure technical failures. They come from small gaps between what the sender knows and what the translator can see.
Sending a draft as if it were final¶
A file with unresolved edits makes the translator choose between competing versions. If the source is still changing, state that clearly and identify the portions that are ready. Microsoft notes that revisions made after a completed translation can increase costs because even a one-word change may require reworking the sentence for naturalness (localize documentation).
That doesn’t mean every source change requires redoing an entire translation. The effect depends on the change and the workflow. The important point is to track revisions and tell the translator what changed, rather than sending a new file with no explanation.
Hiding revisions instead of resolving them¶
No Markup is a display setting, not a cleanup step. Microsoft Support says hidden changes can appear again when the document is reopened (accept or reject tracked changes). Accept or reject each revision that affects the source, then run a final check for comments and hidden content.
Sending isolated strings without context¶
A list of short labels may look easy to translate, but it can hide important distinctions. Is “Open” a command, an adjective, or a status? Does “Save” appear on a button or in a sentence? Notes about location, function, and conditions can answer those questions. Microsoft’s contextual metadata guidance recommends comments that explain how and where strings appear.
Splitting sentences into fragments¶
Concatenation means joining separate text fragments in software to form a sentence. The source language may allow a particular order or punctuation pattern that doesn’t work in the target language. Microsoft warns that fragments can deprive translators of context and that sentence order, punctuation, spacing, and pluralization may differ (concatenation guidance).
Write complete strings when possible. If the software structure makes that difficult, share the assembled sentence or a screenshot and explain how the fragments appear together.
Microsoft Learn says: “With a few exceptions, memory isn’t the primary consideration when authoring resources. Best practice is to never concatenate strings.” (Source)
The practical takeaway is to design the source string for translation rather than expecting the translator to reconstruct a sentence from disconnected pieces. If a product has to keep fragments, the translator needs the assembly rules and a way to handle target-language word order.
Leaving placeholders unexplained¶
A variable name isn’t a definition. A placeholder such as {value} could represent a price, quantity, date, or user-entered phrase. Explain what it contains and give an example value. Add any restrictions that affect the translation, such as maximum length or characters that the system won’t accept.
Treating a layout as a universal template¶
A source page layout may not suit the target language or market. Text can occupy a different amount of space, and line-breaking conventions can change. A layout that depends on manual spaces or fixed line breaks is especially vulnerable. Build the source from real document structures and plan for a layout review where the final design matters.
Forgetting the next source revision¶
A translation can become outdated when the source changes after handoff. Keep track of the source version and share later changes in a way that lets the translator identify affected content. CAT tools and translation memories can support synchronization between source revisions and localized content, as Microsoft notes in its localization guidance.
A clean process doesn’t prevent all changes. It makes them visible, traceable, and easier to assess.
Microsoft Support warns: “Choosing the No Markup view only temporarily hides changes. They will be visible again the next time someone opens the document.” (Source)
That warning captures a frequent handoff trap: the document may look clean on one person’s screen while still carrying unresolved edits. Check the actual file, not only its current display.
FAQ¶
How should I prepare a Word document before sending it to a translator?¶
Choose the approved source version, accept or reject tracked changes, remove irrelevant comments and hidden text, and run a spelling and grammar check. Use Word styles for headings and recurring elements so the document’s structure is clear.
Should I accept tracked changes before sending a file for translation?¶
Accept changes that belong in the final source and reject changes that don’t. No Markup only hides revisions temporarily; it doesn’t remove them from the Word document, as Microsoft Support explains.
What reference materials should I send with translation files?¶
Send a brief that explains the audience, purpose, tone, and relevant constraints. Add a glossary, style guide, previous approved translations, and screenshots or diagrams when they clarify meaning or use.
How do I prepare software strings and placeholders for translation?¶
Provide complete strings rather than concatenated fragments, use named placeholders where possible, and explain what each variable represents with an example. Add context about where the string appears, what it does, and any character or length restrictions.
Why should translators receive the final source file and contextual notes?¶
A final source prevents translators from working on outdated wording, while contextual notes explain meaning and use that the text alone may not reveal. Microsoft says context metadata can guide translators when a string’s use or a placeholder’s meaning is unclear, but it doesn’t replace clear source text (Microsoft Learn).