Translation Tribulations

Remote presentations and tutoring

2012-01-25T00:29:00.000+01:00

I must confess that I am not really a great fan of remote viewers and the like on principle. The technology has been around quite a while, and about the time my friends in IT tech support developed enthusiasm for doing remote maintenance, I was running from tech support roles as fast as my legs could carry me. And while I appreciate a good webinar quite a lot, even the best cannot, in my opinion, match the value of personal delivery. When I deliver a lecture or workshop I like to see the faces of the participants, read their body language, ask them questions. And software just doesn't do that well in my opinion, even when the features are there.

But... I spend a lot of time on the phone explaining things to people who feel they are experiencing the inexplicable with the translation environment tools. And unfortunately not everyone uses the right descriptive terminology to give me a clear picture of the problem. So one day, while I was getting quite frustrated trying to picture what a user was doing on her screen, one of us thought of using TeamViewer (and it surely wasn't me). The quickie show & tell mutated into several hours of highly productive coaching, which was repeated on a few occasions with this person and others. I wasn't impressed with the quality of sound transmission via my UMTS data connection, but the visuals worked well. More recent tests with Netviewer left me very impressed by this platform's sound quality and features, so I may use this for coaching and remote group instruction.

I still prefer to deliver workshops of several hours in person, even if it means I have to travel across half the continent to do so. I really do believe that is most effective, and I learn a great deal from talking to the participants informally about their experience. That is really missing in the online medium. But I think now when calls for help come in or a colleague needs to see exactly how a particular procedure works, we might all save time and frustration with remote technology after all. That may sound a bit Jurassic, but I really don't like to use technology unless I see a clear benefit to it which cannot be achieved by better means.

Now that I have "the bug", of course, a number of useful possibilities are seeping into my mind. "Teaser demos" of presentations usually delivered in person in a longer format, for example. Whatever I end up doing with this, I am far more optimistic about the technology than I was. Have you used it as a presenter or participant? What advantages and drawbacks have you experienced?

A NIFTY method for legal terminology

2012-01-18T22:29:00.000+01:00

Practical corpus linguistics has been a personal interest of mine for a long time, as it constitutes one of the best methods for developing specific domain terminologies in an efficient manner. Since I first laid hands on "Working with Specialized Language: A practical guide to using corpora" by Lynne Bowker and Jennifer Pearson (ISBN 0-415-23699-1) I have enjoyed great benefits from this approach. So when a discussion thread on a private translators' site mentioned a follow-up to a talk last autumn on legal corpus utilization for terminology research, my attention was drawn to it immediately. The information is reproduced here in slightly modified form with the permission of the person in charge of the project. The blog mentioned in the text is worth a look as well.

Dear fellow translator,

At the Lisbon Tradulinguas conference in October, I ran a workshop on terminology, presenting a methodology that I am testing - called NIFTY - which applies to all language pairs. This message is addressed to people who attended the workshop, those who tried out the method using the conference CD, or anyone who would like to try it out now.

I would really appreciate any feedback that you can give me - it's really important for my project to have input from professional legal translators - this is NOT an ivory tower experiment! Of course no names will be cited in any reports of the results - participants will remain anonymous.

If you could spare a few minutes, there are two alternatives:

1) I have set up simple online forms that are really fast to complete.

First you just complete some basic questions about your profile (it can be anonymous - just use a false name if you prefer) - this helps me to understand what sort of translators find the process useful or not.
http://protra.wufoo.eu/forms/nifty-participant-information-registration-form/

Then I will send you by return a participant code, which will give you access to these two short forms:

About compiling the NIFTY corpus:
http://protra.wufoo.com/forms/nifty-corpus-compilation-feedback-form
About using the NIFTY corpus:
http://protra.wufoo.com/forms/nifty-corpus-use-in-translation-feedback-form
2) You can give me your feedback by email in extended text form.

Of course I am here to help if you need any assistance or advice on using the NIFTY tools.

Lastly, if you are interested, I have launched a blog since the conference, where I post tools, resources and news that might be of interest to legal translators: http://wordstodeeds.com

Thank you for taking the time to read this message.

Kind regards
Juliette Scott

N.B. The survey platform is fully compliant with the US-EU Safe Harbor Framework as set forth by the U.S. Department of Commerce regarding the collection, use, and retention of personal information from European Union member countries.

The PhD project itself has been reviewed by the University of Portsmouth Faculty of Humanities and Social Sciences Research Ethics Committee.

Filling out the initial form indicating interest is a relatively painless process; it took about 5 or 10 minutes of my time. I am curious to see how her methods differ from my current practice and what I can learn here.

Keeping up with changing English usage

2012-01-18T01:11:00.000+01:00

“Every professional language user should be aware of current usage options and changing conventions.”
-- Professor Mike Hannay, VU Amsterdam

“English is a first language for many different language communities across the world and is changing all the time. So many people use English for so many different purposes every day that it is not at all surprising that at any one point in time there is massive linguistic variation. Indeed, ‘Englishes’ rather than ‘English’ is the name of the game, and anyone responsible for preparing English texts ready for publication needs to be aware of this variation in usage, so as to be able to make appropriate decisions and produce stylistically balanced texts which are fit for purpose. Often, however, people are uncertain and conflicting stories abound.

“At the same time, there are also matters of usage that seem to be a perennial source of contention. They may relate to opinions about what is correct and not correct, in whatever form of the language, or they may relate to what is considered stylistically preferable, in terms of readability. What are these issues, and is it really clear what is correct and incorrect, and what is good?”

These are the topics that Mike Hannay will be addressing in his one-day course on March 9, 2012 for which registration is now open. Apart from looking in detail at specific usage issues (based in part on your own experience and suggestions), Mike will also be examining how translators and editors can best deal with matters of language variation. The venue is Regardz Eenhoorn Amersfoort. The course lasts from 9:45 a.m. to 5:15 p.m. and qualifies for 6 PE points. The usual early-bird discount of €50 applies (until February 13).

Please see http://www.teamwork-vertaalworkshops.nl/events/evenement.php?id=43 for full information.

Are professional organizations worth the bother?

2012-01-17T19:32:00.000+01:00

There are two broad categories of professional organizations potentially of interest to language professionals such as interpreters and translators: those which are intended specifically for providers of language services, such as freelance translator and interpreters, and those which are not. The latter, which would include chambers of commerce, business clubs, technical societies such as the American Chemical Society and so on are clearly of great value. They are a means to stay abreast of new developments in areas of interest (perhaps an earlier profession) and perhaps to meet potential direct clients.

