Showing posts with label DVX. Show all posts
Showing posts with label DVX. Show all posts

Apr 15, 2014

Speech recognition for translators: microphone tips

Guest post by Jim Wardell

Mark Myworts is heavy into a major procrastination project, pawing through moldy old copies of Popular Mechanics in Grandpa’s basement, when a small classified ad in the back pages catches his eye. He blows off the dust:
“Translators! Double your income overnight with amazing new technology! Works wonders for English, German, Spanish, French, Italian, Dutch. No obligation. Call ... Full confidentiality guaranteed.”
[Fade in “Twilight Zone” theme music.]

[Cut to Mark talking intently to his computer.] “... should be used instead of the diminutive terms ‘pud’ and ‘loser’” ...

[Fade to Mark and kiddies.] “Well daddy, can we? can we? Can we go to the circus tonight?” “Sure kids, I’m knocking off early today,” says Mark nonchalantly, getting a kiss and one of those sexy “well-what-about-after-the circus” looks from his admiring wife.

Science fiction? 1950s social mythology? Perhaps.

But the simple fact remains – at least now in 2014 – that translators into English, German, Spanish, French, Italian and Dutch really can double their productivity on average using some amazing, although not quite so new technology: speech recognition.


***

I’ve been using speech recognition to translate from German into English for nearly 20 years. But it was not until about seven or eight years ago that computing power and speech recognition software had improved to the point where serious productivity gains became possible. It was at that point that it became imperative for me to find a CAT tool that was totally compatible with Dragon NaturallySpeaking. At the time, only two products met this requirement: Déjà Vu and memoQ. For various reasons, which I won’t get into now, I decided to go with memoQ, a decision I have never once regretted.

Most any CAT tool can be made to work with Dragon by using the little “Dictation Box” text buffer that’s provided as a workaround in Dragon for software that is not truly Dragon compliant. The procedure needed to translate average moderately sophisticated technical documents in noncompliant CAT tools can often be cumbersome and inefficient: one copies the contents of the current source segment text into the Dictation Box so any strings that do not need to be translated can be left as is or moved around as desired and so that sections of text that need to be translated can be overwritten by marking them and then dictating the new translation “over the top”. Once the source segment has been duly massaged in the Dictation Box, the contents of the box are then transferred to the target box in the noncompliant CAT tool. Of course, various tags and formatting that might have been present in the source segment are often lost when source text pasted into the Dictation Box. So they need to be put back in again after the contents of the Dictation Box have been pasted into the CAT target box. If this sounds gruesome, it is.

So why not just dictate straight into the noncompliant target box and fix the messes as they occur? The answer is simple: there are often too many messes, and, worse still, any incorrect speech recognition that occurs cannot be corrected in a way that will ensure that correct and not erroneous data will be fed and saved in the Dragon speech recognition engine. Over time, this would degrade speech recognition accuracy! I spent some years trying to address this issue with publishers of CAT tools other than memoQ and Déjà Vu ... with zero success. So if you’re not already using Dragon and want to use it with a CAT tool, make sure that the CAT tool that you are thinking of using is really fully compatible with Dragon and that you can get your money back if it’s not. Do not trust and do verify.[1]

At one point before I switched memoQ, I was compelled to do a good bit of this acrobatics moving text into an out of the Dragon Dictation Box. I began to have the feeling that the cutting edge that I was working on in a number of well-known CAT tools was so dull that I might just as well have been typing in my translation in the old-fashioned way. So I collected some statistics discovered that that was indeed the case. My output was the same in noncompliant CAT tools and Dragon as with touch typing without Dragon.

All that changed with the memoQ’s full Dragon compatibility! Incidentally, memoQ has full Dragon compatibility throughout the interface and not just in the translation grid. So if you want to dictate notes or definitions in term base entries, you can, and you can still use all of the selection and correction features you are accustomed to using in Dragon. Want to write a longish note to a client in a memoQ Comment box? No problem. Dictate away.

* * *

Anyone who has dealt with integrated technologies, any process in fact, knows that the old saying “A chain is only as strong as its weakest link” is totally true. So to get really great speech recognition results, not only does one’s CAT tool have to be compatible and outstandingly good, one’s computer needs to be sufficiently powerful, and one needs to use the best available microphones. I heartily recommend KnowBrainer.com as a source of top quality microphones for speech recognition. To my knowledge, KnowBrainer is the expert in the USA, probably the world, when it comes to speech recognition products. People who want to achieve maximum accuracy with speech recognition software should make their first stop KnowBrainer’s Microphone Comparison page.[2] For many years, I used KnowBrainer’s top-rated Samson Airline 77 microphone. This microphone was vastly superior to anything I had ever used in the past and came delightfully close to delivering 100% speech recognition accuracy. Earlier this year, however, I learned that the wireless channel used in my old Airline 77, which I bought while I was still located in the United States, was being shifted to use by mobile phones in Europe and would no longer be legal. So I checked out KnowBrainer again, and learned about a relatively new microphone being produced specifically for speech recognition by a Belgian company: SpeechWare. Upon consulting with KnowBrainer’s Lunis Orcutt (Mr. Speech Recognition in my book!), I ordered the SpeechWare 3-1 TableMike. This desktop mic is a great product and just as good as my old Airline 77. It’s the mic that Lunis himself uses.

