Get better dates with memoQ

There's hope for all those incels stuck with RWS Trados Studio, Memsource, Wordfast, OmegaT and a host of other horrors if they are willing to make a change....

Not surprisingly, dates can be a real nuisance to translate and check, depending on the client's specifications. Target language specifications that include the use of elements such as non-breaking spaces can be particularly troublesome. But even apparently simple tasks like writing all dates in the target language as DDMonth-AbbreviatedYYYY or the like can go wrong far more than expected, and skilled reviewers easily get caught up in the flow of the text and overlook details of format (and often even correct content) in dates. This proved to be a shock to one LSP client who found hundreds of overlooked date errors in a large volume of recently reviewed text.

What's the solution to these inevitable human errors? Proper automation of the monkey work so professionals can concentrate on what they are good at: a fluent text that accurately reflects the intent of the original.

In the case of the QA horror of checking four source languages to ensure the dog's breakfast of date input formats (which also included day+month and month+year entries) regardless of capitalization, memoQ enabled a simple auto-translation ruleset to be created (a few hours' work, including testing and documentation); this was then attached to a project using a QA profile configured to check only against the enabled auto-translation rules, and BOOM! after about a minute, all the date errors in something like 100,000 translated words were revealed. The only false positives found were a few instances where times were written after the date, and the rule can be updated easily to avoid this issue.

I do a lot of date rule development for many languages, and I've published some of this in simplified forms on this blog. But interesting new tricks come up all the time. And I've found it useful when developing rules for others, who usually understand little about writing proper specifications that capture all the likely source input, to create special screening rules like the one shown in the first screenshot, which can be used to examine an entire large TM imported to the memoQ working grid, and see how the input and target texts vary. I used that expression on two large TMs in a view, and in just a few seconds, my laptop screen showed me all renderings of every English date in those TMs into Portuguese. While researching target formats for some new rules I also found quite a number of errors in the TM which I could have corrected had I cared to.

Having rules like this available in the translation phase can prevent quite a few errors to start with. I've found too many cases of dates in March translated as May and overlooked by both the translator and the reviewers. memoQ is - as far as I know - the only tool which will offer such conversions in a results table from which they can be inserted just like any other "terminology hit".

Other tools like RWS TradoZe Studio will allow you to use regular expressions for quality assurance (checking the text), but I'm not aware of any tool other than memoQ which allows you not only to include these checks in customized QA profiles but which can also provide them for on-the-fly review from a library of named expressions. That's what memoQ now does in version 9.8 (scheduled for release in June, within a few weeks) as shown in the first screenshot above.

This new rules library feature of memoQ makes it possible for the first time for users who have a life which does not involve wasting brain cells learning to program regular expressions to use the efforts of those who actually like that sort of thing and do it well. So with this tool, anyone can easily check for things like date errors and a lot more without knowing a single bit of regex syntax. That's some progress :-)

Stuff like dates just keeps getting better for memoQ users, leaving them more time for life and better stuff... like other kinds of dates.

