Requirements for Successful Localization
Who even said that localization has to be successful in the first place? There exists an opinion that certain products require a minimal level of localization — a machine translation should suffice for the target audience to decide whether the game is worth downloading, and once they’ve played it for a while, they will inevitably become sucked in. Let’s take a few steps back and analyze this issue from a critical perspective. Suppose we have a game with its own potentially great niche — it’s fun to play, well balanced, and has a suitable monetization model, for instance. Finally, it hits the virtual store shelves. Needless to say, it requires marketing. You seek the services of an ASO expert, who, after analyzing the conversion, tells you: “We must expand into new segments!” OK, then. Expansion is your next move. How do you do it though? There are two methods, which are by no means mutually exclusive — in fact, it’s quite the opposite! They complement each other extremely well.
Method 1
Working with ratings and feedback. Player reviews on your game page are perhaps the most honest information channel, where an interested user can decide for themselves whether the product is worth downloading. Should the number of negative or unprocessed reviews reach a specific threshold, potential players instantly lose the desire to download the game. Moreover, if all the reviews are strictly positive, that may alert some people, as they will believe the reviews to be fake. The best possible scenario is when you have varied reviews that receive prompt responses from the developers.
We conducted a survey asking several of our partners who had been tracking down the relationship between a game’s rating and competently processed feedback, and each of them said that the two factors formed a correlation. The quicker a developer reacts to a review, the better their reputation in the players’ eyes.
Method 2
Localize. Localization pushes the visibility of a game well outside its native store. We’ve mentioned a number of times that the ROI of a localization can skyrocket all the way up to 1,890%. Yes, that one case may be a statistical outlier, but in the grand scheme of things, a localized game generates significantly more profit than one without localization, because it enjoys greater visibility and higher local player loyalty.
But let’s get back to your game, shall we? You and your ASO guy have decided that your game requires localization. You’ve also browsed the webpages of localized games, remembered the descriptions of items sold on AliExpress, and realized that if you’re going to invest in localization, you have to be smart about it and not bother with machine translation at all. You want the game to speak the language of its players, and the more natural it sounds, the better. So, you need a clear-cut strategy, and you decide to plan everything out in advance.
What are the necessary steps to a successful localization?
Step 1. Market Selection
To choose the right markets to enter, there is a whole range of factors you must analyze in advance, including the popularity of the genre of your game in specific regions, the monetization model, the platforms on which your game will release, the difficulty of licensing the game in the target regions, and even the EF EPI.
First and foremost, we recommend that you translate your game into the most widely spoken European languages, i.e. EFIGS (English, French, Italian, German, and Spanish), as well as into Chinese, Japanese, and Korean. This is a standard set of languages, which will serve as your diversified investment portfolio, substantially increasing your profit with minimal risk. If you also have a hunch that your game will also enjoy great demand in other regions, you should probably consult the relevant analytical articles. Like this one, for example.
Step 2. Planning the Work Process
As a rule (and our example is no exception), localization planning usually happens shortly before the release of the game. And more often than not, this is a really bad idea! The most successful practical experience has demonstrated that this kind of work should be done during the market selection stage, which, in turn, should precede the primary development stages. Why is that? Because your market selection isn’t simply determined by your regional analysis, but it also dictates the rules for your entry into the markets of those regions. To give you a simple example: if you plan on releasing your game on consoles in Germany, you have to make sure it contains no scenes of murder. Or if you want your tasty share of the Chinese mobile games market, you have to remember that the Chinese virtual storefronts and advertising platforms treat approval documents very seriously, and you won’t just have to cut down violent and gore scenes to a minimum, but you’ll also have to look into the complex licensing procedures in China. This, of course, directly affects development and store featuring. Culturalization as an element of localization is a forward-looking measure that allows you to minimize financial losses during the early stages of the cycle and flag potential bottlenecks for the linguists, who will as a result localize them while taking into account the cultural specifics of the target region. They don’t say “forewarned is forearmed” for no reason, after all.
Here is the order of localization stages as recommended by Allcorrect:
* Legend:
Dark-blue blocks: mandatory stages.
Blue blocks: mandatory stages that are often forgotten.
Yellow blocks: complementary stages.
Framed blocks: stage requirement depends on game type.
The localization testing stage deserves a special mention (the gray block). As soon as you have some translated text that’s already been integrated into the game, it wouldn’t hurt to do at least one round of localization testing. The translation may be of very high quality, while the localization, on the other hand, might be downright abysmal. But how can this even be possible? The answer is very simple! The localized text may exceed the original in length and thus not fit within the designated strings/areas. Or the font you selected may not support certain language symbols. Even paid events might malfunction in the localized version of the game because the button has slipped out of bounds. And if the game has elements containing voice acting, then localization testing is an absolute must — oftentimes, the text in the audio tracks and subtitles doesn’t match, and failing to address this issue will make the end product look sloppy. To sum everything up to this point, just like any changes integrated into the game, localization demands testing to ensure everything works as intended, which is best accounted for during the planning stages.
Step 3. Resource Internationalization
There is another hard-to-pronounce term that we will touch upon as an element of localization: internationalization. It refers to one very basic concept: all the resources that are to be translated must be separated from the code (yes, this includes currency, dates, and numbers too!) and compiled in such a way that they will function correctly in all target languages.
A simple internationalization checklist will look something like this:
- File formats. These must be universal. As a rule of thumb, stick to text files, so .xlsx, .csv, .xliff, .po, and .json should all work for our purposes. Any text included in graphical resources must be converted into one of the formats listed above and then separately redrawn for each locale.
- Not much to say here. For all intents and purposes, only Unicode exists. Everything else is just tech support for obsolete encoding standards.
- Screen space. Localized text may occupy between 30% and 200% more screen space than the original, depending on the volume and target language. Here you will find IBM’s guidelines on the topic. By the way, you can run a pseudolocalization check in advance in order to get a rough idea what the localized text will look like. There are several easy-to-access online resources where you can do this. CrowdIn is one of them.
- You’d think there’s no way anything could ever go wrong here, right? In some instances, however, selected fonts may not support superscript, subscript, and other special symbols in different languages, which will inevitably cause delays during development. This is especially true for your very own beautifully drawn custom fonts, so be sure to check how many variations of the “a” symbol you will require across all the target languages (e.g. ä, à, ą, etc.).
Oh, and more thing! If your code generates pretty Asian fonts in real time, this will result in your game build taking up a massive chunk of storage space, as well as constantly freezing, because the speed of the process directly correlates with the hardware specs of the device running the given build (e.g. a mobile phone). This used to happen to games made in Unity, but this issue has already been dealt with.
- You can talk about this topic for hours on end! Yes, this concerns scenes containing murder, violence, nudity, minority groups, alcohol consumption, and all the other things that make your game edgy and truly one of a kind. In certain markets, such edginess can be a real show stopper, meaning your game will never reach the target audience. The key details to account for here are the game’s age rating, licensing and general legal specifics, and the cultural code of the locale, as well as its history and mentality. We’ve already discussed a number of curious cases from the world of culturalization in our previous articles, and there are certainly quite a lot of nuances to digest there.
Step 4. Preparing Resources for Localization
Everything that will eventually be translated into your target languages must be compiled together and finalized. Usually, this file or collection of files is referred to as a lockit (short for localization kit). Your lockit may include the main file for translation (or a number of files), all additional reference materials for the team of translators (e.g. a bestiary, maps of locations, the narrative, descriptions of in-game mechanics, screenshots of gameplay, etc.), and even a working build of the game.
We will discuss the extra materials a bit later in the article when we touch upon the topic of context. Right now we need to think about the format of the main file.
It is optimal to keep the file in table form, since this offers the simplest means of structuring information and adding comments to strings. Why is this important? Well, for example, the lines of dialogue may not necessarily be arranged in order, and a column containing string IDs will help the translator understand the logic behind the general arrangement of the lockit. Furthermore, some strings may contain single words that can be translated in several different ways depending on the context. This is another instance where the string ID might indicate what exactly it is (e.g. itemdescription_vault).
Generally speaking, in a perfect world, all strings should be sorted chronologically and not alphabetically or by some other characteristic. This will significantly simplify and speed up the translation process.
Besides the ID column, you can also add a column containing string limits. This information will safeguard you against translated text that doesn’t fit inside a button or text box.
Additionally, you can include a section containing comments that are relevant to each string. You can use these to specify in which scene the string will appear or the tone of the speaker. Oh, and more thing! For dialogue stings, always indicate the speaker and whom they are addressing. This is crucial to the translator’s understanding of which modes of address or verb forms most reflect the style in the source text.
You can also add some screenshots in. If you do, your team of translators won’t have to pester you incessantly with questions like: “What does a Giant Mouzard look like?” This is more of a luxury, of course. 😊 Just kidding! In reality, if a game has customizable characters or hidden objects, screenshots will go a long way towards ensuring that words like “chest” are translated as storage containers and not as a person’s breast.
Step 5. Context
At this point, the role of context in localization has become the stuff of legend: only the laziest (or shiest) members of the industry have yet to contribute their two cents regarding its importance. Perhaps the most common reason why a localized project can become a total disaster is the lack of context. When there’s insufficient context, the translator may misinterpret a string or even a whole series of strings, unleashing a tragic yet simultaneously comic “masterpiece” upon the target audience.
So, what can be considered context? Practically anything, actually! Even materials that at first glance appear to be of no use to the translator, like descriptions of gameplay mechanics, narrative, script, location maps, etc. If your game contains dialogue, and particularly voiced dialogue, then things like character descriptions, pictures of them, and even a chart of their relationships are absolutely essential.
All in all, the golden rule here is that one can never supply too much context.
Step 6. Localization
Here there’s no getting away from the classic project management triangle, which consists of three elements: cost, time, and quality. As for the list of factors affecting each one of its sides, it will look something like this:
- Level of resource readiness. In a perfect world, any text sent out for translation must not be changed thereafter, because should that happen, not only will all the changes have to be replicated in the other languages, but you’ll also have to identify any other potentially affected fragments of text. For instance, if the gender of one of the characters is changed, all the strings that mention or involve said character must be revised as a result. If an item is removed from the game, then the relevant changes to quest and/or achievement descriptions will have to be made. If a game mechanic is altered, this will have to be reflected in the text too.
- The number of planned localization stages. Generally, the process can be split up into three primary stages: localization, voiceover work, and testing.
One translator has a daily text output of 1,700-2,000 words per day, a number that can be increased by expanding your localization team for every language. However, this may entail stylistic discrepancies and inconsistent translations of important terms. If you plan on enlisting the services of editors, then keep in mind that one editor averages a daily output of 3,000-4,000 words. However, you shouldn’t assume that translators and editors will be working seven-day weeks — five days a week is a more reasonable expectation. Another important thing to note is that it will take approximately a week to approve the project specification with the client, as well as for the team of translators to familiarize themselves with all the reference materials. You want the notoriously tricky context to be just right, don’t you? In that case, you should allow time for your localization team to review everything without missing any important details.
Voiceover work is even trickier. First of all, you need to decide on what kind of voiceover you want for your game, and specify the time limits for each string. Moreover, the same principles should apply to your requirements for finalized files: effects, compression, frequency, file type — consider all these things in advance before sending your project specification to the studio.
A voice actor works 4-5 hours a day, at most. Yes, they can voice different characters, which will help reduce costs slightly, but their work time during the day is fairly limited. Besides, studios can only record one actor at a time, and you have to account for that as well.
Oh, and don’t forget to allocate some time and a budget for pre- and post-production.
The testing stage is a bit more straightforward. All you need for localization testing is a test plan or a set of test cases (made by simply editing the functional test cases), a description of the cheat code system, and the lockit (which you should already have by now). To calculate a rough estimate of the time required to complete the test, simply take how long it will take an average player to complete the game and increase it by 20-30%. The extra time will be spent on filling in bug reports and carefully reading the text during gameplay.
- Choosing contractors for each localization stage. There are several ways you can go about this. You can hire in-house translators and editors and then you’ll have an entire localization department all to yourself! Wow! You’ll also have to appoint someone to manage said department. You can also commission freelancers to translate the project, but then you’ll have to allocate time and resources to coordinate their work and curate the process. Or you can take the risky approach and give crowdsourcing a shot, but the quality of the end product will be totally unpredictable. You can also contact a localization agency — in this case, the quality is guaranteed to be spot on, but the costs you’ll incur will be higher too.
When it comes to voiceover work and testing, there aren’t as many options to choose from, but that’s because these services are generally considered very niche, and we’ll have to delve into the specifics of how everything works with them.
Your average localization plan will look something like this:
We intentionally didn’t include voice acting, because as a rule, this element is only present on AAA projects, for which the working processes are so highly nuanced that this plan won’t bear much relevance to them anyway.
Step 7. ROI Calculation
It seems like your ASO guy has dragged you into one risky affair. But now, after everything we’ve done for him, he’d better calculate the return on our investment in the localization project or else.
Once we have actual numbers on our hands, we’ll see that a well-made localization really is cost-effective. And when all is said and done, feel free to share your observations in an article like this one.
