[Bug] Automatic Tagger fails to place tags

[horac01]

Version & system info

Supervenaler Workbench v1.10.364
OS: Windows 11
Install: downloaded zip (exe)

Operating system

Windows

How did you install Supervertaler?

Windows installer / .exe

What happened?

Hi Michael,
I was playing around with the automatic tagging feature in the Workbench edition but could not get it to place the tags in the target (both within an imported .docx and .mqxliff), albeit trying different providers/LLMs.
I am attaching a sample message from a .mqxliff which I believe the model should be able to handle easily for you to look at...
Anyway, thanks again for all your work!
Best
Jan

Steps to reproduce

1. Imported a sample .mqxliff
2. Deleted the tags in the target segment
3. Launched the Automatic tagger feature

Screenshots or screen recording

[michaelbeijer]

Hi @horac01,

Thank you — that screenshot was the whole ballgame. The dialog text told me exactly where to look, and the sample segment made it reproducible in minutes.

You'd found a real bug, and it wasn't the AI's fault. The model was placing your tags correctly every time; the safety check that inspects the result was throwing the good result away.

Your segment carries Word-derived tags whose closing form includes attributes:

<rpr id="4">Spolková republika Německo</rpr id="4" transform="close">

The validator only recognised the plain </name> form of a closing tag, so it never matched that closer to its opener, decided the tag was unclosed, and refused the placement — hence unclosed tag(s): hrpr, and hence "nothing happens" no matter which provider or model you tried. The <bmk …> bookmarks in your segment 19 hit the same wall. Closing tags with attributes are now recognised.

Checking that fix turned up a second bug, which explains your .mqxliff results. memoQ numbers tags sequentially across a segment, so an opening tag and its closer normally carry different numbers ([1}De uitvoer{2]) — but the validator was pairing them by number and concluding they were "unpaired or out of order". So every memoQ tag pair was being rejected too. Pairs are now matched by position instead, which is correct whichever numbering a file uses.

Both fixes are in v1.10.366, released just now: https://github.com/Supervertaler/Supervertaler-Workbench/releases/tag/v1.10.366

Genuinely broken output is still refused — tags that close before they open, unclosed tags, crossed nesting — so AutoTagger still won't write bad tags into your target; it just no longer refuses good ones.

If you get a chance to try it on that same .mqxliff and a Word import, I'd be glad to know it behaves. Thanks again for reporting it so precisely.

Best,
Michael

[michaelbeijer]

Follow-up for @horac01 — the memoQ half of your report needed a third fix, which is now in as well.

My earlier comment covered the two bugs behind the Word case. Testing against a real .mqxliff afterwards showed AutoTagger still doing nothing there, but for a completely different reason: memoQ writes namespaced inline tags —

<mq:ch val="→" />

— and the tag-name pattern allowed only letters, digits and hyphens, so it stopped at the colon and never recognised those tags as tags at all. AutoTagger concluded "the source segment has no inline tags" and correctly did nothing. Namespaced names are now matched, which is what makes AutoTagger work on .mqxliff in the first place.

Two other things came out of the same test file:

• A tab inside a tag looked like it had been lost after tagging. Freshly tagged text was written to the grid raw while every other cell renders through the invisible-character markers, so a tab showed as → in the source cell and a bare gap in the target. The stored text was always correct — only the display differed. Fixed.
• AutoTagger is now in the right-click menu (single segment or a selection), alongside the other segment actions, which are themselves now identical in all three grid context menus.

All of it is in v1.10.367: https://github.com/Supervertaler/Supervertaler-Workbench/releases/tag/v1.10.367

Leaving this open until you've had a chance to confirm it behaves on your own files — both the Word document and the .mqxliff. Thanks again; the sample segment turned one report into three real fixes.

[horac01]

Hi Michael,

I suspect you must have some superpowers (despite sharing the developer seat with CC;)
I've tried only briefly before leaving for vacation -- both the Word (the very same as before) and .mqxliff seem to work -- even with fairly more complex tag structures! (I've noticed the tags have to be viewed expanded for AutoTagger to handle them all correctly but it is probably obvious.) If only I discovered the feature back then;))

Many thanks again and enjoy the summer!

Regards
Jan