Short date checking in QA profiles
Two approaches, with different purposes
In a recent article on the Translation Tribulations Substack, I discussed various regular expressions for identifying likely numerical short dates and some for making changes to them by means of find and replace dialogs. The information in that post can be used in quite a number of translation environment tools and text editing systems (basically any that allow regex searching and replacement operations). In memoQ, that would be the filtering fields above the source and target text columns of the translation and editing grid when the use of regular expressions are enabled, or in any of the Find or Find and Replace dialogs with regex enabled.
This filtering, searching and replacing is all manual work, and while that’s a good way to get started using regular expressions to gain confidence and visually verify that the expressions used are performing as expected, in many cases some kind of automation is desirable. In memoQ, this can be helpful in the following ways:
automated conversion of source language information (date formats, for example) to the required format in the target language in a way where the correct value can simply be inserted (by keystroke or pretranslation) into the target text,
checking target language information (such as date formats) against the source language during an automated QA check, and
checking source and/or target information during an automated QA check, with the possibility of one-click substitution of correct values if only the target language is checked.
The first two items are covered by auto-translation rules. I’ve shared a number of examples of these in previous articles, and I will discuss specific examples for numerical short dates in a separate article. These rulesets have considerable advantages when it’s important to convert source text information to specific target formats. At the most basic level, these can be fairly simple to create, but in many cases, inconsistencies in the source text can require quite a lot of “idiot-proofing” to allow for non-standard formatting or bad typing. So over time, many of these rulesets can involve into complicated resources that many may find difficult to understand without thorough, well-written documentation.
Automated checking of conversions governed by an auto-translation ruleset can be enabled on the first page of a memoQ QA profile, the settings configuration which determines what automated checks are performed during a QA run.
Only the auto-translation rules selected in the project at the time the QA run is performed will be applied.
The last item in the list can be accomplished using the Regex tab page of the QA profile. There it is possible to perform checks based on a number of different conditions.
The seven possible conditions for checking are framed in red in the screenshot above. Most of the difficulties I see people have with this page of a QA profile results from choosing the wrong condition, usually a matter of inattention when configuring multiple checks and forgetting to update the condition for a new regex. But too often people simply forget to mark the checkbox at the top, and then they wonder why none of their carefully crafted expressions seem to work in a QA run. So pay attention!
From that list of seven conditions, I consider two of them to be relevant to checking numerical short dates:
missing regex replacement in target and
forbidden regex match in target (the last option).
Here’s an example of a configuration to check for the correct conversion of DDMMYYYY numerical short dates (with various separators) to the correct US format MM/DD/YYYY where the style guide specifies single-digit values for the day or month must be preceded by a zero:
Automated correction (via button click) in the resolution window for the QA check isn’t possible with those regexes, because they reference the source text. If you want that possibility, it is necessary to write some checks only for the target text:
Something like those last three rules in the screenshot above is also a useful backup for cases where the source text may express the date in another way, and the desired format for the translation is a numerical short date in any case. The condition chosen, forbidden regex match in target, refers only to the translation, and so autocorrection is possible in the QA resolution window:
Clicking the button framed in red in the screenshot above will substitute the correct value 07/07/2015 in the target text of Segment 4. And doing so will also take care of the other error message for that segment.
Of course, the methods described here apply to a lot more than short dates, but I think these provide simple examples for learning how to work with the Regex tab page of a QA profile.