Trados: beware of wrong links

I have complained in the past of various problems Trados has with fuzzy matches. A particularly insidious one is the way Trados treats Internet URIs and other links.

For matching purposes, Trados processes URIs as if they were no different than any other text segment. By doing so, it considers two identical URIs (say, for example "http://aboutranslation.blogspot.com") as 100% matches (which is OK), but it also consider two different URLs (for example, "http://flickr.com" and "http://facebook.com") as fuzzy matches.

This is wrong and dangerous.

If the two URLs are as different as Flickr.com and Facebook.com, the problem may seem trivial: a glance suffices to see that they are different, and to copy over the correct URL.


But other addresses looks much more similar, and we can easily accept the wrong link while translating quickly:

Trados, in fact, consider these two links as 97% similar.

But there is no such a think as a "similar" link: it either gets you to the correct page or file, or not, and the way Trados matches them adds to the risk of inserting a wrong link in our translations.

Changing the internal logic to treat URLs differently would be trivial, but the Trados programmers (or, more likely, their managers), cannot be bothered to spend the necessary time for a simple improvement that would ensure higher quality.

Yet again: Trados fuzzy match woes (Expanded)

Continuing from my post of August 25, some further evidence of just how badly designed the fuzzy matching algorithms are in Trados:

So, according to Trados, "INSTALLING DISPLAY" is a 67% match for "Installing Display", while "Ownership of the Services and Marks." is a 65% match for "Description of the Service and Definitions."


A smarter matching algorithm would give more importance to meaningful words ("Description", "Service", "Definitions") than to grammatical ones ("of" "the" "and"), and would treat a difference between upper and lower case as much less significant than the chance similarity of two sentence structures.

By the way if "Installing Display" is changed to "Installing the Display", it does not come up as a fuzzy match at all (unless the fuzzy threshold is set extremely low), since it becomes a mere 40% match:


The worse thing is that all these problems have been known for years, but Trados (and now SDL/Trados) programmers have done nothing to improve the situation.

Trados: which bugs have been fixed?

I've just received a rather pushy call from an SDL/Trados representative. He wanted to know if I was considering upgrading from Trados 2007 to the newest version. When told that I was actually consider whether to change to a competitor's product, he asked why.

The reason I gave him was defects in the program, and old bugs never fixed.

I wonder however, if any of the more persistent bugs have been fixed with the latest releases - as far as I know, they haven't, but I would be happy to learn otherwise.

In particular, I'm thinking of such longstanding defects as the poor quality of low-fuzzy matches (see the previous post), the fact that formats are often mangled in MS Word documents, the irregular behavior of Workbench when translating MS Word tables with multiple columns (when Set Close/Next Open Get skips entire rows), the absence of shortcuts to open directly the previous segment, or the feebleness of the search functions within Tag Editor.

As far as I know, all development efforts were focused on supporting Vista/Office 2007, on corporate features, and on fixing some really disastrous new bugs (if any were introduced or discovered recently).

No real improvements to longstanding bugs, defects and annoyances as mentioned above. Does anybody know if this is still true, or which defects (if any) have been fixed after, say, version 7.1 and which improvements have been implemented?

How to win back discontented Trados users

Today I received a phone call from an SDL representative: he had seen that I had accessed the SDL site (to download an updated copy of WorldServer Desktop Workbench), and tried to sell me some new service or product.

Unfortunately for my caller, I had just loaded a new termbase in MultiTerm, so some of the glaring shortcomings of SDL technologies were fresh in my mind. The phone call, far from a successful sales pitch, soon became a diatribe against some of Trados' long-standing problems.

I then received a follow-up e-mail:

"...[I] am sorry you feel discontent with our products. I would like to win back your commitment to our technology, just let me know in what direction we can possibly do that."

My answer summarized some of the more pressing (and annoying) problems with Trados and MultiTerm:

1. MS Word interface: fix the formatting problems - it is unacceptable that Trados consistently messes up the formatting of even simple MS Word documents. Other TM products that also use MS Word as an interface (for example, Wordfast) experience far fewer formatting problems with MS Word (or none at all).
   Please note:
   
• advising translators to use TagEditor instead is a cop out, and, at best, only a partial solution,
  
• saying that the MS Word document should be formatted some other way, that styles should be applied in some other more controlled manner, or similar advice is useless for translators: we translate the document we get, not the document we wish we would get.


2. Concordance search: a translator should be able to search not only on the source language, but also on the target.
   
