Non-technical stuff to be aware of
Note: this was originally published in 2019 on Medium. It has been now reviewed and updated to be posted here.
I’ve been working as a translator from English to Brazilian Portuguese for the video game industry for 12 years now, and I had to deal with a lot of non-technical problems that could’ve been avoided with a little more information and preparation. There are a lot of articles and tips on the internet about how to deal with CAT Tools (Computer-Assisted Translation Tools), text extraction, cloud translation, and so on, but most times when a translation goes wrong, it isn’t due to 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. These are my own thoughts, and I hope they might be helpful for other people. Don’t take them at face value, but as tips on what to be aware of.
In this article, I’ll talk about “localization” and “translation”. For those unfamiliar with these terms, localization includes marketing for the local consumers, content adaptation for the local market, sometimes assets editing, and 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 usually referred to as the “target language”, and Language A is the “source language”.
Since localization and translation coexist in this field, both terms can be used interchangeably.
So, let’s start!
Context
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 about 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), you can’t ask for help from people who 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 the 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, does a line of dialog refer 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? Can they 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 announcement or launch. However, it’s hard to deliver quality when people don’t know what’s going on.
Note this only applies when talking about scenes, stories, or 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 and think about the rest of the game that needs translation, things 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 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.
So, all in all, what developers can do is prepare a document (or multiple documents) aiming to give translators as much context and information 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.
Grammar
Another way too common problem we face is gender variation. Specifically, grammatical gender because, while English doesn’t have gender variation in its grammar – and a lot of games are made and written by people who are only familiar with English – 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 (but I wouldn’t doubt it).
So, what is grammatical gender? It’s a “classification” of sorts that defines words as masculine, feminine, or neutral (depending on the language in question), and “sets” the rest of the phrase, its syntax, to be consistent with adjectives, verbs, and so on. 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, pronouns, and verbs in past tense 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 for most languages: masculine, feminine, and neutral; also, gender variation applies to characters 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 (or neutral, in case they are non-binary), 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 easier to prepare for this before starting production than trying to implement changes retroactively because this will mess up the writers’ workflow during development.
Side note: although Portuguese doesn’t have a neutral gender, there are ways to circumvent the grammar to address non-binary people. It does require to bend the rules a bit, but it’s nothing major or unheard of.
Character limitation
As important as context and gender variation are, they are meaningless if the translators have no space to actually translate. This problem is more common on mobile games, but it also happens a lot with consoles and PC games. What I’m talking about now is character limitation. Character as in, a letter.
Why is this important? Because some languages have longer words than English. 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 available. I can understand that many things have to be toned down to fit there, but it should be considered if it’s possible to use rolling text or an expandable interface, when applicable, to avoid compromising quality.
With AAA games, we sometimes have a bigger margin, usually 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 up almost two times more space with one of the possible translations in Portuguese (“Terra Devastada”). On a project that I worked on, the developers changed the interface 1 year after the release, 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
This is another 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 game. The easiest way to do this is by setting up a Q&A (Questions and Answers) form or spreadsheet. Every line that’s being translated should have its own ID code, so the translators can refer to it in the form while asking the question and the developers will know exactly what they are talking about, or at least know where to check on their end.
It is very important that someone from the dev team, writing team, or close to the development, manages this aspect because, somewhat frequently, there are projects in which translators ask questions about a line, a scene’s context, or what a neologism means, and the answer is “we’ll ask the dev team”, or “I don’t know”. Once, a friend told me she asked “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 fixed in the future. Sometimes it takes so long to get an actual answer that games are almost shipped with avoidable mistakes.
So, ideally, someone familiar with the project should always be in contact with the localization team and manage the text batches being sent and received.
Time
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!”.
Some people outside the industry 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.
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. It might also be true for other languages as well 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 allows 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” (an extra fee paid for urgent work, overwork, or to work on weekends/holidays). However, if the job request is sent on Thursday afternoon, it becomes doable – although not ideal. It’s important to always have room for extra time because nothing ever goes as expected. Tight deadlines and rushed jobs rarely end up well.
Final thoughts
Most of what I talked about involves small problems that, on their own, might be quick to solve, but when they aggregate together, things start to get complicated and 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 of some use.
In the end, most issues are just avoidable problems that can be solved when looking ahead while doing one’s best to have a good balance between productivity and quality, given the limitations each project can have.