The biggest mistakes made by game developers and game publishers

Read and learn from someone who has 29 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 (English-Dutch)/0.13 euro (English-Japanese/Chinese) 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:

Original values
Original values

...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
takes
drops

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 Every Word Has Only One Possible Translation

This issue can manifest in two ways: a) developers copying and pasting translations without consulting the translator, or b) using the same string in different contexts.

a) Never, ever cut corners by copying and pasting previous translations without consulting the translator. This can lead to disastrous results. I once translated a spaceship simulator where "space" was translated as ruimte (space as in the universe). The client copied this word into a prompt instructing the user to press "SPACE" (as in the space bar) to jump—without asking me first. The result was a prompt telling the user to "press the universe" every few seconds. The outcome? A complete flop, with reviews likening it to "All Your Base Are Belong To Us." Instruct your programmers to never touch translations if they don't speak the target language and to always consult the translator.

b) The second problem arises when using the same string in different contexts. Take "space" again: in one context, it refers to the "space bar" (Dutch: spatie), while in another, it's the title of a level set in outer space (Dutch: de ruimte). Naturally, you can't use the same string for these two different translations. You need two distinct strings for different contexts, even if the source text looks identical in English.

7. Not Providing Context and Ignoring Questions

Always provide context for as many strings as possible. Consider these lines:

Great, you did it!
I can't believe that worked.
Run, run, before they get us!
I'm glad we made it.

It’s easy to assume this is a chase scene, interpreting "I'm glad we made it" as "I'm glad we weren't caught." However, in this case, it actually means, "I'm glad we made this bomb instead of them. At least we know how to make a good bomb." These two interpretations require vastly different translations. Is it far-fetched? Not at all. This happens more often than you might think. While the source text should be unequivocal, that's not always possible. Providing context is key. Many developers do this by including an explanation in a separate column in their Excel files.

The translation software I use flags potential pitfalls like this, prompting me to ask questions. However, if both the software and I miss the nuance, the result will be an incorrect translation. Offering context explanations or playtesting the game can help eliminate these errors. Do you think playtesting is standard? Most developers never playtest the localized versions of their games, which explains why so many of them receive negative reviews.

Did you know that some of the most reputable translation agencies (yes, the really big names) hire foreign exchange students to playtest your games without ever meeting or interviewing them? Your game might have been tested by someone who knows everything about biotechnology but nothing about games or linguistics. How do I know? Former employees told me. Another reason to be vigilant when prices seem too low.

In dialogues, it's crucial to indicate who says what to whom. In English, everyone is simply "you." However, in Dutch, "u" is used for superiors and elders, while "jij" is for friends or younger people. Japanese takes politeness to a whole other level. Pronouns, verbs, and grammar change entirely:

Genki? (How are you, informal)
Gokigen wa ikaga de gozaimasu ka? (How are you, very formal)

Japanese also has distinct male and female language, each with its own grammar rules.

8a. Using Hard Enters in the Middle of Strings

Japanese developers and mobile game developers love to do this.

Many translators use CAT tools that automatically copy repetitions in text, helping ensure consistency and speed up delivery. However, these tools work on full segments. Consider the following example:

The
sword dropped
The
axe dropped

This becomes:

Het
zwaard viel
De
bijl viel

in Dutch. Automatically copying "the" twice won’t work because Dutch uses different articles for "sword" and "axe." The same applies to longer segments.

A segment can only be copied reliably if it's complete. If split, its translation may vary depending on what precedes or follows. In short, even occasional hard enters can render CAT tools useless.

What’s the impact? On average, localizing soft-coded strings is about 12% cheaper and faster than hard-coded ones for every language.

8b. Using Hard Enters in the Middle of Strings (Part Deux)

There's a reason Japanese developers often hardcode their strings: in Japan, text wrapping is done manually (since Japanesehasnospaces, automatically wrapping text in the middle of words isn't ideal). English and Dutch, however, use spaces, allowing automatic wrapping (just try resizing your browser window right now).

Rather than coding a simple word-wrapping routine (which can be done in PHP with a single line), translators end up manually wrapping text line by line, string by string. This is highly inefficient and increases both time and cost.

