Internationalization: 5 Steps to Prepare a Game for Localization Public  

Unlocalized image text, truncations, grammar issues … In modern mobile game localization, are such issues now relics of the past? Unfortunately, no. Still, to this day, it is not uncommon to install an app onto your phone that supposedly supports 20 or more languages, only to find the same old localization issues that have been irritating users around the world for over a decade. 

These may happen because of: 

  • developers new to the industry who don’t necessarily have enough experience in polishing their products for a global audience
  • simple inattentiveness
  • non-native and non-dedicated localization teams
  • bureaucratic issues
  • time and budget constraints

The list goes on. Localization fails can occur in any company and for many reasons. No one is exempt from them, be it a big game development studio, an indie team, or a localization manager from a language service provider. But regardless of where in the supply chain you sit, it’s never too late to learn and do better next time.

Let’s discuss five key steps to start planning the successful localization of your game.

1. Internationalization

Internationalization (i18n) is the process of preparing sources in a way that allows a game (or any other digital localizable product) to function globally. The task of internationalization is to ensure that the product design will meet the needs of users in different countries and adapt easily to localization.

However, not all developers are aware of the usual internationalization requirements, which are better taken into account at the early stages of the game development process. Ignorance of these requirements may lead to serious problems during localization, adversely affecting the game cost, quality and time to market.

Internationalization is a hot topic addressed not only in couloirs:

  • There’s an i18n Special Interest Group at GALA association. It features monthly online meetings during which internationalization issues and life hacks are discussed.
  • There are technology solutions available that help find and fix internationalization bugs. For example, Globalyzer by Lingoport detects bugs from within integrated development environments (IDEs), check-in/pull requests or daily runs against your repositories.

The earlier you find the defect, the less you lose on fixing it (not to mention the consequences of not fixing it):

Source: Lingoport webinar. Initial author: Capers Jones

In order to find internationalization defects, you need to know what to look for. We compiled a list of basic aspects to consider based on the materials of the GALA’s i18n Special Interest Group, Lingoport, and Ekaterina Zaitseva, the Lead Localization Manager at RJ Games.

Basic internationalization aspects to consider

# Step to consider What you need to know
1 No hard-coding

Avoiding hard-coding or embedding text in any graphic files as much as possible reduces the cost of localization (it is easier and cheaper to translate the text than to redraw the image).

Character and numeric constants, screen location coordinates, file names, file path names should not be hard-coded: they are different for each region.

2 Enough space is reserved for the menus and dialog boxes When translated from English, the text takes up more space in many languages, so it’s important to reserve enough space in advance – to avoid truncations and hardly manageable char limits.
3 Concatenations Sentence structure plays a key role in localization, and concatenations should be refactored to use insertion points prior to the strings being externalized.
4 Variables and placeholders

Having a description inside the variable/placeholder on what will be rendered there helps to move the words around without interfering with the variable values. E.g.,

Take {DiscountAmount} % off when you buy {PurchaseAmount} or more.

Variables need to be used in no more than one context, so that they are not subject to automatic out-of-context reuse.

5 Plurals

Plural formation results in different forms of the words. Not all plural formation is as simple as adding an “s” as in English. E.g., for 1 string in English, we may need several strings in other languages:

  • One for a singular (xyz=1) string
  • One for a plural (xyz = 2 and more) string 
  • One if xyz is zero, because in some languages that is expressed differently

Providing different versions for the words few, many, plural, other (e.g., for fractions) may be required as well. 

See also: Language Plural Rules and Quantity strings.

6 Gender Providing information (e.g., in metadata) on gender and human/non-human nature of the objects helps to avoid declension problems.
7 Normalization of source Creating a normalized source version (eliminating misspellings, jargon, uncommon abbreviations, etc.) for translation, rather than fixing the translations, helps to avoid negative effects on TMs.
8 Mirroring the interface Right to left (RTL) languages including Arabic and Hebrew require mirroring of all interface elements.
9 Fonts and special symbols Testing of every font for every planned language, including font size (it should not be too big or too small) and paying attention to special characters, such as umlauts, is advisable.
10 Encoding

Unicode should be supported.

For the Chinese market – the app should support a standard that is not fully compatible with Unicode: read more about GB 18030.

11 Support scripts other than the Latin alphabet Users should be able to enter characters in their language (for instance, spell their names) into dialog boxes.
12 Text display peculiarities: wrapping, vertical text Word wrap rules are taken into account for different locales (in some languages there is no tradition to divide words by syllables). Vertical text and text breakdown used in Asian languages should be supported (there are special rules for splitting and formatting text, and distinguishing paragraphs).
13 Colors Paying attention to colors to take into account cross-cultural aspects. Read more.
14 Quotation marks Sometimes the usage of additional quotes (e.g., four quotes in the XML attribute) may lead to breaking the source file. Using of " or chevron quotes may be a solution.
15 Geolocation Geodata automatically inserted into translated UIs may not always be localized already: this should be checked.
16 Time and date, currency, numbers Creating text strings with variables for time & date, currency, numbers is helpful. This approach proves that the game cares about the customers beyond its home borders.
17 Download and upload test Localization resources can be uploaded/downloaded in a single established format. Resulting source files contain all text for localization (see also: point 1). This eliminates the possibility of incomplete localization (partially translated text).
Want to take a closer look? Grab the table in Google Sheets!