If this kind of thing interests you, I think my friend Marek Pawelec may be teaching an in-person course in regular expressions for memoQ in July of this year, and he, I and others (including memoQ's Business Services unit) are available to help you with turnkey solutions to project challenges like those described here.

"Faulty" memoQ light resource defaults and how to change them

So often in the decade since I began using memoQ, I've felt an undercurrent of irritation at some of the default settings for certain types of resources, and with the need to switch these resources manually in so many projects. But with so many other pressing matters, I didn't really focus on the problem until a participant in last week's summer school course at Universidade Nova in Lisbon expressed the same irritation with regard to the default QA settings.

QA settings are probably the most familiar irritants to many memoQ users. Some have declared memoQ QA to be "unusable" because of many false positives or a failure to check certain things, and these opinions are usually unfounded and reflect a poor understanding of the available options and how to use them. But even those of us who do know how to use them get caught out by forgetting to change the QA settings to our favorite profiles on many occasions.

No more. If, for example, you want to change the memoQ QA default settings, it is very easy to configure them to match your preferred profile. I started off by cloning my empty QA profile, a template file that I maintain in which no checks at all are enabled. This is the starting point I use for custom QA rule sets in memoQ.

I then edited the renamed file and configured it with the terminology, auto-translation rule and tag settings I prefer in routine cases, leaving many of the usual, irritating memoQ QA defaults disabled. Then I exported the MQRES file as a backup and opened it in a text editor.

There I copied all of the text starting with the XML declaration (skipping the MemoQResource header), and I looked (for example, in the Resource Console, though the Options and Project Settings would do as well) to see where the default resource was located:

Then I went to the file location...

... opened the file, and pasted the copied text of my desired settings into the file:

Default resources (as well as already-imported light resources) do not use headers. Then I saved the new default file and closed it. Then I started memoQ again and make a copy of the Default file for QA settings, and used the editor to examine its contents, which matched those I had pasted into the file for the QA option defaults.

I'm not sure (yet) whether these defaults will be replaced when bugfixed builds or new versions are installed, so I am keeping my exported custom QA configuration as a backup in case I need to do this again. And I will be looking at other light resources which might benefit from this approach.

I had originally considered setting my empty QA profile (with nothing set) as the default until I realized that this could lead to a false impression that nothing of interest was wrong if that default profile is accidentally chosen (or not deselected, rather) for a quality check. Then I realized that the best default to use would, of course, be the settings I use most frequently.

One objection to this procedure raised on social media is that one can set the default for new projects in the memoQ options under "default resources". However, this does nothing for projects which already exist. In these, the change would have to be made project-by-project. And for users who tend to re-use projects for a particular client rather than use the powerful, but somewhat confusing project templates feature, this is a real time-consuming nuisance. Changing the installation-level defaults automatically changes how QA is done in all the exiting projects that use "default" QA options.

memoQ as an instrument of bowdlerization

Recently in a memoQ user forum, someone asked if the environment could be used to ensure that certain words would be kept out of a target text. 

The question wasn't clearly understood at first: some thought the asker wanted to ensure that certain words were not translated and suggested the use of non-translatable lists, others pointed out that the memoQ term bases have an option to mark certain term translations as forbidden, which would be indicated by a black color in the Translation Results list, for example:

But no... what was wanted was indeed a monolingual list to ensure that the target text did not contain certain words, regardless of what the source text said.

This is indeed possible in memoQ:

The red box in the screenshot above marks a word on such a forbidden list, which is in an English to English (US) revision project I set up to clean up Mark Twain's 1601 and make it fit for teaching in Sunday school. The presence of a no-no is indicated by a little lightning bolt icon for a QA warning. Actually running a QA check for terminology gave the following result, a list of forbidden expressions (with some alternatives suggested):

How is this done? With an ordinary memoQ term base. One can make a term entry only for a single language - the target language in this instance - and mark the Forbidden term checkbox on the Usage tab.

If there is no source term (or in my example above, where the source and target language are variants of the same language), there will be nothing shown in the translation results list, but if there is a termbase entry marked forbidden which is found on the target side, then a warning will be displayed in the translation and editing grid if the QA profile currently selected for the project includes terminology. (If the QA profile does not include appropriate term checking, no warning will be displayed for segments in the grid, nor will the forbidden words be indicated when QA is run. The Default QA profile does include term checking, but I use a lot of different profiles focused on fewer issues, such as just tag checking, so I have to pay attention to this detail.)

Building such a list word-by-word with manual entries is tedious. So it's probably easier to import your monolingual list of words to avoid from a text file or an Excel sheet, and then in the memoQ Term Base Editor, select a range of terms (like all of them) and set the desired forbidden status for the entire selection:

Bulk changes to any term properties are possible this way as I showed some time ago in a short video tutorial.

The critical setting for the scenario described here is marked with a red box in the QA profile below:

As you can see, the source text can also be checked for forbidden expressions if that option is also selected.

I have created a dedicated termbase to track forbidden expressions in three languages. Lists - monolingual or otherwise - of forbidden expressions can be maintained in one or more term bases or the expressions can be kept in a more ordinary term base. If barring certain common expressions in one or more languages is important to you, it might be convenient to maintain this information in a dedicated term base.

And for recent versions of memoQ (8.4 and later), make sure that the term bases you want to use for quality assurance are marked on the Term bases page of Project home. Here it's not a good idea to use your larger translation term bases for QA, because these may result in rather large numbers of false positives. Optimum term properties settings for translation and quality assurance are often not the same.

Thus memoQ can be used as a powerful tool to avoid embarrassment from an unfortunate choice of words and to adapt the target language to fit a particular audience better. Thinking back to the time, years ago, when a friend who ran the translation department at a conservative German company nearly got fired for writing that a certain software operation could be performed at the touch of a penis (a Freudian slip after he and some other translators were joking about how sick they were of a certain phrase in the user documentation) and remembering the sensitivity to terms I have seen with some clients (at the same software company, the term FAQ was banned, because executive management was afraid that it might be pronounced like fuck), I can see how this somewhat unusual approach to terminology in memoQ could be a job-saver for some.

All-round Translator Terminology Workshop Pre-event Webinar

As previously announced, on June 30th in Amsterdam, the All-round Translator (ART) is offering the workshop "Coming to Terms: Mining & Management" covering a range of practical topics for applied corpus linguistics, optimizing terminology management and efficient sharing of terms in teams. This technical workshop will cover a range of tools and techniques as described on the ART event page.

A month before the Amsterdam workshop I will be presenting a free webinar offering an overview of some of the material planned for June as well as related topics with a particular focus on one of the tools I use most - memoQ - with highlights of recent improvements in its terminology features with memoQ versions 8.3 and 8.4.

This webinar is open to anyone interested regardless of whether or not they plan to attend the June workshop. The talk will use Zoom, which I adopted for remote teaching of corporate clients and others because of its greater versatility and superior recording facilities compared to my old favorite, TeamViewer. (Technically it's also a "meeting", not a "webinar" in Zoom-speak, but that's a distinction without a difference for people who don't feel up to 50 simultaneous speakers and 10,000 viewers.) The platform is free for participants to use, and if I'm not mistaken, a web browser can also be used, though interaction is more limited via that medium. (Don't ask me how, I am still gathering experience with this tool and its myriad options.)

The presentation (approximately one hour, starting at 4 pm Central European Time = 3 pm Lisbon time on May 24th) is free, but registration is required: the link for that is here.

Come to Terms in Amsterdam, June 30th

At end of June this year I'll be doing an expanded, in-person reboot of my occasional terminology workshop with new material and workflows for those who want to do more to control quality and improve communicative vocabularies in interpreting, translation and review projects.

Space is limited at the All-Round Translator event, but I hope you can join us to learn about

• Better teamwork through timely terminology sharing
• Faster, more effective discovery of frequently occurring specialist terminology
• Better access to critical terminology in many environments
• More efficient and accurate QA for terminology
• More accurate, efficient and fault-tolerant term use when translating with memoQ
• Greater flexibility to meet client terminology needs

The Early Bird rate for the workshop is €99 + VAT until the end of April, €120 + VAT  thereafter.

The content is applicable to work with many translation environments, but some segments will share particular tips for maximum productivity using the unbeatably practical memoQ environments.

Double Vision with MS PowerPoint to Check Translations

I learned an interesting thing tonight thanks to David Hardisty, who teaches translation technical skills at Universidade Nova in Lisbon and translates quite a bit from European Portuguese to English. For all the years - decades? - that I have used Microsoft PowerPoint, I was never aware that it is possible to run two different presentations - as presentations - at the same time.

Why is this useful? If you want to do a detailed, screen-by-screen comparison of two different presentations - say a German original and its Arabic translation - and ensure that everything looks OK with the with animations, effects, text sizing in fields, etc. this can enable more focused, accurate comparisons. Just clicking through the slides in two windows in edit mode might miss something that depends on dynamic elements in the application.

Here's how you do this:

1. Open the first PowerPoint file.

2. Go to Slide Show... Set Up Slide Show... choose Browsed by an individual (window)

3. Click OK. Then press F5. Resize the presentation window as you like and put it wherever you want on one of your screens.

Then repeat Steps 1 through 3 for the second presentation. And the third if you like. And....

On a TEUR with German financial translation

Currency expressions occur in great variety in German financial translation, and it is often a great nuisance to type and check the corresponding expressions, correctly formatted, in the target language. One group of such expressions are those involving thousands of euros, typically written in German as "TEUR". However, depending on the proclivities of the source text author, other forms such as T€, kEUR or k€ may be encountered.

On the target side, clients might want to see figures like "TEUR 1.352" rendered in a number of ways: perhaps EUR 1,352 thousand, perhaps €1,352k, perhaps something else.

I have described before how to map out source and target equivalents for developing auto-translation rules or regex-based quality checking instruments to use as the basis for development specifications and case testing as well as how to document the structure and reasoning of the respective rules.

Here you can download an example of possible solutions to the specific problem described above. The downloadable ZIP archive contains two different rulesets for each of the English target text formats cited above; these may be adapted to fit the particular requirements of a client as needed.

There are, of course, quite a number of other currency expressions one routinely encounters when translating financial texts or other business documents, and the diversity of client preferences for target language formats can be considerable. In many cases, it is worthwhile to document which rulesets correspond to which client's preference, perhaps even including client names in the filename to keep things straight. Thus "KPMG_TEUR-to-English" might be the  ruleset name for the client KPMG's preference for how to translate those particular expressions to English.

Busy financial translators who use memoQ and who have discovered the benefits of rulesets like these tell me time and again how many hours or days of effort are saved routinely by using tools like these in translation and subsequent quality checks. They are a "secret weapon" in an often competitive environment with a lot of short, stressful deadlines.

Those who wish to have rulesets of their own to handle the specific requirements of their clients can turn to a number of sources for help. Kilgray's Professional Services department can develop custom rules, as can competent consultants such as Marek Pawelec or yours truly. One caveat: in hiring development experts for memoQ tools based on regular expressions (regex), it is generally a good idea to work with consultants whose primary focus is memoQ. Regular expressions are used in many other environments, such as Apsic Xbench and SDL Trados Studio (as well as many others having nothing to do with translation), but without an intimate, daily working acquaintance with memoQ, developers are often unable to understand the best approaches for working with the memoQ environment and it is all too possible to spend a lot of money on custom work which proves to be unusable, for example because the complex rules take many minutes to load each time a project or document is opened, because the developer did not break the problem down efficiently into its component parts. But done right, these rulesets are an investment which can pay enormous dividends for many specialist translators.

First month with SDL Trados 2017

A month ago, when I announced the Great Leap Forward from my rather neglected SDL Trados 2014 license to the latest, presumably greatest version, SDL Trados 2017, after seeing how wet the largely untested release of memoQ 8 (aka Adriatic) has proved to be, there was some surprise, as well as smiles and frowns from various quarters. It's been a busy month, and I am still testing options for effective workflow migration and exchange (useful in any case given how often memoQ users work together with those who prefer SDL tools) as well as discussing the good and bad experiences of friends, colleagues and clients who use SDL Trados Studio 2017.

As can be expected, this product has more than a bit of a bleeding edge character, though on the whole it does seem to be a little more stable and less buggy than memoQ Adriatic so far, with fewer what the Hell were they smoking moments. However....

I was a little concerned at the report from a colleague in Lisbon that the integration of the plug-in for SDL Trados Studio access to Kilgray Language Terminal amd memoQ Server translation memories doesn't work with SDL Trados 2017 after functioning so well in SDL Trados 2014 and 2015. Despite the stupid inter-company politics between SDL and Kilgray, which hindered the approval of the plug-in so that a warning dialog appeared each time it was loaded in SDL Trados Studio (bad form by the boys in Maidenhead), it was a great tool for users of SDL Trados Studio and memoQ to share TMs in small team projects. I was very happy with how it worked with SDL Trados Studio 2014, and I am very disappointed to see that API changes in the latest version have bunged things up so that Kilgray will have more work to re-enable this useful means of collaboration. I hope that SDL will see fit to be less petty and more cooperative with the upcoming "fixed" plug-in! It is in their interest to do so, as this makes it easier for SDL Trados users to stick to their favorite tool while working on jobs for or with those who prefer memoQ as their resource. Better work ergonomics for everyone and no BS with CAT wars.

I was pleased to see that SDL Trados Studio has added AutoCorrect facilities recently. And they seem to work reasonably well in English and mostly in German, though there was a strange quirk which hamstrung the "correct as you type" feature. That setting took a while to "stick" somehow when I tested it first with German. It was fine for Portuguese too. However, Ukrainian and Arab colleagues can't get it to work for some reason. I did not believe this at first until a colleague in Egypt showed me live via shared screens in Skype how the autocorrection simply failed to activate. Perhaps this is an issue with languages that don't use the Roman alphabet, so I suppose colleagues in Russia, Serbia, Japan and elsewhere may be tearing some hair out over this one. It doesn't affect me directly, but it looks like a pretty serious bug that ought to be addressed ASAP.

SDL generally kicks some butt with regex facilities in SDL Trados Studio; customer service guru Paul Filkin has written a lot about these features on his Multifarious blog, and most advanced users of the platform make heavy use of regular expressions in filters and QA rules. For a long time, memoQ users could only look on in envy at all the excellent possibilities before Kilgray belatedly added more regex options to its work environment. However, there are a few raw rubs remaining.

My Arabic translator friend pinged me recently to ask if I was aware of the "regex trouble" in the latest Studio version. He made heavy use of these features for Arabic and English work in some rather amazing, creative and inspiring ways (I had not imagined) in earlier versions of SDL Trados Studio, and some of these features are rather broken at present in SDL Trados 2017. He gave me a very useful tutorial (which I had planned to beg him for anyway soon) in the use of regex in SDL Trados Studio for basic filtering, advanced filtering and QA checks. Overall I was very impressed with the possibilities, but the failure of some regular expressions which worked well in the advanced filters to work at all in the basic filter or in QA rulesets was very disturbing. We argued a little about what the basis of the problem could be in the software programming, but it is a major problem which limits the functionality of SDL's latest software severely and should cause advanced users and LSPs to wait and watch for the fix before upgrading to the latest version. The persistence of such a major flaw in such an important area as quality assurance some 6 months after release is frankly shocking. I hope this will be addressed very soon so that I can migrate and upgrade some of me favorite QA routines from memoQ.

Last but not least is an irritating bug in an auxiliary feature for what has always been one of my favorite terminology tools, MultiTerm. It was the first Trados product many years ago, and despite many quirks over the decades, it remains one of the best. Face it: the memoQ terminology model is OK for most practical uses, but for maintaining high quality corporate terminologies tracking many important attributes it is hopeless garbage. Most other CAT tool terminology databases and glossaries are far worse. MultiTerm sets the standard today still for affordable, flexible, powerful terminology management. For 17 years I have used this excellent platform for my best terminologies for my best clients and delighted in its output management options (even when they can be a pain in the butt to configure properly).

When I want to access my high value MultiTerm resources while translating in memoQ or working in web pages or MS Word, I use the convenient MultiTerm widget to access the data. However, I am very disappointed to find that recent versions do not display the attributes for terms when the widget is used for lookup. Damn. That makes the results just as annoying as the lobotomized MultiTerm/TBX imports into memoQ. I really hope that SDL fixes this flaw ASAP and remains on top of the terminology game with MultiTerm and its lookup tools as a valuable resource even for translators who hate Trados Studio and won't use it.

Overall I am seeing a lot of nice things in SDL Trados Studio 2017, and I would say it is probably more mature and stable than memoQ 8 at this point. But it really is just a late-stage beta release, and more fixes are needed before I can trust it for routine production work. We are all better off for now to stick with the prior versions of both SDL Trados Studio and memoQ.

Planning special rules for structured "expressions" and multi-word abbreviations

Translators and editors often deal with what I'll call "structured expressions" or "patterned data" in many forms, which include:

• long and short dates (2016-01-13; 1/13/16; 13.01.2016; January 13, 2016; 13th January 2016; etc.
• time expressions (14:35; 2:35 pm; 2:35 PM; 2:35 p.m.; etc.
• currency expressions (EUR 2.3 million; € 2,300,000; €2.3m; etc.) 
• legal references (Section 14a paragraph 3 line 2; section 14a (3) line 2; etc.
• bibliographical references for chapters, pages, margin notes, etc.
• and much more.

There is also a wealth of abbreviations for multiple word expressions in some categories of text; favorites in German include:

• in Verbindung mit (variously written as i.V.m., i. V. m., iVm or some typoed hybrid of the aforementioned with spaces and periods included or forgotten depending on the authors' preferences and degree of care)
• im Sinne des (i.S.d., i. S. d., iSd, etc.)

These can be devilishly hard to check efficiently for consistency or other quality factors in a long text, and for the translation, there is often no single "right" way to format the target text equivalents, with many individual preferences to be found with translation buyers. Even with a good style guide (all too rare anyway), these issues can be challenging time-wasters.

Translation assistance tools such as Apsic Xbench, SDL Trados Studio and others, even memoQ, have various approaches to making life easier for a translator or editor faced with these challenges. Unfortunately for most people, these approaches usually involve the use of "regular expressions" or "regex" as nerds affectionately call it. Not an easy thing even for many hardcore techies!

On past occasions when I have written about the use of regex in translation tools, I have usually stated clearly that the best approach for the best, most reliable results is to have the regex "rules" for handling the text developed by a knowledgeable third party. The experts who deal with this stuff routinely can often reduce a task that would take a semi-skilled person like myself hours or even days to the time for a coffee break, and even if a task takes a while and runs up a bit of a bill, it's much more likely to be done right the first or second time.

But... there's a catch usually. Most of these regex fireaters are not skilled in mind reading, many are not translators, and even those familiar with translation challenges might not be familiar with your working languages or your particular subject areas and their possibly unique challenges. So effective communication is really, really important (it always is, of course, but here even more so if you are dealing with a verbally challenged, monolingual math freak who might be your local expert for regex).

Even for areas I know reasonably well and languages I more or less master, I am often frustrated by help requests from colleagues and clients who need special rulesets developed for a client's preferences for date and currency information, because the request is not clear in its scope and detail, and many important cases are left out, so the end result is not fully satisfactory.

Over the years and with a lot of back and forth (sometimes inside my own head with yours truly as my nightmare of a "client"), I have developed a system of simple documentation for planning and testing rules to help translate and quality check patterned information or multi-word abbreviations. This system provides an easy structure for non-techies (or even hardcore techies) to organize the help request for most efficient handling. Here is an example of part of such a planning sheet for a recent project involving Arabic:

When the time comes to test, just copy the source text column into a separate file, add whatever variations you want to the examples to test your accomodation of typos, etc. and then load that file as a "translation text" for testing in your working environment. If you have the same information for another, overlapping language pair, such as German and English, it is easy to couple that to make a ruleset which maps multiple source languages to a target language. An example of such a result is a memoQ auto-translation ruleset for mapping long dates and month-plus-day dates from German, English, French and Spanish into Portuguese which can be obtained here.

This simple, tabular approach to data collection to plan regular expression rules has made me a lot more efficient at such tasks and faciulitated the re-use of data to make new rulesets for clients and colleagues (or myself) as needs arise. The liberal commenting of examples can be very helpful; information to include which could affect rule structure might involve capitalization, location in a sentence, variations or differences in particular contexts, etc.

For my own work, rulesets include a series for dates, currency and legal reference formats from German to English for generic and client-specific use for US and UK English. With the help of these tabular planning sheets, I can adapt any of these quickly for most other languages.

For tracking the development of rules and their improvement history I have another set of templates which I use for systematic planning and identification of areas to improve. That will be discussed on another occasion.

Building a regex-savvy "termbase" in memoQ

For years I have been frustrated by and dissatisfied with how abbreviations are handled in the current memoQ termbase model. The crux of the problem is the handling of the periods in the expressions. This can be seen with termbase entries like the following, for example:

If the abbreviation "Art." appears in the source text, only the second source entry - the one without the period - will give a match result in memoQ. The first entry is simply ignored.

An additional problem which one would face, even if the terminal period character in the term did not pose a problem, is that authors are often notoriously variable in the way they write abbreviations. Take, for example, the abbreviation for the German expression "in Verbindung mit", usually written as "i.V.m."

In recent legal translation work, I have encountered this expression written as above, but also as "i. V. m." (with spaces), "iVm" (no spaces no periods) and sloppily typed variations like "iV.m" or "i. V.m." What's a poor wordworker to do?

The answer came to me while refining a set of auto-translation rules for bibliography formatting and legal references. These, too, can suffer from similar troubles: "page 7" might be abbreviated as "p. 7", but in the sloppy chaos of source texts poorly edited one might find "p.7", "p 7", "p7" or even variations with the letter capitalized, like "P.7". If you are translating nearly 1000 references in a bibliography, robust shortcuts are very helpful and save a lot of time, and if those shortcuts are based on memoQ auto-translation rules, they can also be used in a QA profile to ensure that every bit matches correctly.

As the screen capture from a memoQ Facebook group above suggests, the way to go about this is to identify which parts of the expression might vary with different deliberate and accidental typing. These are usually spaces and periods in the case of abbreviations; sometimes, particularly with German legal abbreviations, capitalization and dashes may play roles as well. (I tore my hair out not long ago trying to understand an Austrian legal text referring to two laws, which differed in their three-letter abbreviations only by a dash inserted after the first letter of one.)

In regular expressions, the question mark character means "zero or one" of whatever character precedes the question mark. So if I want a rule that acts in the case of one or no periods, I put a question mark after the period character. And because in the language of regular expressions, a period is shorthand for any character, if I want to talk about an actual period ("."), I have to precede that character by a backslash ("\."). In the technical jargon of Nerdworld that is known as "escaping the period" and there is no escaping such syntax if you want a regular expression rule about periods, period.

Spaces (normal or non-breaking ones) are represented by an escaped lowercase "s": "\s". So a matching rule for the English abbreviation "e.g" which catches a lot of typing variations might be

e\.?\s?g\.?

And in German, the target replacement rule might be

d.h.

Of course, if a typist is sloppy, there might be more than one space, or a comma might be typed accidentally instead of a period (the keys are adjacent, and if your screen is as dirty as mine gets sometimes, your eyes might not notice); capitalization might also differ accidentally or based on context. The regular expressions for matching can be adapted to handle all these cases if need be.

Rules of this type are not particularly difficult to construct, but refining them to accommodate all the variations you are likely to encounter may require an expert hand. Thus, as I have suggested before,. the average user should focus on documenting all the possible source variations clearly in a table which includes the desired target equivalents, and this table should be given to an expert (Kilgray support, a qualified consultant like Marek Pawelec or a technical programmer familiar with regular expressions and their use in memoQ). Trust me, this will save a lot of frayed nerves and probably significant time and money as well.

So now I am building a few memoQ auto-translation rulesets which are essentially fault-tolerant abbreviation glossaries. These, together with the similar rulesets for formatting bibliographical references and references to sections, paragraphs, lines, margin notes, etc. in laws, have been very helpful in reducing the time spent translating messy legal source texts, and the accuracy of the work has been improved significantly. Give it a try for your translation challenges!

Go Figure (with memoQ!)

When translating patents, legal briefs, reports, manuals and many other kinds of documents I inevitably encounter figure references to photographs and illustrations in the text as well as the labeled captions for these. In this morning's translation of a petition in a nullity suit, one such reference takes the form in Verbindung mit Figur 1,  but it might just as well appear as

Fig. 1

Fig 1

Abb. 1

or

Abbildung 1

in this or some other text; in documents with multiple and/or sloppy authors I might even find a mix of all these in the same text.

As I value consistency in writing even when the client might not care, I try to translate all of these to the same form in English where it makes sense to do so. That might be Figure 1 or Fig. 1 depending on the situation and the styleguide stipulated for the project.

But when I finish the 10,000 or so words for this job and need to do my final check before sending it to the client, I expect to be a little tired, and I want to use my attention and energy to focus on the accuracy and reading comfort of my translation. In doing so I tend to miss little details like the occurrence of "Fig. 1" on page 32 as opposed to "Figure 1" on the other 40 pages. That is why I use the QA feature of memoQ to check the consistency with which I have translated the figure references as well as other matters such as the accurate use of special terminology for the project.

The specific feature I use here for quality assurance is

an auto-translation rule set (aka "autotranslatables"), which is highlighted and selected in the screenshot of the project's settings above.

As I have stated many times before, autotranslatables should be used, but not created by the average translator. Aside from the fact that the regular expressions involved are not particularly easy even for most of the nerds among us, there are a lot of little subtleties that make the difference between a well-functioning rule set and annoying garbage, and even the "experts" struggle with this for sophisticated rules.

But the present example of Figure mapping is a comparatively simple case which can illustrate the principles and some of the "risks" to mere mortals.

My rule set for mapping figures from many German forms to a particular English form consists of a single rule.

All of the possibilities that I expect in German are compiled in a list, along with the English expression for each, and this translation pair list is named #figurelist# and is found on the corresponding dialog tab in the memoQ rule set editor for autotranslatables. (I usually edit rules externally in Notepad++ where I can comment them liberally, but in this case I felt no need to do so.) This named list is used as a variable in the regular expression for the rule to describe a source text match.

(#figurelist#)\.?\s+?\b(\d+)\b

Jeepers. That regex for the source text looks complicated, doesn't it? Wouldn't (#figurelist#) \d+ be just as good? After all, it seems to work just fine. Well, except that the list would need a few extra entries to account for abbreviations with and without periods.

No. "(#figurelist#) \d+" is total, incompetent crap. Here are some reasons why:

• It is more efficient to express the possibility of a period after the text for "Figure" with the regex "\.?",  because you'll never have to worry about abbreviations with or without periods in your lists. Mine will get longer, as I'll probably expand these rules to cover Portuguese as well and use the same rule for both Portuguese and German sources.
• There may or may not be a space or even extra spaces after the Figure expression. Simply typing a standard space after the (#figurelist#) group means that it must be present and it must be an ordinary space to match. If it's missing or someone typed a non-breaking space (a reasonable thing to do to keep both parts of "Figure 1" on the same line), the rule will not work! Using \s+? to express the possibility of 0 to n spaces after "Fig." or whatever is in fact the right way to go.
• If you test the "simple" crappy regex, you'll also find that "Abb. 14" gives to results: Figure 1 and Figure 14. That is because the rule does not stipulate that the second part must be a whole "word", so the substring match with the first character also gives a result. Bad, bad, bad. The chaos that this sort of mistake can cause with more complex rules like currency expressions used in important financial translations is frightening.

The regex for the result also appears more complex than it should be, but there is a reason behind that as well. Instead of the simple $1 $2 (first group followed by a space followed by the second group), I specified output with a non-breaking space, because it looks rather unfortunate to have a line wrap in the middle of the expression for a figure. One sees that a lot, because it's a nuisance to remember to type non-breaking spaces all the time on the keyboard. This rule can also be used to check the use of the non-breaking space; an ordinary space will generate a warning when the memoQ QA profile is run with the autotranslatables check activated.

There are many ways in which regular expression rule sets can enhance the user experience and the quality of translation results when working in memoQ. It is not hard to use these rules, but it is beyond most users to create and maintain their own rule sets. Therefore

• Kilgray should include more useful examples of rule sets (in addition to the very helpful number rules) in future releases of memoQ
• The average user should ask the help of Kilgray Support for simple rules they need (in most cases this would fall under the usual commitment of paid support and maintenance for the year)
• memoQ users should work with Kilgray's Professional Services department or other competent consultants to devise robust rule sets to boost their translation and quality assurance productivity. Beware of casual advice found in forums or social media; much of it does not consider issues like the problems described above despite the aggressive insistence one might see for a particular "solution". Truly, you get what you pay for :-)

Post scriptum:

An yet ye hack by night and sun, the work of regex be never done.

Of course something was forgotten in the example here. The myriad styles and customs of source text authors will inevitably offer up challenging variants to break your well-crafted rules. Today's is a text full of figure references like Abbildung 4.12, which would refer to the twelfth figure in the fourth chapter. For this the modified rule might be 

(#figurelist#)\.?\s+?(\b\d+\.?\d+?\b) 

Or perhaps not quite. Try it and you'll see a few problems. This is just another example of why it is good to make use of professional resources to help you with these challenges and to have a systematic way of recording and elaborating them. I'll explain more about such an effective system for planning and documentation in a future article. I've noticed that the "experts" in the translation field often care little for the usual standards of project specification, perhaps because they are sick and tired of translation projects with so many specification documents for those who know better.

Validating Roman numerals in translation QA

The issue of Roman numerals in my translation work has been at the back of my mind for a few years now, but the pain level had not been such that I got around to dealing with it. It comes up time and again in legal translation work: references to the "X. Senat" or the like which mess up segmentation (and require a bit of regex to do a new segmentation rule); references to "Art. VII" of some law (I need to catch the typos like "VIII"); source text errors like "VIIII"; and of course dates like MCMXXIV, etc. and century references.

For simple matters I used regex which would capture and reproduce "Roman numerals", but erroneous data using the right letters would also be accepted:

[MDCLXVI]+

That is, of course, rather useless for QA which checks the correctness of the expression in the source text. So with a bit of thought I came up with:

Without the word border syntax ("\b"), non-standard expressions like "VIIII" might appear to be validated in the interface of memoQ, for example, because the whole express would be marked green in the source text, and one might not notice that it was resolved into "VIII" and "I".

These expressions can be used in various ways in any CAT tool that supports regular expressions, such as SDL Trados Studio or memoQ.

If you want this typing aid and QA tool as a memoQ autotranslatable (along with a little demo data file), you can get it here.