File Formats for Technical Translation: What to Send

Translation file formats are the least interesting subject in a documentation project and one of the most expensive. Content that a translator handles in two days can sit for another three in file preparation and layout repair, entirely because of what arrived in the handoff folder. None of that work improves a single sentence.

Six families cover almost everything that reaches a technical translation project: Office documents, desktop publishing files, CAD drawings, software resource files, structured XML, and PDF. Below, what a translation tool can read in each, where text tends to hide, and what you should expect back.

What a translation tool actually reads

A CAT tool does not open your file the way you do. It applies a format filter that separates translatable text from everything else, presents the text as segments, then rebuilds the file in its original format with the target text in place. Styling, structure, and code are protected during that round trip. Two consequences follow, and they explain most format problems in this guide.

First, anything the filter cannot see stays in the source language. Text baked into a JPG, a chart label stored as a picture, an XML attribute nobody configured as translatable: none of it appears in the tool, so none of it appears in the review, and it ships untranslated. Second, anything the filter cannot cleanly rebuild has to be repaired by hand afterward, which is where desktop publishing hours come from.

So the practical question is never "what format do you accept". The question is which of your files gives the filter a clean round trip, and the answer is almost always the editable file that generated the final document, delivered with its dependencies: linked images, fonts, referenced drawings, the full book or project folder.

Office files: DOCX, XLSX, PPTX

Word files are the easiest family and still produce steady surprises. A DOCX built on real paragraph styles round-trips cleanly. A DOCX where headings are manual bold text, sections are held together by empty paragraphs, and half the figures are floating text boxes will come back needing hours of tidying, because target text of a different length pushes every hand-made adjustment out of position.

Specific things worth checking in a Word source before handoff:

• Tracked changes and comments. Accept or reject everything first. Filters treat deleted text inconsistently, and translating a revision you already rejected is a pure waste.
• Automatic fields. Tables of contents, cross-references, figure numbering and index entries are generated. They must be refreshed after translation, not translated as static text.
• SmartArt and grouped shapes. Text inside a SmartArt diagram lives in a separate part of the file. Some filters read it, some skip it, and none of them resize the shape when German expands the label.
• Text inside images. A screenshot with English button names is a picture. It needs either a numbered legend or a rebuilt graphic, and both are quoted separately.
• Headers, footers and embedded objects. Revision blocks, running titles and embedded Excel tables carry real content that reviewers routinely skip.

Excel adds its own traps. Hidden sheets, hidden rows and filtered views contain text that a filter will extract even when you forgot it exists, so you pay for it. Formulas should stay untouched, but named ranges and text used inside lookup functions break the workbook if translated, and data validation dropdown lists usually must match strings elsewhere in the file. Chart titles, axis labels and series names live in the chart definition rather than in cells. Column widths are fixed, so expansion truncates what you see even when the cell content is complete.

PowerPoint hides text in slide masters and layouts, in speaker notes, in grouped and stacked shapes, and inside charts. Autofit shrinks text to fit, which means a German or Spanish slide that technically fits may be unreadable at 9 points. Decide in advance whether notes are in scope. On training material they usually are, and their word count can rival the slides themselves.

Desktop publishing: InDesign and FrameMaker

For InDesign, send IDML, not INDD. INDD is a version-bound binary that only the matching InDesign release opens reliably. IDML is the documented interchange format that translation tools read and write, and it preserves styles, threading and anchored objects. Export it from your working file and include the fonts and linked images, or send a packaged folder. Without the links, nobody can verify that a caption still sits under its photograph.

Text expansion is the recurring problem in laid-out documents. English into German commonly runs 25 to 35 percent longer, Romance languages 15 to 25 percent, and Chinese or Japanese contract instead, which leaves holes rather than overflow. Text frames built tightly around English will overset. Whether you plan for a post-translation layout pass with technical desktop publishing or handle it in house, budget for it as its own step, because reflowing a 60-page manual is not part of translating it.

FrameMaker follows the same logic one level up. Binary .fm files should be converted to MIF for the translation round trip, and a book (.book) needs all its component chapters, its graphics folder, and any variable and conditional text definitions. Conditional text matters most: if the file carries hidden conditions for other products or markets, decide whether they are in scope before the word count is agreed, since the tool will find them. Generated lists, indexes and cross-reference formats have to be rebuilt at the end in FrameMaker itself, and index markers deserve a specific instruction, because a translated index that was never sorted for the target language is useless.

CAD drawings: DWG and DXF

Drawings hold small amounts of text in a large number of places, which is exactly the profile that produces omissions. Text in a DWG can sit in single-line text objects, multiline text, dimension overrides, leaders and callouts, table objects, block attributes, and inside externally referenced drawings. Title blocks are usually block attributes, and they are the single most frequently missed element on a translated drawing set.

DXF exists as an interchange format and is readable everywhere, but dynamic blocks and some annotation behavior degrade in the conversion, so native DWG is preferable when the target audience will keep working in CAD. Two more constraints shape every drawing project:

• Fonts. Legacy SHX fonts have no glyphs for accented Latin characters, Cyrillic or CJK. Substituting a TrueType font changes the visual weight of every annotation on the sheet, so agree on the substitution before production rather than during review.
• Space. CAD does not reflow. Longer target text runs into dimension lines and off the sheet, and someone has to move it. A drafter familiar with your drawing standard should do that, not a linguist.

