It’s one of the things I have to deal with on a regular basis in working with my in-house translators: how to improve on people’s bad translation choices. The word “bad” here is not meant as an absolute: it simply refers to a term that we as a group prefer not to use and that we invariably correct if we come across it. In most cases it’s just a turn of phrase that is not as universally common as one would like to think, or a typographic convention that has not been thoroughly understood and absorbed. Yet very often not even a clear explanation is enough to eradicate these choices, including when a request to create a personal checklist with one’s own special little flaws is made.
I guess we all fall into the rut of using the same phrases, adjectives, adverbs and idiomatic expressions we have become accustomed to. To be honest, many of these are like a buoy in the ocean, useful little helpers that can come to our aid when nothing better or more appropriate comes to mind.
But if we are not conscious of this, if we don’t pay enough attention to the fact that habits in translation can turn your words to putty, then it is also possible that making a change would not really work and that we would be unable to appreciate the better (or sometimes just different) choice that is imposed upon us.
In Italian, for instance, words like the verb “consentire” have become staples of our linguistic production because they are neutral and flexible. So much so, in fact, that when someone start using other, less orthodox terms, we are immediately alerted to the change and run for cover.
In an ideal world we would have created a common, flexible, accurate set of language choices that we all share and that make our work (mine, like that of my translators) similar in that it stems from the same set of choices.
But these are the things that take planning and time, and very often we refrain from engaging in these types of undertakings because we “just don’t have the time”. And all the time we know that it would only save time to do it!
It’s nothing new to note that delivery times have been increasingly shrinking over the past 10 years. Everyone who’s in the business knows this is how things are now, and that’s that.
But what are the actual reasons for the ever closer due dates?
Is it always the fault of the unreasonable end client who will not take no for an answer? Is it the fault of the large LSP between yourselves (well, at least ourselves) and the end client? And why is it their responsibility? Have they lost their bargaining power entirely and simply nod and agree to any conditions? Or is it because they find it hard to organize a workflow which involves translator, reviewer, DTP editor, and translator again? Or is it perhaps because they are under the desktop publishers’ thumb and have no choice but to sacrifice the translator’s time?
I ask myself these questions daily, as I incessantly negotiate for extra time with my clients, but the answer can only be a guesswork.
My first explanation is that the economy is pushing and prodding end clients to issue their material earlier than reasonably possible. It is plausible. The economy has changed, recently for the worse, but even before that, communications have become so fast that a company simply has to keep up, or else.
My second explanation is that large LSPs are backing up and are no longer in a position to negotiate with a firm hand. I don’t think this was brought on by the recent economic crisis. I believe in fact it started earlier, with the gradual merge and consolidation of the major global language service providers. As a result, the smaller LSPs who are still in business are no longer prepared to require certain (and previously perfectly reasonable) conditions for fear their clients will go somewhere else. How else can one explain the fact that negotiation of delivery dates is not as part of the larger LSPs’ routine as it is part of mine, as I often have to urge them to ask for extensions as if they hadn’t even thought about it.
My third explanation is again a platitude, and that is that speed has become far more important than quality, and everyone is happy to live with that. Speed makes languages grow more similar to one another through previously unconscionable loans and it makes details go from paramount to expendable. Speed is preventing translators (and reviewers at that) from exercising their mind and their knowledge of the source and target language; instead, it forces them to resort to words and expressions that have grown to form their source database for this or that client to achieve speed. And the tighter the deadline the more this source database is pillaged and abused.
I have no particular qualms of conscience about the way things are going and I’m not a purist or perfectionist who still clings to a romantic view of translation. I do care about my mind, though, and I know that not exercising languages, even your own, equals to forgetting them. And this simply won’t do.
Clients have been very generous with me over the years. They’ve identified for me countless things that I should or should not do and most of all they’ve taught me the importance of acronyms and abbreviations in this business.
I’m joking of course. Yet to be honest with you I never cared much for acronyms used on a regular basis. Those who make use of them have always seemed to me to be a little pretentious and whenever I hear people making a large use of acronyms I always think that they don’t really give much importance to the effect that their choice of words will have on their audience.
But, be that as it may, one cannot deny that our job is fraught with acronyms that identify tasks and functions. We have PM for Project Manager, to start with the most obvious one. Then we have TEP for Translation, Editing and Proofing, possibly the most common set of tasks for a translator. We have LSO, which stands for Language Sign-Off, and which is a kind of proofing whereby the translator reviews and then endorses the linguistic quality of a translated text. Among the most recent ones we’ve learnt are PLP, which also refers to a kind of proofing, but unfortunately we’ve not worked out the exact meaning (or it was simply forgotten) and now we simply perform PLP without asking too many questions. The very latest one is TAT, which stands very aptly for Turn Around Time, a very nice and very important latest addition to our list of localization acronyms.
There are others of course, many others, though sometimes and for some of them I find it hard to make out whether they have been made up and spread by a single client or whether they are indeed widely used in the business.
Yet at the end of the day, this massive use of acronyms does nothing to advance clarity of purpose while it does, in fact, make you feel that it is sometimes more important to know what a few initials stand for than to perform a task that somebody else is asking you to perform.
[Tue, Jan 12th 2010]
PLP = Post-Layout Proof
For a few weeks now I have been putting off dealing with a PO I received because I just know I won’t be able to match it to a set of projects for the same client I have in my database. How typical! So typical in fact I’m almost ashamed of having been had for the umpteenth time! And yet it happens, more often than we’d like to think.
Sometimes clients put off sending POs to translators/LSPs because they simply have other, more pressing things to do. And if you’re not 100% on it, you end up delivering the job without a PO to show for it. Sometimes, even when you kindly ask your client to send you the PO at his/her earliest convenience, they don’t do it promptly, then a few more days go by and — again — if you’re not on top of things, you may just end up forgetting yourself, because you have other, more pressing things to do. And when, weeks later, you go back to that item, you discover you have forgotten all the specifics about the job, the PO, your request for it etc. and you have to trace your steps and go back to the beginning. In the worst case scenario, you sometimes have to chase a PO for weeks, spending precious time doing something that should have been automated to begin with.
There was a time when Purchase Orders were sent out together with the job assignment they referred to. Mostly this is still the case, but in my experience, when there is no clear PO system at the clients’ end, or when there is no clear distinction between the PM and the person in charge of issuing POs, things can very easily get lost in the cracks. And when that happens, patience, accuracy and quiet obstinacy on your part are usually the only remedy.
Wouldn’t it be great if our clients could send us only the information we need when they submit a job to our attention — and no more than that? It would indeed, but then, come to think of it, how often does it happen? Not quite often enough, at least in my experience.
Sometimes I have to read a submission message over and over again trying to make out exactly what the client is requesting. Other times the client throws everything they’ve got into the submission without giving much thought to priorities and essentials. This happens a lot when they send you a TM or a glossary you already have and they omit to tell you if is has been updated, and you then need to use/import it, or if it is exactly the same as the one they sent you before, and you can therefore disregard it entirely.
The fact is, at least from my experience, that because the stress at the multi-language vendors’ end is on quick turnaround times and speed in general, the concept that “spending 30 minutes now helps you save 3 hours later” is just no longer a principle that carries any weight.
When we started working for large multi-language vendors, particularly from the US, standard practice had a PM “digest” the entire bulk of intormation, reference material, terminology, translation memories, etc. that would come with a job and then serve you the “filtered” version, i.e. ONLY those things that were truly needed to carry out the job at best. What would be the use of sending 3 XLS glossaries when you can create a single termbase out of them and send that to the translator/single-language vendor company? And why send a dozen PDF reference files when the time allotted for the job barely allows you to translate and review? The trouble is, devoting time to preparing, checking, converting, streamlining a job in a way that makes life easier for the translator/SLV is apparently no longer part of the Project Manager profile. Project Managers in a MLV company seem rather to be focused entirely on clients and clients’s needs, sometimes at the cost of requesting very unconventional and unsuitable things of the translator/SLV (but I will come to this issue in a separate post).
As a PM in a smaller single-language vendor company, when I have to assign jobs to my translators (whether in-house or freelance), I always try to put myself in their place and, with that in mind, to decide what needs to be conveyed to them and what doesn’t. I write specific job instructions, and our system allows us to retrieve end-client specific instructions that have been entered only once and can then be updated as needs be. I also try to mould my instructions so that they are logical and consequential, with every task in the right order of discharge. And naturally, the less organised is the material and the instructions I receive from our client, the more time I will have to spend trying to make sense of it so that my translator is spared the aggravation. I don’t always achieve what I set out to do, but at least this is the direction I’m heading towards and one that makes sense in more ways (and for more people) than one.
[Definitions from the Localization Industry Standards Association’s glossary]
multi-language vendor (MLV): A language service provider that provides translation or localization into more than one language, as well as (usually) project management and a variety of value-added services.
single-language vendor (SLV): A language service provider that provides translation or localization into one language. The smallest SLVs are freelance translators, while larger SLVs may employ many translators.
My name is Gabriella Ascari and my job in Albatros is to do with Project Management. Although I hold a degree in Interpreting and though I double as a translator within the company, I have always been a Project Manager, ever since the company started and since before I knew what it involved.
So, to make my 12-year experience in this field available to whomever is interested, today I’ll be starting a new section of this blog focused on Project Management as a way of life — so to speak.
Before I delve into one of the areas of PMing that are part of my everyday routine, however, I should perhaps describe our individual vantage point. Because while Albatros is by no means a large company, we do have to deal with some of the same issues that large multi-language vendors deal with on a daily basis (eg. assessing turnaround times, assigning jobs to internal and external resources, receiving and sending queries, etc.).
On the other hand, though Albatros is not necessarily small by some standards, we do have quite a few things in common with freelancers and with their relationship with clients (eg. obtaining the material we need to carry out a translation job, negotiating deadlines, making sense of translation kits that baffle any attempt to make head or tail of them, etc.).
So in this light, and with no intention of naming names or making my blog entries too heavy or irking, I’m planning to share some of my daily mishaps and endeavours while Project Managing through this blog. Hopefully, it will be interesting. If not, I hope it will at least have been therapeutical.