Read and learn from someone who has 22 years of full-time experience in the industry.
1. Outsourcing translations to the cheapest agency, with dire consequences
The below applies to most European languages.
I charge 0.10 euro per word. However, if you look around, you will find plenty of translators who charge less. There are even cases of "translators" charging only 0.01 euro per word.
This graph shows the going rate for English-Dutch, based on the aggregated data of all Proz.com users (Proz.com is the largest (and worst) portal for freelance translators - the data is only accessible to Platinum members, hence this copy). Somebody is certainly not going to sit on the very left side of the spectrum because clients are queueing up in front of his office. Here I explain more about my own rates.
Check this page to see how you can test your translators. Find out for yourself and correlate the rates charged with the quality delivered.
Wud ya boy a game if it loked loik dis? Wat inpresion du u thnk it makez on yer yuzerz? Translations like these have been delivered by so-called professional translators. Remember: a bad localization is worse than no localization at all. The lower the rate, the worse the localization. If there's no budget for a good localization, spend your money on something else that will benefit your company more.
Add 20%-100% to the above rates if you are planning to work with an agency. You don't believe me? According to The Price of Translation: A Comprehensive Analysis of Pricing for Globalization Service Buyers (2008), based on a survey by Common Sense Advisory of 300 translation companies, the average agency charges about 24 dollar cents per word for English-Dutch translations (thanks to Paul Sulzberger for pointing that out to me). That is more than twice as much as the average translation rate of an English-Dutch freelance translator.
So ask the agency how much they are paying their translators (verify if possible). If you use an agency that charges 0.20 euro per word, but only pays their translators 0.01 euro per word, you will still end up with a terrible translation. These agencies exist by the way, and some of them are very big. The problem is that if I mention them, I will probably get sued. So you'd better do the maths yourself.
Of course, there are also some very good agencies.
2. Expecting a 100,000 word manual to be translated within 3 days
This actually happens more often than you think, and the numbers are not made up. Translating requires more thinking than writing. After all, when writing there's only a creative process involved, and no conversion process. So the first thing you should ask yourself is this: how long did it actually take me to write this manual? Chances are translating it will take just as much time.
Here's another perspective. Google tells you the average translator can only translate 2,000 words per day. To translate the above manual in three days, we need to reserve two days for translation and one day for proofreading. That leaves two days for 100,000 words, i.e. 50,000 words per day. To translate 50,000 words on one day, you need no less than 50,000 words / 2,000 words per day per translator = 25 translators.
Try to imagine what happens if 25 people start writing your manual simultaneously. No management tool is going to help you with this. The result would be a disaster, with 25 different writing styles. The same applies to translation.
Note that the proofreading on the third day merely means checking grammar and spelling. To actually unify the 25 different styles, you need one extra person (not more, as that would result in multiple styles). It will take at least 3 extra working days to have one person unify 100,000 words. When you need this 'unifier' to start working to make your deadline, the translators haven't even started working yet.
So this is technically impossible. Any agency that says they can cater to your needs anyway and deliver a good translation, is lying. But of course, there are plenty of shady businesses that will tell you otherwise.
However, that doesn't solve your problem, does it? How do you prevent ever getting into a situation like this? Well, you can try to plan things in advance, for example by feeding translators pieces of text as soon as they become available (the above-mentioned manual surely wasn't written in 3 days)! Even if some of these pieces change later on, CAT tools should be able to tell translators exactly what changed where, so that you'll never pay twice for the very same sentence.
Important: Especially July, August and September are extremely busy when it comes to game translations. Most game translators are fully booked during these seasons. Try to have your texts translated earlier or later if you want to avoid working with second-rate translators who are not specialized in games.
3. Embedding text directly into the code, instead of separate text files
Though most CAT tools offer support for languages like C++ and can directly extract translateable text from several kinds of code, it mostly is not a good idea to directly embed your text into your scripts. For a translator it doesn't matter whether the text is displayed when John Doe enters the room, or should scroll from left to right only after the player has found the BFG. Embedding text directly into the code instead of separate files will make your life harder for several reasons.
First, the number of words counted will increase tremendously (often up to twice the actual amount) if there are no filters available that can separate the text from the code. That means exactly that: it's going to cost you twice. Second, it will slow down the localization process tremendously, as the translator needs to actually read the code to determine which segments need translation and which not. Third, the consistency of the translation will become a lot worse:
show_data(samples, countone, "Original values");
show_data(samples, counttwo, "Original values");
The translator's CAT tool will consider these as two separate strings. If there are thousands of other strings between the above-mentioned two strings, you can be sure the translator will have forgotten how he translated the first instance of Original values by the time he arrives at the second instance . Had the code looked like this:
...the CAT tool would have automatically propagated the first instance to the second instance. That saves money, saves time and leads to more consistency. So use separate text files or even better: XML.
4. Assuming every language has the same grammar as English
Programmers like efficiency, for good reasons. Why code:
Brian takes the gun
Brian drops the gun
If you can use this instead:
Brian %s1% the gun
Here's why this is really a bad idea, using Dutch as an example (the bold words are equivalents). The translation of the full sentences is:
Brian pakt het pistool
Brian laat het pistool vallen
Please try to imagine how we are going to fit the translation laat...vallen in %s1%. You can't. You see, drop in Dutch becomes laat vallen (literally: let fall) and the verb clause is split around the object of the sentence (the gun). This is a typically Dutch phenomenon. But there are much stranger languages around. The Japanese for example can put adjectives (that is words like good, bad, nice, beautiful) in a past or future tense. So if you say this is gad, it could mean something like this was good. Would you ever have imagined that? The thing is that every language has its own interesting phenomenae, which developers simply cannot take into account when constructing 'concatenated' sentences like these.
Tip: if you need to construct concatenated sentences, consult your translators in advance. Once you have started localizing your games regularly, you should have a rough idea about the languages you normally localize to. So use your team and ask your translators for help; no translator is going to charge you for some simple advice on these matters.
The best solution is to avoid concatenated constructions at all. If you construct them, make very clear which sentences can be combined with which sentences (all possible combinations) and be prepared for some unpleasant surprises that require some changes in the code.
Using the concatenated approach might result in less words, but does not lead to a cheaper or faster localization. The number of words saved is often less than a hundred (this is hard to back up, but purely based on personal experience). On top of that, the translator will need to really slow down when encountering segments like these, trying to think of workarounds and solutions that work in his target language.
The most important thing to remember is: never glue segments together without consulting your translators. In translation, A+B is definitely not always AB! Language is not mathematics.
5. Assuming every language is as concise as English
Consider the following example:
Up (maximum string length: 2 characters)
The word for up in Dutch is omhoog. How are we going to fit this in 2 characters? There is no way the word omhoog can ever be abbreviated to 2 characters. Om, Oh, whatever you try, no one will ever understand the original meaning. In a best-case scenario, you need at least 4 characters here: omh. Even then, the result is pretty ugly.
Let's reverse the situation. Please come up with a 2 character translation for the Dutch word ar, which means sleigh. Sl is probably not going to cut it, is it? Be realistic and allow at least 50% more space for your translations (as you can see, in this particular example even 50% is not enough). Even better: use a dynamic user interface that adjusts on the fly (i.e. don't hardcode it), so that no unnecessary sacrifices need to be made. It is more work, but will save you lots of time during the localization process itself.
6. Assuming that every word has only one possible translation
This problem can appear in two forms: a) developers copying and pasting translations without consulting the translator or b) developers using the same string in different contexts.
a) Never, ever cut corners by copying and pasting previous translations from your translator. This can have absolutely disastrous results. I once did a translation about a space ship simulator - in this context space is translated as ruimte (space as in universe). The client copied and pasted the word ruimte to a message popping up every 3 seconds, instructing the user to press SPACE (as in space bar) to jump, without consulting me beforehand. The result was that the user was instructed to press the universe every so many seconds. The end result, reminiscent of Zero Wing (All Your Base Are Belong To Us), was run into the ground by all review sites. Instruct your programmers to never, ever touch translations if they don't speak the target language and always consult your translator.
b) The second way this can go wrong is by having only one instance for a string called space, while using it in two different contexts. The first context is a screen on which players can input their names. In this case space refers to the space bar (Dutch: spatie). The second context is the title of the first level, which is set in space (Dutch: de ruimte). Of course, there is no way the two different translations can be put in the very same string. So you need two different strings here, for two different contexts, even though in English, the source text of the string is the same.
7. Not providing any context and not answering questions
It's often a very good idea to provide context for as many strings as possible. Consider the following:
Great, you did it!
I can't believe that worked.
Run, run, before they get us!
I'm glad we made it.
Obviously these are some random strings taken from a chase scene. And I'm sure you interpreted I'm glad we made it as I'm glad we didn't get caught. However, in this particular case it meant I'm glad we made this bomb, instead of them. At least we know how to make a good bomb.
It goes without saying that the two different interpretations lead to two very different translations. Far-fetched? This happens more often than you think. For a good translation, the source text should be unequivocal. This isn't always possible, so to prevent any problems, it's always a good idea to provide context. Many developers do this by explaining what the string is about in a separate column in Excel.
The translation software I use warns me for possible pitfalls like these, in which case I will send you some questions. But if both the software and I overlook these kind of pitfalls, the result will be a wrong translation. An extra explanation about context or actually playtesting the game are great ways to get rid of these kind of context-sensitive errors. You think playtesting is normal? The vast majority of the developers never playtests localized versions of their games. It is therefore no wonder that so many localized games are run into the ground on review sites.
By the way, did you know that some of the most reputable translation agencies in the world (I'm talking really big names here) have your games playtested by foreign exchange students they have never met or interviewed before? Your game too might have been tested by a clueless user who knows everything about biotechnology, but nothing about games or linguistics. How I know this? Because former employees told me. One more reason to be really vigilant when prices are suspiciously low.
By the way, in dialogues, it is extremely important that you indicate who says what to whom. This is because in other languages, there are different levels of politeness. In English, everybody calls everybody you, but in Dutch we use u towards superiors and elderly people and jij towards friends or younger people. Japanese holds the absolute record when it comes to politeness levels. Verbs, grammar, pronouns, everything changes:
Genki? (How are you, blunt style)
Gokigen wa ikaga de gozaimasu ka? (How are you, a bit politer)
In Japanese, there are also phenomenae like male and female language, each with its own grammar.
8a. Using hard enters in the middle of strings
Especially Japanese developers and developers of mobile phone games love doing this.
Many translators use so-called CAT tools for their translations. This software automatically copies repetitions in the text, enabling the translator to give you a discount on similar strings, making sure the style of the translation is consistent and greatly speeding up delivery. However, the smallest building blocks CAT tools can work with are full segments. An example:
in Dutch. As you can see, automatically copying the string the, which occurs twice, is never going to work here, as Dutch uses different articles for sword and axe. The same applies to longer segments.
A translated segment can only be copied reliably if the segment is complete. If a segment is split in several parts, you will see that these depend on eachother, meaning that the translation of a certain part of a segment can change depending on what comes before or after it. Id est, even if English(A+B)=Dutch(a+b), English(A+C) is not necessarily Dutch(a+c). It often is Dutch(a'+c).
Since it's impossible to determine beforehand which segments are split in the middle and which are not, even the occasional use of hard enters in your text can render CAT tools totally useless.
What does this mean in practice? On the average, localization of soft-coded strings is about 12% cheaper and faster than localization of hard-coded strings. For every language you localize to, that is.
8b. Using hard enters in the middle of strings (part deux)
By the way, there's a reason why especially Japanese developers love hardcoding their strings: in Japan it's customary to wrap text by hand (Japanesehasnospaces, and it wouldn't be user-friendly to have the text automatically wrapped in the mid
dle of words). Languages like English and Dutch though do feature spaces, and can therefore automatically be wrapped on the fly (in fact, that's exactly what's happening when you're reading this text: try resizing your browser window and be surprised).
Because of this, and the Japanese developers mostly not wanting to code a separate word-wrapping routine for languages with spaces (which is not that hard: in a language like PHP it takes just one extra line in your code), translators instead need to spend hours and hours on wrapping the text by hand, line by line, string by string, which is very counterproductive (read: the localization will take more time and will become more expensive).
Fortunately I know a bit about programming myself, so to speed up the process I wrote my own PHP software which extracts the strings from Excel, unwraps them, and after translation rewraps them back into Excel. Even then, hardcoded strings are still much harder to translate - especially if you imagine that not all your translators can write their own software.
Suppose a string is spread over several lines and one word has to be changed: the change will make certain lines longer and shorter, so that all lines need to be rearranged and rewrapped.
This string is not
wrapped on the fly.
Its maximum width is
|No no, this string||<= two extra words, line changed|
|is not wrapped on||<= no word changes, but line changed nonetheless|
|the fly. Its maximum||<= no word changes, but line changed nonetheless|
|width is 20||<= no word changes, but line changed nonetheless|
|characters.||<= extra line!|
So repeat the mantra after me: thou shalt not hardcode! Thou shalt not hardcode!
9. Assuming that anybody can translate
On birthday parties, people often ask me what I do for a living. When they find out I'm a translator, they mostly reply that their English is absolutely perfect and that they can't understand I'm making so much money with something so easy. This page mentions several criteria you can use to separate good translators from bad translators. But even then, it is very tempting to have a translation done by someone you know well, who claims that he or she will be able to deliver a perfect product.
Don't fall for it. I am well aware of the fact that our industry has a very bad reputation, and that merely the fact that someone calls himself a "translator" is no guarantee for a good translation. But outsourcing translations to non-translators, who claim they can translate just because they happen to have the Dutch nationality, will definitely result in a disastrous product.
Look very critically at your own user forums. Do a quick grammar and spelling check and you will be surprised. Most American and British people can't even write their own language. The same applies to Dutch people. And this is just writing we're talking about, which is a lot easier than actual translation.
The vast majority of professional translators delivers an absolutely terrible product. I know this because I have screened hundreds of professional translators, inviting them to do a test translation. I have completely ignored their writing style (no matter how bad) and purely focussed on grammar and spelling. Even then, 95 out of 100 translators could not deliver acceptable quality. These people can continue their jobs because clients are ignorant, do not care or do not (want to) know.
What also happens very often is that game publishers/developers have their own websites translated (partially) by internal staff, often non-linguists. The fact that someone is Dutch does not mean he or she is actually able to come up with a good Dutch translation. In fact, at least one very famous publisher has done an absolutely terrible job with localizing their website to Dutch, which is literally infested with grammar and spelling mistakes. It all started very well when they had the basics done by me - but went totally down the drain when they decided they could do the rest of the translations themselves.
Let the programmers program, let the marketeers market and let the translators translate. It's really not that difficult.
There's a reason why our industry has such a bad reputation. If this already applies to professional translators, try to imagine what happens if you use non-professional translators. Are you frightened? Not nearly frightened enough.
10. Trusting Microsoft's existing localization
Recently I translated a high-profile game that pulled Dutch strings directly from Microsoft's DirectX library. Microsoft however had never translated these strings, resulting in a schizophrenic menu containing both English and Dutch. It was too late to make any changes in the code, and the game will be released in its current, schizophrenic form.
Don't trust Microsoft too much. Their localization of Windows is sloppy to say the least.
11. Not giving enough information
This problem can lead to all kinds of disasters. Let me give just one example. Recently I spent two full days on playtesting a high-profile game. The goal was to catch any strings that didn't fit in dialogue boxes. After two full days were spent, the developer mentioned that a new, lower resolution had been implemented into the game, resulting in a bigger font, hence less letters fitting in a dialogue box. The developer could as well have poured the 500 euro spent on playtesting down the drain, as the whole game needed to be retested from scratch in the lower resolution.
12. Assuming numbers, units, dates and times don't need localization
Besides the fact that Europe uses a metric system, as opposed to the non-metric system used in the UK and the US, we also write numbers in a different way. The numbers 3.0, 1,000 and 10,000 are rendered as respectively 3,0, 1000 and 10.000 in Dutch. So yes, numbers need to be localized too.
And if your game uses units like mph (racing games) or lbs, you will need to implement a unit conversion routine that converts these to respectively km/h and kg. This applies to any non-metric units used in your game.
Many countries also use different formats for dates and times. In Dutch for example, we use the DD-MM-YYYY format for dates and the 24-hour HH:MM format for times (AM and PM are not used). Even the symbols used in these formats (- and : respectively) can change.
13. Handling punctuation yourself
One of the translations I localized had to be entered via a web interface. The punctuation was handled automatically. I.e., the full stops at the end of every sentence were placed automatically, so that inserting a full stop in the actual translation would eventually result in sentences ending with two full stops, like this.. Once I understood what was going on, this was easily solved, but even then some of the Dutch sentences got weird punctuation.
You see, even such a simple thing as a comma is used differently in every language. In English, this sentence looks perfectly normal. In Dutch however, we'd never put a comma behind "English". ¿Also, did you ever consider that Spanish phrases questions like this? I will spare you the details about Japanese, a language that doesn't use spaces andiswrittenlikethis.
14. Outsourcing every project to another agency or translator
This is a great way to make sure that every single project will use different terms and writing styles. Not to mention the fact that you lose a great deal of money because you can't leverage legacy translations. Last but not least, if you let agency B handle the update for a manual translated by agency A, you can rest assured you will get the most schizophrenic manual in the world.
There are ways to ensure consistency, but they often end up to be more expensive than sticking with agency A in the first place. On top of that, the vast majority of (at least the Dutch) part-time game translators do not have the software tools needed to use legacy translations.
It's often very tempting to go to another agency because your previous agency cannot deliver fast enough or because you have found someone else who is cheaper. And of course, sometimes there is no other possibility. However, there is a price you have to pay, and you must be prepared for it.
By the way, did you know that most companies have no localization policy at all, and that the same project often ends up at 5 to 6 different agencies or translators? Programmer A calls agency A, programmer B calls agency B, the secretary calls agency C and the Development Manager uses the services of freelancer D. Imagine the chaos.
Worst is that many agencies give you the impression that your translation is handled by only one translator, while very often, this is not the case. They often use multiple translators (or even other agencies) for one project, without ever telling you, once more resulting in a schizophrenic translation. There are exceptions, but they are few. If an agency can translate more than 2,000 words per day, be very vigilant and realize there is a price to pay.
15. Not using CAT tools
CAT tools are tools that store every sentence a translator has ever translated for you. This can be quite useful, as when you update a manual, re-used sentences are translated automatically.
Even the biggest game translation agencies in the world almost never use CAT tools (out of the 8 game translation agencies I have been working with on a full-time basis for 15 years, only one asked me once whether I used these tools - and that was all they did). Indeed, typing translations manually in Excel still seems to be the de facto way to localize games.
How many new words are there in your latest update? Developers try to come up with the right answer by colour-coding every new segment while adding it. Agencies try to find the answer by comparing all sentences one by one (charging every minute spent). With the right tools however, you can calculate the answer (and hence your discount) within 5 minutes.
It always amazes me how agencies ask translators without CAT tools to use the same terminology as in previous translations. There is no way you can guarantee that without using these tools. You cannot possibly expect people to look up every single noun in existing translations using Edit > Search in Excel to see how said word has been translated before (and remember it while translating the rest of the text)! It's not like you need to do this 10 times or so... to ensure 100% consistency, you'd need to repeat this procedure about 2,000 times for a simple 25 page manual (a 25 page manual has about 2,000 unique potential terms).
So what often happens is that translators just make a wild guess, look up what they think could have been translated before, and just get on with it. Meanwhile, the agency tells you your translation is 100% consistent with previous translations. Indeed it's what they asked their translators to ensure, but translators without CAT tools have no choice but to ignore these instructions and play dumb. After all, being honest means they won't get the job, which will eventually go to someone less honest anyway. By the time you get complaints, they have already moved on to the next project for another client.
16. Assuming all text will be in ASCII
This isn't really an issue for localizations to Dutch, but can have tremendous consequences if you ever decide to localize your game to say Japanese or Chinese. Japanese uses about 8,000 characters (of which about 2,000 are used regularly); Chinese uses 40,000 (of which about 8,000 are used regularly). As you can see, the one-byte ASCII set is by no means sufficient to address all characters used.
It's 2017 and I think that by now, ASCII routines should be totally forbidden and replaced by Unicode routines, even if your game is only in English. You never know what you will do in the future, and Unicode offers support for all languages. Of course, you will still need to integrate different fontsets for (what we consider as) exotic languages, but that's a lot easier than rewriting your code from scratch.
17. Bad internal communication
I once had to do a sample translation for a client, which was about 3 bunnies. One of the bunnies spoke very old-fashioned Japanese, and of course I tried to reflect this in the translation. The client turned down the translation, because their proofreader found the Dutch "too old-fashioned". Clearly the proofreader was not instructed properly by the client. On the other hand, the old-fashioned language was used on purpose so clearly, that I can't help wondering why the proofreader didn't see this.
Anyway, it was too late. I lost that client, because once you've been labeled, you're labeled forever. So here's the golden rule: if a bunny is supposed to use old-fashioned language, then let it use old-fashioned language. I'm sure you know how to apply that rule to your own situation.
18. Pissing off your translators
Welcome to our new mini-course How to piss off your translator in 3 minutes!
a. Not paying on time. EU law says that standard payment terms are 30 days net. That means 30 days net, not 31 days net, not 41 days net and certainly not 51 days net. Ask yourself how long it would take you to quit your job if your boss suddenly decided to pay your wages one month later just because that's his new policy. I have 550 clients. If you decide to pay me 30 days late, I will direct my attention to other clients that actually pay on time. You can't really blame me for that.
b. Organizing Formula 1 races. If you have a job, it's not cool to send it to all 50 Dutch translators in your pool and handing it to the one who responded first. When you ask a translator if and when he can deliver, he needs to interrupt his current job, analyze the text, check his schedule and write an e-mail to answer you. Depending on the format of the text, this takes about 5-120 minutes. It is not cool to receive a mail saying the job went to someone else who responded faster just after you have finished your 120 minute analysis. In fact, this is a sure way to have all your e-mails forwarded to the e-mail box for time-wasters (which I'm about to merge with the e-mail box for junk mail).
c. Not giving decent feedback about sample translations. If you ask a translator to deliver a 300 word sample translation to check the quality of his work, it's not cool to give a 2 word summary about your impressions. The translator invested at least one hour in showing you what he or she is capable of. The least you can do is provide some decent feedback. I'm sure that during a job evaluation, your boss will do more than just stating that your current performance is "not acceptable" and then fire you. He will elaborate a bit. So should you.
d. Having translators go through tons of paperwork for nothing. It is not nice to have translators spend hours reading, filling in and signing 10-page NDA's, Work for Hire contracts, internal company policies and supplier forms just for general coolness. If you let your translators go through that much paperwork, you'd better have a decent job waiting that will actually materialize.Even worse are clients that let you spend days on contracts and forms, only to come up with the final and completely unexpected Mother of All Contracts which suddenly stipulates, amongst other things, that the translator has to pay millions of dollars if delivery is late (while the translator does not get any compensation if the client's payment is late), that the translator may not work for any of the client's clients, friends, acquaintances, affiliates, LinkedIn contacts, family members, pets and tapeworms not even if they directly approach the translator (while the client is free to steal the translator's clients whenever he deems fit) and that the translator should reserve at least 4 hours per day for the client by refusing other jobs from other clients (while at the same time not guaranteeing that the translator will ever get work, so that the translator ends up staring at his fingernails for the rest of his life - without compensation). Basically these clients from hell want to run with the hare and hunt with the hounds. They guarantee nothing but want everything. They use double standards and have the ethics of a peanut. They want to use you as their employee (if not worse) while at the same time refusing to bear the responsibility that comes with it. Yeah, try to have your local dentist sign this contract and see how many seconds it takes to get punched.
Anyway, if you thought telemarketeers were wasting your time, think again. The above clients are much worse. Translator communities have special shit lists for time-wasters like these. Don't end up there, as it's impossible to get off.
e. Not treating translators with respect. We are highly-educated professionals who have studied at least as much as programmers, game developers and publishers. If you think anybody can translate because it's so easy, I suggest you start your own translation business and do the work yourself, as a good translator makes more than 16 K per year (well, at least I do).
Porting to a language like C+ can be tough; translating to a language like Dutch can be just as tough. Please don't treat us like we're students flipping hamburgers in the local Burger King. If you treat us with respect, respect is what you will get. Personally I think you should treat everyone with respect, no matter whether people are flipping hamburgers in a restaurant or not. If you don't think so, please don't contact me.
f. Using one-sided agreements. Often developers contact me saying that this and this text will be ready on date X, and that they want the translation back no later than date X+2 days. They want me to absolutely guarantee this delivery date and tell me that the source text will definitely be ready on date X.To guarantee delivery on date X+2 days, I will of course need to reserve time for this project by refusing other projects. So it only makes sense to ask for a guarantee in return: in the unlikely case that the source text does not arrive on date X, I want to get fully compensated for the time I reserved. After all, the text would *definitely* be ready on date X, right? For some reason though, this always causes this type of clients to chicken out: they want guarantees without guaranteeing anything themselves. It just doesn't work that way.
19. Not enabling players to control text speed
Not all players read as fast as you do. It is very frustrating to see dialogue texts disappear while you haven't even finished reading them. This becomes especially an issue if you have your game translated, as translations often become longer than the original source text. So let people control text speed themselves and implement a button the player must press to move to the next dialogue. And if this is not possible, for example in cutscenes, either use voice-overs or err on the side of caution and have the reading speed tested by normal people (not game testers, who read all day long and can read much faster than normal people).
20. Using illegible fonts
Not all players have an HDTV. Do what professional studios do: they mix the music on the worst loudspeakers they can find (often transistor radios). If music sounds good on those speakers, it will sound good everywhere. So grab that old dusty CRT from the attic. If that monitor displays the text neatly, the text will be legible no matter what system you use.
21. Assuming Google Translate is as good as a human translator
The CAT tools I mentioned above are merely huge databases that work on a sentence level. There are other tools out there that work on word level - these are called machine translation (MT) tools. Basically they try to apply grammar rules to translate sentences word by word automatically.
This technology is still in its infancy. To prove this, I have copied the above paragraph to Google Translate and translated it to Dutch. I then copied the Dutch translation back to Babelfish and retranslated it to English. Here is the result:
The appliances of the CAT which I am above only giant fact files have mentioned which work for a sense level. There are there other appliances which work for word level - these are called automatic translation appliances. Fundamental trying they apply grammar rules translating word automatically sense word by.
Or what do you think of this slogan one of my clients came up with, which was featured prominently on top of their website:
De download en speelt uw favoriete spelen!
The download and playeth thy favourite games!
I'm sure that one sold well.
Never, ever use Google Translate. No, not even for that one little word. Fire any employee who even considers using it. The result will be a total disaster.
Loek van Kooten
Your English/Japanese-Dutch game translator