ApSIC Xbench is one of the best quality control tools for translators. It ensures the consistency of our texts, helps follow glossaries and other reference materials, and minimizes oversights. It also allows us to create our own checks, which reach their full potential when we use regular expressions and store them in checklists. For example, we can encode our client's style guide so that Xbench indicates the parts of the text that do not comply with it with just the push of a button.

Xbench has two main versions: 2.9, which is free, and 3.0. Both can be downloaded from the official Xbench website.. Although its licensing system is extremely flexible and easy to use, it is not difficult to imagine situations where some team members use the paid version while others prefer the free one. It may also happen that a translator starts using the free version before deciding to purchase version 3.0. In any case, doubts often arise about the reuse of resources between one version and another.

Can the same checklist be used in 2.9 and 3.0?

Any checklist can be imported into any version of Xbench. However, when changing versions, some of those checks might not work as expected. These differences between versions can come from three sources:

• Changes in the syntax of regular expressions.
• Error correction.
• Addition of new features.

Changes in the syntax of regular expressions

The same expression can yield different results in different versions:

This change was introduced in version 1216 of Xbench 3.0. Before this version, the syntax of 2.9 and 3.0 was the same. Fortunately, there are only four operators whose behavior varies:

: End of word
^: Start of segment
$: End of segment

Moreover, this difference only occurs when they are followed or preceded by an expression that can be empty. That is, when we combine them with these other operators:

?: The previous character is optional.
*: Zero or more repetitions

This situation is the one that occurs in the previous example. In principle, the expression <i?phone> should only find phone and iphoneHowever, in 3.0 we see that it has also found telephone because after the change in question, the word start operator (<) only intervenes if that i exists. To achieve the desired result, it would be necessary to introduce groupings with parentheses, so that the < operator cannot affect an empty expression:

<(i?p)hone>
<(i?ph)one>
<(i?phone)>
Etc.

These parentheses are considered unnecessary in all common regular expression syntaxes. Perhaps for this reason, shortly after, they annulled this change, but it seems only partially: it was reverted with the end-of-word or segment operators, but not with the start ones. The following table illustrates this inconsistency and how the syntax of these operators changes between versions. The cells in green indicate a match with version 2.9 and the numbers refer to the version of Xbench 3.0, not to the evolution of regular expressions in the Middle Ages:

Search	Until 1186	1216-1243	Since 1266
phone o iphone	<i?phone>	<(i?phone)>	<(i?phone)>
phone o phones	<phones?>	<(phones?)>	<phones?>

Bug fixes and new features

Other possible sources of differences between versions are bug fixes and the incorporation of new features. Some of these corrections affect the behavior of regular expressions, so they must be taken into account when switching from one version to another. For example, until version 1336 of Xbench 3.0, all hyphens had to be escaped with the escape character so that they were not interpreted as an interval operator. In the final summary below, there is an example of this case ( the Super-8 example) and others similar.

Regarding the new features, special care must be taken when using character normalization. A practical example would be searching for videoWith character normalization enabled, it would find both video and videoIn the versions that don't have this option, it would only find videoFortunately, there are several alternatives that would work well in all versions, such as the following:

v[ií]deo
v(i|í)deo
video|vídeo

Summary

The checklist files . xbckl files can be loaded without any problem in any version of Xbench regardless of the version in which they were created. However, many checks can lose their effectiveness partially or completely if they are not adapted for each version, especially when regular expressions are used.

Here are some tricks to improve the compatibility of your regular expressions between versions:

• If segment or word start operators are followed by an expression that may be empty, surround that expression and at least one other character in parentheses:

<(i?phone)> rather than <i?phone>

• Protect all your hyphens with the escape character as long as they are not the interval operator or the PowerSearch exclude operator:

Super\-8 rather than the Super-8 example

• Don't use the end-of-word operator before the end-of-segment operator. It is redundant and that combination does not work in older versions:

Sincerely$ rather than Atentamente>$

• To search for repeating asterisks, use their hexadecimal code:

(\x2A)+ rather than \*+

• Avoid character normalisation:

[:alpha:]+ or [a-záéíóúüñ]+ rather than [a-z]+

Final thought

Given that version 2.9 has been frozen since 2013 and that 3.0 is still evolving, it is likely that this gap between versions will increase over time. This would even be desirable if the current syntax is extended to support less voracious regular expressions (which can be lazy instead of greedy), more than nine variables can be defined, or include zero-length assertions such as lookahead and lookbehindconstructs. Achieving backwards compatibility would be more complicated, but it would be worth it for the higher level of sophistication that many checks would achieve. It is the hope, in short, that this first blog entry will be obsolete as soon as possible.

Postscript. On re-reading the entry it sounds strange to wish that the premiere of a blog will soon be obsolete. Borges said of newspapers that they are deliberately written to be forgotten. Perhaps the same fate is in store for blogs. He also explained a kind of immortality of intelligence in which ‘every time we repeat a verse of Dante or Shakespeare, we are, in some way, that instant in which Shakespeare or Dante created that verse’. Now it is not impossible that the reason for this entry is to relive the moment when Borges said that ‘if at the end, when the work is finished, the author thinks that he has done what he set out to do, the work is worthless’.