CAT tools not as effective after all? Thread poster: Ivan Eikås Skjøstad
|
|---|
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, webMe... See more 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)... ▲ Collapse
| | | | Gerard de Noord 
France
Local time: 01:04
Member (2003)
English to Dutch
+ ...
You deserve the ProZ.com Link of the Year Reward.
Regards,
Gerard
| | | | PRen (X)
Local time: 19:04
French to English
+ ...
Gerard de Noord wrote:
You deserve the ProZ.com Link of the Year Reward.
Regards,
Gerard
A really interesting read, thanks for the link.
| | | | Heinrich Pesch
Finland
Local time: 02:04
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 e... See more "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] ▲ Collapse
| | |
|
|
|
| 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 challeng... See more 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. ▲ Collapse
| | | | | 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.
... See more 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 ▲ Collapse
| | | | GingerR
Local time: 01:04
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 CAT... See more 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. ▲ Collapse
| | | | Samuel Murray
Netherlands
Local time: 01:04
Member (2006)
English to Afrikaans
+ ...
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.
| | |
|
|
|
Jerzy Czopik
Germany
Local time: 01:04
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
| | | | | 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.
| | | | Jaroslaw Michalak
Poland
Local time: 01:04
Member (2004)
English to Polish
SITE LOCALIZER
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... See more 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? ▲ Collapse
| | | | 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? | CafeTran Espresso | You've never met a CAT tool this clever!
Translate faster & easier, using a sophisticated CAT tool built by a translator / developer.
Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools.
Download and start using CafeTran Espresso -- for free
Buy now! » |
| | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news