On top of that, the International Game Developers Association (IGDA), advises gaining awareness of the top four cultural variables which apply to your target markets. Those are history, religion, ethnicity, and geopolitical considerations.

2. Communication and collaboration

With all the internationalization steps to check, localization is being increasingly integrated upstream into the development process. This probably won’t come as much of a surprise, but the ground-zero step in any game internationalization and localization effort needs to be communication.

To start the conversation, a localization team may share the way Globalyzer detects issues in the code (also known as “i18n gremlins”) with the development team. Though every app and mobile game is unique in its requirements, this description discusses the rule sets. They are the foundation of how the issues are found. It can serve as an illustration of what to look for, and is written in a language software teams understand.

3. CAT tools, QA and test planning

If the steps taken don’t prevent all possible localization issues, the careful selection of CAT and QA tools can help to correct any that have popped up.

Pseudolocalization

A handy approach is to run pseudolocalization for testing of the app, though it’s less efficient than finding an internationalization bug as code is written. Even machine translation (MT) helps to get a view of the localized product. Both MT and pseudolocalization might lead to proactive design changes and can be utilized via CAT tools.

Source: Lingoport

CAT tools for games

Among game translators, popular CAT tools are:

  • memoQ
  • Memsource
  • Trados Studio
  • Smartcat
  • Smartling
  • Wordbee

Some also use Matecat, MS LEAF, XTM, and POedit.

QA best practices

When a language vendor delivers their finished product, one can apply industry-standard practices such as a third-party review of a sample translation and extensive QA metrics, or at least compare two variants of translation (translated and edited) via tools such as Change Tracker or TQAuditor

It also makes sense to run an in-house check of the localized bilingual file prior to importing it back into the game build. QA built-in CAT tools, or Xbench and Verifika can help with that. Even without the time and budget for a full review, QA tools can help you know which translator works more attentively. 

Make sure to check examples of QA tools in the 2019 Nimdzi Language Technology Atlas:

The earlier you choose the CAT and QA environments, the smoother the localization will be. Also, keep in mind that some of these may not support the file formats you’re using, so choose carefully.

Options for testing

Some game developers send packs of localized game user interface screenshots for the translation teams to verify. Then the error lists (handled via a simple Google Sheet or an online bug repository, such as JIRA) are filled in and sent back to be fixed.

Others provide maximum context, allowing the translators to play the game and even give them special cheat codes to facilitate the gameplay process. The information on game logic helps localization teams a lot, even if full-scale linguistic testing is planned as well. If you can ask the development team to leave notes for text strings, you should do so. The more information available, the better.

Source: RWS Moravia and Lingoport webinar

Playing the game is usually a preferable option for translators. Not only does it give the needed context, but it also builds a special connection between translators and the games they work on. 

This way, translators begin to feel more dedicated, which leads them to strive for quality even more. So it’s wise to check and agree with your legal team about whether or not you can allow for that special bond to happen.

4. Legal preparation and documentation

The level of translator involvement is not the only thing to verify with the legal team. Early collaboration with a legal department establishing vendor contracts will streamline future localization efforts for you and your vendor. 

Accordingly, the communication with vendors prior to the actual project start will help to calculate localization budgets. Don’t forget to reserve an extra budget for unforeseen expenses. It might also be a good idea to check the legal restrictions with payment systems abroad.

In addition to legal matters, which should be considered and added to the documentation in advance, it’s wise to prepare templates, checklists, a Style Guide, an Onboarding Guide, or the “Project localization Bible,” as Ekaterina from RJ Games suggests. You can start compiling a glossary, even though there may be no full source text available at the beginning of the project. Some of the key terms are already known. Mature companies create special onboarding kits for developers, such as “Globalization 101,” which can focus on internationalization and culturalization aspects. 

5. Feedback collection

Even if you don’t have any text to localize yet, you still can benefit from collecting user feedback. One way to do this is to pay attention to the comments in app stores of similar games. While the errors aren’t useful themselves, understanding their root cause may be.

“Checking the feedback for similar games should happen, if at all, very early in the process. No point doing it after you made a final decision about the fonts,” says Lena Batova, a game translator and localizer. 

Another option is to make it easy for players to leave feedback within the game itself. It can be a simple feedback button or a fancy help widget. Make sure to discuss this with the development and design teams (especially considering the multilingual background of the users). And don’t forget, thanking the players for their feedback adds a nice touch.

A plan for success

Regardless of the amount of localizable text in the game, the five steps mentioned above typically give the best results when done in advance.

It may seem a bit tricky to decide which steps should be prioritized in your particular case, but the main idea is pretty obvious. The earlier you start, the less painful and more fruitful your game localization will be!

Stay up to date as Nimdzi publishes new insights.
We will keep you posted as each new report is published so that you are sure not to miss anything.

  • Sign up
Password Strength Very Weak
Lost your password? Please enter your username or email address. You will receive a link to create a new password via email.
We do not share your personal details with anyone.