Column[1]Count: when a tag is a line break

A software company’s interface strings, fourteen thousand segments in a memoQ bilingual file, full of entries like Column[1]Count. The [1] is an inline tag, and our pipeline treated it the way inline tags usually deserve to be treated: as something that sits between two pieces of text and must stay between the same two pieces in the translation.

So “Column” was translated, then “Count”, and the tag stayed in the middle. In Spanish that gives a column and a quantity side by side, instead of a column count. Of 5,747 segments with a tag glued between two words, 5,158 came out translated half by half. Another 423 had the tag moved to the end, which on screen is a label with an empty second line.

The tag was a line break

The label is “Column Count”, displayed on two lines. We could prove it without the original file: in almost three thousand of those segments, an escaped carriage return sat right before the tag. A carriage return followed by a tag is a Windows line ending, and the tag is the line feed.

The fix was to recognise those tags as line breaks and give them the opposite instruction to every other tag: translate the label as a whole, then break it where the target language breaks naturally. The cause had been our own instruction, not the model. We had told it to keep every tag in the same position relative to the words, and for a line break that is exactly wrong.

Then we switched it on for everyone

It worked, so we enabled it for every memoQ bilingual file. That was the mistake.

In a memoQ bilingual file a tag carries no content. A tab and a line break look identical. A heuristic that is right on the file in front of you is only a hypothesis about everyone else’s, and on other clients’ files it was badly wrong:

• □[1]Yes, quite often: a checkbox followed by a tab.
• 3.[1]Care should be taken: a list number followed by a tab.
• Member ID:[1]: a form field waiting for its value.
• remove the “[1]” profile?: a variable, inside the same UI file that started all this.

On a three-thousand-segment sample from another client, 151 of 474 tagged segments would have been misread. Inside the original UI file, 192 tags were variables, not line breaks. Moving those tags would have been worse than the bug we set out to fix. We stopped the re-run.

Where it landed

Line-break handling is off by default. A pipeline profile can switch it on for a client whose files are known to need it, or set it to decide per document, based on the carriage-return signature that proved the case here. Even when it is on, it only applies to a tag with a letter or digit directly on both sides, so a checkbox, a list number, a closing tag or a quoted variable is never treated as a line break.

The interface file was re-run with it on and now reads the way it will read on screen. Every other memoQ file behaves exactly as it did before, which is the other half of the fix.