Get best of the week

Localization Rules for Developers



First we do, but then think - or vice versa?  Alconost  tells you what localization features to consider at the game development stage.

We wrote this article as an answer to the repeated questions of the developers: “What is wrong with my game? Why is translation not enough? How to fix it?"

Starting to develop the game, many try to save resources on everything - and this is even effective if you do not plan to develop your brainchild over time.

But most developers soon after launching the game on the local market begin to think about how to attract more gamers from other countries. And there is a need for localization.

First, let's deal with terminology. Localize game- means to adapt it to the selected locale (language standard, country or region), translating the interface into the target language and making amendments to cultural, religious and political factors.

Article written in Alconost

It should be emphasized here that localization implies an adapted translation of the interface, but not a change in its elements.

For example, if in a game translated into German there are jokes about a character from English folklore, then when localized, the joke is replaced by one that will be understood in Germany. But if the German text does not fit into the interface, the solution to this problem goes beyond the scope of localization.

Another example of localization is the translation of text with numbers. In some language standards, such as en-US (American English), numbers sometimes need to be written in words rather than numbers. In other languages, numbers must correspond to certain forms of singular and plural nouns. For example, in Russian there are much more options than one and more than one, which English is well worth. And in Japanese and Chinese there are no plural forms at all. Well, if the numbers and texts in the game are fixed as static images, simply translating the text will not be enough.

These two examples with humor and numbers are just the tip of the iceberg: there are many other non-localization issues that may arise during translation. They are sometimes called pseudo-localization or internationalization errors.

In general, the technical tasks that precede localization relate to internationalization (in short - “i18n”). These are, as a rule, technical problems that could have been avoided, and their correction may require efforts from the developers.

To anticipate such errors, we at Alconost decided to create a list of rules. If you follow them from the very beginning of development, then you quietly and without unnecessary efforts prepare the game for localization.

1. Select localization languages ​​in advance


It can be argued that it is impossible to foresee all possible translation languages ​​before actually launching the game. This is partly true: first you test your audience on a non-localized version, and then expand your reach with localization. But this rule is not universal.

To begin with, there can be so many cultural and regional taboos in a game that without localization it’s impossible to attract an audience in such a region, no matter how exciting the game may be.

The question arises: how best to choose promising languages ​​before starting work on the game?

  • Analyze localization projects of competitors. Usually, if a competing game is popular in a particular market, then your localized product has a better chance of success.
  • . , - -, , , , Streets of Rogue, , . . , . -, .
  • , . , « ».

In any case, remember rule number 0: the English language should be, as far as possible, the source.

And yet, we recommend starting from the first day to develop a game with an eye on at least two languages. These two languages ​​are the "default" most likely - English and Russian. In this scenario, you will have several advantages. Firstly, the game can be translated into other languages ​​already from English, in a consistent and uniform manner. Secondly, realizing bilingualism in the game from the first day, you will automatically stumble upon the pitfalls of preparing for localization. And the transition to 20 language versions will not be so difficult.

2. Prepare an interface for possible languages


We usually recommend creating “with a small margin” interface elements so that their size is at least 30% larger than what is needed for the source text. This is especially true for short lines, such as menu items.

But we have another idea, better. If you started with rule No. 1 and already compiled a list of languages, develop an interface for the most complex (most voluminous for localization) language standard.

For understanding, texts in German will be on average 30% longer than English, in Russian and Arabic - about 10% longer. But the characters of traditional Chinese writing occupy 30% less space than the English text.

3. Do not embed text strings in code


Lines that cannot be retrieved from code cannot be localized. Remember, localized strings should be edited without editing the code.

Another important tip: try not to compose texts from single words or fragments. A good example of such an error was shared on the StackExchange platform by a Google developer:

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

In this example, we get a string of the form "$ 123", although in some other languages ​​the currency sign should be after the number.

Therefore, it is better to use format strings that can be localized. For example:

String format = Locale :: get ("currency format"); // returns "$ {0}" in English

