ASET's Kevin Hendzel intervened in the ongoing chain of e-mails, stating that he didn't know about the contract, that it had been sent without his knowledge, and that it should be discarded, while ASET drafts something much more appropriate.
Some translators suggested that ASET should take into consideration the opinions expressed in the current exchange of opinions in drafting the new contract.
Also, several translators who know Kevin Hendzel wrote about his contributions to our profession and to ATA, so perhaps the current fracas could indeed be ascribed to internal miscommunications at ASET.
All the same, several aspects of the proposed contract were disturbing. We'll have to see what the new contract looks like.
In the meantime, I'm inclined to give ASET the benefit of the doubt.
Sunday, August 06, 2006
Saturday, August 05, 2006
ASET puts their foot in
ASET, a translation company who boasts of the quality of their work, seems to have just put their foot in: they sent to their existing suppliers a "new supplier package": W-9, W-8, and an 18-page contract.
For some reason, e-mails from translators who are answering to this rollout are forwarded to all other translators to whom the package was sent: so far I've received 16 of these e-mails, most very critical of the way ASET behaved (among other things, the e-mails complain of unreasonable demands and extended payment terms), with more than a few translators demanding to be removed from ASET's list of suppliers.
I've not had time to study the new contract myself, but this looks like a medium-sized PR fiasco for an otherwise fairly well-regarded translation company: they seem to have alienated at a stroke a number of good translators.
For some reason, e-mails from translators who are answering to this rollout are forwarded to all other translators to whom the package was sent: so far I've received 16 of these e-mails, most very critical of the way ASET behaved (among other things, the e-mails complain of unreasonable demands and extended payment terms), with more than a few translators demanding to be removed from ASET's list of suppliers.
I've not had time to study the new contract myself, but this looks like a medium-sized PR fiasco for an otherwise fairly well-regarded translation company: they seem to have alienated at a stroke a number of good translators.
Update
Probably more like a major fiasco: 48 messages and counting, not a single one of them positive, and many of them from excellent translators that no good agency could afford to lose.
Labels:
Business Practices,
Translation Companies
Tuesday, June 27, 2006
Workshop for translators on corpus research
Mediterranean Editors and Translators has organized a workshop on "Meaning & Usage From Context—“corpus” research-based translation & editing of specialist texts".
From the workshop's prospectus:
From the workshop's prospectus:
Generalist translators or editors can extend their range into specialist knowledge fields by basing their new texts on insights gleaned from “corpora” or text collections that can be set up quickly for systematic analysis. Even specialists can gain a deeper understanding of language variation from studying context in a well-constructed target-genre corpus.The workshop will take place in Canet de Mar (near Barcelona), on July 7th. For more information, write to: metmworkshops@gmail.com
Labels:
Translators' Education
Friday, June 23, 2006
Virtual Terminologist
Virtual-Terminologist is a website that offers customization and import services for Trados termbases.
Additionally, they make available for free download a few termbases (French-English language pair only, so far), and have an informative page on the Cardinal Virtues in Terminology Management.
Additionally, they make available for free download a few termbases (French-English language pair only, so far), and have an informative page on the Cardinal Virtues in Terminology Management.
Labels:
Glossaries,
Terminology
Friday, June 16, 2006
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):
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:
[...]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 consider this answer less than helpful, and said as much to the support person:
I hope this helps.[...]
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: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.
- Trados 5.5 did not have this bug.
- 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
- We paid good money for a program that is full of bugs.
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.
Thursday, June 15, 2006
The qualities of a good translator
"Hélas les traductions restent confiées le plus souvent à des êtres subalternes, dont la bonne volonté ne supplée pas l'insuffisance. Un bon traducteur doit bien savoir la langue de l'auteur qu'il traduit, mais mieux encore la sienne propre, et j'entends par là : non point seulement être capable de l'écrire correctement, mais en connaître les subtilités, les souplesses, les ressources cachées, ce qui ne peut guère être le fait que d'un écrivain professionnel. On ne s'improvise pas traducteur." (André Gide)Very true, but I think that a translator should first of all know the "subtilités, les souplesses, les ressources cachées" of his or her source language just as well as those of his or her native language.
(Hat tip: AS. Traductions)
Labels:
Translation Theory
How to drive away readers and prospects
I found an interesting post on another translation blog and wanted to comment on it. Unfortunately, in order to leave my comment I would have needed to allow Word Press to install cookies on my machine - which is something I normally don't do for security reasons.
So I went to the blog author's personal web site, to find a way to send him a message to politely request that he use a less restrictive commenting policy.
On this translator web site there was a nice "Contact Us" link. Almost done, I thought, and I clicked on it.
I was redirected to a "page not found" page.
No big deal in my case: I was just trying to leave a comment on the blog. But there are few surer ways to lose a prospect than preventing him or her from communicating with us.
So I went to the blog author's personal web site, to find a way to send him a message to politely request that he use a less restrictive commenting policy.
On this translator web site there was a nice "Contact Us" link. Almost done, I thought, and I clicked on it.
I was redirected to a "page not found" page.
No big deal in my case: I was just trying to leave a comment on the blog. But there are few surer ways to lose a prospect than preventing him or her from communicating with us.
Labels:
Business Practices,
Web
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.
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.
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.
Things to pay attention to when localizing a web site
(From BtoBOnline.com)
According to this article, "localizing your Web site for international users requires more than hurdling a few language barriers".
The article describes many things to be considered and difficulties to be overcome for those who plan to have an international version of their web site.
While it concentrates on issues other than translation, I think this could be very useful to translators who are asked to quote for the localization of a web site: it gives us other factors to mention to our prospect, from planning for non-broadband connections to getting a local URL for the international site.
According to this article, "localizing your Web site for international users requires more than hurdling a few language barriers".
The article describes many things to be considered and difficulties to be overcome for those who plan to have an international version of their web site.
While it concentrates on issues other than translation, I think this could be very useful to translators who are asked to quote for the localization of a web site: it gives us other factors to mention to our prospect, from planning for non-broadband connections to getting a local URL for the international site.
Labels:
Localization,
Web
Wednesday, June 14, 2006
Found in Translation
(From marketWIRE)
The San Francisco Center for the Book presents "Found in Translation," an interactive exhibition in the Center's gallery through July 21, 2006.
The San Francisco Center for the Book presents "Found in Translation," an interactive exhibition in the Center's gallery through July 21, 2006.
The exhibition presents a far-reaching look into both the process and implications of translation: each exhibit turns an idea on its head by viewing it from two or more sides (languages, cultures, genders, points of view)[...].
Using text from many languages and in a variety of media, the exhibit also provides a hands-on interaction with the artwork.
Labels:
Other
Subscribe to:
Posts (Atom)