How Do You Fix Tables in InDesign After Translation?

The translated file is back. The body text looks fine. You scroll to the first table — and it is a wreck. Red overset dots on half the cells. Column widths that have clearly been dragged around. A header row that stopped repeating somewhere around page four. And the Table Styles panel reads [No table style].

Tables are the hardest structural element in any InDesign document to survive a translation round-trip intact. They break in predictable ways — but fixing them systematically, rather than cell by cell, requires knowing exactly what failed and why. This article covers the six failure modes, the correct fix sequence, and a step-by-step repair checklist you can run on any multilingual table layout.

Why Tables Are the Hardest Thing to Survive Translation

When an InDesign file goes through a translation workflow — via IDML export, through the Trados or memoQ IDML filter, or direct in-file editing — tables face several structural risks simultaneously, not just one.

Text expansion is the obvious risk. A German sentence that was 80 characters in English is now 110. The cell that was exactly wide enough is now overset. But expansion is only one of the problems. The IDML round-trip can also strip cell style and table style assignments, lose header row designations, reset row heights from At Least to Exactly, and break decimal tab stops. Translators working directly in the InDesign file sometimes manually drag column widths to make expanded text fit — which destroys the table's proportional geometry and leaves no visible trace of the change unless you measure carefully.

The result is up to six overlapping problems to diagnose before you start fixing anything. Fixing them in the wrong order means undoing your own work.

The Six Table Failure Modes

Run a quick diagnosis against all six of these before touching anything in the file. Mark which failures are present, then work through the fixes in the sequence given later in this article.

Fix order matters. Releasing row heights before correcting column widths shows you the true text volume. Reapplying styles before fixing geometry means a style reapplication may reset row height settings you already corrected. Restoring merged cells before anything else prevents geometry errors that cascade into every other fix.

Fix 1: Cell Overset — Row Height Set to Exactly

The red dot on a table cell means exactly what it means on a text frame: more text than space. But the fix inside a table cell is not the same as relinking a text frame chain.

The first thing to check is Row Height mode. Select all body rows in the table — click the first row's left edge handle, shift-click the last — then go to Table > Cell Options > Rows and Columns. If Row Height reads Exactly, that is your problem. Change it to At Least with your original minimum row height as the value. This releases every overset cell simultaneously and lets rows grow to accommodate the translated text.

If row height was already set to At Least and overset is still present, the problem is column width — the text is wrapping excessively because a column is too narrow. Do not keep adjusting row height. Move to Fix 2 first.

For individual cells with stubborn overset after row height is freed: select the cell and open Text Frame Options (Ctrl/Cmd+B). Check the inset spacing values. A top and bottom inset of 4mm on a narrow column eats into your usable text height significantly, and this value can be reset incorrectly by a style reapplication.

Fix 2: Column Widths and Table Geometry

This is the fix that requires the most discipline, because the temptation is to drag columns until they look approximately right. Resist it. Technical documents — SDS, IFUs, product catalogs — typically have multiple tables across many pages sharing the same column proportions. Fixing each table by eye creates subtle inconsistencies that are invisible at 50% zoom and obvious in print or on screen at 100%.

The correct sequence:

1. Note the target total table width. This is either documented in the spec, or you measure it from the source-language file. Do not guess from the translated file — the translator may have widened the whole table, not just individual columns.
2. Click anywhere in the table and check the total table width in the control bar (W field). If it has changed from the target, fix the overall table width first: select the table, enter the correct width value in the W field, and confirm.
3. If all columns should be equal width: select all columns (click the first column top handle, shift-click the last), right-click, and choose Distribute Columns Evenly.
4. If columns have fixed individual widths: select each column and enter the correct width via Table > Cell Options > Rows and Columns > Column Width. Do not enter values by dragging.

After redistributing columns, check again for overset. If text is still tight in a specific column — translated content is genuinely longer and columns cannot widen further without the table exceeding the text frame — you have two options: reduce tracking on the cell paragraph style (do it at style level, not on individual cells), or reduce the font size by half a point in the cell paragraph style. Both changes propagate to every cell using that style.

Fix 3: Table and Cell Styles Have Dropped

This failure is the most invisible. The table can look visually correct — right colours, right borders, right fills — while the Table Styles panel shows [No table style]. This matters because any change you make will not inherit from the style definition, and if a global style update is applied later (updating the brand colour in the table style, for instance), this table will not receive it.

The fix is straightforward, but the order matters:

1. Click anywhere in the table to activate the table context.
2. Open the Table Styles panel (Window > Styles > Table Styles) and apply the correct table style. This sets table-level formatting: outer border, spacing above and below, header and footer fill.
3. Select all body cells and apply the correct body cell style from the Cell Styles panel.
4. Select header cells separately and apply the header cell style.
5. Check alternating row fills: Table > Table Options > Fills. Confirm the Alternating Fills checkbox is active and the correct pattern and colours are set.