String currency = String :: Format (format, money.toString ());

The latter option gives translators the ability to rearrange words within a string.

4. Remember that time, dates, units and numbers must also be localized.


It is necessary to add to the previous rule that numerical information must also be available for translation - it cannot be left in the code.

Be prepared to change the format of numbers in the interface: for example, a clock counting the time in a game will most likely also have to be localized. The point here is that the culture in Western countries is basically monochronous, that is, people there represent time as a time axis, and in Asian countries as a circle.

And this is not to mention the fact that the formats of dates and units of measurement differ in different languages.

Therefore, before localization, we recommend preparing and taking into account these nuances.

5. Use variables and format setup tools and give access to them


When localizing and editing text, using variables sometimes seems like a good alternative to hard coding. But if you do not give translators the opportunity to use variables at their discretion, this may turn against you.

The problem is that the order of words and phrases in different languages ​​is different. Therefore, our recommendation here is to make variables part of the phrase so that they can be inserted in the right context. Here is a small example of how it’s right and how not:

Wrong: “Mommy ate” +% num + "apples."
Correct: "Mommy ate% num apples."

It will be useful to briefly describe the variables: this will avoid confusion and erroneous correlation (or non-correlation) of a variable with the previous fragment of text.

6. Do not sew text into images


If you have images in the game, be prepared to localize them, especially if they have a lot of text, which means redoing the graphics from scratch.

Editing graphic resources is often not superfluous, so that their colors and symbols correspond to the standards of the selected region. But if the images are redone to insert the translated text, this is a waste of time and effort.

7. Use the correct fonts and encoding


If you use "special" characters that do not fit into the string class, there will be encoding problems. And if after localization the target product has the wrong encoding, it seems like it will take a lot of time and effort to eliminate the characters.

The same goes for fonts. Some game fonts do not have glyphs for all languages. As a result, for certain language versions you will have to select other fonts. Do not forget about it, otherwise you risk getting a bunch of characters like □□□ instead of subtitle text.

We recommend using Unicode instead of ASCII: UTF-8 is the most common and optimal encoding.

In general, watch out for the encoding of the source files. Here we will not go into details - a comprehensive guide to this topic can be found in ourEnglish-language article about the hunt for "krakozyabry" .

8. Ready for localization? Try pseudo translation


So, the technical nuances are taken into account. It's time for test localization. There are many great pseudo-localization tools on the Internet that mimic a foreign language interface, including changing the length of the text, checking the encoding, and finding hard-coded strings.

Essentially, you run a script that simulates the target language and produces a build, which is then checked during testing as the original non-localized build.

Such a preliminary test is not a panacea, but it helps. And also, testing a new interface with "abracadabra" instead of text can be very fun.

9. Start compiling your glossary in advance.


A glossary is a collection of in-game terms and concepts that must be translated in the same way. These are mainly objects, names of states, statuses, artifacts and character names.

It is important to maintain consistent terms in the game using the glossary. Imagine that one item was translated as a “potion” in one place and as an “elixir” in another - and the players suddenly had an insoluble logic puzzle.

10. Be prepared to give context


It is important in the translation process to give the localization team context. Judging by our experience at Alconost , well-established communication between translators, localization managers and developers helps to determine this context.

We understand that it is not possible (and not necessary) for all developers to be in touch around the clock. Therefore, we advise you to choose a contact person who communicates with translators in real time through a translation management platform .

Typically, such a platform is chosen by the customer. Therefore, virtual communication with the localization team is convenient and productive. Well, that’s justified, because the work done with the mind will certainly pay off.

We hope our tips helped you. Good luck and more satisfied players! Well, if you need help with localization or advice, write to us at Alconost .

About the author

Alconost localizes games , applications and sites in 70 languages. Native translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also make advertising and educational videos - for sites that sell, image, advertising, educational, teasers, expliner, trailers for Google Play and the App Store.

→  Read more

More articles:


All Articles