3. TagEditor: recommending the use of TagEditor for the translation of MS Word documents would be more acceptable if TagEditor were a richer text editor. For starters, it should offer more powerful search functions (at least the equivalent of MS Word wildcard searches; better still, full regular expressions).
   
4. MultiTerm: a more user-friendly and less counterintuitive interface and process would help.
   
5. Artificial limitations to the freelance edition of Trados. Two translators who acquire two different freelance licenses should be able to run them on the same home network, without the need to purchase a more expensive version of the program.

What are the things that bug you most as regard Trados, MultiTerm and the other SDL products? What would you add to my list (or remove from it)?

Trados 6.5 and SDLX 2004 (or older) no longer eligible for upgrade after April 1st, 2008

With a remarkably misleading title ("Our upgrading guidelines are changing"), SDL announces that, from April 1st, 2008, Trados v6.5 (or older) and SDLX 2004 (or older) will no longer be eligible for upgrade price, and that people wishing to upgrade their old software after that date will have to buy a new (i.e., full price) license.

The first page of the announcement only indicates that

our upgrade guidelines will be changing from Tuesday 1st April, 2008

Only if you click on "Visit our Frequently Asked Questions section", you'll find that

If you are on versions Trados v6.5 or previous or SDLX 2004 and previous, we recommend you upgrade to SDL Trados 2007 now in order to retain discounted upgrade pricing for the software. From the 1st of April 2008 onwards, there will no longer be upgrade eligibility from these versions.

Stopping eligibility entirely is, indeed, a change, but the way it is presented is misleading and borders on the outright dishonest.

So, many translators who were working happily with Trados 6.5, and had no intention to upgrade right now (but thought they might upgrade later, when they purchased a new computer with Windows Vista and Word 2007), will either have to upgrade immediately, or be compelled to pay full price later.

Of course, they might also decide to stay with the current version, and look for a competitive upgrade to some other tool later.

Way to go, SDL: instead of improving your buggy software to build up customer loyalty, compel the customer to upgrade RIGHT NOW, or lose that benefit forever.

When are two names 67% the same?

Would you prefer:

• To have "afxc04z5.htm" suggested as a translation when the html file in the string you are translating is actually "afxc04z5_10.htm"?

Or

• Would you rather copy manually the file name from the source segment to the target one, avoiding the risk of accepting a wrong file name while typing rapidly?

I would always opt for the second option - it's just too easy accepting a fuzzy match "as is", when you are typing fast, and this type of error is serious (it would break a web site), and remarkably difficult to spot (file names looks similar, and re-reading the translation there is no logical clue to indicate that something is amiss).

The brillant programming team that gave us useless fuzzy matches like this or this one, once again chooses the wrong answer:

Voting on Trados features

In my previous post I complained about Trados fuzzy matching algorithms.

Among the comments I received there is one from an SDL marketing representative, who sais to enter suggestions and ideas in a portal they created to gather the votes of other users. The address of this portal is http://ideas.sdltrados.com.

If true, that is, if SDL is actually going to act on their user's opinions, this would be a step in the right direction: too many of the features added in recent years were not aimed at helping translators but rather only translation users or companies.

It is time that SDL remembered that Trados was supposed to be a tool for translators.

Shouldn't Trados programmers improve their matching algorithms?

I sometime wonder what the programmers at SDL/Trados think that "similar" means, but I'm sure that what they think must be different from what most translators think.

Take for example the strings

1. "- LEAD DESIGN -",
2. "- LEAD PROGRAMMER -", and
3. "Lead Design".

Most translators, when asked to translate "- LEAD DESIGN -", would find the translation of "Lead Design" more useful than knowing the translation of "- LEAD PROGRAMMER -".

Seemingly, Trados programmers disagree: as you can see from this screenshot,
Trados considers "- LEAD PROGRAMMER -" a 75% fuzzy match for "- LEAD DESIGN -", while "Lead Design" only gets a 67% score.

How the program arrives at this result is clear: both strings 1 and 2 follow similar patterns (all caps, leading a trailing dashes), while 3 doesn't.

But writing a more intelligent algorithm shouldn't be all that difficult: a better algorithm would give more weight to the actual words, and not to such irrelevant characteristics as case or dashes.

Trados programmers should, in short, try to think of what is useful to translators, and implement that in new algorithms, rather than rely on old ones that have probably not changed in over ten years.

European Commission Translation Memories Available for Download

The European Directorate General for Translation (DGT) has made publicly accessible its multilingual Translation Memory for the Acquis Communautaire.

The Acquis communautaire is a collection of texts and their translation in 22 languages. It comprises the entire European legislation, including all the treaties, regulations and directives adopted by the European Union (EU) and the rulings of the European Court of Justice.

