Mobile menu

CAT tools not as effective after all?
Thread poster: Ivan Eikås Skjøstad

Ivan Eikås Skjøstad  Identity Verified
Norway
Local time: 08:58
Member (2002)
English to Norwegian
+ ...
Sep 11, 2007

I just read an article of a company working with Trados and SDLX: "After a year of experience, the translation process is about as efficient as it was before adopting a new suite of tools"...

http://www.inter-locale.com/whitepaper/multilingual/MultilingualPaper.htm

written by Addison P Phillips, Director, Globalization Architecture, webMethods, Inc.

It's very interesting to read, and finally understand that it's nothing wrong with the user of these CAT-tools (including myself)...


Direct link Reply with quote
 

Gerard de Noord  Identity Verified
France
Local time: 08:58
Member (2003)
German to Dutch
+ ...
Great read! Sep 11, 2007

You deserve the ProZ.com Link of the Year Reward.

Regards,
Gerard


Direct link Reply with quote
 
xxxPRen  Identity Verified
Local time: 02:58
French to English
+ ...
Agreed Sep 12, 2007

Gerard de Noord wrote:

You deserve the ProZ.com Link of the Year Reward.

Regards,
Gerard


A really interesting read, thanks for the link.


Direct link Reply with quote
 

Heinrich Pesch  Identity Verified
Finland
Local time: 09:58
Member (2003)
Finnish to German
+ ...
One citation Sep 12, 2007

"Support from SDL

Like all software, translation memory products have bugs. Unfortunately, obtaining support and fixes for bugs turned out to be more difficult that we felt it should have been. As software vendors ourselves, we expected our vendors to leap on bugs and provide fixes. We expected that future fixes would not be accompanied by regression on previous bugs and that we could get fixes quickly.

This isn't exactly our perception of the support we received. For example, fixes to one set of minor filter problems were delivered in a build of SDLX that broke attribute matching. Since our software translation relied on XML attributes for context, this forced our engineers to run two different versions of SDLX to process different file types: one with fixes that supported our on-line documentation and a different (unpatched) version for our software files and their critical attributes. Since there can’t be two copies of SDLX on the same machine, we needed at least twice the number of computers for basic file processing."

And all that effort for stuff that nobody reads in the end. At least I have never found any help in those "Help"-files of software programs.



[Bearbeitet am 2007-09-12 07:18]


Direct link Reply with quote
 

Riccardo Schiaffino  Identity Verified
United States
Local time: 00:58
Member (2003)
English to Italian
+ ...
Interesting article Sep 12, 2007

Very interesting also the fact that it indicts (probably unwittingly) not only the defects of the two translation memory tools that the author's company used and the shortcomings of the companies that created them, but also the defects in the methodologies employed both in localization and in development by the author's own company.

I worked for many years in the translation department of a large business software company, and I'm sure that we faced many or most of the same challenges (including real simshipping), yet there is little hint of the kind of solutions we developed or employed to translate our software and documentation.

After the first release in which we employed TM tools, we consistently saw them saving us around 85% of the work when translating documentation - which we also used to produce the help systems.

The translation of the software itself was a more complex affair, for which we developed our own tools, as we did for the management of terminology.


Direct link Reply with quote
 

Piotr Bienkowski  Identity Verified
Poland
Local time: 08:58
Member (2005)
English to Polish
+ ...
This is the experience Sep 12, 2007

of a software vendor, not a freelancer.

Most of us never or hardly ever get files for translation in formats other than DOC. I get some XLIFFs but I deal with them with a different CAT tool than Trados/SDLX.

But even so these tools should deliver on the promise of handling the more "unusual" formats as well.

I used to be an enthusiast of SDLX but my enthusiasm was somewhat moderated after some failures of SDLX to export a big file back to DOC.

I think it is wrong for SDLX (and Trados too) to rely on the RTF format for its conversions. Each version of Word handles the RTF format a bit differently and in the worst case it can break the conversion process, which happened to me.

So far, my copy of SDL Trados 2007 freelance wasn't successful with importing a file in the new MS Office XML format.

Heartsome XLIFF Editor can import this format, although segmentation is a bit worse than I expected.

My PLN 0.03

Piotr


Direct link Reply with quote
 

GingerR  Identity Verified
Local time: 08:58
Member (2004)
English to Polish
+ ...
Tough job, anyway... Sep 12, 2007

While I am not a SDL/Trados fan, I suppose that the story would be very similar with any commercially available CAT tool. That was the nature of the project itself - it did not lend itself very well to use of a CAT suite.

Most of the problems stem from the fact that the source files were not created with the use of CAT tools in mind - then it is understandable that the effects were poor. For example, it is easy to give an example of Java code which is very easy to translate with CATs and another one which practically cannot be processed this way.

