Aspiring game translator Fabio D. contacted me and asked me to explain the different steps in a typical game localization project. As usual, there are many ways to getting a game translated, but what follows is a more or less standard procedure.

Project offer

No project starts without someone making the first step and throwing the possibility of a collaboration out there.

It could be you who has sent cold-messages to a game developer or project manager and managed to get their attention. Though it could also be the prospective client who contacts you with basic information about the game, such as the genre and how many words the game has. They might even send you the game files to look at, a Steam key to try out the game, or a link to a YouTube video to get a glance of what you’re getting into.

They will ask you whether you are available for a project like this, when you could deliver the localization of their game, and how much you charge. Although instead of asking you what you can offer them, they might just tell you right away what budget and deadline they have in mind.

The quote

A quote is a price estimate for your project. This is the scary part where we talk numbers, and the part where your project might be over before it has even started. Quoting too low might be just as much of a turn-off as quoting too high.
The quote should contain at least the final price, though I also like to include the option of additional services, such as proofreading by another translator, or a couple of hours of game testing. I think that sending a quote as a PDF looks a tad more professional than sending numbers directly in the email, but sometimes you may have to act extra fast.

To know what to put in your quote, you review and evaluate all the information as carefully as possible. I strongly recommend to look through the text to see how
a) well it is written
b) difficult or complicated it seems.

You should also check out the game or game website to see if the game is your cup of tea—if you know you’re just not good with shooting games, then perhaps you should pass on this one.

Do your calculations: Do you have enough time to finish the translation on time, including an extra buffer for things that might go wrong (computer failure, sick cat etc.)? How much do you have to charge to make it worth your time?
You can respond with as many more questions as you like, but once you have all the details you need, you should send the quote to your prospective client—which should happen as early as possible, but definitely within a day.

Negotiations and acceptance of project

Both your client and you might choose to not collaborate for a number of reasons: perhaps the price was not right, the deadline stress-inducing, or you simply weren’t the right fit for this particular project. You guys might also write back and forth for a while, negotiating about price or deadline
However, if both of you accept the terms, you got yourself a project.

Receiving the localization kit

The localization kit (often called loc kit or lockit) is the “package” your client sends you which should contain everything you need to complete your project.
In order to translate a game, you need at least a game file which you will receive from your client. The most common file formats I receive for game translations are .xls and .txt though I do receive the occasional .docx file, and once in a blue moon I even get asked to translate directly in the developer’s software.

Apart from the files to be translated, you never know exactly what you’ll find in a localization kit. A loc kit might contain the following:

• The textfiles

• A game build

• Character info/Style guide

• Screenshots

• Links to online resources

• A link to a shared Q&A document

• Previously translated files

• Glossary

• Additional information and instructions

Preparing the project

Create a project folder where you store all the information related to the translation project.

Importing your textfiles into your CAT tool

CAT is short for computer-assisted translation, and it’s basically a software that remembers your work, and thereby helps you produce a translation of higher speed and quality. You can even reuse previous translations or glossaries from similar projects. It’s also a much nicer environment to translate in than an Excel file. I used to find getting used to this software too daunting for a while, but I couldn’t imagine translating without it anymore. It’s definitely worth the investment. If you don’t use a CAT tool to translate the game text, you skip this step and open your textfile.

Familiarization

At this early stage of the project—which could also happen before you receive the textfiles—you familiarize yourself with the game by thoroughly looking through all the information you have received with your loc kit, by playing the game, and by reading the textfiles, . Be sure to go through the files thoroughly as this will make your translation work much easier.

Did the client give you a character limitation or a list of forbidden characters? Observe how the textfiles are structured: does text appear by level, character, or in an illogical order? When you play the game, pay close attention to the style of the game and if some UI (user interface) text translations might be too small for the textbox (and would therefore cause a text overflow bug).
I don’t recommend skipping the familiarization step since it will only cause more trouble later on.

Translation and Q&A

What now comes is the part your client thinks is what they pay you for: translating the game. Translate every segment or line of your textfile. If you translate directly in the file, make sure you don’t accidentally forget a line.

Whenever you stumble upon something you’re not sure about, play it safe and put a question in the Q&A (questions and answers) file, which is usually sent as a link to a shared Google Sheet these days. Use and implement the answers from the Q&A right away or save them for editing or proofreading—whatever works for you.

Editing

The terms editing and proofreading are often used interchangeably, though editing is a much heavier rewriting process than proofreading. At this point I might make drastic text changes and check my translation against the source text. I might also rewrite or shorten sentences while being on the lookout for possible inconsistencies and broken tags.

Proofreading

Then comes the proofreading in which I polish the my translation and eliminate misspellings. If time allows, I do another round of proofreading before running an automated spellcheck—because the machine beats me almost every time.

Sending out the files

Once no text changes are in sight anymore—or sometimes in regular increments agreed on before—I export the translated files from my CAT tool and send them my client’s way.

Testing

After the developer has implemented the game text and made the game build available, your translation can be viewed in the game. They will usually tell you right away if something went horribly wrong, for example if you have altered the code or used characters the game doesn’t support.

Even if my client hasn’t booked me for game testing, I like to spend at least a little bit of time to look through the UI (user interface) to make sure there are no text overflows or mistranslations in the game menu.

Whatever I can fix by myself, I change in my file and resend it to my client once I am done. Otherwise I send them questions (e.g. Could you enlarge this textbox? or The German character “ß” looks odd—could you use another font?) Once I have done what I can, I resend the modified file which the client will then reimplement.

Bigger developers tend to have the testing done by a professional testing team (kudos to them), though indie devs can rarely afford this and rely on their native fans or generous localizers.

Post-mortem

When the project is officially finished, I ask my client for feedback. Were they happy with my services? Was there anything I could have done better? I also ask them to send any important player feedback my way and give me the chance to fix my errors in case there should be any.

If they were happy with my translation services, I ask them whether they would mind writing me a testimonial, for either my website, LinkedIn, or ProZ account. While some are understandably too busy or simply not interested in handing out favors, most of them are happy to help a translator out. This is also a good time to remind them to add you to the game credits in case they previously forgot you, and to ask them to refer you to their colleagues with translation needs.

Invoicing

After the project is done, (sometimes in-between for longer projects), it is time to send your invoice and be paid at whatever terms you have agreed on during your negotiations.

Game launch

Once the game has been launched, I like to check in to see whether my translation looks all right in the store text. Steam, for instance, has a text limitation for the short descriptions. In case I find it cut off, I let the client know right away, with a shortened version of that text attached. For translations with direct clients, you can proudly add the game to your portfolio. Congratulations!

As final word, unless you have signed an NDA (non-disclosure agreement), help your client out by doing a bit of publicity for their game. Share it on social media or tell your friends about it. Indie developers don’t have the budget for a big marketing campaign to stand out in the vortexes of Apple Store and Steam, and what they just paid you might be a small fortune to them, so throw them a bone by spreading the word, just a bit.

Sharing is caring <3