Cutting corners when bootstrapping a new game is a widely-used strategy. And it might even be an efficient one, as long as you aren’t planning to grow incrementally.

However, shortly after the long-awaited local release is in the bag, most game developers start thinking about how to attract more international gamers. And after taking a crack at promoting their game in more countries, they come up with several ideas for localization.

Just so we’re clear, localizing a game means adapting it to the selected locale (country or region) by translating the user interface into the target language and making adjustments for cultural, religious, and political factors.

For instance, if a game that needs to be translated into German contains jokes about an English folk character, localization handles this by replacing the jokes with other ones that are popular in Germany. However, if there isn’t enough space in the user interface to accommodate the larger size of the German text, this issue can sometimes require more effort than just localization.

Another example illustrating the scope of localization would be the translation of numbers. For example, some locales such as en-US (American English) require numbers to be written in words rather than numerals in certain cases. Other localization locales might require matching numbers with the plural\singular forms of nouns. For example, in Russian, there are more options than just “one” and “more than one,” while in Japanese and Chinese there are no plural forms at all. However, if numbers and texts are hardcoded in static images within the game, just translating the text isn’t going to cut it.

These two cases are just the tip of the iceberg — there are countless non-localization issues that can rear their ugly heads during the localization phase. Some people call them pseudo-localization or internationalization errors — big words referring to something that could have been predicted and avoided but can require serious work on the part of the developers to fix.

This is why we at Alconost have decided to draw up a list of rules for developers to keep in mind from the very beginning of the design process in order to make localization as painless as possible. Just follow these essential guidelines to get your game ready for localization with no extra effort.

1. Pre-select localization languages in advance

You might object that it’s impossible to foresee all potential locales for a game before it actually goes live. Well, this is somewhat true: first, you test the audience with a non-localized version, and then you scale up with localization. However, it doesn’t always work this way.

To start with, your game might contain so many cultural and regional taboos that it would be a no-go for the selected locale without localization, even with the most enticing narrative.

So what is the best way to predict promising locales before you start?

The two “default” locales should probably be English and your native language (if that isn’t English). This approach has several undeniable benefits: first, you’ll be able to translate your game later on into new languages using English as the source material, which helps ensure consistency. Second, having two languages from day one will automatically guide you through all the pitfalls of preparing for localization. Then you’ll see little difference when you have 20 languages.

2. Adjust the interface for potential languages

When building interface elements, it’s generally a good idea to plan for at least 30% extra space (or even more, if possible) for other languages. This is especially valid for short strings (menu items, UI, etc.).

However, I have an even better idea. If you’ve taken Rule #1 into account and have a preliminary long list of locales, there’s another helpful option: design your interface for the worst-case language.

For example, the German version is going to be an average of 30% longer than the English one, and the Russian version will be approximately 10% longer. The same is usually true for the Arabic version. On the other hand, traditional Chinese characters generally take up 30% less space than English texts.

When it comes to bytes, one Latin letter equals one byte, but Cyrillic and Arabic characters are twice as big, which also needs to be accounted for when planning data storage.

3. Don’t build text strings into the code

Transforming the text for localization will result in these hard-coded strings being lost. Remember this localization rule: every localizable string should be editable without touching a line of code.

Actually, all the engineering tasks that need to be performed in order to begin the localization process are attributed to the internationalization process or i18n for short.

Another important tip is to avoid building pieces of text out of smaller single words. A good example of this kind of blunder has been spotted by a Google programmer contributing to StackExchange:

String currency = Locale::getCurrencyString() + money.toString(); // creates $123

The above example showcases a problem — other languages might place the currency mark after the number.

Instead, format strings can be used that need to be localized themselves. For example:

String format = Locale::get(“currency format”); // returns “${0}” in English String currency = String::Format(format, money.toString());

The latter approach allows localizers to rearrange words within the actual format string.

4. Remember that time, dates, units of measurement, and numbers also need to be localized

