I have been a game translator for many years (see my Ask a Pro for more about my experiences). In this post I’d like to share some insight into the process of game localization for translators.
The main responsibilities of a translator are the initial preparation, and the localization itself, including all of the different types of content that need to be translated; so let’s take a look at both of those steps and explore some of the common problems and issues that come up that make game translation different from other projects.
The initial preparation is a really important step, in which you have to carefully check all the texts and information about the game that you’ve starting to work on. Sometimes, along with the files, you also receive additional information about the game, such as details on characters and scenery, a brief summary of the plot, or other production content (artworks, videos, etc.). Obviously, the more information you receive, the easier it will be dealing with these first two steps. At this early stage, you must decide the style that you’ll use for the entire localization process. An example of information that must be considered is the game genre, its main target, its scenery, and the historical period in which it’s set. These are very important, because they help you to learn all about the game, and understand better how to translate it. A style guide allows you to create a set of “rules” for the project, which will include some more creative as well as technical aspects, such as grammar and spelling.
Before preparing a style guide, you have to consider the type of texts that you will face in the project.
Each of these types has some small “traps”, which often arise because you don’t have enough information about the game which you are translating. In fact, you have to consider that most of the time, you don’t have the game and you cannot play it, so you must try to imagine each situation, both carefully analyzing the texts and counting on your own experience as a gamer. And that’s why it’s important to be a gamer or at least a casual gamer, because you can “imagine” the texts in the game without seeing it. You already know how and where the texts will appear in the interface or probably in some tutorial windows, and this will be very helpful for the localization step.
What needs to be translated?
Normally in a game localization project there are three possible types of texts:
– User interface texts
– Descriptive, help and tutorial texts
Starting from the dialogue, first we must distinguish between the dialogues that will be dubbed and the ones that will be only subtitled. In the first case, I think it’s very important to try to localize the texts rather than just translating them. This is true for subtitles too, but obviously in the dubbed lines you have more freedom. In any case, the lines should be as natural as possible, so it is very useful to try to become one with the characters and “feel” the dialogue. In the case of subtitles, the approach may be different but it is equally important to create fluent and natural texts that reflect what the characters are saying. Another important issue is the length of the lines that in both cases must be similar to the original text, to avoid any sync problem. As you can imagine, if a translated subtitle is much longer than the original one, to respect the synch with the original dialogue it will stay on the screen for less time.
There are many issues that can come up, but one of the main problems is when the translator doesn’t know who the characters are in a particular dialogue. It may happen, in fact, that in a given file there is only a series of lines without any indication of the characters involved, and obviously this can lead to several problems. One of the most common ones has to do with the gender of the character, so if the subject is a woman or a man, the text could be different. In these cases, if you cannot get more information, the best rule is to make the text as neutral as possible, so it can fit perfectly for both male and female characters. This is true for languages like Italian.
Sometimes the situation can be even worse… you can have some non-consecutive dialogue lines scattered throughout the whole file, which is not the perfect condition to assure the best quality. In these cases, it’s very important to have good cooperation with the customer to get a better file, or at least more information.
Another pitfall is due to the fact that in English you can use the “you” both for second singular person and second plural person, while in Italian or in other languages like French, they are distinct. Thus, in dialogues where it’s not clear if the character is talking to one or more persons, it may cause problems in the translation. Even in this case, besides requesting further information, your instinct will advise the best strategy. For example, some years ago I was translating the dialogues of a MMORPG (Massive Multiplayer Online Role-Playing Game) without any indication of the characters and knowing that the dialogues would be used both for a single character and for a full party (your group). Considering the fantasy and medieval setting, I decided to use the second plural person, which fit very well because it was common in that historical context, and it was perfect both for a single character and a party.
User Interface Texts
Turning to the user interface texts, the two main aspects to consider are terminology and length.
For terminology, I refer both to the typical gaming terminology (and here it’s very important to have some familiarity with the gaming world) and the one specific for the platforms on which the game will be released. Each hardware manufacturer uses a specific terminology that the translator must follow perfectly and without any mistake. In case of errors, in fact, the text may not pass the approval phase, thus delaying the whole project.
When you translate from English to a language like Italian, you can have some issues with the length of the texts. Normally the grammar rules and the Italian terms tend to greatly lengthen some lines, and usually in games interfaces the space is very limited. A general rule is to avoid abbreviations where possible, but in some cases they will be the only possible choice. Let’s say that you have to look for a perfect balance between readability and understanding, also you must carefully consider the type of game and the target to which it refers. So for example, in a puzzle game dedicated to the most casual players it’s very important to use simple and clear language, with no abbreviations or very specific terminology, which you might be able to use in a more “traditional” game.
Descriptive, help and tutorial texts
About the descriptive or tutorial texts, I’m describing them last but it could be very useful translate them first, because they may reveal more information and details about the game. Here the space constraints are usually less restrictive (often but not always). It’s very important to pay special attention to the specific terminology of the game, which you have already identified in the initial preparation, maybe after doing some research. For example, if you are working on a WWII action game with a lot of historical descriptions of the missions, a literature search will allow you to select the appropriate terminology for the specific historic period and the type of game.
Style Guide & Glossary
After this brief descriptive analysis of the main categories of texts that you will face, you can understand how important the initial preparation is, because it allows you to create a style guide and a glossary.
Once you have defined the type of game, its main scenery and the target to which it is addressed, with the information that you have received or through an analysis of the assets provided, it’s essential to choose the style of our texts. This step is crucial because it allows you to standardize the entire text of the game, ensuring the highest possible consistency. It’s especially essential if there are more translators involved on the project. In fact, on larger projects, you often work in teams and so deciding the style first allows everyone to assure the best consistency, reducing the editing workload and the probability of mistakes.
When we talk about style, we are talking about some basic rules, from the main linguistic choices (such as the use of the third or second person in dialogues to assure a more formal or informal style), to the more grammatical ones (use of parentheses, ellipses, exclamation points, etc.). To clarify the concept, let’s take a simple example: Suppose you have a project with five translators who work on all the parts of the game. If you don’t use the same style rules, you will probably have a final text with two or three different styles. If the final texts are directly delivered to the client as they are, the final result will be very poor. To avoid this situation, you will lose a lot of time with a deep editing. You can save time by creating a good style guide at the start of the project and then adopting it.
The second phase is based on the glossary. Some projects may already have a glossary as reference (it happens often when you are working on a sequel or a new title in a series), while other projects might not have it and so you have to create it. Why is it so important to create a glossary? To ensure maximum consistency throughout the project, or in other words, to make sure every term is always translated in the same way. Obviously, in the case of a new glossary, its creation will continue during the localization and here a CAT tool could be very useful, with its translation memory features. Assuring the best consistency is not only for aesthetic reasons, it’s also very important for gameplay. For example, if in a game you have to create a specific item to gain an achievement, it’s important that the item translation is the same in all the in-game texts, otherwise it can be confusing for the player. A very useful tool to create, manage and share a glossary online is Google Docs. It allows you to create an online sheet (compatible with Excel) in a few minutes and it’s completely free. All the translators can access the glossary, updating and consulting it in real time. Obviously if you are using a CAT tool you can convert the Excel file to the specific format used by your software.
The creation of a style guide and a glossary are important tasks when you work alone, but become critical when the project involves more translators. Obviously, it’s essential that all translators use the same terminology and style to assure the best consistency in the final file, reducing the work in the editing/proofreading process. So a good initial preparation can be helpful to save time and avoid some common mistakes during the next step: the translation.
Once you have created a style guide and a glossary, and you have done a fast check of the project files, you can start the translation. A major difficulty lies in the fact that 9 times out of 10, you don’t have a chance to see or try the game (which normally is still in development) and then you have to make some crucial decisions with the available information. In this step, collaboration with clients is very important, because it allows you to overcome any doubt that may arise, having them answer your questions or provide you with some additional assets. This collaborative effort will allow for better localization, so it’s always very useful. Obviously, if you can play the game (maybe because it’s already available), play it as much as possible, so that you know every detail and can dissolve all doubts encountered during localization.
The translation is very similar to any other localization process. It’s essential to respect the deadline, which requires precise timing and a daily word count. You have to deliver a high quality file with no mistakes and with the best consistency, so I strongly suggest using a CAT tool, because it can very helpful with its translation memories and spell checking features. Which one? At the moment there are many different CAT tools available on the market and each one has its pros and cons… But that’s another topic. You can find more information about some CAT tool experiences on this blog!