QA & LQA

Introduce QA check for incorrect order of tags

Current behavior:
Export of XML-based files incl. Multilingual MS Excel may fail with a "Could not be generated: exported file cannot be opened" error, although no QA warnings are shown. This may happen due to a different order of tags on the target side.

Available workaround (if any):
A range of custom QA checks can be configured to detect these spots (for paired or unpaired tags in the following setup). The regexp entries in the fields are the same for the source and the target side, and are as follows:

for "Tags order (unpaired)":
^.*\{1\}.*\{2\}.*$
^.*\{1\}.*\{2\}.*\{3\}.*$
^.*\{1\}.*\{2\}.*\{3\}.*\{4\}.*$

for "Tags order (paired)":
^.*\{1\>.*\<1\}.*\{2\>.*\<2\}.*$
^.*\{1\>.*\<1\}.*\{2\>.*\<2\}.*\{3\>.*\<3\}.*$
^.*\{1\>.*\<1\}.*\{2\>.*\<2\}.*\{3\>.*\<3\}.*\{4\>.*\<4\}$

(The "Nested tags" QA check finds incorrectly nested paired/unpaired tags only.)

Requested behavior:
A new QA check called "Incorrect order of tags" that finds up to 100 incorrectly ordered paired and unpaired tags in the target segments, even if tag numbering starts with >1 due to segmented paragraphs or a segment being split.

Use case:
Since no warnings are shown, it may be hard to find these errors by the naked eye especially in large files, while the issue blocks file export.

2

1 comment

  • Having a new QA check would be super useful, because adding all the possibilities of regexp isn't very handy, and doesn't give the warranty either that it will catch the mistake if there are more tags in the job than defined in the regexp.

    0

Please sign in to leave a comment.