What about the other kind, professional associations for editors, translators, interpreters, terminologists and other language-slinging rabble? Well, as one reader from Putinland commented on my post about finding good translators, she saw no single benefit to her membership in that country's largest translators' association. She was aghast at the idea that someone might cancel a ProZ membership, because she assumed that corporate clients would not look for professionals but instead would only work with agencies, and these agencies in turn would cast their nets at The Translators Workhouse. (I looked up Cravy's profile at The Workhouse and when I saw the wealth of information there, it was hard to imagine how agencies would not be dueling each other for the opportunity to offer her work. But that is not the right profile - see the comments. That is an ongoing problem with ProZ and other portals - anyone can set up a profile under nearly any name or pseudonym, with no verification that the person behind the registered e-mail address is real. This is why the portals are often playgrounds for scamsters.)

Fortunately, the real world isn't quite as Dickensian as that, though perhaps a bit darker and more Satanic at the wordface in some parts of the world. But King Henry's sockpuppet is partly right: all organizations are not created equal. They exist in a particular social context of the countries in which their members live or do business, and they are very much dependent on the efforts of their members.

The professional translators' organization of which I am a member, the German BDÜ, can be a real mixed bag at times; one fellow I know who places enormous value on professional conduct quit his local chapter in disgust a few years ago, referring to it as the Hessian Housewives' Association. Since then, however, he has come back and contributed to the serious business focus of his state chapter, and across Germany the organization offers first-rate continuing education seminars, free legal counseling, affordable liability insurance, an excellent private forum for members to exchange information and job requests, a superb online search tool for translators and their specialties and more. To say that I get my money's worth out of membership would be a huge understatement. I don't have to like everything the BDÜ does, but I applaud a great deal of it.

As I was compiling the list of professional organizations for freelance translators and interpreters which provide online search tools for potential clients to find a service provider, I was a little shocked at how parochial and unprofessional some of these venerable organizations appear on the Internet sites. In a discussion of that list on a private site, one colleague commented that it is a shame there isn't some sort of meta search engine to serve up the data from a great number of professional sites around the globe. I'm not really sure that would be a good thing if it were possible, and a quick look at the search tools for a few of the association sites quickly makes it clear that a programmer attempting such a task would soon turn to the bottle. There is no consistency at all in the lists of specialties used; some organizations simply list members in a given region with no statement of the types of text they feel they are fit to translate. Appalling.

I think that attracting an international clientele is important to many translators in this age; for those living in countries with developing economies, this is one of the keys to the best rates. But in order to do that, it is necessary to offer the site in languages which are probably understood by potential international clients. The Germans do it. So do the French. The Swiss and Italian associations I looked at failed this test. If you are a member of a professional association for language service providers, has your association given due attention to this point? If not, get out the thumbscrews or find and organization that does. (That's called "voting with your feet", an option familiar enough to some who live in parts of the world where that is the only effective vote.)

Linking online search engines for the associations would require using the same list of specialties or at least subsets thereof to be effective. But what chance of that is there with an organization that feels it is important to list beekeeping but nothing to do with chemistry or chemical technology? Quite a lot, I'm sure. Unifying and merging search tools might be a good project for groups like the Canadian umbrella organization I listed. I was not happy to see that I would have to go to each individual state organization to do my search. Really!

This is the 21st century, but some organizations for language specialists seem to be stuck in the 19th. The disorganization one can see in some areas, even in developed countries where one might expect better, make it obvious why even a highly flawed commercial portal that many serious professionals avoid like herpes can be a "success". But fortunately, there are some organizations, big ones, that get it and offer a hunting ground that is generally happier than the portalZ with their spotty or non-existent identity verifications for members and silly aliases. Mind you, I eventually adopted an alias myself on ProZ, but that was to avoid having information I wanted to present about myself or my business get buried in spammy pages repeating my commentary for Tamil, Swahili, Tagalog, Urdu and other languages at the center of the world stage.

So are these professional organizations for language service providers such as freelance translators, interpreters and editors worthwhile? Definitely. If you choose the right one.

The Great Firewall of Washington!

2012-01-17T16:58:00.000+01:00

Slowly I am beginning to understand the association of the color red with the Republican Party in the United States. Before the 2000 presidential election, red and blue had no fixed association with Democrats or Republicans, and when I thought of the color red at all in the years after that I was usually seeing red because of Republican policies designed to dismantle the country or all the blood, foreign and domestic, which Republican lawmakers and Republican wannabes like "blue dog" Democrats so happily see shed. But slowly the truth is emerging from the fog of the Bush wars: the Chinese connection. Ol' Shrub & Co. happily financed their military adventures with Chinese money, now it seems that Republican lawmakers, following the lead of their Red Chinese masters, want to erect a Great Firewall in Washington to strangle free expression. Beijing disapproves of dangerous ideas like the First Amendment to the US Constitution, so their eager Red Party students in the US House of Representatives and Senate SOPA and PIPA respectively to set things right, based on the hollow premise of preventing copyright violation. President Obama has stated his opposition to the legislation now proposed; let's hope he doesn't roll over and play dead for the Reds as he is wont to do.

As part of the protest against US legislators' attempts to strangle free expression through unconstitutional preemptive restraints and other measures, Wikipedia will be blacking out its English pages worldwide tomorrow. Wikipedia, like any other Internet-based platform exists within and is affected by the framework of laws, and I find it entirely appropriate that this otherwise neutral platform stand up and take a position in this matter. Details regarding the blackout, scheduled to begin at 5:00 am UTC on January 18, 2012 and continue for 24 hours, will be found here.

We as translators depend very often on the public availability of information for our work. Intellectual property should have appropriate protection, but the Stop Online Piracy Act (SOPA) in the U.S. House of Representatives, and the PROTECT IP Act (PIPA) in the U.S. Senate are not the way forward. If you are a US voter, please make this clear to your erected representatives.

Januar-Übersetzertreffen in Hohen Neuendorf bei Berlin

2012-01-17T14:01:00.004+01:00

Liebe Kolleginnen und Kollegen,

zum etwas verspäteten Start ins neue Jahr treffen wir uns am:

Donnerstag, 19. Januar 2012, ab 19.00 Uhr

Wir gehen noch einmal ins:

Gasthaus-Pension Strammer-Max

Schönfließer Str. 16 a

16540 Hohen Neuendorf

S-Bahn S1 und S8 Hohen Neuendorf

Das Gasthaus befindet sich direkt gegenüber vom S-Bahn-Ausgang auf der anderen Straßenseite und ist nicht zu verfehlen.

Hier die Speisekarte (ohne Preise):

http://pension-strammer-max.com/auszug-aus-der-speisekarte/

DIE ÜBLICHE BITTE:

Sagt doch kurz Bescheid, ob ihr dabei seid oder nicht.

Bis Donnerstag!

Andreas Linke (andreas [at] vll [dot] biz)

BDÜ workshops (German): technical documentation & journalistic/advertising translation

2012-01-13T13:14:00.001+01:00

Im März veranstaltet die BDÜ Weiterbildungs- und Fachverlags GmbH zwei interessante Workshops zu den Themen Professionelle Textproduktion für technische Dokumentation in deutscher Sprache (02.-04.03.2012) und Übersetzen journalistischer und werblicher Texte (30.03.-01.04.2012)

Aus dem Programm "Professionelle Textproduktion für technische Dokumentation":

- Einführung: Anforderungen an technische Dokumentation

- Textanalyse und Textproduktion: Fremdtexte bewerten und verbessern

- Sicherheitshinweise: normative und rechtliche Anforderungen

- Terminologiearbeit

Die Referentin Susanne Murawski arbeitet seit 25 Jahren als Technische Redakteurin, Projekt- und Abteilungsleiterin für Technische Dokumentation.

Aus dem Programm "Übersetzen journalistischer und werblicher Texte":

- verschiedene journalistische Darstellungsformen

- Text- und Übersetzungsanalysen

- Übersetzen vs. kreatives Texten/Copywriting

- interessant und verständlich Schreiben - Regeln und Tipps

- Übersetzungsübung eines journalistischen Fachartikels

Die Referentin Jutta Witzel ist Fachjournalistin, Projektleiterin und Trainerin. Seit 2004 ist Jutta Witzel hauptberuflich Fachjournalistin für die Themen Sprache, Interkulturalität und Diversity Management. Die journalistische Qualifikation erwarb sie durch Seminare beim Deutschen Journalisten-Verband, dem Deutschen Zeitschriftenverlegerverband und der Bayerischen Akademie der Presse.

Die Seminare finden in Berlin statt. Der Frühbucherpreis beträgt für BDÜ-Mitglieder 525 Euro pro Seminar (Der Frühbucherpreis ist gültig bis zum 2.2.12. für das Seminar zur technischen Dokumentation und bis zum 1.3.12 für das Seminar zum Übersetzen journalistischer Texte).

Im Preis enthalten sind Tagungsgetränke, Kaffeepausen, Mittagessen (inkl. 1 alkoholfreiem Getränk), Skripte sowie die gesetzliche Mehrwertsteuer.

Weitere Informationen sowie die Möglichkeit zur Online-Anmeldung finden Sie auf www.seminare.bdue.de

Finding good translators

2012-01-11T23:40:00.000+01:00

Over the past decade I've spent many hundreds of hours helping clients and colleagues find suitable translators to collaborate on their projects, mostly involving German and English, but occasionally venturing into other languages such as French, Spanish, Russian, Chinese or even Vietnamese and Sinhalese. Unfortunately, it can be said that "many are called [translators], but few... [should be] chosen." For various reasons.

In desperation, many turn to public commercial portals such as ProZ aka PrAdZ aka The Translators' Workhouse or perhaps more benign incarnations of the same concept. Some of these pretend to screen "professionals", but as in another old commercial profession, the main criterion in proZtitution is to see if a trick can be turned and a Google Ad dollar made or the like. One of the Zertified Red Pros I've seen on PrAdZ is well known to me from the twenty hours I spent preparing an expert opinion for possible legal action by his client due to gross incompetence and damage to business relations; others are of similar caliber. Yet many translation agencies continue to drink from those soiled troughs, where anyone with an Internet connection and a knowledge of the URL http://translate.google.com/ can hang out a virtual shingle as a translator; occasionally a corporate client unknowingly falls in and drowns as well.

Mind you, there are still a few very good translators to be found in such places, but they are getting fewer and fewer, verra hard tae find. The few grains of wheat are buried in a mountain of chaff and bird dung.

Many clever translation buyers (translation agencies, corporations great and small, law offices, and individuals) know the open secret to finding a better class of translator: professional association directories. Sure, you can find rotten eggs in those nests too, but on the whole, these are far more serious professionals, most of whom actually make a living as translators and perform to standards that will enable to keep them doing so as long as they like. Not the desperate unemployed, the frustrated actors or journalists who can't get enough work to pay the rent, starving studentZ or bored house hubbies.

Where do you find contact lists for these professionals to find the "right" one with the special knowledge you need? Here. I'll keep a running list of professional organizations around the world and links to their online directories. I know only a few myself, because my interests are limited to a few languages and countries; some of these have been kindly provided to me by international professional colleagues who know the organizations intimately and are in some cases involved with running some part of them. If you are looking for competent people, certified or otherwise, these are very good places to start your quest. It is more likely to have a happy end or a happy working relationship for the years ahead.

Note that while I list these organizations by country, most or all have international members and language combinations that go beyond those one might expect from that country, so even if you are in Mexico, it might pay to browse a French directory for a Russian to Italian translator :-)

I'll add listings as I receive them and perhaps a short comment by members I know if they care to share them. When these organizations mention certifications, it means something more than a little red pee.

Australia
AUSIT - home page - online directory search (badly designed form, no specialty selection possible)
NAATI - home page - online directory search (see the note in the comments)
WAITI - home page - online search directory (odd search wizard, no specialties)

Austria
Universitas - home page - online directory search (in German)

Canada
CTTIC - home page
Here there are links to the regional organizations and their directories (print or online). It's a bit fragmented; the group in British Columbia, for example, has separate directories for "certified" and associate members. Too bad they can't offer a nationwide directory in this modern age, but as they say, "seek and ye shall find", and the findings are surely better than what one would typically turn up at a commercial portal without standards.

Finland
SKTL - home page - online directory search (in English)

France
SFT - home page - online directory search (in English here)

Germany
BDÜ - home page (in English here). National scope. The site's programming is primitive (still uses HTML frames!!!), so the directory will have to be accessed from the home page. You can't miss it though: a link with a big magnifying glass at the top of the page and large, bold words that say "search online for interpreters and translators". The cream of the German crop will usually be found here.

ADÜ Nord - home page (in German). More focused on the northern region. The online search form for translators is on the home page, impossible to miss. There are great language service providers to be found here.

VÜD - home page (in German) with an integrated search form for translators and interpreters at the top

Ireland
ITIA - home page - online search form

Italy
AITI - home page - online directory search (mostly in Italian, unfortunately - appalling, incomplete localization)

Netherlands
NGTV - home page - online directory (unfortunately all in Dutch still; I really expect less parochialism from my colleagues there! Still, this is a good place to find quality)

Bureau Wbtv - home page - online register search for sworn and certified translators(in English)

New Zealand

NZSTI - home page with a search box at the top

Spain

Asetrad - home page - online search with specialties (in English)
MET - home page - online search (this organization includes language specialists for all aspects of English)

Sweden
SFÖ - home page with online search form by language combination & subject (in English)
Kammarkollegiet (authorized translators) - info page - online directory search (in English)

Switzerland
ASTTI - home page - online directory (the links here are to German pages, but the site is available in Italian and French as well)

United Kingdom
ITI - home page - unfortunately, these Brits are just as primitive with their HTML site structure, so the online directory must be accessed in a frame on the home page. Still, the link is at the top of the page and easy to find, and there are a lot of excellent translators to be found here.

IoL - home page - online directory

USA
ATA - home page - online directory search

How low can ProZ go?

2012-01-09T23:16:00.002+01:00

Since The Great Moderator Purge at ProZ a few years ago, things have continued to get curiouser and curiouser, and The Translation Workplace has evolved into more of a Translation Workhouse, or as some colleagues from former Iron Curtain regions who have the historical background to comment authoritatively might put it, a gulag. One from which, thankfully, most serious translators in the major language pairs have escaped to a better life. After being gagged there for several years and dealing with other nonsense, I stopped being a paying member of the site in 2011. The experience of this German colleague provides further confirmation that I made the right decision. For years, there have been rumors, some quite plausible, others less so, of corruption in the Blue Board ratings, and for some, access to this data remains one of the few justifications for membership. But if the ratings themselves are skewed by arbitrary actions... let her story, posted on another translators' forum and reposted here with permission, speak for itself:

Hey folks,
I know I don't need to tell you how bad ProZ is for the industry, and I don't want to turn this into a discussion about that site, but if you need a little story to convince others to stop supporting ProZ with their money, here's a funny one from today.

A while ago I did one project for an agency that turned out to be a typical broker. Absolutely no QA, low rates (earlier, they were looking for a 50K legal translation within 2 days for 0.09 USD/word - without adding any value to the project themselves), and so on. The project was small enough for me to use as a test to determine if I wanted to continue working with this guy. After all, he had 30 5-star ratings on the Blue Board.

But as it turned out, my initial feeling was correct: he sent me three emails way before the deadline asking me when I would deliver, but when it came to paying me with equal speed after timely delivery, the excuses and bossy behavior began. He said I should be happy about getting paid after 30 days because that is supposedly "GREAT" in our industry, and he declared that he was under no obligation to pay me when I wanted to be paid, etc.

So, long story short, I went to ProZ to leave a negative rating. My review included all necessary information and described my experience. I didn't mention any names, nor did I use foul language or similar.

First attempt: my review got censored and deleted without any explanation. I sent a support request and asked what was going on. Got a reply that told me to resubmit my review.
Second attempt: I resubmitted my review, and removed the word "arrogant" from it, just to be sure. It got censored and deleted again, without any explanation.
Third attempt: I simply selected one star and added "Not recommended." to the comment field. It got censored and deleted again. This time, I received an email telling me that I was not allowed to add any comments and should only indicate my WWA rating.
Fourth attempt: I simply gave a 1-star rating and added no further explanation. [This was finally let through.]

WTF?? If you see a bad rating, don't you want to know why the rating is so bad? Leaving a bad rating without any explanation makes the translator look bitter and vengeful. And why are comments allowed for the good ratings then?

Anyway, I'm happy I don't waste my money on Proz, and I'll cheer for everyone who stops paying for their membership. If you want to share this story with paying members, feel free to do so. :-)

Verra interesting.

United Nations General Assembly resolutions: 6-language parallel corpus

2012-01-09T00:35:00.000+01:00

Thank you to colleague Christian Taube for pointing me to another interesting public dataset, the parallel corpus of UN General Assembly resolutions available in TMX format in English, Russian, French, Arabic, Chinese and Spanish. All six languages are in the same TMX file. Altogether there are over 72,000 entries. Not a big collection compared to the EU DGT data, but possibly of better quality and certainly useful for those whose translations relate to the subject matter and involve pairs drawn from these six languages.

Importing into a CAT tool is a fairly simple matter: when the languages of interest are specified, the respective tool will extract the data desired. I tested this in memoQ (53 K entries imported) and SDL Trados Studio 2009 (48 K entries imported) with English and Russian, and the process was quite painless. I presume the difference of about 20,000 translation units read and the number imported have to do with redundancies and memoQ and SDL Trados Studio interpret these in a slightly different manner, but I don't really know. I also tested OmegaT, but unfortunately it chokes on the file when copied into the TM directory:

To use this data in OmegaT, the desired language pair must first be extracted with another tool to create a bilingual TMX file (as opposed to the hexalingual one). I exported the data I had brought into memoQ to make an English/Russian TMX and it then worked fine in OmegaT.

The following suggestion was offered by Yves Savourel on the Yahoogroups OmegaT list:

If you work on Windows, you can drop/drop the TMX file in Olifant (the "old"
.NET version: http://sourceforge.net/projects/okapi/files/)

That will show you the 74,070 entries in 6 languages in it.

Then do "File > Export", select the output file name, and then the 2 languages
you want in that new TMX file.

This tip is good for everyone, of course, not just OmegaT users. The Okapi tools are excellent and free for maintaining TMs when the tool providers can't be bothered so far to offer decent facilities for maintaining the data in their software (not naming any names here, but you know who you are....)

Translation tool concordances compared

2012-01-08T00:35:00.000+01:00

A recent experience when tutoring a new memoQ user started me thinking about the way concordance searches work in various translation environment tools and how the results are displayed. The user, who was quite experienced with OmegaT, kept telling me that memoQ could not find examples of a term's use in the TM and she had to do all her searches in OmegaT. I was somewhat puzzled by that, and when I looked at her screen with the memoQ concordance dialog, I saw something like this:

The memoQ version 5 concordance dialog

Looks like the term ("Inverkehrbringen") was found. So what was the problem? For years she had looked at this concordance view:

The OmegaT concordance dialog

The differences in layout and the lack of highlighting of the key term (which was aligned in the center of the memoQ concordance window in the ancient KWIC display tradition) were unexpected and confusing to the new user.

This inspired me to have a look at how various other tools display concordance results. I was not very happy with some of what I discovered, especially with some of today's leading commercial tools. I took a look at the TWB translation memories in SDL Trados 2007, concordancing in SDL Trados Studio 2009, Wordfast Pro (very limited test due to a demo license and my inability to load my TMX test data), memoQ and OmegaT.

In terms of overall performance, the best results were obtained with OmegaT and "Trados Classic" (2007). Searching a huge TM gave results in a flash. Concordance searches with SDL Trados Studio 2009, on the other hand, really sucked with a big TM (EU data, about 400,000 TUs). I vacuumed my entire apartment and fed the dog while I waited for the result, and I wasn't even told how many hits were found. Unfortunately, my favorite working environment, memoQ, performed worst with the same big data set: it simply gave an error message. Further testing revealed that this error was due to the very large number of hits. (This would have been obvious had I paid enough attention to read the dialog title in the first place.)

memoQ error message from too many concordance hits

So it looks like some development attention may need to be directed here. (Update: Kilgray's develops are actively working to remove this restriction.) Of all the tools I was able to test with a large concordance, memoQ was the only one to fail this way. My personal TM with about 10 years of my work in it is nearly as long as my German/English EU legal test database, but concordance searches in it using memoQ are not unduly slow.

Other concordance views looked like this:

The concordance in SDL Trados 2007 - hits limited compared to OmegaT (see above)

SDL Trados 2009 - perhaps the easiest to read, but slower than molasses

Wordfast Pro - format not bad, but the test was limited due to the demo license

The Déjá Vu X concordance hasn't changed significantly in appearance in the latest version (DVX2). Once again, Victor Dewsbery was kind enough to provide me with screenshots of the two "scan" options for searching the translation memory. The initial scan produces only fairly close matches, while the "power scan" is more like the usual concordance with the term embedded in a larger body of text (the non-matching parts being crossed out)


DVX2 scan (first click)

DVX2 Power Scan (second click)

I do have a license for the older version of DVX, but I didn't attempt any stress testing. While its performance with large TMs has always been good (my personal "Big Mama" is about 330,000 TUs), import and export of such data volumes are painfully slow. We're talking overnight. I hope the new version is better in that respect. There I must really give kudos to the OmegaT developer: loading the TM was even faster than with Trados Workbench, which for me has always been a benchmark of speed to aspire to. All you have to do to add a TMX file to the TM of an OmegaT project is to drop it in the "TM" folder of the project. Very nice :-)

I also received a screenshot of a search in Transit NXT from colleague Hans Lenting in the Netherlands. He searched the term "Inverkehrbringen" in the German/Dutch EU dataset from the DGT:

STAR Transit NXT concordance search

As you can see, there are many ways to display data from a concordance search. Which do you find easiest to deal with? Personally, I love the insertion features of the memoQ concordance, but for readability I think some of the other tools are better. And I do like to know how many results I can expect from my data, and I might even want to view them all.

Social media: a waste of time?

2012-01-07T22:16:00.002+01:00

In the past few years, a number of friends and colleagues have informed me quite indignantly what an utter waste social media are, a few implying that participation in platforms such as blogs and Twitter is simply filler for those without work. I'm sure that may be true in some individual cases, but my personal experience and observations tell a very different story.

My involvement began some years ago in translators forums while doing research for writing projects and expanded to blogs and private forums when the deterioration of ProZ as a public forum for professional discussion drove most of the serious professionals away or gagged them. While Twitter was still derided as a tool for keeping the world updated on your breakfast and bowel movements, I discovered that it was fast becoming one of the most efficient tools for the quick exchange of tips and professional tidbits among serious professionals. Facebook? Well, I don't like the shifting ground of the company's information policies, but used judiciously, even that platform has socially redeeming value.

The value of all these platforms will vary according to one's goals and the overall balance sought. But let there be no doubt: social media are valuable and sometimes surprisingly effective. I've had a very large number of financially worthwhile projects result from the the time spent sharing information, but more importantly, I have been able to get to know great professionals in distant places, sometimes help them and receive help in return. Maybe some day I'll throw out a few statistics or examples from my experience, but today I would like to share an inspiring example from two colleagues in the US and Austria, the Jenner twins.

At Christmas time, they issued an appeal for assistance for the co-founder of the Nevada Interpreters and Translators Association, Álvaro Degives-Más, who has given so much to help others in our profession. Hoping to raise a few hundred dollars to help him and his wife defray crushing expenses from uninsured surgeries, in two weeks, the generosity of colleagues and a few companies has yielded over 7500 dollars. A small part of the total bills, mind you, but an impressive achievement nonetheless, made possible through the power of social media. Read the update here, and if you are able to, please consider doing a small bit to help these people see a light at the end of a very dark tunnel.

Understanding memoQ's term extraction stopword codes

2012-01-07T13:29:00.000+01:00

Recently I shared a link to a small stopword list for a minor language, which I had set up as a memoQ resource for a friend, and another translator questioned why I had coded the stopwords as I did. My answer was truthful: no good reason. I had simply copied the practice in Kilgray's default files for other languages. As I looked further into discussions of term extraction and stopwords on the memoQ Yahoogroups list, I realized that I was not the only one who had a hard time getting a clear picture of how things actually work. So I decided to learn by experiment.
First I created a stopword list with nonsense words having every possible coding combination. A memoQ stopword list is a test file with an XML header and *.mqres extension, with a structure that looks like this:

<memoqresource resourcetype="Stopwords" version="1.0">
<resource>
    <guid>2b077cde-8c10-4ee1-86db-14eb42f010cc</guid>
    <filename>KSL_test-stopwords_EN.mqres</filename>
    <name>KSL_test-stopwords-EN</name>
    <description>For testing only</description>
    <language>eng</language>
</resource>
</memoqresource>
gak    111
unga   101
munga 011
kunga 110
fra    000
blu    100
bly    001
bla    010

The entries in the stopword list (here the nonsense words gak through bla) are each followed by a tab and a three digit binary code. The first digit of this code controls whether a phrase is excluded from the list of candidates if it begins with this entry. (Kilgray calls this "blocks as first".) The second digit of the code controls whether a phrase is excluded if the entry occurs within it (not at the beginning nor at the end, Kilgray calls this "blocks inside"). The third digit controls whether a phrase is excluded if the entry occurs at its end ("blocks as last").

A "1" means yes, "0" means no. So "011" means

allowed at the start of the phrase,
not allowed inside the phrase
not allowed at the end of a phrase

Thus kunga will cause a phrase to be excluded if it occurs at the start of or inside the phrase, but not at the end. Phrases ending with kunga might appear in the list of candidates.

My test file contained the sentence

The quick brown fox jumped over the lazy dog

repeated four times in three blocks for each test stopword, with the stopword substituted at the beginning, inside and at the end of "over the lazy dog":

The quick brown fox jumped unga the lazy dog. The quick brown fox jumped unga the lazy dog. The quick brown fox jumped unga the lazy dog. The quick brown fox jumped unga the lazy dog.

The quick brown fox jumped over unga lazy dog. The quick brown fox jumped over unga lazy dog. The quick brown fox jumped over unga lazy dog. The quick brown fox jumped over unga lazy dog.
The quick brown fox jumped over the lazy unga. The quick brown fox jumped over the lazy unga. The quick brown fox jumped over the lazy unga. The quick brown fox jumped over the lazy unga.

After the term extraction, the following four-word phrases from the text chunk of interest were found with the stopwords:

fra The lazy dog
bly The lazy dog
bla The lazy dog
munga The lazy dog
over unga lazy dog
over fra lazy dog
over blu lazy dog
over bly lazy dog
over The lazy kunga
over The lazy fra
over The lazy blu
over The lazy bla

All these occurrences follow the defined rules as you can see from the stopword list above. None of the stopwords occurred singly in the extraction candidates, of course. So entering "000" as the code for a stopword will exclude that stopword alone but not in any phrase.

How is this relevant in practice? In English, for example, words like in, the and first are uninteresting by themselves and belong in a stopword list. But a phrase containing them, like "in the first instance" might indeed be of interest. In cases like that, the proper code for these stopwords might be "001" or "101" (allowing inside in both cases, at the beginning as well in the first case) might be appropriate. These are matters of judgment that will differ for each language. One user commented that he finds it more useful to be very restrictive in the extraction ("111") and add phrases during the actual translation, and I am inclined to follow this practice as well. Where one discovers exceptions, the stopword rules can always be edited in various places in memoQ.

EU (DGT) translation memories for DE-EN, DE-NL and NL-EN

2012-01-04T17:54:00.000+01:00

As part of some testing efforts, I had occasion to download the gigabyte+ of translation memory data the EU's Directorate General for Translation (DGT) made publicly accessible from the body of EU law. Aside from being massive (hundreds of thousands of translation units for most pairs) and good for stressing a translation environment tool, I find such data useful for looking up official names of directives and organizations. The English (and possibly other language text such as German, Dutch, etc.) is, as some of my British friends might say, very courageous, but if one needs to access the actual text in a target language for an EU law being quoted in the source language, this data source is perhaps a time-saver.
If anyone has a use for the German/English, German/Dutch and Dutch/English language pair TM data from this organization, here are some links to the extracted data I prepared for my tests:

DGT TM data for German and English (about 530,000 TUs)
DGT TM data for German and Dutch (about 306,000 TUs)
DGT TM data for Dutch and English (about 500,000 TUs)

And in conclusion, to honor the EU's commitment to quality in what they call English, I offer the following Frank Zappa classic:

Chris Durban offers two workshops in the Netherlands in February 2012

2012-01-04T12:28:00.000+01:00

Translation guru Chris Durban and award-winning translator Ros Schwartz will be bringing their much-acclaimed one-day workshop on the nuts and bolts of good writing to Amsterdam on Friday, February 10, 2012. Style Matters is a one-day workshop for English translators: "The ability to produce polished prose, no matter how uneven the original text, is one factor distinguishing top-end translators able to command high fees from bulk providers and bottom feeders." Most examples will come from French, but knowledge of the source language will not be required as the focus will be on writing good, clear English.

The workshop venue is Regardz Zilveren Toren, right next to Amsterdam's main railway station. Please see the Teamwork website for further information and registration: http://www.teamwork-vertaalworkshops.nl/events/evenement.php?id=41.

The following morning, Chris will be in the nearby town of Amersfoort giving two fascinating talks on translators and the translation business. The Mystery Shopper is a report on an experiment where Chris posed as a translation buyer and commissioned a number of short translations from different freelance translators and translation agencies – "one of the highlights of the recent ITI Conference” (Blogging Translator). In Finding and Working with Direct Clients, Chris reveals the secrets of finding better - and more profitable - clients. The talk concludes with a case study and a Q&A session. The workshop venue is Regardz Eenhoorn, just opposite the railway station in Amersfoort. For further information: http://www.teamwork-vertaalworkshops.nl/events/evenement.php?id=46.

There is an early-bird discount for both days, by the way, until Monday 9 January. Both days qualify for PE points for certified translators and interpreters registered with the Bureau BTV in Den Bosch (Netherlands). The two events are being organized by Tony Parr and Marcel Lemmens of Teamwork.

ODT files in translation environment tools

2012-01-02T18:16:00.000+01:00

After an interesting afternoon with a friend who was a bit frustrated with the behavior of her translation assistance technology with an ODT (Open Office text) source file, I decided to have a look at how a variety of common tools handle this format. I created a small test file which contained some of the troublesome elements and saved it as *.odt for testing. The test file looked like this:

The ordered list was created using the numbering feature.

When the file was imported to OmegaT, the segmentation looked as follows:

Fairly clean, though the segmentation is a bit off due to the encoding of the space after the end of the sentence in the second block of text. Nine segments where there should have been ten.

With memoQ, the result was:

Altogether there were a dozen segments after import. The part with the hyperlink was segmented incorrectly in three parts instead of one. However, memoQ did handle the space tag after "tool." correctly and start a new segment at "Here". Once can, of course, use the segment joining function to correct the segmentation until Kilgray gets around to fixing the segmentation on the hyperlink tag:

Update 9 January 2012: The developers at Kilgray have informed me now that this quirk in the ODT filter has been corrected and will be included in the next build released.

When I tried to test my SDL Trados Studio 2009 license, at first it refused to joint the party:

Never a dull moment with SDL as we all know. Of course SDL Trados 2007 was in fact installed, but when I upgraded to Studio 2009, of course it trashed my 2007 installation, and I had been too irritated to do anything about it for over half a year since I don't use Trados for anything more than file preparation and compatibility testing anymore, and I was still able to do that for my projects with the damaged installation. However, when I discovered that the ODT file caused TagEditor to run and hide without even saying goodbye, I sighed deeply and wasted half an hour reinstalling SDL Trados 2007. At least I didn't have to go through that insane check-in/check-out license procedure online. I trusted in God and my Windows Registry entries, and the location of my license file was remembered, so all was well.

The second attempt at SDL Trados Studio 2009 was much better:

Same segmentation problem as OmegaT, and examining the tags reveals where the issue might be addressed in a tweak of the filter.

I haven't got the latest upgrade, but someone was kind enough to run my test file through SDL Trados Studio 2011, which appears to offer the best results for filtering ODT (the settings were slightly different, with the URL included, but that is also possible with some other tools):

SDL Trados TagEditor also worked after re-installation. The results were:

Oh dear. Well, it works, but if I still used TagEditor, I would run, not walk, to the much cleaner interface of OmegaT for this sort of thing if I didn't have the good sense to upgrade to Studio or something else commercial. Note the same segmentation issue and the need for filter modification.

Victor Dewsbery was kind enough to import my test file to the original Atril DVX and the newer DVX2 and send me the results:

DVX import of the test file

DVX2 import of the test file.

I also tried to test SDLX, Wordfast Pro and Wordfast Anywhere. The first two tools don't support ODT. Wordfast Anywhere claims too, but went nowhere, with the following status message displayed in my browser for about half an hour before I gave up and went to lunch:

Of course I canceled. I had a blog post to write and a New Year to get on with. Anyone who wants to try the test file in another tool (to compare apples with apples) can get it here.

Wordfast Pro: Translating memoQ bilingual RTF tables

2011-12-27T17:46:00.001+01:00

After a recent crisis an agency friend of mine experienced when a translator did a large job of some 22,000 words and was unable to incorporate corrections by a reviewer (resulting in a rather creative but stressful rescue effort involving memoQ LiveDocs), I resolved to have a look at WordFast Pro myself and see if there wasn't some better, easier way to work with translators who have this tool.

The current version of WordFast Pro doesn't support XLIFF, so that's out as a possibility. However, it does read RTF files, so I tried the same techniques which have recently proved successful for improving the interoperability workflows with Trados TagEditor and SDL Trados Studio among others. And indeed this approach was successful.

A view of the memoQ bilingual RTF file imported into Wordfast Pro for translation.
By hiding the red tags with the mqInternal style, the tag content is protected in Wordfast Pro

To prepare content in memoQ for translation in WordFast Pro, do as follows:

Copy the source to the target for the entire text.
Export a bilingual RTF file.
Hide all the content of the RTF file which is not to be translated.
Use the search and replace function in your word processor to hide the dark red text for the tags, which are marked with the mqInternal style. The settings for the dialog in Microsoft Word are show below and are set using the Font... option (marked with a red arrow in the screenshot) in the Format dropdown menu of the Replace dialog.

The font color to hide will be found under More Colors... in the font colors of the font properties dialog:

In this way, the translation can proceed without the risk of damaging the text constituting a tag, and the QA features of Wordfast Pro can be used to do a tag check before delivery.

After the translation is completed and the tags have been checked, export the RTF file and unhide all the text. If there is a comments column available, any comments which are added to the table will be importe back to memoQ for feedback.

SDL Trados Studio: Translating memoQ bilingual RTF files

2011-12-27T14:46:00.000+01:00

Some time ago, I noted that SDL Trados Studio experiences difficulties importing XLIFF files in which the sublanguages are not exactly specified if the default languages are not set to the same major language. So if you plan to translate an XLIFF from memoQ or another tool in SDL Trados Studio, it is necessary to ask the one generating the file to specify the sublanguages or, if that is not practical, use the workaround described here. I discovered this bug before the release of the 2011 version of Studio and spoke to SDL development and management staff specifically about this at the TM Europe conference in Warsaw, but apparently this is not a priority to fix compared to other issues, and it may be a while before SDL Trados Studio users can work with client XLIFF files without coping with this headache.

Several of my client agencies using memoQ for project management have quite a number of freelance translators using various Trados versions and who have no intention to stop doing so. It's important to work smoothly with these resources in a compatible way, which also protects the data and formats. In a recent article on processing memoQ content with Trados TagEditor, I published a procedure I developed which enables the memoQ tags in the text of the bilingual RTF table export to be protected as tags when working in SDL Trados TagEditor. Now I would like to present a similar approach for Trados Studio users, which can serve as an alternative to XLIFF exchange.

If the bilingual RTF table is created in memoQ specifying the mqInternal style for tags

this style setting can be specified as non-translatable in SDL Trados Studio. To do this, select the menu choice Tools > Options, and in the dialog which appears under File Types, add the mqInternal style to the list of styles to be converted to internal tags in the appropriate formats (RTF, and just in case the file gets re-saved as a Microsoft Word document, for Microsoft Word 200-2003 and Microsoft Word 2007-2010 as well):

SDL Trados Studio dialog for setting RTF, DOC and DOCX styles as "non-translatable" (converting to tags)

Once the mqInternal style has been entered this way in SDL Trados Studio, the prepared bilingual RTF file can be imported. "Preparation" for import includes copying the source text to the target and hiding all the text you do not intend to translate (the file header, the source column, and the comments and status columns if present). The result will look something like this:

The prepared memoQ bilingual RTF file imported to SDL Trados Studio. Note that the bold and
italic type are displayed normally as in memoQ, which offers the translator greater working ease.

Please note that the same procedure described for working with these files in TagEditor (hiding the red text of the tags, see the TagEditor article for details) also works for SDL Trados Studio, but this method involving the mqInternal style saves a few steps.

Clean up the tag mess with CodeZapper for all CAT tools

2011-12-27T01:55:00.002+01:00

Readers of this blog probably know by now that I am a Dave Turner fan. His CodeZapper macros have probably saved me hundreds of hours of wasted time over the years (not an exaggeration), and I think there are a lot of other translators and project managers with similar experiences. It doesn't solve every problem with superfluous tags, but it solves a lot of them, and Mr. Turner works steadily at improving the tool. I blogged the release of the latest version not long ago; it is now available directly from him for a modest fee of 20 euros (see the link to the release announcement for a contact link). That means it pays for itself in far less than an hour of saved time.

Over the past few days I have been updating some training documentation and running a lot of tests on tagged files as part of this. During this work, I have been struck time and again by the differences in the tags "found" by different tools working with the same file. Sometimes one tool looks better than another, but the patterns are not always consistent. What is most consistent is the ability of CodeZapper to clean up the files in various versions of Microsoft Word and make the tag structures appear a little more uniform.

Here's an example of the same DOCX file "unzapped" in several tools:

Import into memoQ 5, as-is, no tag clean-up. Previous versions of the same file showed more tags in places.

SDL Trados Studio 2009 before tag clean-up.

TagEditor in SDL Trados 2007 before tag clean-up

Initially, OmegaT would not import that particular DOCX without a tag cleanup. I reported the problem to the developers, who upgraded the filter to handle a previously unfamiliar character in internal paths of the ZIP file (DOCX is actually just a renamed ZIP package like many other file types). See http://tech.groups.yahoo.com/group/OmegaT/message/23931 for information on the new release. Opening, editing and re-saving the troublesome file enabled it to be imported after all without the latest version bugfix. So users should keep that trick in mind perhaps if a similar problem is encountered. I've had to do similar actions in the past with other tools, so this is probably a good general tip to keep in mind regardless of what tool you use. When I downloaded an tested the latest standard release of OmegaT (2.3.0_4), the tag structure looked fine - no zapping of the DOCX was necessary in this case.

After treatment with CodeZapper, the file looked the same in memoQ (where the extra tags weren't present in the first place, though one can't count on things always being this way). The view in Trados Studio and TagEditor improved significantly, though there were still more tags, and OmegaT accepted the DOCX after tag cleaning.

SDL Trados Studio 2009 import of the DOCX file after tag cleanup with CodeZapper

SDL Trados 2007 TagEditor import of the DOCX file after tag cleanup with CodeZapper

OmegaT import of the DOCX file after tag cleanup with CodeZapper (OmegaT 2.3.0_3)

It is important to consider that superfluous tags mean wasted work time with formatting and QA corrections, perhaps even a higher risk of file failure (such as the inability to import the file at all into one tool). This is why for some time now, I and others have advocated modifying the costing of volume-based translation work to include the amount of tags. This requires, of course, that you have access to a counting tool which reports the number of tags (SDL Trados Studio does this - Atril's Déjà Vu has long offered this feature, and memoQ even allows you to assign a word or character "weight" for counting purposes). This is the only fair way I know of to account for the extra work (beside time-based charges). Consider that everyone is affected: translators, reviewers and project managers! I've had to talk more than one of the last group through "tag rescue" techniques after hours.

Perhaps it is worth considering as well that cleaner tagging will also improve "leverage" (match quality) in translation memories. So if a tool does offer cleaner tag structures (fora variety of source formats) consistently, working with that tool efficiently to manage projects will save time and money as well on top of the time and money saved with the use of CodeZapper macros in MS Word files.

OmegaT: Best practice for translating content from memoQ

2011-12-26T01:39:00.000+01:00

OmegaT is popular in some circles because it is Java-based and thus cross-platform, and it is free. Although rather limited in many respects compared with full-featured commercial tools such as SDL Trados Studio or memoQ, this Open Source tool can handle quite a number of formats well, offers interoperability pathways with the leading commercial tools and there are a good number of excellent professional translators who are satisfied with its features. Thus outsourcers using memoQ should understand the best procedures to follow if working with translators using OmegaT in order to avoid difficulties.

In the past, I have recommended using the bilingual XLIFF exports from memoQ for compatibility with memoQ. In theory, it's a nice approach, but I am encountering difficulties with memoQ-generated XLIFF files (possibly a Kilgray problem or a problem specific to my installation, not one having to do with OmegaT, which handled XLIFF from other sources properly in my tests). So for now I would say that a workflow involving memoQ's bilingual RTF tables is the best approach. Do the following to prepare the content for the translator:

Create a bilingual RTF table export from memoQ of the content to be translated. Use the "mqInternal" option for tags in order to change their color and facilitate proofreading of the final result.
Copy the source content cells into an empty DOCX or ODT file. OmegaT cannot read RTF and requires one of these two formats to be used in this case. The translator will be able to read these directly and translate.
Other resources such as TMs and glossaries:

OmegaT uses TMX for its translation memory. If you have a TM, provide it to the translator in this format.

The OmegaT glossary format is:
source term target term additional information
Provide terminology to the translator in this format if possible.
OmegaT is also capable of reading TBX, the industry-standard for glossary files.

The table cell content from the prepared file will look something like this in OmegaT:

Note that the memoQ tags are surrounded by additional OmegaT tags. Since OmegaT does not actually protect tags in its working environment, it is important that the translator verify the tags and proofread carefully, checking that all tags are present and applied correctly.

Once the translation is ready in the target DOCX or ODT file, open it in Microsoft Word, copy the translated table cells and paste into the target column of the bilingual RTF file, add any comments necessary to the Comments column of the table (if present). After the bilingual RTF is re-imported to memoQ, run a QA check to verify the tags again. After that the work can be proofread for content in memoQ or a bilingual export of an appropriate kind and the target file generated and delivered afterward.

SDLXLIFF files in TagEditor, OmegaT and memoQ

2011-12-25T21:47:00.000+01:00

As SDL Trados Studio gains acceptance, SDL's own flavor of XLIFF is encountered with increasing frequency by translators using other tools. I decided to test three of these to see how they fared: TagEditor (for "backward compatibility" with Trados users who haven't upgraded), the Open Source tool OmegaT and memoQ.

A simple DOCX test file was created, which looked like this:

It was opened in SDL Trados Studio 2009 and saved as an SDLXLIFF file, which was subsequently imported into each of the other three translation environment tools.

TagEditor test
Using the default XLIFF INI supplied with SDL Trados 2007, I obtained results which looked as follows:

Some ugly tag salad there and exposed , vulnerable information from the header. Using the adapted INI file I made for memoQ XLF files, things improved a bit:

Still not very pretty, but it works, and it works better than an memoQ XLIFF currently does in TagEditor. No breaking of tags.

Translated and brought back into SDL Trados Studio, the translation grid looked like this with everything in good order:

The target DOCX file with the translation saved nicely and was perfect.

In real life, however, it may be necessary to adapt the INI file in TagEditor more extensively for good results. The German consultancy Loctimize has compiled some good instructions for doing so in which the entire workflow is also described nicely (in German). So far I haven't run across similar instructions in English.

OmegaT test
Initially things looked much better with the SDLXLIFF file imported to OmegaT:

A great start, much cleaner-looking than TagEditor! But when the translation was re-imported to SDl Trados Studio, a small problem was apparent:

One of the tags in the second segment was dropped. In a similar test with an XLIFF from memoQ, the version of OmegaT I tested (version 2.3.0, update 3) appeared to trash even more tags, and the target file was completely reformatted! In fact, it even trashed tags on the source side in the memoQ file! Thus I was deeply concerned about the XLIFF filter in OmegaT. However, as astute observers have noted, I probably deleted the missing tag when editing in OmegaT, and a subsequent successful re-test of the workflow confirmed this. But the problem with the XLF file from memoQ was frighteningly repeatable. Careful, systematic testing revealed, however, that the roundtrip of a bilingual XLF file from memoQ back into memoQ failed. Either there is a problem with the version I have installed (5.0.56) or the installation is corrupted. The matter is being pursued with Kilgray support. The target file from the SDLXLIFF translated with OmegaT was fine.

memoQ test
I have translated many SDLXLIFF files in memoQ and seldom encountered a problem of any kind. The file from SDL Trados Studio looks as follows in the memoQ environment:

Please note: with memoQ I can use an XLIFF which has not had the source copied to the target or one which has been pretranslated. That is not really the case for the other two environments tested, because with both TagEditor and OmegaT the source must be copied to the target or you have nothing to translate. You might say that memoQ offers "real" XLIFF editing for translation.

The SDLXLIFF file translated in memoQ reimported beautifully to SDL Trados Studio 2009 and saved to a target file (DOCX) from there with no problems.

Trados TagEditor: Optimal translation of memoQ bilinguals

2011-12-25T16:47:00.002+01:00

With the growing number of translation agencies, direct clients and outsourcing translators adopting Kilgray's memoQ as a working platform for managing translation project content, it is particularly important for these new memoQ users and their partners to understand the best approaches to working together with persons who use other tools. One tool which is still commonly found is SDL Trados TagEditor. Compared to the other "classic" Trados tool, the Workbench macros for Microsoft Word, TagEditor has the advantage of enabling many different file formats to be processed while protecting their formatting elements (also known as "tags").

SDL Trados TagEditor can work with two types of "bilingual" files prepared in memoQ: XLIFF (*.xlf) files and bilingual RTF tables. Each approach will be presented here along with some suggestions for best practice.

XLIFF files
TagEditor comes with a default INI file for translating XLIFF, typically found at the path C:\ProgramData\SDL International\Filters\XLIFF.ini.This INI enables the contents of the target segments from the memoQ XLF file to be translated as the source in TagEditor. Thus for this approach to work, the source must be copied completely to the target in memoQ before the bilingual XLIFF is created using the Export bilingual function of the Translations page. This makes pretranslation undesirable in most cases, because the source text for matches will not be accessible and the translator will end up with a very screwy TM. Data for the TM should be supplied to the translator as TMX; be aware that match rates for the segments in TagEditor will differ significantly in some cases.

The memoQ XLIFF files will have a lot of "junk" at the top of the file when viewed in TagEditor:

Skip the content between the mqfilterinformation tags and do not change it in any way. Place the cursor below that to start working. If you prefer not to see that information at all, use the XLIFF INI for TagEditor which I modified for use with memoQ XLF files. Then the XLIFF will look a bit cleaner with the header information filtered out:

Astute observers may have noticed, however, that all is not really well with the tag structures in the views above. I think there is problem with the way that memoQ is generating the XLIFF files, with some tag structures being replaced by entities. (You see this if you open the XLIFF from memoQ in a text editor.) This causes consistent problems like the following in TagEditor:

This will require a lot of tag fixing. Thus I really can't recommend the XLIFF method at this point, not for my simple little test file in any case. The methods using the bilingual RTF tables with memoQ tag protection are safer and the structures that result are much simpler.

But if you do use this method, when the translation is complete, clean the TTX file using Trados Workbench or use the menu option File > Save Target As... in TagEditor to create an XLIFF file to return with the translated content. If the content inside the mqfilterinformation tags has not been segmented, an accurate count of the words translated will be shown in Trados Workbench upon cleaning the TTX (as accurate as that tool is given its limitations with numbers, dates, etc.)

Bilingual RTF tables
There are created in memoQ using the Two-column RTF option of the Export bilingual function. Technically speaking, the files have more than two columns (source and target, index numbers and possibly columns for a second target text, comments and status). Good practice for working with these files in TagEditor and many other tools also requires the source to be copied to the target column. This can be done in memoQ or later in a word processor. The table might look like this, for example:

For best results in TagEditor, it is important that this file be generated with the "mqInternal" style selected for tag formatting. The dark red color imparted to the tags with this option means that proofreading in a word processor is easier, and it also enables the text of the tags to be selected and hidden using a search and replace function. If the RTF file is then saved as a Microsoft Word file, the memoQ tags in the table will then be protected in TagEditor!

If the "full text" option for tags is selected, this makes little or no difference in the TagEditor view.

Here's a quick look at what the protected memoQ tags look like in TagEditor and what can happen without protection:

One possible workflow for memoQ RTF tables in SDL Trados TagEditor consists of the following steps:

Copy the source text to the target in memoQ
Export a bilingual "two-column" RTF file with the mqInternal style option selected for the tags
Re-save the RTF as a DOC or DOCX file! This is necessary so that TagEditor will use the right filter.
Select and hide all the text in the file
Select only the text to translate in the target column and unhide it
Using search and replace, hide all the dark red text. The settings for the dialog are show below and are set using the Font... option (marked with a red arrow in the screenshot) in the Format dropdown menu of the Replace dialog.

The font color to hide will be found under More Colors... in the font colors of the font properties dialog:

Launch TagEditor and open the Microsoft Word file with your content to translate. All the hidden text will be protected in tags. Translate the accessible text.
Create a target MS Word file from your TTX as described above for the XLIFF files translated in TagEditor.
Open the target file and unhide all the text.
(Optional) When reviewing the text in the word processor, comments may be added if there is a comments column. These will be imported back into memoQ and can serve as valuable feedback.
Re-save the target file as an RTF
Re-import the RTF with the translated table into memoQ. The target text will be updated to include the translation.
A QA check for tags, terminology, etc. should be performed in memoQ before exporting the final file for delivery. If an external reviewerr is used, another bilingual file in an appropriate format can be generated in memoQ for that work.

Steps 4 to 6 can be performed using a macro for convenience.

The procedure described above can, of course, be abbreviated considerably by simply copying the source text cells into a new Microsoft Word document, doing the search and replace to hide the dark red text for the tags, then processing the file in TagEditor. After translating, unhide the text in your working file, then paste the cells over the target cells in the RTF file.

Here's a look at the test file translated in TagEditor (with a comment added as shown by the dark speech balloon icon) after it was re-imported to memoQ:

And here's the translated file itself:

Converting MARTIF to Excel

2011-12-24T02:20:00.000+01:00

This afternoon I received an interesting project of a sort I don't see often - Star Transit. I avoided these like the plague for years, because I dislike Transit as a working environment, though I expect the latest version is probably an improvement over what I used to use. However, since Kilgray created an excellent import routine for Transit packages (PXF files), working on these projects is quite a simple matter. Except for terminology. The memoQ integration currently does not include the Transit terminology.

The client was kind enough to supply MARTIF exports from the Transit dictionaries, but unfortunately that's not an import format for memoQ, though really it should not be that difficult to deal with that XML format (I hope). So I went on the search for a solution and soon discovered a PrAdZ thread in which Czech translator Antonín Otáhal offered a VBA macro for converting the MTF files (MARTIF) to Excel.

The solution works nicely, though in my tests I found it necessary to open the MTF files in Notepad and re-save them as ANSI so the special characters in German would not get trashed. And I hate typing a full file path into the selection dialog, so I modified the code to include a proper file selection dialog. If anyone else can use such a tool, I've made it available here as an XSLM file (a macro-enabled Excel worksheet for MS Office 2010). Improvements are very welcome; I've been out of the programming game too long now to refine this much without investing more time than it is worth to me.

Nonetheless, I'm quite pleased that I can now save a tab-delimited or CSV text file from Excel and import this easily into memoQ or other translation environments. So moving term data from Star Transit to other tools is now a little easier.

To use the tool

Make a copy of the Excel file
Open your working copy of the Excel file
Press Alt+F8 to bring up the list of macros
Select the macro "mtf2excel"
Click the Run button. A file selection dialog will appear, and if everything is OK with the encoding, your term data should appear shortly in the columns of the Excel sheet.

Presegmented "classic" Trados files

2011-12-21T19:01:00.001+01:00

Given that many outsourcing translators, agencies and companies still use older versions of Trados but often want to work with qualified translators without tripping over tool issues, this is still a current topic despite the new SDL Trados tools having been on the market for several years. And my old published procedures on these matters are either no longer publicly available or are somewhat in need of updating.

Before I began blogging in 2008, I wrote a number of procedures to help my partner, colleagues and clients understand the best procedures for handling "Trados jobs" with other translation environment tools. When translating a TTX file with Déjà Vu, memoQ and many other applications, it is often best practice to "presegment" the file using a demo or licensed version of Trados 2007 or earlier. In fact, if this is done on the client's system, many little quirks of incompatibility that can be experienced if the translator used a different build of Trados (for example) can be avoided.

What does "presegment" actually mean? It is a particular method of pretranslation in which for segments where the translation memory offers no match, the source text is copied to the target segment. If performed with an empty TM, the target segments are initially identical to the source segments. If this procedure is followed, full, reliable compatibility is achieved between applications such as Déjà Vu and memoQ for clients using Trados versions predating Trados Studio 2009. For newer versions of Trados, the best procedure involves working with the SDLXLIFF files from Studio. If a freelance translator does not own a copy of SDL Trados 2007 or an earlier version used by an agency or direct client, this is the procedure to share with a request for presegmentation. While some clients might expect the translator to do such work using his or her own copy of Trados, I have experienced enough trouble with complex files over the years when different builds of the same version of Trados are used that I consider this to be the safest procedure to follow - safer even than having the translator do the work in Trados in many cases.

Step 1: Prepare the source files
Before creating a TTX file and presegmenting it for translation in DVX or creating a presegmented RTF, DOC or DOCX file compatible with the Trados Workbench or Wordfast Classic macros in Microsoft Word, it is a very good idea to take a look at the file and clean up any "garbage" such as optional hyphens, unwanted carriage returns or breaks, inappropriate tabbing in the middle of sentences, etc. Also, if the file has been produced by incompetent OCR processes, there may be a host of subtle font changes or spacing between letters, etc. that will create a horrible mess of tags when you try to work with most translation environment tools. Dave Turner's CodeZapper macros are a big help in such cases, and other techniques may include copying and pasting to and from WordPad or even converting to naked text in Notepad and reapplying any desired formatting. This will ensure that your work will not be burdened by superfluous tags and that the uncleaned file after the translation will have good quality segmentation.

Step 2: Segment the source files
If the source files are of types which Trados handles only via the TagEditor interface, then they may be pretranslated directly by Trados Workbench to produce presegmented TTX files. If they are RTF or Microsoft Word files, on the other hand, and a TTX file is desired, you must first launch TagEditor, open the files in that environment and then save them to create the TTX files, which are then subsequently pre-translated using Trados Workbench. If a presegmented RTF or Microsoft Word file is desired (for subsequent review using the word processor, for example), then the files can be processed directly with Trados Workbench.

Important Trados settings:

In Trados Workbench, select the menu option Options > Translation Memory Options… and make sure that the checkbox option Copy source on no match is marked.

In the dialog for the menu option Tools > Translate, mark the options to Segment unknown sentences and Update document.

After the settings for Trados Workbench are configured correctly, select the files you wish to translate in the dialog for the Workbench menu option Tools > Translate and pretranslate them by clicking the Translate button. This will create the "presegmented" files for import into DVX, memoQ, etc. If the job involves a lot of terminology in a MultiTerm database, which cannot be made available for the translation in the other environment (perhaps due to password protection or no suitable MultiTerm installation on the other computer), you might want to consider selecting the Workbench option to insert the terms.

Note: to get a full source-to target copy, use an empty Trados Workbench TM. However, if an original customer TM is used for this step you will often get better "leverage" (higher match rates) than if you work only with a TMX export of the TM to the other environment. If I am supplied with a TWB TM, I usually presegment with it first, then export it to TMX and bring it into memoQ or DVX for concordancing purposes. However, in some cases, such as with the use of memoQ's "TM-driven segmentation", you might get better matches in the other environment (not Trados).

The one performing the presegmentation might want to inspect the segmented files in TagEditor or MS Word to ensure that the segmentation does not require adjustment. Segments can typically be joined in other environments such as memoQ in order to have sensible TM entries in that environment or deal with structural issues in the language, but this will not avoid useless segments in the content for Trados. The best way to deal with that is by fixing segments there. Otherwise, I often provide a TMX export from memoQ to improve the quality of the Trados TM.

Step 3: Import the segmented source files into the other environment
The procedure for this varies depending on your translation environment tool. Usually the file type will be recognized and the appropriate filter offered. In some cases, the correct filter type must be specified (such as in memoQ, where a presegmented bilingual RTF/DOC must be imported using the "Add document as..." function and specifying "Bilingual DOC/RTF filter" instead of the default "Microsoft Word filter".

Some tools, like memoQ, offer the possibility of importing content which Trados ignores, such as numbers and dates, This is extremely useful when number and date formats differ between the languages involved. It saves tedious post-editing in Word or TagEditor and also enables a correct word count to be made.

A few words about output from the other (non-Trados) environment
If you import a TTX to Déjà Vu, memoQ, etc., what you will get when you export the result is a translated TTX file, which must then be cleaned using Trados under the usual conditions. Exporting a presegmented RTF or Microsoft Word file from DVX gives you the translated, presegmented file. The ordinary export from memoQ will clean that file and give you a deliverable target file. To get the bilingual format for review, etc. you will have to use the option to export a bilingual file.

Other environments such as memoQ or Déjà Vu may also offer useful features like the export of bilingual, commented tables for feedback. This saves time in communicating issues such as source file problems, terminology questions, etc. and is infinitely superior to the awful Excel feedback sheets that some translation agencies try to impose on their partners.

Editing translations performed with Trados
A translation performed using the Trados Workbench macros in Microsoft Word or using TagEditor can be easily reviewed in many other environments such as Déjà Vu or memoQ. In fact, I find that the QA tools and general working environment with this approach is far superior to working in TagEditor or Word, for example. Tag checks can be performed easily, compliance with standard terminology can be verified, content can be filtered for more efficient updates and more.

Editing translations performed with more recent versions of Trados (SDL Trados Studio 2009 and 2011) is also straightforward, as these SDLXLIFF files are XLIFF files which can be reviewed in any XLIFF-compatible tool.