Formatting QA Checklist for Translated Files Before Delivery

A translated contract can read perfectly and still arrive with a table split across pages, a comment hidden in the margin, or a date that looks wrong to the recipient. Formatting QA catches those delivery problems before someone else has to report them.

Formatting QA is the final review of how a translated file looks, behaves, and communicates information. It isn’t a second translation from scratch. It’s a structured check that the target file preserves the source’s intended organization while using language-specific formats and remaining usable for its audience.

A practical review separates four questions:

• Does the translated content still say what the source says?
• Does the page structure still make sense?
• Are formatting and review marks ready for the recipient?
• Can people use the document, including people who rely on assistive technology?

The checks below work for DOCX and PDF deliveries. A PDF may need a different editing route than a Word document, but the reviewer still needs to inspect the visible result, compare important content, and confirm that the final version is the one being delivered.

What formatting QA checks, and why the file can break¶

Formatting QA checks whether a translated document remains readable and functional after text changes. The review covers more than fonts: headings, tables, lists, page breaks, dates, links, comments, and accessibility all affect how people use the file.

Translation changes the length and shape of text. A short source heading may become a longer target heading; a label may wrap onto another line; a table cell may no longer fit its contents. A document can therefore have accurate words and a damaged layout at the same time.

The way the file stores content matters, too. Word documents use paragraphs and other structured elements. A PDF doesn’t store paragraphs or tables in the same way: its text is placed at coordinates on a page. A translated PDF workflow that extracts text without preserving its positions can lose relationships between labels, values, and table cells. That mechanism explains why a text comparison alone won’t catch every layout fault.

A useful starting point is to understand the difference between three kinds of review:

These reviews overlap, but they aren’t interchangeable. A source-to-target comparison can confirm that a number appears in both versions, while a visual check catches that the number has shifted into the wrong row. A formatting review can spot a broken link, while a language reviewer confirms that the visible link label describes the destination.

Start by keeping the source and target files open side by side. Use the same page or section in each as a reference, and note meaningful differences instead of trying to make every page look identical. The translated language may take more or less space. The goal is to preserve the document’s purpose and hierarchy, not to force the target into the source’s exact line breaks.

Microsoft Support says, “Screen readers keep track of their location in a table by counting table cells.” (Microsoft’s accessibility guidance for Word)

The cell structure matters because a table isn’t just a visual grid. People using a screen reader need a logical relationship between a cell and its heading. A table that looks tidy but has confusing structure can still be difficult to understand.

For a deeper look at table-specific issues, see how to preserve tables when translating DOCX files. If the translated file has already lost its layout, why translated Word documents break formatting explains common causes and ways to investigate them.

Run a file-by-file review before delivery¶

A reliable QA pass moves from the document as a whole to smaller details. Begin with the page structure, then inspect recurring elements, review the text and numbers, check Word markup, and finish with a clean copy of the file.

Start with a visual comparison¶

Open the source and target in a page-oriented view, such as Word’s Print Layout, or compare their rendered PDFs. Check the beginning, middle, and end, then review every page or section that contains dense content, forms, tables, or unusual formatting.

Look for these structural changes:

• Page breaks that divide a heading from the section it introduces.
• Orphaned lines, where a single line from a paragraph is left at the top or bottom of a page.
• Text that spills into a margin, overlaps an image, or sits outside a text box.
• Lists whose numbering or indentation changes partway through.
• Captions separated from the figure or table they describe.
• Headers or footers with missing, clipped, or untranslated content.

A difference isn’t automatically a defect. Longer translations may shift a paragraph or table to another page without affecting meaning. Record the problem only when the change makes content harder to find, hides information, breaks a relationship, or contradicts delivery requirements.

Check headings and lists¶

Compare the heading hierarchy, not just the appearance of the heading text. A title should still read as the document title, and section headings should retain their relative levels. A heading that has been styled to look larger but isn’t marked with a built-in heading style may be harder for assistive technology to interpret.

Microsoft advises using built-in heading styles and checking the logical heading order by scanning the document’s table of contents in its Word accessibility guidance. If the translated file has a table of contents, confirm that its entries and page references correspond to the translated headings.

Lists need the same kind of structural check. Confirm that numbered steps remain in the right order, that nested items still appear at the right level, and that bullets haven’t turned into separate paragraphs with inconsistent spacing. When a list continues after a table or image, check that the numbering doesn’t restart unexpectedly.

Compare tables cell by cell¶

Read each table across rows and columns rather than scanning only for familiar words. Check that labels still align with the correct data and that no value has moved into a neighboring cell. For complex tables, compare the source and target one row at a time.

Microsoft recommends simple data tables with column headers. Its accessibility checker can flag split, merged, or nested cells, while a visual check can catch entirely blank rows or columns. Microsoft’s guidance also recommends avoiding fixed-width tables where possible and checking how a table renders on phones and tablets. A wide, fixed table can force small text or horizontal scrolling for people using magnification.

Microsoft Support explains, “Screen readers keep track of their location in a table by counting table cells.” (Word accessibility guidance)