The usual workflow extracts drawing text into a bilingual table, translates it in a controlled environment against the same termbase as the manuals, reimports it, and finishes with a CAD operator repositioning annotations and checking the title block. Bilingual delivery is worth asking about: target text can go on its own layer so a single drawing displays in either language, which suits plants where the maintenance crew and the OEM read different ones. Details of that pipeline live on our CAD drawing translation page, and the document-level view sits under native CAD file handling.

Software and UI files: XLIFF, PO, RESX, JSON, YAML

Resource files are structurally simple and semantically difficult. The text is short, context is scarce, and the surrounding code is unforgiving. XLIFF is the format to prefer when your build chain can produce it: it carries segment IDs, status, and developer notes, and it is what most tools use internally anyway. PO files from gettext work well and handle plurals properly through the plural-forms header, which matters because Japanese uses one form, Polish uses three, and Arabic uses six. RESX offers a comment field that is often the only place a translator can learn whether "Monitor" is a screen or a verb.

JSON and YAML are the harder cases. Neither has a standard place for context, keys must never be translated, and YAML in particular is sensitive to indentation and quoting, so a stray character breaks the parse rather than producing a visible error. Three rules apply across all of them:

1. Placeholders survive intact. Tokens such as %s, {0}, {{count}} or %1$s must appear the same number of times in the target. Word order changes between languages, so positional placeholders are safer than sequential ones.
2. Concatenated strings do not translate. Assembling "Delete " plus a number plus " files" in code forces the translator to guess gender, number and word order. Full sentences with variables inside them are the fix, and they cost nothing to write that way.
3. Length limits are real. An HMI field, a PLC message line or an embedded display may allow 16 or 20 characters. Tell the translator the limit per string, or accept truncation.

Run a pseudo-translation build first if you can. It replaces every string with lengthened, accented placeholder text and exposes hard-coded strings, encoding problems and layouts that break under expansion, before anyone pays per word. More on the wider workflow under software and UI localization.

Structured content: XML and DITA

Teams on DITA usually have the cleanest handoffs on the site, because the format was designed to separate content from presentation. Send the map along with every topic it resolves, plus key definitions and any referenced files. A partial delivery produces broken links at publish time in the target language, and diagnosing that after the fact is slow.

Reuse is the feature that repays a translation budget and the one that occasionally hurts. A warning stored once and pulled into 40 topics through a content reference is translated once and priced once. The same mechanism breaks when a reused fragment has to fit different grammatical contexts: a noun phrase that works everywhere in English may need different case endings in German, Polish or Korean depending on where it lands. Fragments intended for reuse should be complete sentences whenever possible.

Two configuration details are worth settling early. Decide which attributes are translatable, since alt text and navigation titles usually are while product and platform attributes are not, and confirm that conditional filtering happens before the word count. Returned files should validate against the same DTD or schema as the source.

PDF is an output format, not a working format

A PDF is a print job that kept its text. It records where glyphs sit on a page, not how a paragraph flows, which is why nothing that comes out of one is really a translated version of the original document. There are two grades of PDF, and they behave differently.

An editable PDF with a text layer can be extracted. Expect broken lines at every column break, tables reduced to loose text, and footnotes interleaved with body copy. A scanned PDF has no text at all, so optical character recognition has to invent one, and its accuracy varies with scan quality: clean 300 dpi originals convert well, tenth-generation photocopies of a 1990s manual do not, and technical strings such as part numbers are exactly where OCR fails most often.

In both cases the document you receive was rebuilt by a person, so it will resemble the original rather than match it. That work is legitimate and we quote it as file engineering, but it is worth ten minutes of searching for the native file first: it is often on a server, with a former agency, or with whoever wrote the manual. If it genuinely no longer exists, say so at quote stage so the rebuild is planned rather than discovered.

Translation file formats at a glance

What to send, what comes back, and where the attention goes.

You send	You get back	Watch for
DOCX	Translated DOCX, styles preserved	Fields regenerated, SmartArt text, images with embedded text
XLSX	Translated workbook	Hidden sheets, chart labels, named ranges, column width
PPTX	Translated deck	Masters, notes, autofit shrinking text below readable size
IDML plus links and fonts	Translated IDML, plus PDF on request	Overset text, anchored objects, expansion in tight frames
MIF or FrameMaker book	Translated MIF or FM, book structure intact	Conditional text scope, variables, regenerated index
DWG or DXF	Translated drawing, single or bilingual layers	Block attributes, title block, SHX font substitution
XLIFF	Translated XLIFF ready for your build	Segment IDs, developer notes, string status
PO, RESX, JSON, YAML	Same format, same structure	Placeholders, plural forms, key names, character limits
DITA map and topics	Translated topics that validate	Resolvable references, translatable attributes, reuse grammar
Editable PDF	Rebuilt DOCX or InDesign file	Layout is approximated, extra engineering time
Scanned PDF	OCR plus rebuilt document	Recognition errors in codes and numbers, longest lead time

Whatever the family, three habits carry across all of them: send the editable original, send its dependencies, and name the deliverable you need at the end. Saying on day one whether you want a print PDF, a web package or a file your own team will keep editing changes how the project is set up. The companion guide on getting documents ready before handoff covers the content side of the same question, and if you want a specific set of files assessed, send them over for a quote and the format work will appear as its own line.