Supervertaler Workbench v1.9.489

Three fixes since v1.9.485 — a pair of Phrase bilingual DOCX import bugs, plus a long-standing macOS tab-alignment issue that finally took.

What's fixed

Phrase bilingual DOCX import rejected valid files (v1.9.487)

A user reported their Phrase-exported bilingual DOCX (63 segments) being rejected with This file does not appear to be a Phrase bilingual DOCX. Expected format: Multiple tables with 7-8 columns and segment IDs containing ':' even though the file was a perfectly valid Phrase export.

Two bugs in modules/phrase_docx_handler.py:

The detector required more than 100 rows in the content table. Short documents (single-page certificates, single-section files) routinely have fewer. Threshold dropped to ≥ 2 rows — the colon-in-first-cell test (SSOMDWjYi5xvD7wq_dc10:0) is distinctive enough on its own.
The detector required exactly 7 columns. Newer Phrase exports add a trailing column → 8. The parser already accepted ≥ 7, but the detector rejected before the parser got a chance. Detector now accepts both 7 and 8.

The error message also rewritten to describe the actual signal (column count plus segment-ID format with an example) rather than the old vague "Multiple tables" wording.

Phrase bilingual DOCX import shifted target → status column by one (v1.9.488)

Follow-up bug uncovered when fixing v1.9.487. The file looked like 7 columns in Word but the underlying DOCX has 8 grid columns, with the Source column using <w:gridSpan w:val="2"/> to span two adjacent grid positions. python-docx surfaces this as row.cells[3] is row.cells[4] — the same cell object returned twice — while Word shows a single visual Source column.

v1.9.487 made the detector accept these files, but the parser still used hardcoded cells[4] as Target, which was actually a duplicate of Source. Every 8-grid-column Phrase file silently shifted Target → Status → Comment by one column. Untranslated rows looked fine (source = "target" because both indices pointed to the same source cell), but the moment a user translated and exported, their work would have been written to the source-duplicate slot — corrupted on round-trip.

Fix introduces PhraseDOCXHandler._unique_cells(row) that deduplicates row.cells by Python object identity. Merged-source duplicates collapse to one entry, leaving 7 logical columns in either layout: [ID, ICU, #, Source, Target, Status, Comment]. Both the extract path and the write path now use this helper, so 7- and 8-grid-column files behave identically end-to-end. 7-grid-column files (no merge) are unaffected.

Tabs still centred on macOS — v1.9.486 fix was ineffective (v1.9.489)

v1.9.486 added QTabWidget::tab-bar { alignment: left; } to the global app stylesheet to left-align tabs on macOS. The rule looked right but was completely ineffective because of two stylesheet-precedence issues I missed:

modules/theme_manager.py:apply_theme() calls app.setStyleSheet(stylesheet) and replaces the entire app stylesheet — wiping out the alignment rule the moment any theme is applied.
Several individual QTabWidget instances (e.g. main_tabs in Supervertaler.py:9666) call their own setStyleSheet(...), which shadows the app stylesheet for that specific widget.

Proper fix lives in the existing _NoFocusRectStyle QProxyStyle: extended to also override styleHint(SH_TabBar_Alignment) returning Qt.AlignmentFlag.AlignLeft. Style hints are queried by every QTabBar at paint time and are not affected by stylesheets, so this path reaches every tab bar in the app regardless of theme changes, per-widget overrides, or future stylesheet additions.

The previous CSS rule is kept as belt-and-braces but the proxy-style override is the load-bearing piece.

Install

pip install --upgrade supervertaler

Or download the Windows release zip below — extract and run Supervertaler.exe. macOS DMG follows shortly.

Navigation Menu

Repository navigation

v1.9.489 – Phrase bilingual DOCX fixes + macOS tab alignment

Choose a tag to compare

Sorry, something went wrong.