The memories can be downloaded from The DGT Multilingual Translation Memory
of the Acquis Communautaire: DGT-TM, which also contains an explanation of what the materials available are and how they can be used.

I found the announcement on the Global Watchtower, the bulletin of Common Sense Advisory. The original announcement also includes valuable insight about how translation companies (and I think also translation professionals), will be able to take advantage of this multilingual corpus.

SDL/Trados Support Looking Up?

"If you have any comments, please email my manager..."

The back cover of the current ATA Chronicle is a big ad from SDL/Trados, with a letter from Keith Laska, Vice President, SDL TRADOS Technologies, announcing new customer service initiatives:

"This year you'll be able to escalate issues directly to my management team, and to me [...] Why not start now? If you have any comments on our level of customer service, please email me [...]"

I have been unhappy with the quality of Trados, and also with the quality of the support, so I thought I might give it a try, and see if this was just a publicity stunt, or if they actually meant it.

So, on Friday I emailed Keith, with a list of complaints. I was not expecting much, but this morning I received a call from Keith, who wanted to get more details on the issues I had. He also said that I would receive a call from a local "Customer Success Manager", and in fact this morning I was also received a long call from David Noiseux, who asked more questions about the details of the issues I have had with Trados.

It is early to tell if things are really improving, but at least they seem to be moving in the right direction.

Proof positive that Trados programmers should change job

I like to keep the matching settings of Trados fairly low: sometimes that way I get some useful suggestions (especially for long sentences where only part of the sentence matches), but often what I get is something like this:


That's right: "Do not submerge in water" is supposed to be a 53% match for "Unplug when not in use".

Trados' matching algorithms have long been known to be among the poorest of all translation memory tools, but this takes the cake!

Poor technical support from SDL

This morning I received an answer to my support request concerning the "skipped segments in tables" bug (see Serious bug in Trados):

[...]The only workaround I can see is to use the option to Set Close after translation and place your cursor before the next segment in the table that needs translating and then use Open/Get to open this segment for translation.

I hope this helps.[...]

I consider this answer less than helpful, and said as much to the support person:

Your suggestion is totally unsatisfactory: having to manually open and close each single segment is part of the problem, not of the solution.

I use Trados in order to speed up translation. Having to manually open, then close each single segment is not conductive to that. Bear in mind that the real-world files in which I encounter this problem may have several hundred segments.

Please note:

1. Trados 5.5 did not have this bug.
2. This bug was introduced with version 6.5 (or possibly 6... I did not test it on that version), and is still present in version 7.1
3. We paid good money for a program that is full of bugs.
   

What are SDL plans in order to resolve this issue? Your company should put some programmer at work and issue a free patch as soon as this serious problem is solved.

In the meantime, a better suggestion than the one you gave me is to use Tag Editor to translate the word files with the tables in them.

I discovered this yesterday by trial and error - you may want to suggest it to other people suffering this problem, while your company (hopefully) fixes the problem. Unfortunately, using Tag Editor will work for users of Trados 7, but not for those of Trados 6.5, since version 6.5 of Tag Editor could not open MS Word files.

Does any of you know if other programs (e.g. Wordfast) suffer the same problem? Does anybody know of any workaround better than using Tag Editor to translate the MS Word files? If so, please let me know.

Update

New answer from SDL trados support: they agree that using Tag Editor is a better workaround, and say they are going to pass the issue on to the developers:

Please translate the file in TagEditor as a workaround and I will raise this as an issue with the developers. We recommend anyone to use TagEditor rather than MS Word as a translation enviroment as it enables them to use the verification tools on their file.

Serious bug in Trados

We recently switched to version 7.1 of Trados, and discovered a new, and serious, bug.

Some of our customers send us software to translate in MS Word files. These files are formatted as tables with four columns, where the first, second and fourth column are protected from translation (formatted as external tags), and the third column is translatable text.

When you try to translate the file, you can open the first segment, translate it, and then close it normally. However, if you try to close it by clicking "Translate to Fuzzy" or "Set/Close Next Open/Get", Trados will not open the next segment or the next untranslated segment (depending on the command you clicked), as you would expect: it opens a segment much further down the table, or altogether outside the table. However, you can still manually open the next segment, manually close it, and so on (thus wasting a huge amount of time).

This bug was not present in Trados 5.5 (I reinstalled 5.5 on a spare machine and tested on the same files where I encountered the problem).

