We have created a tool to help you out.
Also Microsoft has created a tool in order to help their translators. It’s called Locstudio, it has been developed and honed at great expense since 1993… and it’s probably the most hated program from the company.Also SDL creates translation tools, it’s their main market and they have been dominating it with Trados since 1994… and translators hate its guts.Even with a full time, specialized team, building a translation environment is very hard, as you need a lot of power and flexibility (after all, it is meant to second-guess human writing!) while being as easy to use as a normal word processor.
Needless to say, developers usually don’t have much time to dedicate to these tools, and therefore they are usually clunky, confusing and limitedIn my experience, this leads to two situations. If the tool is complex, people begrudgingly embrace it and end up limited in some way. Maybe the tool doesn’t allow to quickly compare strings, and inconsistencies pop up, or it doesn’t support spell checking and it becomes typo country.If the tool is simple, it simply gets “reverse engineered” and bypassed. People copy and paste strings into Word, or translate the source files and ignore the whole thing except for a quick check five minutes before delivery...
We really need this by today, can you do it faster?
All translations are a multi-step process. The very first draft is done with one eye on the source and usually sounds a bit off. After that, it gets reviewed several times, balancing precision and style, so that it means the same as the original but in a good, consistent, correct way of its own.
Of course, the more time you spend on a text, the more difficult it gets to say if it’s fine or not. Given enough time, any monstrosity looks perfectly okay! You need some “cooling off” time between reviews, and that’s why the industry has settled on 2500 words per day (roughly ten pages) as a standard for "ready to print" text.
When you ask for a faster translation, you are substantially squeezing the revision phase and end up wasting money in two ways. Either you need a second reviewer, paying extra for something that was being done for free (plus adding a whole set of broth-spoiling problems), or the translator cuts the revision short, covering their eyes as they press “send” because you didn’t let them do their job.
I don’t want to pay for that
"This text is fully of repetitions, so you should only copy and paste them for free, and this bit here is recycled from this translation and thus it should be discounted, and…"
Let’s get things straight. All translations are padded, all of them. Be it the long series of “race 1”, “race 2”, “race 3” that Excel itself can do with a drag and drop, to the Epilepsy boilerplate that comes with a default translation courtesy of the console maker, most projects have a bunch of strings that are paid in full, but get done very fast.
So why should you pay them? How is that fair? Well, to be honest, the average translator tends to do many side things too. Maybe your text contains factual mistakes that had to be double-checked, or it had to be miniaturized in order to fit extreme space limits, or it had to be input through a proprietary tool...
Why should he do something he doesn’t get paid for? I’m not saying you should hand out free cash, If a task is really menial -like tweaking a text with minor changes- prepare it so that it’s quick and easy to do -i.e. by highlighting what has changed- and then ask for it to be charged by the hour. But for the rest, consider the padding as an investment into the goodwill of the translator, as chances are you will really need it…
Please be careful not to break the variables throughout the text
This is a classic rant in the translator arena: “lego brick” sentences like “%s failed to %” don’t really turn into “System failed to load” or “File failed to save” as easily in translation as they do in English.
But, well, translators are a smart bunch, no? Let them work hard!
Actually, this is not the point. The real problem is that using this kind of variables in a text to be localized makes no business sense.
Let’s say that your product has 100 different system messages and they are 10 words each: variables can potentially save you 1000 words of translation, shaving roughly 100 USD from your localization budget. Nice!
When the text arrived to QA without the variables it was pretty straightforward. If you have been savvy enough to include a developer mode, the tester could just flash the messages one after the other, check them on screen and off you go. At five minutes each, the lot could be wrapped up in a full day.
But when it arrives to QA with the variables, it has become a very complex puzzle. Lots of strings will have to be tweaked and changed, taking a couple of extra days and completely blowing your 100 USD saving.
But what if the strings with variable are not 100, but 1000, 10000, 100000? At that point it makes sense, no?
Well, yes, it does but in this case, why you are submitting the audience to such an onslaught of boring text?
Why are you building a system that robotically displays the same things over and over, when it’s precisely the thing people hate most? If your text message is so repetitive, why don't you cut the repetitions and use lists, symbols and icons?
No, unless you are trying to build an interactive narrative engine like Chris Crawford, I’d say text variables are the biggest money waste in localization after…
We’ll fix that later
This one has so many variations that I don’t even know where to start. “This string is no longer used” is probably the most self evident waste of localization money, but also “we’ll decide space limits at a later stage” and “this is temporary text, please translate as is for now” are subtly suicidal.
Translating a piece of software is like copying an engine, one bit at a time. You don’t really have the whole picture, so you just have to guess how each piece will interact with the next, so that your copy, when “built”, can work at least decently.
That’s why non final text is so devastating, because completely breaks those initial assumptions, until it's too late to fix them.
Let’s say a game has three styles for running: sprint, rush and dash. The translation for the first two is convincing: “sprint” and “scatto”. The third one is a bit odd, “slancio”, but it’s a sacrifice we must do in order to have three clearly separated terms. All fine, except that “sprint” is no longer used. When we get the news files have been delivered and audio has been recorded. We worked harder, but your game will have to make do with the worst translation, because out assumptions were distorted by the obsolete text.
Something similar happens when the source gets heavily edited, or length limits change drastically. Usually, in these cases, you get the translation back next to the new text.
The problem is, in most cases the only way to do this properly is rewriting all from scratch but, as you usually get a reduced “revision” fee and schedule, this is simply not an option. So old text gets quickly arranged to match the new context and pushed out of the door just in time for delivery.
Paying more for a butchered translation? Definitely the master way to waste your localization budget!