Fortunately, I know a bit of programming, so I created a PHP tool that extracts strings from Excel, unwraps them, and rewraps them after translation. Still, not all translators can write their own software, and hardcoded strings remain much harder to handle.

If a string is spread across multiple lines and one word changes, you must rearrange and rewrap all lines:

Before change:
This string is not
wrapped on the fly.
Its maximum width is
20 characters.

After change:
No no, this string	<= Two extra words, line changed
is not wrapped on	<= No word changes, but line still changes
the fly. Its maximum	<= No word changes, but line still changes
width is 20	<= No word changes, but line still changes
characters.	<= Extra line!

So, repeat after me: Thou shalt not hardcode! Thou shalt not hardcode!

9. Assuming Anyone Can Translate

At parties, people often tell me they can't believe I make a living as a translator since "anyone can do it." This page outlines the criteria to separate good translators from bad ones. It's tempting to hand translation tasks to someone you know who "claims" to be fluent, but don't fall for it.

Simply being Dutch doesn't guarantee the ability to produce a high-quality Dutch translation. Even professional translators often deliver terrible products. I've tested hundreds and found that 95 out of 100 couldn't pass basic grammar and spelling checks. They continue working because clients don’t know, don't care, or turn a blind eye.

Some companies attempt in-house translations with non-linguist staff, resulting in disastrous outcomes. A well-known publisher once botched their website's localization, filling it with errors. It started fine when they used my services, but quickly fell apart when they decided to handle the rest themselves.

Let the programmers program, the marketers market, and the translators translate. If this applies to professional translators, imagine the mess when using non-professionals.

10. Trusting Microsoft's Existing Localizations

Recently, I translated a game that pulled Dutch strings directly from Microsoft’s DirectX library. However, Microsoft had never translated these strings, resulting in a schizophrenic menu mixing English and Dutch. It was too late to fix, and the game released in this jarring state.

Don’t trust Microsoft too much. Their Windows localization is sloppy, to say the least.

11. Not Giving Enough Information

This problem can lead to all sorts of disasters. Let me share one example: I recently spent two full days playtesting a high-profile game, focusing on catching strings that didn't fit within dialogue boxes. After I completed this time-consuming task, the developer casually mentioned that they had implemented a new, lower resolution, resulting in a larger font and less room for text in the boxes. The result? The entire game now needed to be retested from scratch in the new resolution. The 500 euros spent on the initial playtesting could have just been poured down the drain.

12. Assuming Numbers, Units, Dates, and Times Don't Need Localization

Numbers, units, dates, and times are different in every region, and yes, they need to be localized too. In Europe, we use the metric system, unlike the non-metric system used in the UK and the US. We also write numbers differently: 3.0, 1,000, and 10,000 are rendered as 3,0, 1000, and 10.000 in Dutch.

If your game uses units like mph (racing games) or lbs, you must implement a conversion routine to convert these to km/h and kg, respectively. This applies to any non-metric units used in your game. Additionally, different countries use various date and time formats. For instance, in Dutch, dates are written as DD-MM-YYYY, and times use the 24-hour HH:MM format (AM and PM are not used). Even the symbols used (- and : respectively) can change. Localization goes beyond words; it's about adapting to cultural norms.

13. Handling Punctuation Yourself

One project I worked on involved translating text entered through a web interface. Punctuation was automatically added at the end of every sentence, which meant that inserting a period in the actual translation resulted in sentences ending with two periods, like this.. Once I figured out what was happening, I adjusted accordingly, but some Dutch sentences still ended up with odd punctuation.

Even a seemingly simple element like a comma is used differently in every language. In English, this sentence looks perfectly normal. However, in Dutch, we would never put a comma after "English." And did you know that Spanish questions are framed with an upside-down question mark like this? ¿Interesting, right? Japanese doesn't even use spaces andlooksabitlikethis. The details matter.

14. Outsourcing Every Project to a Different Agency or Translator

This is a surefire way to ensure each project uses different terms and writing styles. Moreover, you lose the advantage of leveraging legacy translations, costing you more in the long run. If you let Agency B handle an update to a manual initially translated by Agency A, you’ll end up with the most inconsistent and fragmented manual in existence.

