Working in localization can make you scream. Sometimes it’s a scream of joy, others of horror. One of our project managers at Allcorrect is here to share his experience and talk about some of the job’s key aspects.
If you want your game to be a hit, you’re going to have to invest heavily into it or get very lucky. The gameplay has to be fun, the plot has to be engaging, progress needs to keep you interested, and the bugs need to be out of sight or at least not critical. Quality games take off with potentially exponential growth. But there’s one thing that can negate all your hard work. Terrible localization. Even a masterpiece can get lost in the shuffle when you have an onslaught of new projects, one of which gets a series of negative reviews after launch. And those reviews might only be there because of the poor impression the players had of the localization.
While machine translation is one answer to this problem, it is often less a solution and more a new set of problems. What is a machine going to do when even humans don’t always understand the context right away?
Let’s take the word “bark.” Is it the sound a dog makes or the outer skin of a tree? Do you see the problem? There’s no way of telling unless you can see the context.
No matter how experienced the translator is, their chances of guessing where a particular line goes in a game is directly correlated to the number of meanings the word has. Beginner linguists may come up with fantastic translations, though they still won’t hold up under quality checks since they were done in an XLSX file—the lockit (the file with the text for localization) structure isn’t available, so all those rough edges can’t be smoothed down.
So, what’s a developer to do if they don’t want their game to flop? Come talk to us, of course. It’s not exactly rocket science. Take the text, translate it, stick it into the game, and profit. But it’s not that simple.
Here’s how a new project always forms up in the project manager’s head:
Let’s start with this: there are a thousand and one CAT tools (computer-assisted translation tools; nothing to do with felines) that make that localization life simpler. But only three of them are worth using. As they need their own article, let’s go back to the project manager’s thought process.
Schedule
The basics. The foundation. The fundamentals.
No long-term project can get off the ground without this (unless it’s over the edge of a cliff). And keeping everything in your head can be great, though it’s not the best idea. The best-case scenario is the project manager burning out. The worst-case scenario is missing deadlines and causing problems for the client.
The schedule should be easy on the eyes. Like a stock picture of sushi. Of course, a thousand things could go wrong: a dishonest produce supplier, a tired chef, a clumsy delivery person. But when you see the picture, you imagine perfect sushi just one click away.
Buy
The schedule should look like that stock picture. And if you want to see progress made every day, every check should be in place—even the head editor’s husband’s sister’s birthday should be there. Reality will rear its ugly head at some point, but we’ll work around that later.
Here’s what needs to be tracked on a daily basis:
How many words have been translated? How many words have been edited? What kind of interim feedback have the linguists gotten? Is the glossary filling up? Are all requirements being met? Are the translations consistent? Is the team asking questions? Is the client answering those questions? Are corrections being made?
The project manager should have an answer for each of those questions. If anyone is falling behind, they need to be contacted to find out if everything is okay. If there’s a problem, they need to be replaced. If the translation quality is six out of ten, a replacement would again be a good idea. Empty glossaries lead to inconsistencies.
Dark Tower and Tower of Darkness aren’t the same thing when we’re talking about game locations. And that’s a pretty innocent example. It’s worse when a French player shoots up (tirer) the door instead of just pulling it open (tirer).
Context is important to translations, and questions are how you get it. A lot of questions asked all the time. Just like in the rest of life. If nobody’s asking questions, the localization is no good. Constantly reminding translators about that or going through the translation yourself to find those problem spots is absolutely essential. And don’t forget to make sure the client knows you’ll need time to update the translation after getting feedback from them. Obviously, the changes should be made across all language pairs.
PTA
This refers to pre-translation analysis.
Tossing the files at your translators and forgetting about them (files and translators alike) may sound tempting, but that’s a good way to lose clients.
What kind of file is it? How is it structured? Do each of the strings have the context listed? How is the text quality? Are there any phrases split into multiple strings? What code artifacts are built into the text? Are there variables? What do the variables stand in for? Will the variables break grammatical rules in the target language? Are there location-specific jokes in the text? What about Easter eggs? How do the characters speak? How do they address each other? Are they formal or informal? How informal are they?
When the client says they don’t have time
And that’s not to mention the different types of punctuation, capitalization, formatting, and so on. They’re better saved for clients who are personally invested in the quality of every string. While there aren’t many of them, their pedantry saves everyone time and money.
The number of questions the project manager asks is directly proportional to the number of problems they’ve had to work through in the past. Everyone feels better when you can ask them before the translation gets started—the clock hasn’t started ticking down to the deadline.
Deals {0} points of damage and apply root.
Inflige {0} points de dégâts et applique enracinement.
Inflige {0} points de dégâts et immobilise.
You can go with the first option. Or the second. But the best choice is to point out the grammatical error in the original and suggest shortening “points of damage” to “DMG” since the string length is going to stretch the interface to the breaking point. The maximum string length is a resource that is always in short supply. Any time you’re able to shorten a string without losing anything, a developer somewhere cries for joy. Saving them the trouble of figuring out abbreviations while also saving a little money on LQA (localization quality assurance) gets you a nice little karma bump.
You can also earn some trust from your client if you let them know ahead of time that using words as variables instead of numbers is risky. Imagine a game with a nonlinear storyline and a variety of characters.
{1} is ready to help you.
{1} est prêt/prête à t’aider/vous aider.
Show that phrase to a translator working in any European language, and their stomach will turn. Who does {1} stand in for? How many of them are there? He, her, it, they? And that’s not to mention things like “me” and “you” that also need to match the subject and predicate in most languages. Variables like that need to be hunted down and exterminated, though the client doesn’t always understand why.
Next time you see a phrase like Vague terminés or Forteresse repéré, remember that you’re not being sabotaged by the translator. The original phrase just looked something like {1} completed or {1} spotted. Worse still, it might have been two separate lines: Wave and completed or Fortress and spotted. Skipping the PTA and not asking or answering questions is a problem.
Sample translation
Just a taste. This isn’t a test task.
There’s no better cushion for a project manager than timely feedback from the client. Showing them the first few hundred strings and asking if the team is on the right track can save {0} man-hours when it comes to large-scale revisions of the text.
You have completed the quest. Your reward awaits you!
Tu as terminé la quête ! Ta récompense t’attend !
Pretty straightforward line. Nice translation. Nothing could go wrong.
Wait a second. Why is the player being referred to as tu instead of vous? And aren’t you overdoing it with the exclamation points? REDO.
The client drops their bomb, though the shock wave hits just a hundred strings rather than a full thousand.
Translation slices
These are lockit segments distributed between translators.
If you want to trip yourself up, one good way is to just blindly share files between translators. Let’s say the client did you a favor by compiling all the strings into a single XLSX file instead of sending you a thousand smaller files. You simply divide the file evenly between five translators. A week later, you notice that one character starts out talking like a ten-year-old only to transition to a trained public speaker and finish almost unintelligibly. The result isn’t great (unless you’re localizing Flowers for Algernon, of course). And your editors have a long, difficult road ahead of them. It would have been much easier if each character had been assigned to a single translator.
Achieve 10 victories, unlock the achievement Slayer.
Get 20 likes, unlock the achievement Famous.
Complete the secret cow level, unlock the achievement Massacre.
Imagine that those three strings are scattered around the file, though the context (the short string description) lets us filter them, say, by the word “achievement.” But you just split the file up at random. You might come up with something like this:
Remportez 10 victoires, débloquez le succès Pourfendeur.
Obtenez 20 J’aime, débloquez l’exploit « Célèbre ».
Terminez le niveau de la vache secrète, débloquez le trophée “Massacre”
Just estimate how much time the editor will be spending to make the text consistent. The noun, quotation marks, and punctuation are all different.
An editor for a project with lots of translators
Of course, I’m exaggerating with these examples. You can’t always filter files by context (often times, there’s no context to filter by). Translators can interact with each other to minimize what the editor has to deal with. When it comes to phrases as common as “unlock achievement,” they can easily be found in the translation memory (the database all project translations are saved to), and good translators never skip them. The correct quotation marks are probably included in the project styleguide.
Still, you can avoid all those problems by running through the files before splitting them up between your linguists.
Styleguide
The Talmud of localization.
How can you check texts if you don’t speak the language? Why pay you to translate if neither you nor the client know it?
But we do know the language. At least, we do thanks to detailed requirements that we write out.
Is the translator unsure how the different characters address each other? We put together an interaction table. Formal in one case, informal in another, and plural when we’re referring to the prince.
Not sure if you should use the imperative or the infinitive? We’ll ask and add the answer to the requirements.
Not sure which quotation marks, apostrophes, and dashes to use? We’ll add sample sentences for each.
Not sure how the characters talk? We’ll ask for context and a short bio.
Yo mate, I ain’t gonna be sittin’ here while you’re showin’ off out there!
Hé, poto, j’vais pas rester les bras croisés pendant que tu te la pètes !
It’s unusual that a character’s speech so clearly shows how they talk. Sometimes, we have to understand the relationship between characters.
You stupid or what? How could you mess up these ingredients?
T’es débile ou quoi ? Comment t’as réussi à te gourer d’ingrédients ?
Everything looks fine at first glance. But if we find out that this is actually a sister talking to a brother she has a good relationship with, we can rein in the rudeness.
Tu es bête ou quoi ? Comment tu as réussi à te tromper d’ingrédients ?
The styleguide should ideally serve as a beacon for linguist and project manager alike. But you often have to adjust it as you get feedback from the client.
The most common way to get feedback is in an XLSX file with strings and mistakes. In a few cases, there was a typo, we missed a variable, or we used the wrong term. There’s no point modifying the requirements based on that, though you can at least compile the most common mistakes and build a checklist for your translators and editors. Something like: “Keep doing what you’re doing, but give these points some special attention.”
Checks
You can’t submit files to the client without checking them.
The first thing project managers need to master is how to run a spellcheck across all languages. But why do we have to say something so obvious? MS Word enjoys finding mistakes where there are none (we call them “invalid alerts”). If we just send our linguists a long list of lines to check when there really aren’t any problems, we risk turning into the boy who cried wolf and scaring them off.
When the project manager asks about the space before an exclamation point in French for the fifth time
If you trust your intuition, you risk missing a valid alert (an actual mistake). It’s a hundred hours of spellchecking that tells you where that happy medium is. At least.
Remember that we translate from English into any other language. Telling the difference between valid and invalid alerts in German or Turkish is no piece of cake. And it’s even harder when we’re faced with Arabic, Hindi, or another Asian language.
The second point is QA (quality assurance). Happily, all CAT tools have built-in QA. But getting them set up correctly is an art form in itself. Running the files through them can be a challenge too. That’s when the human factor can play a role. Be that human a linguist or a project manager. Missing a term or variable in a chunk of 50,000 words is a minor annoyance. Missing twenty terms is catastrophic.
The third thing is checking against special requirements. We use macros, third-party Xbench programs, highlighted XLSX cells, or a Google Doc… And then we make sure the files are synchronized on the client side—there’s nothing worse for a project manager than to thoroughly check a file that never reaches the client.
Wrapping up
Why might all this be interesting?
We’ve only covered some of the balls project managers have to keep up in the air. If we break them down into percentages, we might come up with something like this:
15%—communicating with the client. Calling, asking questions, writing out large blocks of text, asking questions, getting feedback, and asking questions.
30%—working with files. Analyzing, processing, checking, and submitting.
30%—communicating with linguists. Explaining the job, negotiating, calculating expenses, exchanging memes, and checking their work.
25%—internal team meetings. Discussing problems, proposing solutions, and implementing new processes.
The best part of the job is that every day is different. You never know where you’re going to spend more or less time. As each day goes by, you’re forced to adapt to new realities, keep your schedule flexible, and work around your clients, linguists, and teammates. And no two project managers are the same, of course. Even if two of them perform at the same level, they’ll each have their own approach. That approach will also grow and transform a little after every project they complete.