As a followup to the last rule, I just want to explicitly state that numerical information also needs to be extractable from the code for localization and therefore must not be hard-coded.

You also need to be ready to redesign your numbers in the interface. For example, a clock ticking down the game’s timeline should probably be localized. The underlying motivation for this is that Western countries are mostly monochronic, which means they’re used to having time represented as a stretching timeline, whereas Asian countries prefer to have time represented as a circle.

Not to mention that the formats for dates and units of measurement differ across almost all languages.

So my recommendation is to prepare yourself and consider every detail when it comes to localization.

5. Use placeholders and formatters and make them accessible

Using placeholders sometimes seems like a good alternative to just hard-coding text when it comes to localization and text editing. However, it can be a double-edged sword if you don’t provide access to placeholders.

This issue is connected to word and phrase order that might be absolutely different in another language. So my recommendation here is: make your placeholders part of the phrase so they can be inserted in context. Here’s a little example of what’s “good” and what’s “bad”:

No: “Mommy ate “ + %num + “ apples.”
Yes: “Mommy ate %num apples.”

A short description of placeholders can also be very helpful. This makes it possible to avoid confusion when a placeholder is considered to be wrongly related or unrelated to the previous piece of text.

6. Avoid text in images

If you use images in your game, be ready to localize them too, especially if they’re enriched with text. This means redesigning the whole image from scratch.

Redesigning images and creative assets is sometimes a good idea so you can meet standards for colors and characters in your target locale. However, it’s a waste of time and effort if you’re just doing it to insert translated text.

7. Use the right encoding and fonts

Encoding issues are inevitable if you need certain “spécîål” characters that don’t fit into your string class. If your target language has an encoding mismatch after localization, it could take a great deal of time and effort to remove those awful ��� characters.

The same problem applies to fonts. In particular, certain fancy fonts for games don’t contain glyphs for all languages. As a result, it might be necessary to choose different fonts for different languages. I recommend keeping this in mind when choosing a font; otherwise, you risk ending up with a bunch of boxes (â–¡â–¡â–¡) instead of subtitled text.

My recommendation is to use Unicode over ASCII whenever possible. UTF-8 is the most common and space-efficient encoding. So make sure your input files are encoded correctly.

I won’t get into more detail about this right now. An exhaustive tutorial on encoding can be found in the article on hunting for “mojibakes.”

8. Play with pseudo-translation if you’re ready for localization

Finally, once you’ve got all the technical aspects outlined above ready, try doing a test run. There are a number of great pseudo-localization tools available across the Web that can imitate your interface as if it were in a foreign language, including adapting text length and checking encoding and hard-coded strings.

These tools basically run a script that mimics the target language and produces a build, which then must be QA tested within the regular process as a non-localized build.

This pre-test is definitely not a panacea, but it helps a lot. And it can also be a lot of fun for developers to do a mockup with a camouflaged interface.

9. Start building your glossary early

A glossary is a collection of in-game terms and concepts that must be preserved consistently throughout the entire game. It mostly contains items, character names, artifacts, and statuses.

Maintaining consistency with the glossary across the entire game is essential. Just imagine if a certain in-game item is translated as “potion” in one place and “elixir” in another — you’ve unintentionally created an extra logic puzzle for your players.

10. Be ready to provide context

No less important than providing a glossary is ensuring that the localization team has all the context they need. In my experience, context can be established by enabling communication between translators, localization project managers, and game developers.

Sure, it’s extremely difficult for the entire development team to be available 24/7. However, during the localization phase, my best advice is to designate a representative to be your contact person — incorrect or insufficient context can really hurt the ultimate results of the localization process.

Besides, the platform for localization workflow is primarily selected based on the client’s preferences, so this communication can be conducted as conveniently and efficiently as possible.

And if the work is done well, it pays off in the end.

I hope you find this simple list of recommendations helpful for designing your games. Wish you great success stories and captivated players! And should you need some help with localization, just drop a line here.