Setting up a game for localization
Non-technical stuff that needs to be prepared for the translation effort
I’ve been working as a translator from English to Brazilian Portuguese for the video game industry for about 7 years now, and although it’s not that long, I had to deal with a lot of non-technical problems that could’ve been avoided with a little more information and preparation. I mean, there’s a lot of articles and tips on the internet about how to deal with CAT Tools (CAT means “Computer-Assisted Translation”), text extraction, cloud translation and so on, but most times when a translation goes wrong, it isn’t because of a technical issue, so I’ll try to illustrate what are the most common problems translators face and how to avoid (or prepare for) them on the other side.
Please note: I’ll talk about my own experience in the industry, as a freelancer working with translation agencies specialized in video game localization. These are my own thoughts, and I hope they might be helpful for people developing new games. Don’t take them as criticism, but as tips on how to improve and smooth the process if you’re having complaints about the translation quality.
Throughout this article, I’ll talk about “localization” and “translation”. For those that are not familiar with these terms, localization includes marketing for the local consumers, content adaptation for the local market, sometimes assets editing, things that kind of “transpose” the game to make it sellable in another place on the planet.
When I talk about translation, I’m talking about getting the text in Language A and delivering it in Language B, which is part of the localization process mentioned above. Language B is sometimes referred to as “target language”, and Language A is “source language”.
If you don’t understand some terms I use or have questions about a topic or theme related to translation, just leave a comment and I’ll try to answer as soon as possible.
So, let’s start!
The first thing a game developer needs to think about when preparing a text for translation is context. It is the most important piece of information they can give. The way I usually describe my job to other people is like this: imagine you are translating a book while it’s still being written, proofread and edited; you receive bits of chapters out of order, without any idea how everything fits together; you have no contact with the writer, and the book company doesn’t always answer your questions about things you might think are important; since you’re (most likely) working under an NDA (Non-Disclosure Agreement, for those unfamiliar with the term), you can’t ask for help from people that may understand the subject or story, but don’t work in the project; and you don’t have the time to research the subject, because the bit you are translating has to be delivered by tomorrow morning, when the company will send you another bit from another chapter to translate, that may or may not still be edited and retranslated in the future.
Now, I know that there are a lot of moving parts when developing a game, and since everything needs to be ready before launch date (if the developer wants the game to be released with more than one language supported), translators usually work when the game is still in production and very, very incomplete. That’s why context is important.
When the writers are creating dialogues, menus, items and such, it really, really helps if they signal what everything refers to. For example, a line of dialog refers to two people talking? Is it a monologue? Is there more than one character present? Should the character talk in a formal way, or more colloquially? Where is the scene happening? Did the translators have access to an outline of the story and the game’s background? Do they have the liberty to adapt jokes to the local culture? Would it make sense to adapt jokes and references to the local culture?
At this point, it might be clear that a script could be useful, yet it is rarely given. And it is understandable, because one small leak might ruin the whole planned launch. However, it’s hard to deliver quality when people don’t really know what’s going on.
Note this only applies when talking about scenes, story, things that are already set in stone, even if the art and animation departments aren’t working on them yet.
When we walk away from the story part and think about the rest of the game’s text that needs translation, things only get worse, especially when dealing with menus. The most common example I see being used to illustrate the problems translators face is the word “gear”.
Why? Because “gear” might be something like a cog, or it might be a piece of equipment. If the game has a menu or item (or anything, really) called “gear”, and the text to be translated doesn’t give any context about what exactly that is, translators will have no clue about what to put there. They will have to guess, and guessing is always dangerous. The best way to deal with this problem is to prepare images as references or, at least, give a brief description for each item and menu that will be in the game. It might increase the workload a bit, but the pay-off is a product better localized.
And players will complain if things are bad.
So, all in all, what developers can do is to prepare a document (or multiple documents) aiming to give translators as much context as possible, especially if the game is still early in development. And if there’s a script ready, share it with the localization team too. Believe me, it will help a lot.
Another way too common problem we face is gender variation. Specifically, grammatical gender, because, as surprising as it might sound for some people to learn this, English doesn’t have gender variation in its grammar, and most games are made and written by people that are only familiar with English. However, many, many other languages have at least two grammatical genders. A lot of them have a third gender too (neutral), and I sincerely don’t know if there’s any language with more (I wouldn’t doubt it).
So, what is grammatical gender? Basically, it’s a “classification” that defines nouns as masculine, feminine or neutral (depending on the language in question), and “shapes” the rest of the phrase to be consistent with adjectives and verbs. This may sound too abstract for people not used to think about grammar, so I’ll give some examples to illustrate:
- “chair” in Portuguese is “feminine” (“cadeira”), so adjectives, articles, and pronouns related to it must all be of the “feminine gender”;
- “city” in Russian is “masculine” (“город”/“gorod”), so adjectives, articles, and pronouns related to it must all be of the “masculine gender”;
- “subway” in Russian is neutral (“метро”/“metro”), but is “masculine” in Portuguese (“metrô”).
Why does this matter? Two reasons: if the developer sets item adjectives as variables (like “perfect” in “perfect sword”, for example) to reduce workload, at least three variations are necessary: masculine, feminine and neutral; also, gender variation applies to NPCs as well, and that’s where most of the problems come from.
Characters, be they controlled by the player or not, need to be identified by the game engine as male or female, so as to be addressed correctly with the pronouns, articles, and adjectives. It is common now, in English, to use “they” as a neutral pronoun (not only in the plural, but singular too), but it’s impossible to translate that to some other languages. In Portuguese, for example, we need to know if there are one or more characters, and we need to know if they are male, female, all male or all female. But the engine also needs to identify which variation it must use, so it won’t call a group of women by a masculine pronoun, or vice-versa.
It’s way easier to prepare for this before starting production than trying to implement changes retroactively, because this will mess the writers’ workflow during development.
As important as context and gender variation are, they are meaningless if the translators have no space to actually translate. Truth be told, this problem is the bane of mobile games, but it also happens a lot with AAA products, surprisingly. What I’m talking about now is character limitation. Character as in letters, not NPCs, players and such.
Why is this important? Because some languages have longer words than English. Really. And limiting the available space for a longer word might compromise the quality of the translation. Once, for example, I had to translate a mobile game that had a 5-character limitation for the button “START”. The shortest “default” word used in Portuguese for that, “INICIAR”, has 7 characters. In the end, we chose to keep the button in English, and I’m pretty sure most people felt that it made the game feel cheap.
Now, this problem is more common in mobile games because of the screen space limitation. I can understand that many things have to be toned down to fit there, but it’s still possible to use rolling text or expandable interface, when applicable, to avoid compromising quality.
With AAA games we sometimes have a bigger margin, as normally the developer provides us with around 30% of extra space to fit things. However, that’s not always useful. Think about the previous example: 30% more over 5 characters is 6 (rounded down), which is still one less than needed. Some words, like “Wasteland”, take almost two times more space with one of the possible translations in Portuguese (“Terra Devastada”). On a project that I’ve worked, the developers changed the interface 1 year later, so everything in the menus had to be retranslated to fit a new hard limit while the previous interface used rolling text. “Hard limit”, in this case, means the space limit is fixed to a set number of characters instead of a percentage.
The fewer characters translators have to work with, the cheaper the game will feel, given the orthographic inadequacies needed in the target language to make the text fit within the set limits.
Communication is another very important aspect often overlooked. Translators need to know everything relevant to the game that’s going on behind the scenes, or at least need a direct line to make questions and get answers related to the product. The easiest way to do this is by setting up a Q&A (Questions and Answers) form or spreadsheet. Every line that is being translated should have its own unique identification code, so the translators can refer it in the form, ask a relevant question about the said line, and the developers will know exactly what they are talking about, or at least can check things on their end.
It is very important that someone from the dev team, writing team, or really close to development, manages this aspect because, often times, there are projects in which translators ask questions about this line, that scene’s context, or what this new word means, and the answer is “we’ll ask the dev team”, or “I don’t know”. Once, a friend told me she asked something like “is character A talking to character Z here?”, and the answer was “probably”.
That’s counterproductive, and the more time it takes to get a straight answer, the more text will need to be corrected in the future. Sometimes it takes so long to get an actual answer that games are almost shipped with avoidable errors.
So, someone familiar with the project should always be in contact with the localization team and managing text batches (the “packets of text”) being sent and received.
Another very overlooked aspect, often based on misinformation, is the time management for the localization effort. There’s a running joke in the translation community about clients asking for a 10-page document to be translated in one afternoon. “It’s way too much, I need at least one full day, probably more”, the translator says, to which the client responds “But everything is already written, you just have to translate!”.
People outside the industry usually think that translation is a quick job, something that doesn’t require a lot of time or effort, so they ask for rushed jobs and then complain about poor quality. This video is a great example of why it’s important to give some breathing room, even though translators work with words, not drawings.
It is said that the optimal volume of work that can be translated into Brazilian Portuguese, in one day, is around 3,000 words, maybe a little more. I tend to believe this is true for every other language, all the more when localizing games, since people often “waste time” checking references, checking terminology, looking for answers in Q&A and so on. Since developing a game involves a lot of moving parts, it is important to have a translation timeline that doesn’t get in the way of the game’s own production pipeline and allow for quality work to be done.
Think this way: if the company sends a translation request of 5,000 words on a Friday afternoon and wants the job done by Monday morning, they will have trouble finding good professionals willing to work without getting paid an “urgency fee” (basically an extra fee paid for urgent work, overwork, or to work on weekends/holidays). However, if the job request is sent Thursday afternoon, it becomes more doable. It’s important to always have room for some extra time because nothing ever goes as expected.
This is also important when preparing the workload for the translation team because the project manager has to think about fuzzies. For those who don’t work in the area, fuzzy is when the CAT Tool analyzes a line, checks it against the database prepared for the project (called TM, short for Translation Memory, that fills automatically as things get translated), and tries to match what it finds, ranging from 0% (no match) to 101% (full match with surrounding lines also matching up). Translators get paid in full, per line, usually only when the matches are between 0% and 50%, and every new threshold subtracts payment up until 100%, when the line isn’t paid. Bear in mind that payment per match changes from agency to agency, company to company, so don’t take this example as a rule.
On the financial side, this is great news, because the longer the project goes, the more chances it has to have matches in the TM and the lower the company has to pay. However, this is decremental to quality, because the higher the match (and lesser the pay) in a line, the less attention the translator will give to it. Why? Because when I said the optimal volume of work is 3,000 words, it meant 3,000 “new” words, which means lines with less than 50%-match in the TM. So if a translator gets a job with a total word count around 5,000 words to translate in a day, it might have only 2,500 new words (the total of unmatched lines in the TM), which will be prioritized. The rest will be dealt with as time allows, and that’s dangerous because of the false positives.
Here’s a practical example of what I mean by “false positives”: imagine the project has the line “They are beautiful” to be translated to Portuguese. Without any context, this has four possible variations: masculine singular, feminine singular, masculine plural, feminine plural. It might refer to people or objects, but fortunately, this is irrelevant in Portuguese. If the line is about flowers, then it’ll have to be translated to feminine plural (because “flower” is a feminine noun in Portuguese). However, if the line is used again to talk about cars, it will have a match of 100%, but it will require to be edited in Portuguese and changed to masculine plural (because “car” is a masculine noun). However, the translator might overlook this line since it has a high match (and pays less) and focus on lines with lower matches (that pay more). It’s basically like giving 5,000 words to translate, but only time to work with 2,500. If the reviewer doesn’t catch the overlooked error, the game might be shipped with it, and that’s obviously bad.
(To talk about reviewers would require another whole post, because they deal with a lot of “collateral damage” stemming from bad or misinformed practices.)
That’s why time management is important. Time is intrinsically linked with money, and we usually want to minimize pay in exchange for the maximum work time possible. This often backfires when quality is expected. In the previous example (“They are beautiful”), if the line was referring to people instead of objects, then each of the four variations (masculine singular, feminine singular, masculine plural, feminine plural) might be used at some point. Without proper time to check context and translate carefully, it would certainly end in disaster. Now imagine this situation 100 or 200 times throughout a whole day, sometimes even more. It’s something easy to deal with, but not that quick if it’s frequent.
Most of what I talked about involves small problems that, on their own, might be quick to solve, but when they aggregate on top of each other, things start to get complicated, and they can’t always be solved on the translator’s side. The whole localization project suffers, and it’s harder to implement changes retroactively than to implement good practice from the start and follow it through. Misinformation, or just the lack of information, usually plays a large role in this, so I hope the text was informative.
In the end, most issues are just avoidable problems that can be solved when planning ahead while looking for a good balance between productivity and quality, given the developer’s own limitation.