The quote points to a practical test: if the relationships between headers and cells are unclear when read in sequence, the table may need structural work even when it looks fine on screen.

For a translated table, check whether target-language text has forced narrow columns to become cramped. A row can also grow taller, pushing related content onto another page. Don’t shrink text without checking readability; consider adjusting widths, breaking a table at a sensible point, or changing the layout when the recipient’s requirements allow it.

Inspect fonts, emphasis, and links¶

Check that the intended fonts appear consistently and that special characters display correctly. Look for substituted glyphs, unexpected font sizes, missing bold or italic emphasis, and text that has inherited a style from a nearby paragraph.

Inspect links by following them or checking their destinations, particularly when the visible text has changed in translation. Microsoft recommends meaningful hyperlink text that makes sense on its own and accurately describes the destination, as explained in its accessibility guidance for Word. A link labeled “click here” tells a reader less than one that identifies the destination or action.

Check dates, numbers, currencies, and units¶

Numbers are easy to overlook because the digits may remain unchanged while the punctuation changes. Check decimal and grouping separators, plus and minus signs, percent signs, time separators, currency symbols, units, and dates. Confirm that values remain attached to the correct labels and that a minus sign hasn’t disappeared.

Number and date conventions vary by locale. Unicode CLDR gives examples such as 1,234.5 and 1’234,5, as well as 21/02/2025 and 21 February 2025, in its guidance on number symbols and formats. The examples show why a reviewer shouldn’t assume that the source’s punctuation is a universal standard.

CLDR also says that when a language is used in a region where it isn’t the primary language, the customary local or regional convention should guide formatting; audience and context can affect the appropriate choice. A translated financial document, for example, may need to retain a source convention if the recipient expects to compare it with the original. A public-facing localized document may need a different choice. Follow the project brief and the recipient’s requirements rather than changing formats mechanically.

Review images, captions, and page furniture¶

Confirm that images are still present, captions remain next to the right image, and labels inside diagrams haven’t been left in the source language. Check logos and seals for clipping or distortion without changing their content. If a figure carries essential information, make sure the translated text explains it where required instead of relying on the image alone.

Headers and footers can contain important content such as document identifiers, confidentiality labels, or page numbers. Compare them carefully. Microsoft advises keeping important information in the document body rather than only in headers or footers, because screen readers don’t scan those areas in the same way as the main text. Keep essential content available in the body as well when the document’s design allows it.

The same review applies to form fields and signatures. Confirm that translated labels still sit beside the correct entry areas and that no information has been covered by a shape or shifted beneath a stamp. Don’t infer or alter the contents of a signature, seal, or official mark.

Inspect tracked changes, comments, and automated QA findings¶

A clean-looking Word page can still contain unresolved review data. Tracked changes may be hidden from view, and comments may remain attached to text even when they don’t appear in the main body.

Word marks deletions with strikethrough and additions with underline; different authors’ changes can appear in different colors, according to Microsoft’s Track Changes guidance. Review the file with all markup visible, including formatting changes and insertions or deletions. A filter can help isolate the type of revision you’re checking, but don’t assume a filtered view shows everything.

Microsoft Support puts it plainly: “Hiding changes doesn’t remove them from the document.” (Track Changes in Word)

No Markup view displays the document as if the changes have been incorporated, but unresolved changes or comments remain in the file. Turning Track Changes off stops new edits from being marked; it doesn’t remove existing colored underlines or strikethroughs. Microsoft also notes that hidden markup can reappear when a file is reopened.

A delivery check should confirm that changes have been resolved, not merely hidden. If the recipient needs a final version, accept or reject each relevant change, remove comments that shouldn’t travel with the file, save, close, and reopen the document. Check the reopened copy again. Word provides commands to accept or reject an individual change, all changes, or all changes and stop tracking. Choose the action that matches the review agreement rather than accepting everything by default.

If reviewers need to keep the change history, don’t flatten or remove it just to make the page look clean. Confirm the requested markup state with the project owner and deliver the file in that state. A file intended for ongoing review and a final clean copy are different deliverables.

Automated translation QA needs the same careful interpretation. A system may identify mismatched tags or formatting patterns, but a warning is a prompt to inspect the source and target, not proof of a translation error.

A community discussion on the TranslatorsWB forum includes this report:

“Memsource sometimes detects tag and formatting issues that cannot be ignored even when they aren’t real issues in the target text”

The report describes a QA finding that may be false in context. Inspect the tagged segment, compare the source and target formatting, and decide whether the warning points to a real problem. If a project interface won’t let you dismiss a warning that you’ve reviewed, document the finding and ask the project manager or support team for the approved resolution.

For a closer look at review markup, see how to handle tracked changes when translating Word files. The key distinction is simple: a visible warning needs investigation, and an invisible revision may still be present in the document.

Check accessibility and decide when the full review is needed¶

Accessibility QA checks whether people can follow the document’s structure and perceive its content. A visual pass can’t confirm everything a screen reader user needs, so pair visual inspection with Word’s Accessibility Checker and review the flagged items in context.