I already reported this bug to SDL, but, so far, with no satisfactory result: the first time I reported it I was told that version 7.5 probably didn't have it (thanks, but I had just paid quite a lot of money for several licenses of 7.1, and was not going to pay more for a new license that just might fix the problem), and that I could copy the text to be translated from the MS Word file, paste it in another file, translate it there, copy it again, and paste it back in the original file (which is a time consuming slapdash workaround that probably wastes more time than manually opening each segment).

The one good workaround I found so far is to translate the MS Word file in Tag Editor: there seem to be no problem when using Tag Editor to translate the MS Word files with the tables in them.

It is worth noting that I had to find this solution by myself, and that nobody at SDL either suggested it or, if they thought of it, bothered to communicate it to me. I think that tells quite a lot about the (poor) quality of SDL customer assistance.

Update (bad news for users of version 6.5)

I tested the issue also under version 6.5 of Trados.

Unfortunately, while the issue is already present in version 6.5, my workaround is not feasible, as version 6.5 of Tag Editor was still unable to open MS Word files.

Update 2 (unhelpful suggestions from SDL support)

I received some (unhelpful) suggestions from SDL technical support: see Poor technical support from SDL.

MemoQ, a New Translation Tool, Launched

Kilgray has just launched MemoQ, a new translation memory tool. According to Kilgray's web site,

MemoQ is the first integrated translation environment, developed in Central Europe, which surpasses its competitors with its performance, savvy user interface and integration capability.

Among the features that look interesting is support for Trados .ttx files, as well as support for TMX 1.1 and 1.4 memories.

From the screen shots provided on Kilgray's web site, it looks more like DejaVu then either Trados or Wordfast. Of course, before forming a definite impression, it would be necessary to try the program on a real project.

One version of the program is free, others have prices that appear lower than comparable offerings from SDL/Trados.

(Hat tip to Christof)

TagEditor Sundry Annoyances

I don't mind working in Trados' TagEditor - at least it is much better than translating Power Point files in the dread T-Window application, but TagEditor sure has more than its fair share of annoying quirks:

1. Since this is basically a no-frill text editor, why does it attempt to display fonts in a half-assed WYSIWYG way? (especially since it does it in such a buggy way: text that changes sizes on screen for no understandable reason, or displays in bold and/or italic when it is neither). Admittedly, these display defects do not affect the translation, but why have them at all, since the preview function is just a click away (and works reasonably well)?
2. Why do source string, translated string, etc. all are displayed in the same color, instead of using the colors one sets in Workbench?
   
3. Trying to use the MS Word spell-checker still doesn't always work, and
4. If you use the supplied spell checker, the Check Spelling window comes up, by default, with the focus on the "Not in dictionary" field, instead of the "Change to" field, as would be logical.
   
5. Why such a puny internal search function: you can only specify a search string, a replacement string, whether to match whole words only or not, whether to match case or not, and (for the search function only) whether to search up or down: no regular expressions, not even the scaled down version one can find in MS Word's wildcard searches... and this when such functionality is easily available in text editors that sell for just a few bucks (such as Text Pad).

Global Content Management

EContent published a few days ago an interesting article on Global Content Management. Among the highlights of the articles are sound suggestions such as

First and foremost, you must learn to write for translation, which means to write simply, clearly and, above all, to write for reuse.

There are also links to useful sites; for instance after suggesting the above, it links to the home page for Simplified Technical English, where one should be able to find help and guidelines for clear writing.

The article continues with more useful information on translation software (both TM and MT), XML, and other related products.

Although the article is clearly not aimed at translators, but at the users of translation, localization, and allied services, it should also be of interest to most translators.

One reason I believe the sooner Trados disappears, the better...

...is the very poor quality of their matching engine. For example, I'm currently translating a list of software strings for a telephony system.

For the following string:

468:"Enable DUALmode"

I get a 62% fuzzy match, the original SL of which was:

451:"New building"

Very useful: the number "4", the colon and both quotes are, indeed, identical.

Even better:

For the string:

519:"Value"

I get a 74% fuzzy match, the original SL of which was:

142:"Permanent"

Hopefully, SDLX will be a change for the better.

TRADOS grows in Language Service Providers market

from marketWIRE

"TRADOS attributes the industry-leading growth to its continuing focus and investment in this important market."

"Viable" Alternative to Translation Memory Products

from i-Newswire.com

"this is so clients need not hire staff to maintain text databases and also to be sure that reused text is not out-of-date or lack unification. The aim was to eliminate the TM department and let DTP operators handle text reuse."

I don't know anything about the details of this new technology, but I rather doubt that DTP operators will be able to handle meaningfully text in languages different than their own.