How to Ensure Effective Language Management in AAA Video Games

Large projects, such as AAA games, are complex beasts with a lot of moving parts, which also trickles down to the localization aspect. While the concept of translating words might seem simple, guaranteeing it will be translated at the highest quality possible is no easy task and involves the effort of multiple people.

It is a complex endeavor - especially when it involves hundreds of thousands, or even millions of words - but not necessarily hard, it all just depends on how well-prepared everyone is to spin into action.

With so many things going on at the same time, there is plenty to talk about, but I’ll focus on practices that can help smooth the process a bit, such as:

• Starting the localization as early as possible
• Sharing as much information and assets as possible with the localization team
• Having a well-structured timeframe, but being fluid with the planning as the project progresses
• Having a well-structured hierarchy of roles, but being careful with power dynamics and responsibilities
• Having open communication and encouraging people to participate in creative debates
• Being aware of the common pitfalls that might hinder quality

With that in mind, let’s take it from the top and explore each topic in detail so we can understand why such a specific focus.

As long as the writing in the source language has progressed enough and it won’t need too much editing anymore, there are numerous advantages to starting the localization early, such as:

• Better deadlines
• More time to refine tone and style
• More time to ask questions and get answers
• Time to revisit and change stuff if required
• More time to try new ideas before the text is locked

As we can see, this is mostly a time-related advantage. Translation does take time, so having an excess of it is a positive thing, as it allows the team to acclimate to the project and refine their work in practice. If things need to be moved around or updated, they won’t impact quality as much as they would if the localization were to start in a later stage of development.

A well-informed team is a powerful one. This cannot be overstated enough: share everything you can with the localization team, from briefs to concept art to roadmaps to story summaries to character descriptions. The more information, the better, and here’s why:

• The localization team must be aware of the producer’s or director’s vision
• In the early stages of development, there won’t be visual references, so more information now means less translation-editing later
• Relevant questions are better asked early on
• Tone and style must be defined and set in stone as soon as possible to avoid lengthy and late edits
• Terminology must be agreed upon early to avoid inconsistencies later

Each project is unique. Rarely something defined for one job can be copy-pasted into another, so having information and defining as much of the project as possible in the early stages of localization helps keep the project running smoothly.

A practical example here would be the glossary: with a list of important terms that will be used throughout the game, translators can agree on what to use early on, fill up the Term Base on the CAT Tool, and not have to worry about inconsistency when everyone is already hundreds of thousands of words deep into the woods.

Rigidity is the enemy of perfection. What I mean by that is to have a general schedule to follow for the localization, maybe with milestones along the way, but be prepared to push and move dates around as things progress.

It seems strange to think this way when pressed for time, but everything flows better when there is some extra time to deal with unforeseen events or unexpected additions during localization. There are many advantages to taking this approach, including:

• Dealing with time zones, which ensures people in different parts of the world have time to respond and react to project demands
• Working around the translators’ availability, as they might have their schedule partially filled already, so some extra time comes in handy
• Dealing with catastrophic issues, such as people getting sick, files getting corrupted, and so on
• More time for editing the translation after having questions answered without having to reopen old batches

Humans are not machines, so they shouldn’t be treated with the same production rigidity, especially in a humanistic field like localization.

Accounting for extra time to deal with issues, mistakes, and unforeseen challenges actually helps keep the quality high while avoiding delays and the typical problems caused by unmovable deadlines.

Localization is a team effort. Each person has their own part to fulfill and no one can be actually considered above or below any other. It’s always important to keep this in mind to avoid developing toxic power dynamics or making people responsible for things out of their scope.

The typical division of roles in any given project includes a:

• Translator: the person who will actually type the source text into the target language
• Reviewer, sometimes also calledproofreaderoreditor: the person who will double-check the translator’s work and fix the mistakes that got through
• Language manager: a hyper-focused project manager, working only with their own native language
• Project manager: a manager who oversees multilingual projects
• LQA specialist: the only person who will see the translation in the game before release

The translator is the one getting the job done, and the reviewer will double-check to spot and fix issues. They should work in tandem and be encouraged to chat and give each other feedback.