Why styles drop in the first place: Trados and memoQ IDML filters operate at the text segment level. Style attributes attached to the table container — rather than to the text inside cells — are sometimes not preserved correctly during re-import, particularly if the IDML filter version differs between export and import, or if the translator used a CAT tool version that predates InDesign's current IDML spec. This is a known IDML round-trip issue and is not something the translator can reliably prevent. It is a DTP2 correction item by design.

Fix 4: Header Rows That Have Stopped Repeating

An InDesign table header row repeats across pages automatically — as long as the row is designated as a header. After a translation round-trip, that designation sometimes resets to body, and the header silently stops repeating. You will notice this on the second or third page of a long table: no column labels, just body rows continuing into blank white space.

The fix:

1. Click in the row that should be designated as the header.
2. Go to Table > Convert Rows > To Header.
3. Confirm the change worked: Table > Table Options > Headers and Footers. Check that the Header Rows count is correct and that Repeat Header is checked.

If the table is threaded across multiple text frames, the header will repeat at the start of each frame continuation automatically once the row type is restored — no additional action needed.

Fix 5: Decimal Alignment and Tab Stops

Tables in product catalogs, SDS sheets, and price lists frequently rely on decimal tab stops to align numeric columns — so that 12.5 and 1,450.00 share the same decimal point position regardless of the number of digits. This alignment is stored in the paragraph style applied to the cell, not in the cell style itself.

After translation, decimal alignment breaks for one of two reasons:

• The decimal separator changed. German, French, and many other European languages use a comma as the decimal separator (1,5 rather than 1.5). If the original paragraph style had a decimal tab stop set to align on a full stop, it will not work on the localised number. The tab stop alignment character must be changed to match the target locale's separator.
• The tab stop was lost in the round-trip. Trados and memoQ IDML filters sometimes strip custom tab stop positions from paragraph styles on re-import. The paragraph style applies correctly, but with default tab stops rather than the specified decimal position — so numbers appear left-aligned or misaligned rather than decimally aligned.

Fix: open the paragraph style used in the numeric column (double-click it in the Paragraph Styles panel), go to Tabs, and check whether the decimal tab stop is present at the correct position and whether the Align On character is correct for the target locale. If the tab stop is missing, re-enter the position and set the correct alignment character. This fixes every cell using that style in one operation — no cell-by-cell correction needed.

Fix 6: Merged Cells and Column Spans

Merged cells survive IDML round-trips less reliably than standard cells. The specific failure pattern: text from a cell spanning three columns sometimes ends up in only the first cell of the range on re-import, leaving the other two cells empty but still merged. Or the merge is undone entirely, converting the spanning header into three separate cells each containing a fragment of the translated text — or nothing at all.

Diagnosis: select the cell in question and check its column span in Table > Cell Options > Rows and Columns > Column Span. If it reads 1 when it should read 3, the merge was undone. If it reads 3 but the cell appears empty, the text landed in an adjacent unmerged cell.

Fix for an undone merge:

1. Select the cells that should be merged.
2. Table > Merge Cells.
3. Re-enter or paste the translated content. If the text landed in an adjacent cell, cut it first, merge, then paste.

The Table Repair Sequence

Apply the fixes in this order. Deviating from the sequence means earlier corrections may be undone by later ones — for example, reapplying table styles before correcting row height can reset cell height values you already set.

RTL Tables: Additional Considerations

For Arabic and Hebrew translations, table column order should be mirrored: what was column 1 (leftmost) in the source document becomes the rightmost column in the RTL version. InDesign does not mirror table column order automatically when you switch a text frame to right-to-left mode. The column reversal must be done manually, or scripted via ExtendScript if you handle RTL table production regularly.

Additionally, text direction inside each cell must be set to right-to-left. This is done via Table > Cell Options > Text, or — better — built directly into the cell paragraph style used for RTL content so it applies consistently to every cell. If the translator set cell text direction manually on individual cells, those overrides will survive the import but will be inconsistent in coverage. Reapplying the RTL cell paragraph style globally is cleaner.

For full coverage of RTL layout behaviour in InDesign — including frame direction, mixed content, and mirroring logic — see the RTL languages in InDesign guide in this series.

The Short Version

Tables break after translation because text expansion, IDML round-trip behaviour, and manual translator adjustments hit the same structural elements simultaneously. There are six failure modes: cell overset from fixed row heights, corrupted column widths, dropped style assignments, lost header row designation, broken decimal tab stops, and undone merged cells. Each has a specific fix. The order matters: merged cells first, then row height, then column widths, then styles, then header rows, then tab stops. Run a final visual scan at 100% before signing off.

For complex technical documents — SDS, IFUs, product catalogs with dense data tables — table repair is a fixed part of every DTP2 stage. It is not a sign that the translation came back broken; it is a structural consequence of how IDML handles table metadata through a round-trip. Budget for it, document it in your process, and run the sequence every time.

Further Reading