When I was a kid I used to hike the hills above the San Gabriel Valley in Southern California collecting rattlesnakes. These usually ended up as food for my king snake or as tasty barbecued snacks and soups. Even as an eight-year old, I was responsible for killing and cleaning my own snakes, and one of the things that fascinated me about those rattlesnakes is how they kept on twitching even after the heads were cut off. Watching a snake dance across a barbecue grill is a strange sight.
Just as strange to me is how some businesses continue to twitch even after they are killed legally. Take Language Promotion GmbH in Zurich, for example. I've reported a number of times in this blog what the modus operandi of that company's owner, Dominic de Neuville is, and a quick look at any of the payments practices lists for translators online soon makes it clear that there are a lot of people out there waiting for a lot of money. In vain it would appear, since Language Promotion GmbH was declared insolvent. This occurred some months ago. But here's the strange part: when I look this evening at the ex-company's web site at http://www.language-promotion.com/CHCOM/index2.php?content=content_ueber_uns, for example, I see that the pages are alive and well, advertising services for a company that no longer exists.
But stranger still: the means of contact still work! And the addresses and telephone numbers for all the forwarding services posing as business offices in Switzerland and Austria are the same as those for a shadowy business calling itself Transit: http://www.transitweb.ch/index2.php?content=content_kontakt. I am told by my contacts in Zurich that this business is not in the commercial register and under Swiss law should bear the name of its operator, once again Mr. Dominic de Neuville. Twitch, twitch.
What does all this mean and why is it important? I'm not sure. It does, however, raise some interesting questions about business succession and possible personal liability of the owner for matters having to do with the now-insolvent GmbH. If the web pages of the dead company Language Promotion GmbH continue to feed potential business to this "Transit", is the new business in some way liable for at least part of the debt for the defunct company? Do the translators left out in the cold with no compensation for their work have a chance of collecting after all?
I don't know the answer to that question, but I am told that when it was raised at a judicial proceeding in another matter last week that the judge, a former collections official, implied that this might be the case. It's a matter worth investigating for those who have a significant amount to collect, and if the Swiss laws allow, it might even be interesting to see some sort of collective action, perhaps by assignment of invoices to a factor or something similar.
Translation agencies that do not treat their freelance translators well (and I think it's fair to say that nonpayers fall in this category) typically have to rely on continual transfusions of talent as they suck the blood out of one service provider (i.e. freelancer) after another. But there are always naive persons willing to take the bait and accept a project for which they have little hope of payment. Read the ProZ forums: there you'll find plenty of threads started by newbies who don't even think to agree on a price before taking a project, doing the translation and delivering a job. How many of these will practice due diligence? Not many I suspect. So take heart, thieves: there will always be a good living to be made unless someone realizes that the hunting season for pigs is year-round in most countries. And as I noted with the example in my essay on juggling snakes, even with "payment in advance" there are possibilities to be bitten.
So translators, look out for your own interests. If you work with agencies, stick to the many thousands of honest ones out there and avoid the rot at the bottom of the barrel. And if despite all due diligence you still get caught out or you are just having a "stupid day" when you unwisely take a project from a nonpayer, remember that you retain the copyright until you are paid and this can be the lever you need to pry the cash loose.
Apr 29, 2010
Carry a big stick!
I haven't been entirely spared by fraudsters. Years ago when I first started translating, I was given an interesting historical text on German rearmament to translate, and the "agent" disappeared into the dust. Several other victims had taken projects from this person through ProZ postings, but although we shared information, none of us were able to do better than to trace the crime to a particular area of the UK. However, I try to make something good of whatever I'm left with in any situation, and the text I translated has been a useful part of my example portfolio over the years. Directly or indirectly it has helped me to land other interesting (paid) projects.
How was I able to do this? Very simple. I own the copyright to that translation! Under the contract law of most civilized jurisdictions, a translator will retain the copyright to any work for which he or she has not received the full contractual consideration.
This is useful to consider in cases where a client has not paid a translator. If my direct customer or my agency has not paid me, I retain the copyright to my work. If that work is published in print or on the Internet, this can have serious consequences for the individual or company publishing the information. I mentioned this to one worried translator who contacted me privately with her collection concerns after reading about the payment practices and other issues with a notorious Swiss fraudster (slither, slither); in her case the end customer was the EU, and the suggestion that she would report the nonpayment resulted in a quick transfer of funds despite insolvency proceedings against the company. Others have used similar tactics with success.
Do check your local laws in such matters, but in general copyright can be though of as a big stick that can crack some pretty hard nuts. And even where there is no payment issue, the formula no consideration = no contract can be useful in dealing with those pesky unpaid "test translations". These too may be fodder for the sample portfolio.
I am personally relaxed in dealing with intellectual property issues when it's a matter of my property. In the late 80s I gave a patentable process for a new medical device material to a friend to help him out; the process was worth millions, resulted in IOL implants in some millions of people around the world and made a number of people rich. And all I got was a lousy t-shirt. Well, a bit more actually, but I'm still working for a living and cleaning my own toilet without regrets. So I don't get too picky about TM copyright issues or worry about these things for the most part. Unless some fraudster is trying to take advantage of me. Then I grab that copyright with both hands, raise it high and...
BAM!!!
Interoperability intelligence
In eight days I'll be giving a presentation at the memoQfest 2010 on interoperability - using memoQ as a collaboration tool for translators and reviewers who use other tools or leveraging features in other tools to achieve things that would be possible with memoQ alone or using memoQ to do the same with other translation environment tools.
I've already written a few posts of this nature, particularly the one discussing Déjà Vu as a collaboration tool and another focusing on the classic Trados software. Sometime before or after the talk in Budapest I'll do the same for memoQ. And it would be possible to do this for SDLX, OmegaT, WordFast and a host of other tools. However, given the wide range of combinations possible and the variations in individual needs, I think it's more important to consider the general concept of tool interoperability and strategies for applying that concept in the most useful way.
Ill-considered interoperability - exchange of TM or translation file data, terminology, etc. - can be troublesome. Although I like to consider myself an expert in using various tools to produce results that satisfy the requirements for other tools, sometimes in the rush and pressure of a heavy workload I make a bad choice and produce data that does not give my client exactly what works best for re-use and reference or functions best in the client's review workflow. So I need to slow down in many cases and think about what is really needed. Intelligent interoperability is called for.
On one hand you must have a clear picture of what is needed. The deliverables for the client should be agreed and specified exactly. How many times have I read frustrated forum posts in ProZ and elsewhere from translators who have done a job, delivered the target language text and then been asked for the "uncleaned files"? "What is that?" they ask. On busy days it's hard to remember to ask all the right questions to be sure that the specifications are clear, so creating a checklist might be useful. And possibly also a written description of your standard workflows and default deliverables. Without some clear starting point you may not understand where a project is headed, and you can end up lost and confused very quickly.
Deliverables specifications are not enough. If, like me, your business strategy involves working with a wide range of formats and tools, it's important to understand the interfaces available, how to use them, and the strengths and weaknesses of each interface. Create "maps" for yourself that show how to get from the source format to your working environment and back with all the information needed by the client.
Let's take Microsoft Word files as an example. Simple, right? In your dreams. Or nightmares rather. Clients use MS Word in totally insane ways that drive translators and translation software crazy. Simple files can be handled by most any tool. But there can be complications:
Part of the process of creating these maps is to document the interfaces clearly. What formats can be imported and exported? memoQ, DVX and some other tools can import dozens of file formats and make the content available for translation in many different ways: as XLIFF, text in RTF tables, bilingual Trados-segmented DOC files and more. Any TEnT can handle at least one of these possibilities. But sometimes there are process vulnerabilities in the data exchange, and these must be understood and documented to avoid trouble with clients!
Unless you are dealing with naked text files, there really is no such thing as a "simple" format per se for translation. And sticking your head in the sand won't make the problem go away: clients will continue to embed all kinds of crap in those RTF and Word files. Ready or not, those files will come to you. What happens at that point is up to you.
Many translators and translation agencies are simply not up to the challenges involved here in the data engineering. This is not a criticism, just a fact. There is a real need I think for affordable, accessible consulting resources to help meet these challenges, but 20+ years of activity as a consultant in the corporate world have made me a bit cynical about the overall prospects for useful help in many cases. When I think of all the computer "consultants" waiting to screw up the configuration on hard drives around the world I cringe.
Tool vendors could help the situation somewhat by focusing on solutions, including integrated solutions that may involve components that come from other sources. This has long since happened in the IT world in general, with competitors cooperating to get a contract where none could satisfy the requirements alone. Will we see the day when Kilgray and SDL work together to create an integrated solution for a major client? I hope to see that or similar configurations focused on the real needs of the clients. Think solutions, not tools and common-sense, practical, useful interoperability is more likely.
I've already written a few posts of this nature, particularly the one discussing Déjà Vu as a collaboration tool and another focusing on the classic Trados software. Sometime before or after the talk in Budapest I'll do the same for memoQ. And it would be possible to do this for SDLX, OmegaT, WordFast and a host of other tools. However, given the wide range of combinations possible and the variations in individual needs, I think it's more important to consider the general concept of tool interoperability and strategies for applying that concept in the most useful way.
Ill-considered interoperability - exchange of TM or translation file data, terminology, etc. - can be troublesome. Although I like to consider myself an expert in using various tools to produce results that satisfy the requirements for other tools, sometimes in the rush and pressure of a heavy workload I make a bad choice and produce data that does not give my client exactly what works best for re-use and reference or functions best in the client's review workflow. So I need to slow down in many cases and think about what is really needed. Intelligent interoperability is called for.
On one hand you must have a clear picture of what is needed. The deliverables for the client should be agreed and specified exactly. How many times have I read frustrated forum posts in ProZ and elsewhere from translators who have done a job, delivered the target language text and then been asked for the "uncleaned files"? "What is that?" they ask. On busy days it's hard to remember to ask all the right questions to be sure that the specifications are clear, so creating a checklist might be useful. And possibly also a written description of your standard workflows and default deliverables. Without some clear starting point you may not understand where a project is headed, and you can end up lost and confused very quickly.
Deliverables specifications are not enough. If, like me, your business strategy involves working with a wide range of formats and tools, it's important to understand the interfaces available, how to use them, and the strengths and weaknesses of each interface. Create "maps" for yourself that show how to get from the source format to your working environment and back with all the information needed by the client.
Let's take Microsoft Word files as an example. Simple, right? In your dreams. Or nightmares rather. Clients use MS Word in totally insane ways that drive translators and translation software crazy. Simple files can be handled by most any tool. But there can be complications:
- The old Trados Workbench macro tools in MS Word freak out with cross references. This used to give me major headaches.
- Some versions of TagEditor can't cope with section breaks if they aren't followed by a carriage return.
- Déjà Vu has a bad tendency to choke on MS Word or RTF files with a lot of graphics. Or even a few graphics of certain types.
- memoQ has its issues with graphics-laden Word files too
Part of the process of creating these maps is to document the interfaces clearly. What formats can be imported and exported? memoQ, DVX and some other tools can import dozens of file formats and make the content available for translation in many different ways: as XLIFF, text in RTF tables, bilingual Trados-segmented DOC files and more. Any TEnT can handle at least one of these possibilities. But sometimes there are process vulnerabilities in the data exchange, and these must be understood and documented to avoid trouble with clients!
Unless you are dealing with naked text files, there really is no such thing as a "simple" format per se for translation. And sticking your head in the sand won't make the problem go away: clients will continue to embed all kinds of crap in those RTF and Word files. Ready or not, those files will come to you. What happens at that point is up to you.
Many translators and translation agencies are simply not up to the challenges involved here in the data engineering. This is not a criticism, just a fact. There is a real need I think for affordable, accessible consulting resources to help meet these challenges, but 20+ years of activity as a consultant in the corporate world have made me a bit cynical about the overall prospects for useful help in many cases. When I think of all the computer "consultants" waiting to screw up the configuration on hard drives around the world I cringe.
Tool vendors could help the situation somewhat by focusing on solutions, including integrated solutions that may involve components that come from other sources. This has long since happened in the IT world in general, with competitors cooperating to get a contract where none could satisfy the requirements alone. Will we see the day when Kilgray and SDL work together to create an integrated solution for a major client? I hope to see that or similar configurations focused on the real needs of the clients. Think solutions, not tools and common-sense, practical, useful interoperability is more likely.
Apr 26, 2010
memoQ projects now translatable and editable in an RTF editor!
It's been nearly four weeks since my last blog post here; since completing the requirements for my German hunting license at the end of March I have been very busy getting to know the 385 hectare area in which I'll be hunting (in part by doing a GPS survey of the area on foot and marking important places on maps using Google Earth and other orientation tools). Business and personal matters as well as preparations for the court battle in Zurich with the infamous non-payer of translation work Dominic de Neuville (formerly of the now insolvent Language Promotions GmbH, currently DBA "Transit") have been a real handful. And with all of that I had the preparations for the Spring Natural Abilities Test (Verbandsjugendprüfung) for two young hunting dogs, Ajax vom Bernsteinsee and Daniavizsla's Barack.
In the whole whirl of activity I had rather lost track of what was going on in Kilgray's world, though I knew I had to get my tail in gear and do some preparation for my talk on tool interoperability with memoQ at the upcoming memoQfest 2010 in Budapest. I remembered the promise of the company's director of development, Gábor Ugray, to complete a feature I've been pestering Kilgray about for nearly two years by the time of the conference, but I figured that it wouldn't happen since I hadn't heard about it for a while.
O ye of little faith. In my two years of contact with the company, Kilgray has seldom failed to meet a promised target, and when plans are changed, the users are informed well in advance and plausible, acceptable reasons for the changes are given along with the new plan. This is nearly unheard of in the translation industry. But once again, the boys in Budapest have been true to their word.
I returned from dog trials in Osnabrück near midnight yesterday, tired and sick from breathing the pollution produced by my chain-smoking friend on a 450 km return trip. (I thought about walking to spare my lungs, but the dogs wanted to get home faster.) This morning I downloaded my e-mail (a horror of hundreds of messages for a few days' absence) and discovered a fat gold nugget in all the electronic mud I had to pan: the public beta of memoQ version 4.2! It's available for download at http://kilgray.
This feature can be used in a number of ways that are important to translators, translation agencies and translation consumers. For many years I have used this feature in Déjà Vu to export commented segments to indicate terminology uncertainties, source text errors, points to consider and more. I also export entire translations for review, comment and correction by persons who do not use CAT/TEnT tools, i.e. a typical translator consumer in industry. The modified versions can be re-imported with a few menu selections and mouse clicks, saving me a massive amount of time updating projects and translation memories. This is the feature I have missed the most over the past year as a heavy user of Kilgray's memoQ environment, and I have been hoping that something similarly useful would be added to the toolkit there.
Although there are apparently a few quirks in the first beta version with this feature (such as an indication of more changes than I actually make to the RTF file), it seems to work quite well, and it exceeds my initial expectations for the export in most respects. The comments column was too narrow for my taste in the test export I made, but perhaps that's because there were no comments. I cheated and re-sized the columns the way I wanted them in the screenshot at the end of this post.
The new feature is accessed in the Translations view of the Project home tab in memoQ. The Export bilingual option offers the following possibilities:
Selecting Two-column RTF causes the Next button to appear:
Clicking the Next button shows the following:
As far as I can tell at this point there isn't a "commented segments only" feature yet, but I'll do my best to get the development team drunk next week and talk them into it. But I'll bet they're already ahead of me on that one. The exported RTF file (with the cheat of resizing the empty comments column) looks like this:
There seems to be a little code page issue with the German "ä" in the title, but hey, it's beta and that doesn't affect the functionality. This RTF file can be edited by someone in MS Word, WordPad, Open Office swriter or other tools and re-imported to the memoQ project. By "editing" I also mean translation. The target column can be exported empty and filled in by a translator using only word processing software. In this way, for example, memoQ can be used as a tool to facilitate the translation or editing/review of all the file formats it works with by persons who use only a word processor!
The re-import into memoQ worked well in my test. In one case I chopped out most of the RTF file and left only a few lines of interest - the ID column ensured that the modified segments were re-imported accurately to the right place, even when I changed the order of the lines and introduced gaps in the text sequence.
Modified segments can be identified and checked quickly using the usual memoQ selection features for edited text:
What I would like to see though is a mark-up view or some sort of change history like one has for the re-import in Déjà Vu. But this is still a great start and removes the last obstacle to full implementation of memoQ in all my translation processes.
In the whole whirl of activity I had rather lost track of what was going on in Kilgray's world, though I knew I had to get my tail in gear and do some preparation for my talk on tool interoperability with memoQ at the upcoming memoQfest 2010 in Budapest. I remembered the promise of the company's director of development, Gábor Ugray, to complete a feature I've been pestering Kilgray about for nearly two years by the time of the conference, but I figured that it wouldn't happen since I hadn't heard about it for a while.
O ye of little faith. In my two years of contact with the company, Kilgray has seldom failed to meet a promised target, and when plans are changed, the users are informed well in advance and plausible, acceptable reasons for the changes are given along with the new plan. This is nearly unheard of in the translation industry. But once again, the boys in Budapest have been true to their word.
I returned from dog trials in Osnabrück near midnight yesterday, tired and sick from breathing the pollution produced by my chain-smoking friend on a 450 km return trip. (I thought about walking to spare my lungs, but the dogs wanted to get home faster.) This morning I downloaded my e-mail (a horror of hundreds of messages for a few days' absence) and discovered a fat gold nugget in all the electronic mud I had to pan: the public beta of memoQ version 4.2! It's available for download at http://kilgray.
This feature can be used in a number of ways that are important to translators, translation agencies and translation consumers. For many years I have used this feature in Déjà Vu to export commented segments to indicate terminology uncertainties, source text errors, points to consider and more. I also export entire translations for review, comment and correction by persons who do not use CAT/TEnT tools, i.e. a typical translator consumer in industry. The modified versions can be re-imported with a few menu selections and mouse clicks, saving me a massive amount of time updating projects and translation memories. This is the feature I have missed the most over the past year as a heavy user of Kilgray's memoQ environment, and I have been hoping that something similarly useful would be added to the toolkit there.
Although there are apparently a few quirks in the first beta version with this feature (such as an indication of more changes than I actually make to the RTF file), it seems to work quite well, and it exceeds my initial expectations for the export in most respects. The comments column was too narrow for my taste in the test export I made, but perhaps that's because there were no comments. I cheated and re-sized the columns the way I wanted them in the screenshot at the end of this post.
The new feature is accessed in the Translations view of the Project home tab in memoQ. The Export bilingual option offers the following possibilities:
Selecting Two-column RTF causes the Next button to appear:
Clicking the Next button shows the following:
As far as I can tell at this point there isn't a "commented segments only" feature yet, but I'll do my best to get the development team drunk next week and talk them into it. But I'll bet they're already ahead of me on that one. The exported RTF file (with the cheat of resizing the empty comments column) looks like this:
There seems to be a little code page issue with the German "ä" in the title, but hey, it's beta and that doesn't affect the functionality. This RTF file can be edited by someone in MS Word, WordPad, Open Office swriter or other tools and re-imported to the memoQ project. By "editing" I also mean translation. The target column can be exported empty and filled in by a translator using only word processing software. In this way, for example, memoQ can be used as a tool to facilitate the translation or editing/review of all the file formats it works with by persons who use only a word processor!
The re-import into memoQ worked well in my test. In one case I chopped out most of the RTF file and left only a few lines of interest - the ID column ensured that the modified segments were re-imported accurately to the right place, even when I changed the order of the lines and introduced gaps in the text sequence.
Modified segments can be identified and checked quickly using the usual memoQ selection features for edited text:
What I would like to see though is a mark-up view or some sort of change history like one has for the re-import in Déjà Vu. But this is still a great start and removes the last obstacle to full implementation of memoQ in all my translation processes.