There are methods to maintain consistency, but they often prove more expensive than sticking with one agency from the start. Additionally, most part-time game translators (especially Dutch ones) lack the necessary tools to use legacy translations.

It's tempting to switch agencies when your current one can't meet deadlines or when you find someone cheaper. Sometimes, this is unavoidable. However, remember there's always a price to pay, and you need to be prepared for it.

Did you know that most companies have no localization policy at all? This often results in the same project being handed off to 5 or 6 different agencies or translators. Programmer A calls Agency A, Programmer B calls Agency B, the secretary calls Agency C, and the Development Manager hires Freelancer D. The result? Pure chaos.

Worst of all, many agencies give you the impression that one translator is handling your project when, in reality, multiple translators (or even other agencies) are involved without your knowledge. This again leads to a disjointed translation. There are exceptions, but they are rare. If an agency claims to translate more than 2,000 words per day, be cautious. There’s always a hidden cost.

15. Not Using CAT Tools

CAT tools store every sentence a translator has ever translated for you, which can be invaluable. When updating a manual, these tools automatically translate previously used sentences, saving you both time and money.

Shockingly, even the largest game translation agencies seldom use CAT tools. In my experience working with eight major game translation agencies full-time for 22 years, only one asked if I used these tools—and even then, it was a one-time inquiry. Typing translations manually in Excel remains the standard practice.

How many new words are there in your latest update? Developers attempt to estimate by color-coding new segments, while agencies painstakingly compare sentences one by one (charging you for every minute). With the right tools, you can calculate the answer and your potential discount within 5 minutes.

Agencies often expect translators without CAT tools to use consistent terminology. However, without these tools, there’s no way to guarantee consistency. You can’t reasonably expect someone to search for every single noun in existing translations using "Edit > Search" in Excel, let alone remember it while translating the rest of the text! For a simple 25-page manual containing around 2,000 unique potential terms, this would need to be done about 2,000 times to ensure 100% consistency.

So what typically happens? Translators make an educated guess, look up what they think was translated before, and move on. Meanwhile, the agency assures you that your translation is 100% consistent with past translations. While they may instruct their translators to ensure consistency, those without CAT tools simply can’t comply. Being upfront means they lose the job, which will then go to someone less honest. By the time you receive complaints, they've already moved on to their next client.

16. Assuming All Text Will Be in ASCII

This might not be a big issue for Dutch localization, but it's a game-changer if you plan to localize for Japanese or Chinese markets. Japanese uses about 8,000 characters (with around 2,000 regularly used), while Chinese employs up to 40,000 characters (with approximately 8,000 in regular use). Clearly, the one-byte ASCII set simply won't suffice.

It's 2024, and using ASCII routines is long outdated. They should be replaced by Unicode routines—even if your game is currently only in English. You never know where future expansions might take you, and Unicode provides support for all languages. Sure, you'll still need to integrate different font sets for more "exotic" languages, but that's far easier than rewriting your entire code from scratch.

17. Poor Internal Communication

I once had to translate a story featuring three bunnies, one of whom spoke in old-fashioned Japanese. Naturally, I reflected this unique style in the Dutch translation. However, the client rejected it because their proofreader found the language "too old-fashioned." Clearly, there was a breakdown in communication somewhere. The proofreader was not properly briefed, and the intent behind the bunny's dialogue was lost.

Unfortunately, it was too late; the client was gone. Golden rule: If a character is supposed to use old-fashioned language, stick to it. The lesson? Clear communication with your translators is key.

18. How to Annoy Your Translators in 3 Minutes

Welcome to this mini-course on how to tick off your translator!

a. Not Paying on Time. EU law states that standard payment terms are 30 days net. That means 30 days, not 31, 41, or even 51. Imagine if your boss suddenly decided to pay you a month late. How long would you stick around? I have 550 clients. If you pay me late, I’ll focus my attention on clients who pay on time. Simple as that.

