XLIFF to Excel and back, without breaking the file

Sooner or later a reviewer, a client or a subject expert says: “Just send me a spreadsheet.” They have Excel and no CAT tool, and a table of source and target is something anyone can read. Getting their changes back into the XLIFF file is where the trouble starts, and most of it is Excel doing exactly what it was designed to do.

What Excel does to your text

Excel is built for numbers, and it helps by converting things that look like numbers. Microsoft lists the automatic conversions: removing leading zeros, cutting numbers to 15 digits and showing them in scientific notation, treating numbers around an “E” as scientific notation, and turning strings of letters and numbers into dates. For translation files that means:

• IDs and keys break. A segment ID of 000123 becomes 123; a long numeric key becomes 1.23E+15. Excel stores numbers to 15 significant digits, so the lost digits are gone for good.
• Text becomes dates. Type 12/2 and Excel shows 2-Dec. A version number, a model code or a fraction in a target cell can turn into a date the moment someone edits it.
• It happens to experts too. Excel’s date conversion damaged scientific data so often that the HUGO Gene Nomenclature Committee renamed every human gene symbol that Excel turned into a date: SEPT1 is now SEPTIN1, MARCH1 is now MARCHF1.

Only Excel for Microsoft 365 and Excel 2024 let you switch these conversions off, under File > Options > Data > Automatic Data Conversion on Windows; older versions cannot. Excel can also be set to warn before converting when a .csv or .txt file is opened. For a single cell, typing an apostrophe before the value stops the conversion, and the apostrophe is not shown.

The limits that matter

From Microsoft’s specifications and limits:

CSV is worse

CSV feels simpler and causes more damage:

• Double-clicking a .csv opens it with Excel’s default guesses for every column. The Text Import Wizard, or Data > Get Data > From Text/CSV, gives control over how each column is converted.
• Encoding is invisible. Excel opens a UTF-8 CSV correctly by double-click only if the file starts with a byte-order mark; without one, accented and non-Latin text comes out garbled. Nothing in a CSV file itself says what encoding it uses.
• Saving as CSV keeps only the active worksheet.
• Quoting varies. RFC 4180 says a field containing a line break, a double quote or a comma should be wrapped in double quotes, with any double quote inside written twice. It documents common practice and is not an Internet standard, so tools differ in the details.

For anything a reviewer will edit, send .xlsx, not CSV.

What a safe round trip needs

Whatever tool you use, four rules keep the XLIFF intact:

1. Match by ID, never by row order. Reviewers sort and filter. A round trip that maps row 42 back to segment 42 breaks the moment someone sorts by status.
2. Keep tags exact. A reviewer’s fix may move a tag but must not drop or invent one.
3. Put changes in their own column. If reviewers overwrite the Target column, you cannot tell an intended change from an accidental keystroke.
4. Refuse a workbook from another file. Applying review decisions to the wrong document, even partly, is worse than applying none.

How xliff.ai does it

xliff.ai has two spreadsheet exports, and only one of them is meant to come back. See XLIFF to Excel for the step by step.

The bilingual workbook has three columns, ID, Source and Target, one row per segment in document order, with inline tags shown as their raw markup. It is for reading, sharing or archiving, and there is no import path for it.

The review workbook is built for the round trip. It has twelve columns: the ID, source, target and status; the first QA issue and its severity; the most severe AI finding with its category, severity and comment; then Suggested fix, Reviewer decision (a real dropdown with Accept, Reject and Modify) and Reviewer comment. A hidden sheet records which document it came from. When it comes back:

• A workbook made from a different document is refused as a whole, with an error.
• Rows are matched by ID only, so sorting and filtering do not matter.
• Only Suggested fix and Reviewer decision are read. Edits typed into the Target column are ignored, by design.
• A fix must contain exactly the segment’s own tags. They may move; if one is dropped or added, that row is refused and counted.
• Decisions do what they say. Accept with a fix writes the fix and marks the segment reviewed; Accept alone marks it reviewed; Modify with a fix writes the fix as draft for another look; Reject is counted and changes nothing. Rows for locked segments or unknown IDs are counted as unmatched.

The cell limits above are not checked on export, so a segment longer than 32,767 characters might not survive the trip; segments that long are rare, but a file that keeps whole articles in single units is worth a look first.

Opening a spreadsheet directly is a different job: if your strings already live in an .xlsx or .csv, xliff.ai can open it as the translation file itself, find the source and target columns from their headers, and write back only the target cells you changed. See XLSX translation and CSV translation.

A spreadsheet is a fine way to let someone review a translation. It is a poor way to store one. Keep the XLIFF as the master, send the review workbook out, and let the import decide what comes back in.