However, after using it for a week or so, I realized that it was not for me because I had to keep my mouth relatively close to the microphone and couldn’t move around like I was used to in the past in order to relax my back muscles and stay fresh. I then ordered a FlexyMike headset mic from SpeechWare that basically uses the same technology but allows one to move around freely. SpeechWare has three models of the FlexyMike: the FlexyMike Basic (FMK01), the Single Ear (SE) and the Dual Ear. I chose the Dual Ear on the principle that distributing the weight of the mic over two ears would be more comfortable and stable for hours and hours of continuous use.

When I was still using the tabletop TableMike, I found that I had a tendency to move a little too far away from the microphone over time, which occasionally reduced speech recognition performance. The TableMike has two settings: a long-range setting, which allows one to have one’s mouth as far as 30 cm (12 inches) from the microphone, and a “normal and VoIP” setting (with a maximum distance of 15 cm / 6 inches). The greatest accuracy is achieved with the closer distance. Lunis says he likes the TableMike because he moves around in the office a lot and doesn’t need to fumble around with headset whenever he leaves his desk. For this reason, I would recommend the TableMike as the best choice for project managers and administrators who may frequently have to leave their desks and who mainly use Dragon at brief stretches to dictate e-mail messages or enter data in translation business management software. For hard-core translation work, the FlexyMike is the way to go. I find the accuracy with the FlexyMike to be perhaps a tad better than that of the Airline 77, which is saying a lot. I can use the FlexyMike while listening to the radio a moderate volume levels, so the noise cancellation is also quite good. KnowBrainer gives its noise cancellation a score of 9, which is better than that of the Sennheiser ME3 KB headset mic (gets an 8), which I have used with good success for years in automobiles, trains and airplanes! All the same, if anyone has to dictate in an extremely noisy environment, one might want to check out “theBoom v4 KB”, which gets a high accuracy rating and a 10 for noise cancellation (but only a 9 for comfort!) from KnowBrainer. My experience is that KnowBrainer is pretty fanatical about these evaluations and that they are quite reliable.

