The email lands mid-project: “The translated files won’t open properly.” Or worse: “All the formatting is gone.”

File handling failures are among the most frustrating problems in localization. The translation might be perfect, but if the final files don’t work—if they won’t open in the original application, or they’ve lost their formatting, or the content appears corrupted—the project has failed.

These failures aren’t random. They follow predictable patterns, and understanding those patterns reveals how to prevent them.

The format fragility problem

Office documents look simple from the user’s perspective. A Word file contains text, some formatting, maybe some images. But underneath, the format is far more complex: XML structures, embedded objects, custom styles, tracked changes, comments, fields that update dynamically.

Translation workflows need to extract the text, translate it, and reinsert it without disturbing any of those other elements. This is harder than it sounds.

Common failure modes:

Tag corruption. Modern document formats use internal tags to mark formatting, references, and structure. If those tags get damaged during extraction or reinsertion, the file may not open at all.

Style drift. The translated text may have different length than the original. When reinserted, it can cause text to overflow containers, break layouts, or push subsequent content out of position.

Embedded object damage. Word documents can contain embedded Excel charts, PowerPoint slides, images with captions, and other objects. Each requires separate handling, and failures in any one corrupt the whole file.

Version incompatibility. A .docx from Word 2019 has different internal structures than one from Word 2007. Processing tools that don’t account for version differences can produce files that open incorrectly or not at all.

Why “supported formats” claims are misleading

Translation platforms routinely claim to support dozens or hundreds of file formats. The claim is technically true but practically misleading.

“Supporting” a format can mean:

• The platform opens files of that type without crashing
• The platform extracts some text from the file
• The platform extracts text, maintains structure, and produces correct output files

Only the third interpretation is useful for production work, but marketing claims don’t distinguish between them.

The result: teams discover limitations mid-project when files start failing. A platform might handle simple Word documents perfectly but fail on complex ones. It might process Excel spreadsheets but lose number formatting. It might extract XML but ignore specific attributes your files use.

The Okapi approach

The Okapi Framework, maintained by the localization industry for over 15 years, represents the most battle-tested approach to file processing. It provides format-specific filters that understand document structures at the level needed for reliable round-tripping.

Round-tripping means: extract translatable content, translate it, reinsert it, and get a valid file that opens correctly and preserves all original formatting. Okapi’s filters are designed specifically for this, not for general-purpose document parsing.

The framework handles:

• Microsoft Office formats (Word, Excel, PowerPoint) across versions
• Open document formats (ODF)
• InDesign markup (IDML)
• XML with configurable element handling
• HTML with tag preservation
• JSON and YAML with structure awareness
• PDF (text extraction for reference, with limitations)
• Subtitle formats (SRT, VTT, TTML)
• Software resource formats (PO, RESX, properties)

Each filter is specialized. The Word filter knows about Word’s specific structures. The Excel filter handles formulas differently from text cells. The InDesign filter preserves layer information.

Format detection vs. format handling

A common point of failure is format misidentification. A file with a .xml extension could be:

• Generic XML
• XLIFF (itself an XML format)
• InDesign markup
• Android string resources
• Custom application data

Each requires different processing. Generic XML handling applied to XLIFF will work but produce suboptimal segmentation. InDesign markup processed as generic XML will extract content but lose critical layout metadata.

Intelligent format detection examines file contents, not just extensions, to determine the correct processing approach. This prevents the “it looked right but wasn’t” failures that plague projects using naive format handling.

Preview before commit

The most effective way to prevent file handling failures is to verify extraction before starting translation work.

An extraction preview shows:

• Which content will be extracted for translation
• Which content will be left in place
• The segment structure (how content is divided)
• Any warnings about potential issues

Reviewing this preview catches problems early:

• “That table should be translated but it’s not showing up”
• “Those code comments shouldn’t be included”
• “The segmentation is splitting sentences incorrectly”

Early detection means early correction. Fixing extraction rules before translation starts costs minutes. Discovering problems after translation costs hours or days.

Handling the unusual

Standard formats are easy. The hard cases are:

Legacy formats. Files from old software versions that modern tools don’t fully support. Sometimes these require format conversion before translation processing.

Custom XML schemas. Enterprise applications often export XML with proprietary structures. Generic XML processing may miss translatable content or include non-translatable elements.

Mixed-content files. Documents containing multiple embedded formats—a Word file with embedded Excel tables and PowerPoint slides, for example.

Proprietary formats. Software-specific formats that require specialized handling.

For these cases, the solution is usually custom filter configuration or pre-processing steps. The key is identifying unusual formats before they cause downstream problems.

Building reliable file workflows

Consistent file handling requires:

Format expertise in the process. Someone needs to understand file structures well enough to recognize potential problems. This can be automated intelligence or human expertise, but it needs to exist.

Testing with actual files. Don’t assume support based on format claims. Test with representative samples of your actual content before committing to a workflow.

Clear extraction verification. Build preview and verification steps into the process. Catching problems early is dramatically cheaper than catching them late.

Preserved originals. Always keep original files unchanged. If something goes wrong with the translated output, you need the ability to reprocess from the source.

File handling isn’t glamorous, but it’s foundational. Get it wrong and everything downstream fails. Get it right and you never think about it—which is exactly the point.

Language Ops processes 80+ file formats through Okapi Framework with AI-powered format detection and extraction preview. Test your files to see how your content processes.