You are currently working on UAT 

  • State Suggested Answer
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 429 subscribers
  • Views 3956 views
  • Users 0 members are here
Options
Related

Problem "Wrong target expression of grouped search" with latest update Trados Studio 2019 (15.1.4.55768)

Ignacio Niveiro

Ok, I have a problem and the reason for it is quite clear, in my opinion. However, identifying the exact cause and fixing it is another matter (a question of time, really).

Let me explain. Apparently the latest update in Trados Studio 2019 (15.1.4.55768) allows greater flexibility in QA checks as it allows usage of regular expressions in grouped search expressions. Particularly, this is the updated feature which I believe causes the problem.

Enhanced regular expressions in QA Checker to enable regular expressions to be used also in the targets of grouped search expressions checks (CRQ-13254).

While that new feature is all great and neat, it is not 100% compatible with older expressions. For example, if we had before the expression ($1)) to check in target, that might be a valid STRING expression but it is NO LONGER a valid regular expression. So, the expressions you have been working with for ages suddenly DO NOT work with this new update.

And unfortunately, you have no idea which one of the expressions is causing the problem as the error report is useless (that's why I am not attaching it here). When confirming the subject, the parser simply says this.

Error dialog box in Trados Studio displaying 'Wrong target expression of grouped search' with an 'X' icon indicating an error. The error type is 'System.Exception, mscorlib, Version=4.0.0.0' and the source is 'Sdl.Verification.QAChecker'.

And the problem is simple. I have a LOT of regular expressions (over 100) and I have NO IDEA which one is causing the problem. I can cut the possibilities because I know that one GROUPED SARTCH EXPRESSION is causing it, so I can skip the other, but I still have over 40. And that is something that should not be allowed. 

In other words, this new update is screwing up backwards compatibility in QA Checker 3.0 and its fixing it falls to the user, it's extremely cumbersome and the error report does not even say which is the expression giving the problem so we have to check all regular expressions ONE BY ONE.

So it would be nice if you considered it and found a fix for this. Perhaps expanding the error report would be enough, since I believe an automatic regex conversion mught be complex or risky.

Generated Image Alt-Text
[edited by: Trados AI at 4:39 PM (GMT 0) on 28 Feb 2024]
emoji
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0

     [UPDATE] After a couple of hours of intensive bug-finding, I found where this particular problem is (this same problem happened with a different regex a couple of days ago but I only decided to write after this new one issue).

    It turns out that if you have the following Regular Expression QA

    Regex Source: ([A-Z]{3}\d{4})(.*?)\.  This expression should match ISO3432 Electromagnetic Radiation.

    Regex Target: $1$2

    Grouped Search Expression - Report if source matches but not target

    The thing is that if the following string appears. 

    ISO3432.

    Then $2 is null. The expression (.*?) allows for zero length groups. Therefore the Regex Target $1$2 gives an error since $2 is a zero-length string.

    I don't think that should be the case. If $2 has zero length, it should be a zero length string and $1$2 should still make perfect sense. I believe this should not give an error. A different thing would be if we had in Regex Target:

    $1$2$3

    This indeed should give an error since there are NOT three groups (there are no 3 expressions enclosed in parentheses).

    But $1$2 should NOT give an error since there are 2 groups here. Only that one turns out to be empty. But empty does not mean non-existent!

    I WANT TO MAKE CLEAR THAT THIS UPDATE REFERS TO A PARTICULAR ISSUE THAT MERITS ITS OWN ANALYSYS (ZERO-LENGTH GROUPS), BUT THIS DOES NOT MEAN THE GENERAL ISSUE (THE DESTRUCTION OF QA REGEX COMPATIBILITY WITH THE PREVIOUS TRADOS VERSION AND THE DIFFICULTY OF FINDING WHERE THE PROBLEM IS) SHOULD BE NOT BE LOOKED UPON EITHER!)
  • 0 in reply to Ignacio Niveiro

    The zero-length string should not cause an error. This looks like a bug that was introduced with the latest update. https://www.regular-expressions.info/zerolength.html points out that PCRE Regex can be set to skip zero-length matches, in which case I assume $2 would indeed not exist and the error be correct.

    I wonder whether there was a reason to implement this function as it is now or whether it really is a bug. (To me, it looks like one.)

    Daniel
  • 0 in reply to Daniel Hug

    As far as I know, Trados uses the .NET 2.0-4.5 implementation of regular expressions, not PCRE. And of course, being able to have zero length groups allows for greater QA flexibility, so it should not be removed in any case.
Reply Children
No Data