Shortly after the long-awaited local release is in the bag, most game developers start thinking about how to attract more international gamers. And sooner or later, after taking a crack at promoting their game in more countries, they come up with several ideas for localization.
This is why we have prepared this list of rules for developers to follow from the very beginning of the design process in order to make localization as painless as possible.
So what is the best way to predict promising locales before you start?
However, your localization plans notwithstanding, our “Rule #0” is to make English the source language if at all possible. And we recommend developing with two locales in mind from day one.
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.
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, 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.
Transforming the text for localization will result in these hard-coded strings being lost. Every localizable string should be editable without touching a line of code. Another important tip is to avoid building pieces of text out of smaller single words.
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.
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.
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 our 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.
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.
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. We recommend keeping this in mind when choosing a font; otherwise, you risk ending up with a bunch of boxes (□□□) instead of subtitled text.
Our 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.
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.
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.
No less important than providing a glossary is ensuring that the localization team has all the context they need. In our experience, context can be established by enabling communication between translators, localization project managers, and game developers.
We hope you find this simple list of recommendations helpful for designing your games. We’re wishing you great success stories and captivated players!