The language manager is a more obscure role, but works partly like a project manager, and partly like a translator or reviewer: they do scheduling, planning, and write guidelines and other documentation, but are also directly invested in the translation effort, more often than not taking part in the translation or reviewing process. Sometimes they are also called language lead.

The project manager is usually the point of contact between the developers or publisher and the translation team. It’s not unusual for them to manage multiple languages at the same time, even if they don’t speak or aren’t fluent in them, as they rarely deal with the text itself.

The LQA Specialist is the last on the chain, and they will be the only person to see the translated text in context, within a game. It’s an important job, and the last chance to catch issues before release.

As stated before, none of these roles are above or below each other. The hierarchy here exists only from an organizational point of view, but each one has its own part to play and the localization effort will never be fully realized if one or the other is missing.

People involved in the localization effort should be able to freely talk to each other and debate about the project without the fear of being reprimanded. Fostering open and honest discussions about issues, debating linguistic solutions, and keeping the whole team informed on whatever’s going on can only be beneficial in the long run.

What I usually see with this approach is:

• People are more invested in the project
• Issues are found and dealt with before they balloon out of control
• Creativity flows better on an open floor
• Morale is boosted
• Feedback happens more frequently, raising the quality and aligning the team

In short: trust that people know what they are doing and treat them with respect and professionalism. Let them talk with each other and debate solutions to the problems they are facing, and avoid gatekeeping information that could help them organize themselves.

Last but not least, there are some other typical issues that pop up in almost every project, so it’s important to know what they are and to tackle them as soon as possible. Some of the most important things to keep an eye on are:

• The Term Base, or Glossary
• The Translation Memory
• Style guides
• An organized source file
• Avoiding micromanaging the team

For starters, the project should begin with a list of important terms to be translated, and this list should be filled and expanded as the project progresses. The earlier this is done, the better it is to keep everything consistent.

The Translation Memory should be as clean as possible, meaning that old lines that aren’t used anymore or were updated should be removed to avoid polluting the results, something very common in larger projects.

The style guides are also very important here to keep everything consistent. They should be an easy resource for the translators to access, and the more detailed and informative they are, the better.

Having a well-organized source file also helps a lot. This means that strings of the same type should be banded together - like weapon names or item descriptions, for example - as it helps the translators place them contextually in the game. Dialogues, on the other hand, work better if they are organized following the flow of conversation between characters.

And finally, micromanaging should be avoided. Let people do what they have to do on their own and, as long as there’s a healthy dosage of communication and constant feedback, no micromanaging will ever be needed.

Most of the high-quality localization projects I was involved in - whether as a translator or manager - followed the practices above. In one of them where I was co-manager, while dealing with a terminology list the client sent to us, the translators were working on the terms they would find in the files that were not included in our list, and then talk among themselves to find a good solution.

Sometimes we would veto it for finding a bit out of scope or out of context with the project but, in turn, the translators sometimes would suggest something better than we already had. We had transparency and space for creativity and, despite some unpredictable setbacks here and there, everything was always delivered on time.

In another project where I worked as a translator, there were open talks about etymology so we could make natural-sounding neologisms in our target language. We had freedom, time, and space to explore our creativity.

The result was so good that people adopted our terminology without ever considering what they looked like in the source language: it read as if it was originally written in Portuguese instead of English.

Effective management of an AAA project requires "trusting the process", meaning that one should never doubt what the team is capable of, and planning should have leeway to deal with unforeseen issues that might happen, whether on the technical or the creative side. Making people comfortable enough to ask questions, brainstorm ideas, or suggest new terms is also very positive.

While the project and language managers seem like central figures in all of this, their role is actually to support the translators so that they are as little distracted as possible from the translation itself. It is essential that translators and reviewers can focus on doing their thing and not have to worry about other duties.

And last but not least, management should be fluid, not strict. No one can predict every situation or problem that might arise, so it's important to have backup plans or time to maneuver around issues no one considered before. Strict planning never works because we are all humans, doing jobs that only humans can, so it's important to always be sympathetic with our colleagues. This is something always worth remembering.