In Word, open Review > Check Accessibility. Microsoft’s current support guidance says the checker flags issues, explains them, and suggests fixes. Microsoft identifies missing alt text and low text/background contrast as common concerns. A photograph, chart, or diagram that communicates information may need alternative text that describes its purpose, while text must remain distinguishable from its background.

Microsoft classifies checker findings as errors, warnings, or tips according to severity in its rules for the Accessibility Checker. The checker can’t find every accessibility issue, so a visual review still matters. Treat the results as a structured starting point, not a certificate that the file is accessible.

Check the following:

• Heading styles and logical order.
• Alt text for images that carry meaning.
• Sufficient contrast between text and its background.
• Tables with clear headers and a straightforward reading order.
• Links whose text identifies their destination.
• Important information in the document body rather than only in headers or footers.
• Tables and page layout at the sizes and devices relevant to the recipient.

Microsoft recommends not using color as the only way to communicate information. If a chart distinguishes categories only by color, add labels, patterns, or another cue where appropriate. A color key that looks obvious on a monitor may not help a reader who can’t distinguish those colors.

Not every file needs the same depth of review. A short internal note with simple paragraphs may need a focused visual pass and a check for hidden markup. A form, report with tables, or document intended for a broad audience needs closer inspection of its structure, numbers, links, and accessibility. Official or high-impact documents also need the relevant subject-matter and recipient requirements checked; formatting QA doesn’t replace legal, linguistic, or domain review.

Some warning signs call for a deeper pass:

• The source has nested or irregular tables.
• Text appears inside shapes, headers, footers, or images.
• The target language expands significantly in a form or narrow column.
• A document contains frequent dates, amounts, or measurements.
• The recipient needs to edit the file, not just read it.
• The layout includes right-to-left text, multiple languages, or mixed scripts.
• The source is a scan or a PDF whose text and tables may not be structurally editable.

Scanned pages deserve special attention because the source is an image rather than editable text. Stamps, handwriting, low contrast, or a skewed page can make the underlying content hard to read. Check that the translated version hasn’t confused a handwritten date with printed text, omitted a seal, or moved a label away from its field. If the source itself is hard to read, record uncertain items for confirmation rather than guessing.

A review can also flag a difference that is intentional. A date may be reformatted for the audience, a line break may shift because the translation is longer, or a table may move to the next page while keeping its relationships intact. The reviewer should ask whether the change preserves meaning and usability before marking it as a defect.

A final checklist and common QA mistakes¶

Use this checklist as the last pass on the exact file you’re about to deliver. A reviewer can copy it into a project workflow and mark each item as checked, not applicable, or requiring a decision.

Common QA mistakes come from treating one view as the whole document. No Markup isn’t proof that a DOCX contains no revisions. A successful automated check isn’t proof that every page is readable. Matching page counts doesn’t prove that tables or figures still communicate the same relationships.

A second frequent mistake is forcing the translation to match the source’s line breaks. Text length changes naturally across languages, so a paragraph wrapping differently doesn’t automatically need correction. Fix layout when it harms meaning or use, not just because the page looks different.

Reviewers also sometimes change numbers to match their own locale without checking the project brief. That can confuse readers who need to compare the translation with the source. Confirm the intended locale and audience before altering date, number, currency, or measurement formats. CLDR’s guidance on regional number and date conventions explains why a single format can’t be assumed for every context.

The final trap is checking a working copy rather than the delivered copy. Save the file, reopen it, and confirm that the approved content, markup state, and layout are still present. Then make sure the delivered attachment or exported PDF is the same version you inspected.

For a wider view of what separates translated text from a deliverable document, read client-ready documents versus translated text. The distinction helps set expectations: a translation can be linguistically complete while the file still needs formatting and delivery review.

FAQ¶

What should a formatting QA checklist include before delivering translated files?¶

Check page layout, headings, tables, lists, fonts, links, dates, numbers, comments, tracked changes, and accessibility. Compare the target with the source, then inspect the final saved copy in the format the recipient will receive.

How do I check that a translated Word document matches the source layout?¶

Open the source and target side by side in Print Layout and compare their pages and sections. Check headings, page breaks, tables, lists, headers, footers, and text wrapping, while allowing for legitimate differences caused by translation length.

How can I find hidden tracked changes and comments in a translated DOCX?¶

Use Word’s Review controls to display all markup, including formatting changes and insertions or deletions. No Markup hides revisions but doesn’t remove them; resolve the changes and comments according to the delivery brief, then save and reopen the file to check the result.

What should I check in tables and numbers after translating a document?¶

Compare table headers, rows, columns, labels, and values cell by cell. Check date formats, decimal and grouping separators, currency symbols, units, plus or minus signs, and percentages against the source and the intended locale.

Why can translation QA flag a formatting issue that isn’t actually wrong?¶

An automated QA tool can flag a tag or formatting pattern that looks unusual even when the target text is valid. Inspect the source and target before changing the file, and ask the project manager or support team how to handle a warning the interface won’t let you dismiss.