That is what surprised me most in the article - that they prefer to create a multitude of pre- and postprocessing tools for their files instead of changing the whole paradigm of their project. Of course, the latter would be an enormous task, but only then they might count on returns from their investment in CATs.


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 08:58
Member (2006)
English to Afrikaans
+ ...
A comment Sep 12, 2007

Joanna Nowak wrote:
Most of the problems stem from the fact that the source files were not created with the use of CAT tools in mind...


Documents are hardly ever designed with CAT tools in mind. It should be the other way round, don't you agree? CAT tools should be designed with documents in mind. Documents are designed for an end-purpose, and getting them translated is not the end-purpose.


Direct link Reply with quote
 

Jerzy Czopik  Identity Verified
Germany
Local time: 08:58
Member (2003)
Polish to German
+ ...
I beg to disagree here Sep 12, 2007

Samuel Murray wrote:

Joanna Nowak wrote:
Most of the problems stem from the fact that the source files were not created with the use of CAT tools in mind...


Documents are hardly ever designed with CAT tools in mind. It should be the other way round, don't you agree? CAT tools should be designed with documents in mind. Documents are designed for an end-purpose, and getting them translated is not the end-purpose.

When you're bringing a new CD player on the market or a car, you (have to) write a manual for that product. And you (have to) know, that this product will be sold on different markets with different languages. So you (have to) know, that the manual has to be translated. Translation is not per se the end purpose of the document, of course. But the end purpose is to be available to the target group. This is possible only if written in target group language. You will hardly hire authors of various target languages to write your handbooks, so you will have them translated. Would the authors bear this simple fact in mind (that their work needs to be translated afterwards), the work of a translator would be much easier. And that would be the first step into the direction of CAT conform documents.

Jerzy


Direct link Reply with quote
 

Riccardo Schiaffino  Identity Verified
United States
Local time: 00:58
Member (2003)
English to Italian
+ ...
Designing for localization Sep 12, 2007

Samuel Murray wrote:

Documents are hardly ever designed with CAT tools in mind. It should be the other way round, don't you agree? CAT tools should be designed with documents in mind. Documents are designed for an end-purpose, and getting them translated is not the end-purpose.


True, but only up to a point: CAT tools should be designed so as to accomodate as wide a variety as possible of source files, and to do that in a robust and reliable way.

But the projects described in the article were primarily localization projects, and software (or even documentation and help files) not well designed in order to take into account the fact that it will have to be localized and translated, often may become impossible to localize well.

For example, if the programmers, unconcerned with the fact that their software is going to be localized, make abundant use of concatenated strings, the result may be impossible to translate with any quality. A simplified example:

"This is his %s; the % is an animal"

If the variable %s will be replaced by the name of an animal (%s = lion, tiger, eagle, whale, elephant, etc.)

In English this works well:

"This is his lion, the lion is an animal"
"This is his tiger, the tiger is an animal"

And the programers will congratulate themselves for saving space and work.

But if they do that, the string will be impossible to translate well in languages with grammatical gender, or more than a single form for the article, for example, in Italian:

"Questo è il suo leone, il leone è un animale"
but
"Questa è la sua tigre, la tigre è un animale"

So software, documentation, help systems, etc. should be designed with localization in mind - and for me that means not only planning to avoid problems such as the one above, but also knowing the localization tools one is going to use, and plan accordingly.


Direct link Reply with quote
 

Jabberwock  Identity Verified
Poland
Local time: 08:58
Member (2004)
English to Polish
Sorry! Sep 13, 2007

I am very sorry, the post titled "Tough job, anyway" should appear under my name, not that of Joanna... Have not checked who is logged, too many Prozians in the house

I agree with Riccardo that not preparing for localization beforehand makes it very difficult, if not impossible. On the other hand, if the preparation is done well, it does not really matter what tools you use. To use one of the more trivial examples, it makes a whole world of difference whether the text strings are placed directly in the source files (which makes them difficult to extract and hard to put back without damaging the code) or they are separated into a specific resource file, where they can be translated even with a simple text editor.

Expecting that the CAT tools will take care of everything is, at least, unrealistic. There is always more to be done, whether at the software design stage, or later. After all, localization is not just translation, is it?


Direct link Reply with quote
 


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

CAT tools not as effective after all?

Advanced search


Translation news





SDL Trados Studio 2017 Freelance
The leading translation software used by over 250,000 translators.

SDL Trados Studio 2017 helps translators increase translation productivity whilst ensuring quality. Combining translation memory, terminology management and machine translation in one simple and easy-to-use environment.

More info »
Déjà Vu X3
Try it, Love it

Find out why Déjà Vu is today the most flexible, customizable and user-friendly tool on the market. See the brand new features in action: *Completely redesigned user interface *Live Preview *Inline spell checking *Inline

More info »



All of ProZ.com
  • All of ProZ.com
  • Term search
  • Jobs