For the average translator, who works long hours in a relatively quiet environment, accuracy and comfort are the two most important factors, more important than noise cancellation. I don’t need speakers on my headset, which means that the headset can be as light as a feather and can be worn comfortably all day long. If need be, Skype calls or music can be played through normal computer speakers. On the other hand, if one is working in an open office setting with a number of other translators close by, one might want to have a headset with speakers covering both ears to block out distracting voices so one can concentrate better. In such cases, I’d consider the mono Umevoice “theBoom Pro-2 KB” or the stereo hi-fi equivalent “... 3 KB” if you want to block out room noise and also want to listen to music while you translate. (I translate very complicated, detailed stuff and usually extremely distracting to listen to music while translating, but not all material that gets translated requires extreme concentration. I could also easily imagine listening to a high-bandwidth feed from, say, jazzradio.com premium (unabashed plug) to make routine administrative work more pleasant.

Getting back to the FlexyMikes: SpeechWare was kind enough to also send me a single-ear model to test and evaluate, so I have used both versions extensively. Both the single-ear and the double-ear mics are extremely comfortable and both are very easy to adjust to get a custom fit that is secure and comfortable. The materials used in both mics are of exceptionally high quality and should provide many years of reliable service.

Both FlexyMikes connect to a computer USB port across a “SpeechMatic MultiAdapter”, which has been especially configured for high accuracy with speech recognition. I am convinced that the special design of the MultiAdapter is one of the main reasons why the FlexyMikes work so well.[3] Be sure to buy this along with your FlexyMike. The same circuitry that’s in the MultiAdapter is integrated into the TableMike units. So if you already have a TableMike, you don’t need to buy a MultiAdapter, unless of course you want something really small and light to use with a notebook computer when traveling.

I did not test the basic version of the FlexyMike, from the pictures it didn’t look as comfortable as the other models.

KnowBrainer.com ships internationally. SpeechWare microphones are also available directly from SpeechWare in Europe.

[1] If you want to see what “fully compatible” means, have a look at http://kilgray.com/news/once-upon-time-there-was-dragon.
[2] http://www.knowbrainer.com/core/pages/miccompare.cfm
[3] So is KnowBrainer: See http://www.knowbrainer.com/NewStore/pc/viewPrd.asp?idproduct=464



***


Jim Wardell will be presenting optimized work methods for speech recognition once again at this year's memoQfest in Budapest, Hungary.

Nov 22, 2013

memoQuickie: keyboard shortcuts for migrants (updated)

(PM - Pro - 2013R2 - 2013 - 6.2 - 6.0 - 5.0)

You can adapt memoQ keyboard shortcuts to your personal preferences or to be ergonomically compatible with other translation environments tools you use frequently for better productivity and reduced risk of errors.


Although keyboard shortcuts can be managed in the Resource Console, it is more useful to do so under Tools > Options… > Keyboard shortcuts, because that is the only place where a given set of keyboard shortcuts can be selected for use. Marking the checkbox for a list in the dialog shown above will make it the active one.

Look carefully at the keyboard shortcuts available in memoQ. Not all of these commands are found in menus (for example, the shortcut for quick search with selected text in a translation grid, Ctrl+Shift+F by default). To examine a set of keyboard shortcuts, select it and click Edit to show the list.


To change a keyboard shortcut, select the value in the Shortcut key column of the editing dialog and press the new key combination.

Aug 19, 2013

Selectable metadata for memoQ 2013 projects

One of the things I have missed very much since switching from Déjà Vu to memoQ years ago is the ability to create and maintain selectable lists of metadata for classifying my data. One of the strengths of DVX was that this data could even be used to prioritize TM and terminology relevance during translation. But even for simple things like sorting and filtering data for an export, it can be very helpful.

Let me give an example. I have an old client I'll call National Translators. Well, sometimes that's the name I use when filling in the Client field for the memoQ project. Sometimes I write Nat'l Transl, sometimes it's NatTrans or even NT. And then when my fingers get rebellious I might have the occasional NtaTarns or worse.

Despite the messy appearance of screenshots of the TM and termbase lists in my various tutorials, for the most part I follow the "Big Mama and Papa" approach to data management with a large master TM and termbase with over a decade of archived reference material. But I do occasionally like to filter those data and produce a more focused termbase or TM for a projects, such as all the NatTrans material from projects involving Poultry. That was easy with Déjà Vu. Each client had a unique, selectable code. Subjects were number coded with a sophisticated classification scheme that I adapted for my own use. With memoQ it's been a real pain in the ass.

Well, it seems that times are a'changin. A little bit at least in this respect. One change that sort of slippe under my radar in memoQ 2013 was the addition of selectable data to projects through the use of the free Kilgray Language Terminal. I almost missed it completely, because I was looking at some of the latest "innovations" there from the wrong perspective. Wrong for me at least.

Clients list on my demo profile on the Kilgray Language Terminal. Click to enlarge.

Kilgray recently introduced the ability to do basic project "management" on Language Terminal. Price lists. Clients lists. And more. I was appalled, or at least quite uninterested in that, though I rather like other aspects of Language Terminal. I have a good tool for quoting jobs and maintaining my client records, and I really don't think I'll be replacing that with the rather simple start that has been made by Kilgray in this area. And having lived in Germany for years, I have almost adopted the knee-jerk aversion to storing my client data online which is so common there.

But... there's another way. Better for me. I don't have to enter my clients' details. I can enter just the names. Or better yet - my preferred codes (which can protect their identities but let me sort my data better). Click on the screenshot above to see an example of this in the last two entries. You need not be as cryptic as I was in that example.

On the "Professional" page of my Language Terminal profile (the link to the left of "Clients"), I can enter my subjects. Kilgray intended this for their find-a-translator search function that they are adding to Language Terminal, but I'm probably not going to be interested in being found and approached by the sort of prospect that might use their database. My philosophy is that looking for a translator based on tool use is fundamentally backward, and I really don't want to support bad practices like that. Translators should be engaged based on subject and linguistic expertise; the translation technology involved is like a shirt, tie and a pair of shoes - you just put on what is appropriate for the occasion. But without the subject and linguistic competence, you really ought not to be part of the game at all.

So once again, I would enter my subject data on Language Terminal, not with the idea of being "found" by some Indian or Mongoloid agency to be offered the opportunity of a lifetime at 2 cents per word, but rather with an eye toward sensible data classification for use in filtering later. Here's an example of what these metadata entered on Language Terminal look like when you start a new memoQ project and mark it to be "entered" on Language Terminal.


I still like the local DVX approach better for such metadata, but this is actually an improvement, and it will help me clean up my data organization. And using these features for my purposes, rather than the purposes for which they seem to have been created, will also maintain confidentiality as I want to. In fact, the profile seen here is not even viewable by other Language Terminal users.

There are many other very useful features of Language Terminal, which make it worthwhile to get a free account, even if you don't use memoQ. The blockbuster is still the free InDesign processing service, which enables one to handle native INDD files, get PDF previews at any time and convert InDesign files to XLIFF for convenient translation in most modern CAT tools. As a memoQ user, I find the backup feature useful as well; the Resources page is starting to get a few useful things, and rumors of future plans make me think this is really something to watch closely.

But this recent "revelation" of the possibility of selectable metadata for my memoQ projects is a small but very welcome addition to my toolbox in memoQ 2013, and finding this in an area of the site that I had already written off as uninteresting to me was perhaps the most pleasant surprise. It's nice to be wrong like that.

Aug 16, 2013

memoQ AutoCorrect: mysteries revealed

Actually, AutoCorrect isn't that mysterious to those familiar with it. Many Microsoft Office users love it or hate it. I usually love it when I type English, but when I switch between languages in the same document, strange mutations occur in my words and I often wonder how I could possibly have typed some of the things I seem to have typed and of course did not.

Last December when I started the research to update my book of memoQ tips (which is still in progress, because the software is a fast-moving target to describe), I found a way to migrate the AutoCorrect lists from Microsoft Word to memoQ (and vice versa). This was a happy day for me, as a Dutch partner had been asking for exactly that for a very long time, and Kilgray's Support had not been able to offer a solution. I never did get around to blogging my findings, but a few months later, a similar solution was published in the Kilgray Knowledgebase. It states that it's perhaps only for migrating AutoCorrect lists from MS Word 2003, but I used an old macro from MS Word 98 when I worked out the problem, and if that still functions for MS Word 2010, then I'm sure Kilgray's posted solution must be fine for new versions. (Just be careful to use UTF-8 as the code page of text files you transfer or there may be trouble.)

But the best solution was actually published a few years earlier by Val Ivonica. In Portuguese. She included the macro code, and I like her macro (or the one she got from someplace) better. For some strange reason, the only really good information available on memoQ AutoCorrect up to now that I could find is in Portuguese. There are some nice examples of useful AutoCorrect shortcuts for periods of a year from William Cassemiro on the Janela Tradutória blog.

I was quite surprised to learn that many users of memoQ have no idea what AutoCorrect is; Déjà Vu offers the same feature, but I think it's missing in the various Trados versions, possibly because of the history of Trados Workbench as an application used primarily in the MS Word environment. The Kilgray documentation I could find was rather skimpy and seemed entirely focused on typing shortcuts. The idea of correcting spelling or vocabulary differences between language variants wasn't anywhere I could find it.

So I put together this "little" overview of how AutoCorrect works in memoQ and how and where to manage the AutoCorrect list resources there. It's a start... perhaps Kilgray or someone else can fill in the missing bits.


Time  Description
0:38  Activating AutoCorrect in an open project
1:47  AutoCorrect in action while typing
3:30  How the "primary" AutoCorrect list "rules"
3:55  Slide show: overview of AutoCorrect
4:59  Slide show: Three places to manage AutoCorrect

Jul 27, 2012

Translating "foreign" bilingual tables in memoQ

--- In memoQ@yahoogroups.com, Liset Nyland wrote:
> A client has sent me a 2-column rtf-file export from DVX.
> It looks similar to the MemoQ export but not quite.
>
> The target column is full of fuzzy matches, so I need to recover these.
...
> ... do you know if there's a bilingual format exported from DVX that can
> be loaded and translated directly in MemoQ?
There is one way to deal more-or-less directly with the DVX bilingual RTF tables - or any others being introduced by other providers or bilingual tables that some customers are fond of using to store translation strings or other content. I would love to see a general import routine from Kilgray that allows selection of source and target columns of various file types in a dialog, but until then...
1. Get a copy of the PlusToyZ macros by German/English to Ukrainian/Russian translator Arkady Vysotsky.
2. Copy the source and column targets into a separate RTF or MS Word file.
3. Run the PlusToyZ macro to convert that to a Trados-like bilingual (the old Wordfast/Trados RTF/DOC bilingual)
4. Import the converted file to memoQ using the default filter, which is intelligent enough to recognize that you are dealing with Trados-compatible bilingual DOC/RTF.
5. Translate, edit, feed the TM, etc.
6. Export the processed file.
7. Use the appropriate conversion macro in PlusToyZ to turn the data back into a table.
8. Paste the data back into the original bilingual table from DVX or whatever tool it came from.
This is the preferred method to use when your bilingual table is partially pretranslated, or you have a translated table you want to edit while having a better look at the source text. This would also be a useful method for jobs I've had where customers have string or terminology lists in Excel to translate that are in some cases incomplete.

Once you get to Step 3, you can translate that bilingual format in any tool which works with the old Trados RTF/Word segmentation, such as WordFast Classic.I think that was actually the reason Arkady wrote those macros in the first place.

If you want to protect the DVX codes (or similar structures, including placeholders) or store them in the TM as proper tags, run the Regex tagger or use a cascading filter a described in my other blog post about regular expressions for DVX external table translation in memoQ. Of course, for content other than DVX tags, a different regular expression will be needed.

Jul 12, 2012

RegEx for translating DVX external view tables in memoQ

Atril's Dejà Vu was the first translation environment tool I am aware of to offer a means of exchanging translation content for review, correction and translation using an ordinary word processor. These "external views" were the original inspiration for memoQ's RTF bilingual tables, which are used in many interoperable workflows not only with people using a word processor but with many other CAT tools as well.

As with memoQ RTF bilinguals, the content in the "external view" which is not to be translated can be selected and hidden with a word processor, leaving only a target column into which the source text has been copied. But these steps alone with the standard RTF filter pose a problem:


The DVX "codes" (tags), which are represented by curly brackets enclosing a number, are not protected. Erasing parts of them can damage the content. It is also not possible to perform a tag check using the memoQ QA functions.

The solution is to use the Regex tagger in memoQ. There are two ways to do this.

If the document has already been imported,


the tagger can be run from the Format menu.

Enter the appropriate regular expression to convert the DVX code to a protected tag: \{(\d+)\}


This expression describes the pattern of the text to protect: a curly bracket (with a backslash in front of it to indicate that this is to be interpreted literally as a character, not as a bracket for grouping something), one or more digits (\d indicates a digit as opposed to d, which is just the letter d, and the plus sign means one or more) and a closing curly bracket ("escaped" with a backslash so it is understood literally as the bracket character in the DVX code.)

Click Add to put the rule in the list, then click Run tagger now.


The result is protected tags in the translation grid of memoQ. These can also be verified with a QA tag check after the translation is completed.

Your regular expression rules can be saved in the dialog above and re-used, or exported from the list under Tools > Resource console... > Filter configurations and shared with others.

The regular expression tagger can also be used as a cascading filter when the RTF file for the external view is imported:



Here the configuration can also be saved or another one loaded.

Jan 7, 2012

Translation tool concordances compared

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.

Jan 2, 2012

ODT files in translation environment tools

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.

Dec 21, 2011

Presegmented "classic" Trados files

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.

Oct 7, 2011

New version of CodeZapper

While I was traveling this week, our esteemed colleague Dave Turner released version 2.8 of his CodeZapper macros for Microsoft Word. I have written about these before; they are among the finest tools I know for cleaning up messy RTFs and MS Word formats that make work with translation environment tools Hell because of superfluous and disruptive tags.

CodeZapper can be a big help with any translation environment which displays tagging in some way. These include OmegaT, Déjà Vu, memoQ and the various Trados instances. For whatever reason, no tools vendor has seen fit to create a quality management tool of this same caliber, though Kilgray at least partially addressed this with a memoQ filter option that often does help with trash tags.

Version 2.8 of CodeZapper is currently available by direct request to the author, Dave Turner. There is now a separate "read me" file explaining the functions of the macro buttons in some detail.

If you benefit from this tool, please support its creator. I do. He has saved me many, many hours of tribulation in translation, far more value given that the little money he has received from me. Here is the first part of Mr. Turner's documentation to give more background on this useful tool:
What is “CodeZapper”?

"CodeZapper" is a set of Word macros (programs written in VBA to automate operations in applications) designed to “clean up” Word files before being imported into a translation environment program such as Deja Vu DVX, memoQ, SDL Trados Studio, TagEditor, Swordfish, OmegaT, etc.
Word documents are often strewn with junk or “rogue” tags (so-called “smart tags”, language tags, track changes tags, soft hyphenations, scaling and spacing changes, redundant bookmarks, etc.).
This tagged information shows up in the DVX or MemoQ grid as spurious {1}codes{2} around, or even in the mid{3}dle of, words, making sentences difficult to read and translate and generally negating many of the productivity benefits of the program.
OCR’d files or files converted from PDF are even worse.
CodeZapper tries to remove as many of these tags as possible while retaining formatting and layout. It also contains a number of other macros which may be useful before and after importing files into DVX or MQ (temporarily transferring bulky images (photos, etc.) out of a file, to speed up import, and then back in the right place after translation, moving footnotes to a table at the end of the document and back after translation, for example).

Is it freeware?

No. To help ensure its continued availability and improvement, there is now a one-time, 20 euro charge for the program. This will entitle you to free future upgrades.

Is it risk free?

Although it’s been fairly extensively tested on a range of files, you should obviously only use it on a backup copy of your files and at your own risk.

How do I install it?

CodeZapper come in the form of a Word template (.dot file) with a custom toolbar which you can either copy to the Word startup directory (following the path in Tools/Options/File Locations/Startup) in which case it will be enabled on starting Word. or to the “Template” directory containing Normal dot and other Word templates (following the path in Tools/Options/File Locations/User templates). You then enable it by selecting it in Tools/Templates and Add-ins, as and when needed.

Apr 6, 2011

Atril is dead!

Long live... ? The e-mail messages the other day announcing the "investment" in Atril by PowerLing, the odd French company hastily formed a few years ago to botch the marketing of Déjà Vu X, and the subsequent merger of the two companies under the name "Atril" was no great surprise, but it was a disappointment nonetheless. The "Atril" web site has a new look, in your face right away with the option to add products to a shopping cart, though at the moment it's really not clear which products:



Like any site managed by the clueless crew formerly known as PowerLing, the content is unfinished, chaotic and will probably mutate into something over time. And yes, it is true that Jesus is coming soon. He's tired of waiting for the promised new version of Déjà Vu to be released first.

Atril and its product Déjà Vu were critical to my translation business for many years. But markets evolve, and the product has failed to evolve with them in an effective way. Right now if someone were to ask my recommendation for a translation environment tool offering a broad scope of source format access and good productivity features, I could not recommend this tool with a good conscience any more. I think the best picks for freelancers these days among the commercial tools are probably SDL Trados Studio if you like pain, memoQ if you prefer pleasure. For LSPs and corporate users same deal (memoQ being the best for performance, flexibility and ease of maintenance, SDL being... well... SDL) unless you need something like the Ontram workflows for your production of marketing brochures.

Mar 3, 2011

Homogeneity: another "secret" competitive weapon with memoQ

Earlier today I received an e-mail with the following question:

At the moment we are wrestling with an analysis issue that should be solvable but we don't know how to. As I always see your posts about all kinds of TM issues, I was hoping you might be able to provide some advice.


The case is as follows:
From one of our clients we have received what is basically a list of tools in Excel for translation (NL-FR). My colleague made an initial quotation for the project based on the Trados analysis, which revealed 23% repetitions in the file. However, the client received a much lower quote from a different provider. The reason for this, according to him, is that there are a lot of high fuzzy matches in the file which the other provider has counted but Trados doesn't (for example, "... metaalzaagbeugel 12 inch zwaar model met D-greep" and "... metaalzaagbeugel 12 inch zwaar model met rechte greep".)


Do you know whether there is a way (or tool other than Trados) that does count these fuzziess when performing an analysis?
To me, this sounds an awful lot like my PM acquaintance has been blind-sided by Kilgray's homogeneity analysis, which has been a feature of memoQ for a very long time. It's a feature about which I personally have mixed feelings. Used in the wrong way by unscrupulous agencies or ignorant persons, it can be yet another club with which to clobber translators and their rates to the ground and bring about the Hobbesian state of being so many fear is in our future, if not our present. But I approach it as a valuable information tool for helping me estimate how much time a rush project might actually take. Or in the case of my correspondent's competitor, it can be used judiciously to calculate a competitive rate that might not land you in the poorhouse.

Classic Trados and most other CAT tools calculate fuzzy matches based on the content of a translation memory. If these sentences:
The cat is black and white.
The dog is black and white.
The rabbit is black and white.
do not have something similar in a TM used for analysis, they will all be counted as "No Match" segments. However, with a good tool like Atril's Déjà Vu X and it's functional "assembly" technology, similar sentences like these are handled almost like 100% matches from a TM. But DVX still won't tell you about the time you might save.

Kilgray's memoQ analyzes a text for internal redundancies and "fuzzy redundancies", the latter being referred to as having a degree of "homogeneity". But as anyone who works with CAT software knows, even high fuzzy matches can be utterly useless and cost more time than content with no statistical similarities. Translation is about meaning, not statistics, and the price assassins at Trados and other tool pimps of the past sold everyone a lousy bill of goods with nonsense marketing lies like "You'll never have to translate the same sentence again." Well, guess what? If you do successive versions of an information brochure or technical manual and don't start to update your language after a while, your text will soon sound like it was written for an age long past and might not communicate as clearly as it should. Those who can read German should have a look at the various editions of the classic cookbook Die Süddeutsche Küche by Katharina Prato, which was popular from the mid-19th century until the 1930s for truly dramatic examples of the changes in a language. (These are available online via Google Books and various libraries online. They are also a good source of offal recipes - people ate all manner of interesting things back then.) But this happens on a much shorter time scale as well: my eight-to-ten-year-old texts for the AOK social insurance brochure and various IT manuals sound rather awful and dated, though they were quite acceptable at the time they were written.

Used as a planning tool, however, the homogeneity function in memoQ can give you valuable information and help you compete more effectively in difficult times and markets.

Nov 3, 2010

Long-awaited Déjà Vu X update released (Build 335)

The following notice was received today via the dejavu-l list on Yahoogroups, one of the best sources for information and support for Déjà Vu users. Build 335 includes the following fixes/improvements:
  • Added support for Adobe InDesign CS5 IDML
  • Added support for Office 2010
  • Performance improvements to SGML/XML filters (including Adobe InDesign INX and Office 2007/2010)
  • Performance improvements to DOC/RTF filter
  • Performance improvements to XLIFF filter
  • Improvements in MIF filter handling of markers and character sets
  • Number-only segments present in the TM are now retrieved correctly
  • Fixed bugs in XLIFF filter
  • Fixed performance issues when using TeaM Server with AutoSearch enabled
  • Fixed a bug in match sorting for AutoSearch/Assemble
  • Fixed a bug where PowerPoint 2007/2010 slides were imported in the wrong order
  • Fixed issues with missing spaces in Office 2007/2010 files
  • Fixed bugs in AutoSearch
  • Fixed bugs in Assemble
  • Fixed bugs with renumbered matches
  • Fixed issues with incorrect characters in External Views
  • Fixed bugs in the Alignment Wizard grid
The update can be downloaded from the Downloads section of the Atril website or directly from one of the following URLs:
http://www.atril.com/dvx/current/Update.exe
http://www.atril.com/dvx/current/WebSetup.exe
The link for the full setup package is http://www.atril.com/dvx/current/Setup.zip

As usual, it is  recommended that you unplug your dongle before updating, since the installer will need to update the dongle drivers. If you are prompted for the location of the drivers when plugging your dongle back in (this is a signal that the old drivers were not updated properly), you can point Windows to the \Dongle subfolder of your DVX installation folder (usually C:\Program Files\ATRIL\Deja Vu X\Dongle).

Version 8 of the application, expected to be released in 2009, is on schedule to arrive before Godot.

Update: The word on the Yahoo user list is that there are a number of bugs in the new build and there have been two "patches" for it already. Some of the issues seem to be very configuration-specific. I'm going to wait a while with the upgrade myself until the bug reports on the list subside.

Aug 20, 2010

Impact

Once in a while I find it useful to review the state of things in my life and business and consider what actions or tools have had the greatest positive impact. Ranking the effects is usually rather subjective, of course, but that's OK - we live by subjective impressions far more than most of us realize.

So I asked myself what has made the greatest positive difference in my translation business in the past year? In the past five years? In the past ten? It was fairly easy to narrow down the answers.

For the past year, the increased use of online management tools for project management, deliveries and invoicing has helped me the most.

In the past five years, two things have mattered most: greater collaboration with a competent partner (which made many projects possible which I would otherwise not have touched) and joining a professional translators' organization (BDÜ in my case) after passing the state exams in Berlin, Germany. That has brought in many nice referrals. I don't think I can narrow down the five-year factors any more, because the impact of all three actions has been huge, and all are rather closely related in various ways.

The greatest impact over the course of the ten years I have been engaged in significant volumes of translation has surely been the use of translation environment tools such as Déjà Vu, SDL Trados and memoQ (just to name the primary ones I work with). That's also why these are discussed so often in this blog. Properly applied, these tools can play a positive role in nearly any commercial translation business.

Of course, every translation business is unique, and needs and priorities differ. What has had the biggest impact for you in the past year, the past five and past ten?

Aug 5, 2010

Results of the Trados user survey

After my first fling with the Google Blogger polling tool, I decided to look a little more closely at the breakdown of the "Trados users" who had responded to the poll.

The new poll asked about the use of various Trados versions. Personally, I use two older versions (2007 & 2006) and once in a while I trot out MultiTerm 5.5 for clients with Stone Age termbases. I'm still testing Studio 2009, though most of my objections have been dealt with adequately over the past year, and if good people like Paul Filkin and Roger Lai can effect a change of culture at SDL Trados so that insulting marketing campaigns like the disgusting "amnesty" a while back are not seen any more, I could envision myself accidentally recommending an SDL product beside MultiTerm or Passolo for productive use. It might take a lot of Unicum to get there, however.

But SDL Trados Studio 2009 looks good on a netbook for the most part. I'll have to give them that. The Hungarians in whose technical footsteps they follow have some optimization to do for that environment. And as requests for Studio 2009 projects pick up, I'll inevitably look more closely at interoperability issues with that environment, and from what I've seen so far, I don't expect to be terribly irritated.

The responses in this poll were not exclusive (as anyone with rudimentary addition skills can discern). So someone who uses both the latest version and the previous one for various clients should have (and presumably did) mark both responses. To me, the results indicate however shakily (due to the low number of poll responses) that SDL has moved successfully to the new generation of technology and established a sufficient base of licenses that it will remain viable for the present generation of translation environment technology. That was to be expected given the momentum involved. But there remains great skepticism among the old user base, and when I talk to agency owners who describe the technical challenges they face with data conversion and interoperability, very often I must point out that what they are looking for is currently offered only by the memoQ Server at a friendly price that might make those who invested in other TM server technologies reach for the Alka Seltzer. In one big Berlin agency I'm close to, the license for SDL Trados Studio 2009 was purchased months ago, but there's no hurry to install it as the project managers ask me to write up procedures for Déjà Vu and memoQ to handle insane character mapping problems for Java properties files in Greek, which the last Trados 2007 could no longer handle well. I assume Studio 2009 can deal with the problem, but the trust seems to be gone. Similar reservations have been expressed by other agency owners who have used Trados since version 1 and are frustrated that when problems arise, the chaps on the support line know far less than they do and read from a script. Meanwhile, in the Wild East, software-slinging CEOs and heads of development still provide competent, detailed, personal support for devilish technical challenges at odd hours.

On the whole, I would say "good job" to SDL for having kept so many users "in the boat" by getting them to buy Studio 2009 licenses. And I hope they can keep them there by expanding the usefulness of the product for all by not only improving its performance (use of resources) but also all aspects of interoperability so that it can become a true universal work tool for translation, even including connectivity to other server systems for its desktop users. To the extent that one can claim any tool provider is in that race, they are not yet in the lead.

Jul 1, 2010

Results of the June translation tools surveys

At the end of May I discovered that a new widget had been added to Google's Blogger tools, which offered me a simple way to conduct single question polls. I had been wanting such a feature for a while, so I promptly tested it with a poll on translation tools used (the one on the bottom in the graphic at the left) and followed it a few days later with a question on the number of tools used routinely when it occurred to me that they were a number of others like me who make routine use of multiple tools. As I see it, the responses to that question are also important when considering the significance of responses to the other question. The initial trend of the results remained fairly constant throughout the month, even with a large surge in responses after Alex Eames kindly mentioned the polls in his last tranfree newsletter.

Over 40% of respondents use more than one translation environment routinely. (Astute readers may note that the percentages don't add up. Google's programmers are obviously fond of new math or at least screwy rounding and truncation.)  This would include people who actually translate in multiple environments as well as those who use environments other than their favored one for project preparation and QA. My partner is a good example of this latter category; she uses "classic" Trados all the time to export TMs and terminologies provided to her, pre-segment Word/RTF and TTX files for translation in Déjà Vu X or memoQ and to perform tag QA on TTX files. Probably a few other things too. But after she learned the benefits of more modern translation environments, I would risk singing soprano if I suggest that she actually take up translating with the Trados Workbench macros or TagEditor again. Maybe I can get her to look at SDL Trados Studio 2009 one day, but first I think I'll take up something safer like mud wrestling with crocodiles.

The 8 to 12% of respondents who indicated that they use no translation tools is probably well under the true figure in our profession. My blog tends to attract readers with an interest in the technology of translation and not so many who like to contemplate flowery phrases for translating obscure poetry (too bad, really - that's more my taste, but first bills must be paid). But since one of my intentions in creating these polls was to get an idea of the technology interests of my readers and perhaps choose some future topics to reflect these interests, I'm not really concerned about an accurate representation of the full population of translators. The profession is simply too diverse and fragmented for me to care. It's interesting to see that I belong to the 1% of nutcases that use 5 or more tools - I can hear I told you so on this one already from many quarters. And I like to think I'm not a nerd. Einbildung ist auch 'ne Bildung.

In the poll on specific tools, I received some criticism for not including certain tools under a category more specific that "other". As you can see, with a grand total of 15% other, I'm probably not missing much there. When I see interesting minor tools I'll certainly mention them if I can do so with some knowledge, but I don't have the time to offer the extensive expert surveys that you'll get from a guy like Jost Zetzsche and his Toolkit newsletter or book on computer skills and tools for translators.

I probably also should have split the Trados part of the question into at least the new and old generation of SDL products, but I simply didn't think of this until a few days after the poll was running, and I decided to deal with that issue in a follow-up question another day (and I have - see the poll in the left sidebar, which will run until August 1st). This is also relevant to me, as I'll be exploring the no-longer-so-new Studio 2009 version more in the future. (Why call it 2009 still when you release the service pack that actually makes it work in 2010?) It may run like a lame pig on many machines, but I do like some of the interface elements a lot, and it's the best program on netbooks I've used as far as critical parts of screens and dialogs not usually getting cut off.

If the poll statistics even roughly approximate the real distribution of tools among commercial translators, then the perception that "everyone" uses Trados is certainly not even close to correct. The greatest share of licenses is certainly for some version of Trados, but if one considers the number of people who use it as I do primarily for some of its filters and to prepare projects for clients who ask for Trados uncleaned deliverables, then the percentage actually translating with Trados will be far under 50%. This is a point well worth considering for those who want to use the most qualified translator for a given subject: statistically, the odds are against you if you insist on Trados use. It's far better to design projects in a tool-neutral manner as far as practical and let the translators work with whatever they feel most comfortable with. The importance of using the best qualified translator for a particular subject rather than the first monkey with a particular tool in his box is one of the reasons why I like Déjà Vu X and memoQ so much: the RTF table exports from these two tools allows projects to be translated or edited by anyone with a modern word processor regardless of the source format. Every translation environment tool should follow the example set by Atril and Kilgray in this respect.

It's also interesting to note that "major" tools like Star Transit and Across only have 6% of respondents claiming use. Anyone who tries to insist on a translator using those tools is playing a very bad hand.

The main conclusion I draw from these data is that give the diversity of tool use among qualified translators, it is more important than ever to design and test our processes for true interoperability and to drop the religious insistence on the use of One True Tool, no matter what that tool may be.

But that's just my initial reaction to the data. What do you think?