b. Hosting "Formula 1" Job Races. Sending a job to 50 translators and giving it to the one who responds first is not cool. When you ask a translator if they can deliver, they need to interrupt their current work, analyze the text, check their schedule, and respond to you. This takes time—anywhere from 5 to 120 minutes. Receiving an email saying the job went to someone else just after finishing a 120-minute analysis is the quickest way to get your emails forwarded to the "time-wasters" folder.

c. Providing Useless Feedback on Sample Translations. If you request a 300-word sample to gauge quality, don’t offer a two-word response like "Not acceptable." The translator invested at least an hour into showing their skills. At the very least, provide constructive feedback. Just as you’d expect a detailed evaluation from your boss, offer the same courtesy to your translator.

d. Making Translators Complete Endless Paperwork for Nothing. Requiring translators to fill out extensive NDAs, work-for-hire contracts, and supplier forms—only to have no actual work lined up—is beyond frustrating. Worse yet are clients who make translators jump through hoops only to introduce the "Mother of All Contracts" that dictates impossible terms: paying millions in fines for late deliveries, forbidding work for the client’s acquaintances or even their pets, and expecting the translator to reserve 4 hours a day while guaranteeing zero work.

These clients demand everything while promising nothing. If you think you can treat translators this way, try having your dentist sign such a contract and see how many seconds it takes before you get shown the door.

Don't be the client that ends up on translators' "do-not-work-with" lists; it's nearly impossible to get off them once you're there.

e. Not Treating Translators with Respect. We are highly educated professionals, having studied just as much as programmers, developers, and marketers. If you think translating is easy, try starting your own translation business. A good translator earns more than €200,000 per year (trust me, I do).

Programming in a language like C+ can be challenging; translating into Dutch can be just as demanding. Please don't treat us like students flipping burgers at a fast-food joint. Show respect, and you will receive it in return. I believe everyone should be treated with respect, regardless of their job. If you disagree, we’re probably not a good fit.

f. Using One-Sided Agreements. Some developers contact me saying, "The text will be ready on Date X, and we need the translation by Date X+2 days." They want me to guarantee the delivery, claiming the text will "definitely" be ready on Date X. To meet their deadline, I must reserve time for this project, potentially turning down other work. So, it's only fair that I request a guarantee: if the source text isn’t ready on Date X, I expect compensation for the reserved time. Strangely, these clients often back out when asked for a reciprocal guarantee. They want promises but aren’t willing to make any themselves. It simply doesn’t work that way.

19. Not Letting Players Control Text Speed

Not all players read as fast as you do. Watching dialogue disappear before you finish reading is frustrating, especially in translations, which are often longer than the original text. Let players control text speed and use a button to move to the next dialogue. If that’s not feasible, like in cutscenes, consider using voiceovers or test reading speeds with normal people (not game testers who read all day).

20. Using Illegible Fonts

Not all players have HDTVs. Do what the pros do: mix music on the worst speakers you can find. If it sounds good on a transistor radio, it'll sound good everywhere. Apply this to text by using an old CRT monitor. If the text looks neat there, it'll be legible on any system.

21. Assuming ChatGPT Can Replace a Professional Translator

While tools like ChatGPT have made impressive strides in natural language processing, they still fall short of human translation. ChatGPT can provide a general understanding of a text, but it struggles with nuances, context, cultural references, and the specialized terminology required for high-quality game localization. For instance, it might misunderstand idiomatic expressions or misinterpret phrases that rely on specific in-game contexts.

Moreover, ChatGPT is known to generate translations that sound fluent but can subtly distort the meaning. This can result in phrases that seem correct at first glance but don’t actually convey the original intent. In a game translation, even minor errors can break immersion or confuse players.

Here's a key point: ChatGPT does not inherently understand context. It relies on patterns in the data it has been trained on, not real-world comprehension or experience. Imagine your game’s storyline being thrown off balance because a key phrase was translated in a way that sounded nice but missed the mark.

Relying solely on ChatGPT for translation is a risky shortcut. While it may save you some time upfront, the long-term damage to your game's reputation and player experience can be costly. Instead, use ChatGPT as a supplementary tool, not a substitute for the expertise of a professional human translator.

Good luck!

Loek van Kooten
Your English/Japanese-Dutch game translator

"The biggest mistake you can make is crossing the localization bridge when you come to it. Prepare yourself."