Should you act first and think later, or think first and act later? Knowing these little tricks when designing your game could save you a fortune.
The original version of this article was based on data from 2019. This updated edition reflects the most recent data available as of February 2026.
We’ve written this article as a tribute to the numerous questions our clients have asked us.
What’s wrong with my game? Why isn’t localization enough? How can we fix it?
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 complete, 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.
To clarify, localizing a game involves 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.
At this point, we’d like to emphasize that localization involves interpreting the interface, rather than modifying its elements.
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 instances. Other localization locales may require matching numbers with the plural and 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 —countless non-localization issues can arise during the localization phase. Some people refer to them as pseudo-localization or internationalization errors — big words that describe something that could have been predicted and avoided, but which can require serious work on the part of developers to fix.
This is why we at Alconost have decided to compile a list of rules for developers to follow from the very beginning of the design process, in order to make localization as painless as possible. Follow these essential guidelines to prepare your game for localization with minimal effort.
1. Pre-select localization languages in advance
In our previous article dedicated to app localization workflow, we started our action list with #1: “Evaluate your potential.” And yes, we’re going to repeat ourselves here.
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?
Analyze the competitors’ localizations. Usually, if a rival game has found fertile ground in a particular market, you also have an excellent chance for a success story.
Evaluate localizations by genre. For example, suppose you’re an indie developer contemplating the release of a retro-style roguelike. In that case, you might have a good idea of your potential locales by looking at a success story in the genre — say, Streets of Rogue, which has been localized into seven languages plus English. Another approach is to look at the question from a regional perspective. So, since video games are an integral part of Japanese culture, Japan might be a target market to consider from the very early days of video game development.
Study the most wanted languages for game localization. At this point, you might want to take a look at our previous research published in the article “Best Languages for Game Localization.”
However, your localization plans notwithstanding, our “Rule #0” is to make English the source language whenever possible. Recommend developing with two locales in mind from the outset.
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.
Here, too, AI-powered market analysis can be helpful. App store data, reviews, and competition trends can be analyzed by tools like ChatGPT to identify the most promising locations for your specific game genre. Developers can quickly identify areas where localization might be profitable, rather than relying solely on manual research.
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 true for short strings (such as menu items, UI elements, etc.).
However, we have a better idea still. 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 expected to be approximately 30% longer than the English one, and the Russian version will be around 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 requiring any changes to the code.
Actually, all the engineering tasks required to initiate the localization process are attributed to the internationalization process, or i18n for short.
Another important tip is to avoid building sentences 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 follow-up to the last rule, we would like to explicitly state that numerical information must also be extractable from the code for localization purposes and therefore cannot 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 predominantly monochronic, meaning they’re accustomed to having time represented as a linear timeline. In contrast, Asian countries tend to prefer having time represented as a circle.
Not to mention that the formats for dates and units of measurement differ across almost all languages.
So our 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 related to word and phrase order, which may be completely different in another language. Therefore, our recommendation is to 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 beneficial. 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 prepared to localize them as well, especially if they’re enriched with text. This means redesigning the whole image from scratch.
Redesigning images and creative assets can sometimes be a good idea to meet the 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 correct 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, specific 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.
We recommend using Unicode over ASCII whenever possible. UTF-8 is the most common and space-efficient encoding. Ensure that your input files are encoded correctly.
We won’t get into more detail about this right now. An exhaustive tutorial on encoding can be found in the previous article on hunting for “mojibakes.”
8. Play with pseudo-translation if you’re ready for localization
Finally, once you have all the technical aspects outlined above ready, try conducting a test run. There are several excellent pseudo-localization tools available online that can simulate your interface as if it were in a foreign language, including adjusting text length and verifying encoding and hard-coded strings.
These tools essentially run a script that mimics the target language and produces a build, which must then be QA-tested within the regular process as a non-localized build.
This pre-test is not a panacea, but it helps significantly. 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 mainly contains items, character names, artifacts, and statuses.
Maintaining consistency with the glossary across the entire game is essential. Just imagine if a specific 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.
By assisting with the creation and maintenance of your glossary, AI technologies like ChatGPT can also simplify this task. They can recognize recurrent phrases, offer consistent translations in various settings, and scan vast amounts of in-game content. Even when a character's name is translated differently in different dialogues, for instance, AI can identify such issues and suggest solutions before players see them. Developers can save time and guarantee that their game environment feels consistent across all languages by incorporating AI into the terminology and glossary process.
10. Be ready to provide context
No less important than providing a glossary is ensuring that the localization team has all the necessary context. In our experience, context can be established by enabling communication between translators, localization project managers, and game developers.
We realize that it’s tough for the entire development team to be available 24/7. However, during the localization phase, our best advice is to designate a representative as your contact person — incorrect or insufficient context can significantly impact the ultimate results of the localization process.
Additionally, the platform for localization workflow is primarily selected based on the client’s preferences, allowing for this communication to be conducted as conveniently and efficiently as possible.
Additionally, AI assistants can act as a liaison between translators and developers. They can create brief descriptions for ambiguous objects, quickly explain game mechanics, or even mimic conversations so translators can grasp the tone of emotion. This expedites the entire localization process and lessens the need for back-and-forth communication.
And if the work is done well, it ultimately pays off.
We hope you find this simple list of recommendations helpful for designing your games. We’re wishing you great success stories and captivated players!
QACAT
AI Video Studio
Localize.io