How to Localize a Video Game: A Step-by-Step Workflow

I thought I’d share my general workflow for a game translation project. Apart from character counts, timeframe, and the business side of things, this is how I typically set up my projects. I’ll cover the core working processes here and save the business side of projects for another post.

Initial Research

Beyond the character and repetition counts, it’s essential to first know what platforms this game will be published on, what the theme is, and what kind of game this is. It sounds pretty obvious, but it’s valuable to get as much information about the game as possible to make the next steps of the localization process smoother. You may already know what elements a “dark themed hack and slash ARPG” might include, but there may be special features or layers of gameplay meta that you’re unaware of. This is the perfect opportunity to familiarize yourself, because the further you get into the project, the harder it will be to correct mistakes or misunderstandings. So ask the developer or publisher:

• Can I play this game now?
• Do you have a presskit I can look at?
• Is there a player guide I can use to familiarize myself with this game?

Making a Style Guide

Now that you know enough about the game, it’s time to make a style guide that either you or other linguists can follow. If the developer has already provided you with a style guide, great. Now is the time to read through that guide, ask questions, and clarify their goals and requirements before the heavy lifting begins. If no guide was given, you should still make one, even if you’re the only one translating. Creating a style guide is a conscious process that can help answer questions to “niche cases” early, helping to ensure a more consistent translation.

What’s Included in a Style Guide?

This can get a bit subjective. Some developers will provide you with a lengthy, detailed style guide while other developers may give you nothing at all. While there are no hard rules about what must be in a style guide, it’s safer to establish the standards in as much detail as possible. The more translators you have working on a project, the more helpful a detailed style guide will be to promote greater consistency across translations.

1. Voice and tone: Is this game light-hearted and casual? Is it gritty, grim, and serious? Should slang be used? Is cursing allowed?
2. Character voice: Should certain characters be portrayed in a specific way? Is the blacksmith a burly, tough dwarf or a svelte Night Elf with a knack for forging?
3. How are abbreviations handled? Is damage DMG?
4. Cultural Sensitivity and Relevance: Can you make jokes? Are there any words or references that would be taboo?
5. Formatting: How should dates appear in game? dd/mm/yyyy? mm/dd?
6. Units/Currencies: Should we automatically translate yuan into dollar? Do we use metric or imperial?

Building the Termbase

I start by doing a manual skim of the entire language pack. If the developer has included context/key columns, I will first note character names, location names, skills, and key game features. If context/key columns aren’t provided, you can add your own while scouting out potential terms for the termbase.
After you have selected your terms, translate them and share the termbase with the client. They may have opinions about how key character names or mechanics are translated. This is not a trivial step. The developer might point out, for example, that they don’t like 公会 translated as “Guild” because this is a strategy game set in space. Imagine you have already translated half of the game when this problem is discovered. Now you need to go back and change Guild, Guild Wars, Guild Council, Guild Leader, etc. There could be hundreds or thousands of segments that you need to correct.

What Should a Termbase Include?

The size and extent of the termbase can vary by developer or translator preference. Some translators like to keep a smaller list of terms, while others will make much larger lists. I’ve seen some termbases that were so large they actually caused more confusion than they prevented, but I think it’s generally better to have too many terms compared with too few terms. A typical termbase for a video game usually includes:

1. Core game terms for: Menus, UI, game modes, key mechanics
2. Names for NPCs, main characters, monsters, mobs, and bosses
3. “Map Stuff” like towns, rivers, mountains, countries, etc.
4. Factions, teams, countries, empires, etc.
5. Gear or armor sets, weapons, potions, elixirs, etc.
6. In-game currencies and resources

Translate the Game

This is where all of the previous work pays off. If you understand the game, have a detailed style guide, and worked with the developer on the termbase, this part of the job should be a little bit easier. So start translating. And ask questions early. Again, the earlier you discover and resolve questions/conflicts within the project, the smoother the process will be. During this time, I will usually log all questions I have and submit them by the end of that day. Which leads me to this suggestion: Establish and normalize communication with the client. In some ways, it’s a natural human tendency to shift the burden of initiating communication to the other side. Some people do this to gain a bit of plausible deniability for their own protection or laziness.

“What? You don’t like how I just translated those five-thousand lines of dialog? Well you should have told me earlier!”

When you proactively communicate with other translators, the client, etc. you can iron out issues right when they appear, and you can establish a better “working rapport” with them. You’ve been translating in silence for three weeks, but now you’re telling them you can’t make the deadline? Maybe another translator could have taken a bit of your workload… or maybe the developer would have told you not to sweat it because the game’s launch has been delayed? You won’t know unless you talk about it.

QA: Round One

Before editing or proofreading, run the game through some QA tools to spot key error patterns. If your CAT tools have QA features baked in, run those tests. If you don’t have such a QA tool, then use a QA tool like Xbench.

One important thing most QA tools check for is consistency in translations. You can either flag these segments for the editor/proofreader, or you can modify these segments before the major editing begins. The editor will have an easier time when the translator has proactively resolved conflicts where there are two different translations for the same source text.

The key reason to run QA before editors and proofreaders see the file is to spot pattern errors so that you can either fix them yourself, or consult other team members about these issues. Another benefit to running QA early is that the editor will then be able to focus more on the linguistic and stylistic aspects of the translation, instead of spending mental energy on basic errors that a QA program could quickly catch.

Editing & Proofreading

Sometimes this is handled by one linguist, and other times it is handled by two or more people. For this stage, I prefer to start with a quick, general sweep of as much of the language pack as I can. During this sweep, I’ll make notes of errors, potential stylistic issues, or any other questions I have. I’ll share this list with the client to get an understanding of:

1. What issues they deem to be most important
2. What issues I thought mattered, but didn’t
   

To illustrate why this matters, consider this example:

One time I was editing a language pack, and I saw that skills were translated like: a. Slash 3 enemies in front of you and inflict 50 dmg to each. b. Slashes 3 enemies in front of you, dealing 50 dmg to each.

I greatly preferred translation B, and thus I proceeded to change every single skill description to this grammatical structure only to find out that the client somehow preferred A over B. I acted on a simple assumption (that the client would prefer B, too), but it easily cost me a few days of my time.

QA: Round Two

Run those QA tools again! After editing and proofreading, the number of issues flagged during this step should be significantly fewer compared with the first round. You’ll still find issues to address. In this stage, most (or all) known issues should be addressed. If minor issues persist, you can document them for play testers to double check using the benefit of full in-game context.

So that about wraps up my process. When localizing tens or hundreds of thousands of words, there will naturally be mistakes. Even the most vigilant of translators make them. The key is to communicate early and often with the developer. Make sure there’s enough time to do a proper job. Make sure you understand each other’s expectations. If you need more context, ask. If you’re skeptical about the timeframe, say it. And don’t get too wound up when mistakes are found by other linguists, game testers, or players themselves. It’s all part of the process, and it is expected in large localization projects!