How To Prepare Your Game For Localization: Step-By-Step Guide (part 1)

2021-06-03 | MICHAEL SOUTO

How To Prepare Your Game For Localization: Step-By-Step Guide (part 1)

Game translation is more than putting all the game text together in a nice Excel or Google doc, to then be pushed into a video game localization tool like Gridly. That’s a great start for your game localization project but it doesn’t guarantee you top-grade translation.

If you want to get a high-quality game translation back, then here are a few tips to help you through the localization of your title.

Step 1: Prepare before translating not during

Think about localization before you start translating, not at the point you ask for text to be localized (or worse still, when it comes back). Here are a few pearls to consider:

  • You may need to adjust your design if you want to localize into Arabic or Hebrew (right-to-left languages);
  • You should always leave space for more characters in your interface. Your translations will almost certainly be longer than English (typically by 30%);
  • Have you tried out Asian characters in your game? Are they legible? Or are they just too small?
  • Don’t mix in-game text with the game code. Instead, store text in separate files.
  • Don’t try to create your own sentences from separate words. It simply won’t work. You can’t just construct a sentence in the same way as English. Just take the hit and translate each sentence you need (or think of another way to do it).
  • Use universally recognizable icons whenever possible - you’ll cut down the amount of text and reduce the number of linguistic bugs.

Step 2: Feed the translation team with plenty of information

So, the translator has your file with the game text, been told the game title and hopefully provided with some info on the game itself and platforms. Is that enough?

This can suffice if you’re happy with basic translation quality. If you want to receive superior game translation quality the translator needs to have a greater understanding of the game source text.

  • Who are the main characters (male or female)?
  • What are their communication styles (serious, old-fashioned, comic), dialects or accents?
  • What’s the time and the virtual world they are immersed to? What do they refer to?

Translators need this information both to follow your vision and to avoid grammar mistakes (in many languages, adjectives have different endings depending on the gender).

We sometimes receive a huge amount of information and that’s great. All too often, however, that the request comes in with very basic info and that is all.

Please, don’t be greedy and provide the game translator with as much information as possible before and during the game localization process. In the end, the result will impact the audience’s perception of your game.

NB: What about security?

If it’s something super secret then, by all means, get the game translators to sign an NDA. That said, however, the translator is fully aware that should details of the game be released and they are to blame then they will not be asked to work with you again (and they care about their reputation!).

Good to know: Most game translation companies have a trusted team (under NDA) that work on the game text.

Bonus: Primary check-list before game localization

These are the questions we ask our clients when we start working on a new title.

  1. Game name: Do you want this to be fully localized? Or perhaps just the tag line? Or perhaps you want the English in brackets after the localized title?
  2. Platforms: Now that’s an easy one.
  3. Languages: Ensure that you have been specific enough with which languages you wish to translate your game into. If you asked for Chinese, then most LSPs game localization project managers will ask which flavor you desire - Traditional or Simplified. However, if you haven’t researched which you need in advance, then this will delay kicking off the game translation (obviously).
  4. Overview: Tell the game translator about the title, the game genre, who the main protagonist is, what the aim is, etc.
  5. Demographic: Who is the game aimed at and what kind of language should it contain? Is this a kids game so the language used should be simplistic to understand?
  6. Age rating: Is this a game for the older market with some mild swearing? If the translator is aware of the target rating then the text can be localized to suit. Swearing guidelines vary in each country, so a clear indication is key.
  7. Video and/or code: If you have code or the game has been released in English already then great. The translator can usually download and have a play. This is of course not so easy for console titles. As a backup, it’s very useful to either provide some video or links to clips that can be found online.
  8. Screenshots/Video of UI: If you can provide a short video that contains footage of the UI then that really helps. The game translator can then understand how much space they have to play with. It will also help with context of strings.
  9. Previous translations: Is this a sequel or update? If it is then the translator really needs to see the previous translations. They are then able to check on whether certain terms should be translated or not (and also what they were translated to). An example: Loyal players will be quite upset if you have a character called “Demon Bob” in the first game who has now changed to “Devil Bob” in the sequel (for no reason).
  10. What should and shouldn’t be localized: If this is a first-time translation then you should have a list of what you do and don’t want localized. You may not, however, be the best person to make this call, so speak with your game localization partner.

You may have other reasons for not wanting to localize certain elements. For instance, certain text may feature in graphical elements which would take an age (and great effort) to localize. Point these out and let the guys know.

An example: You feature a map containing names of towns. If the map graphic cannot be changed then references to the towns featured in the translation should be kept in the source language. A translation shouldn’t refer to the “Shadow cliffs” in a localized form for instance when the player looks for this town they will have no idea where or what to look for.

Step 3: Decide on the style of special characters and variables

Now, let’s move to more specific stuff.

Does your game text feature special characters that must be treated in a certain way? Best to get this information in front of the translator.

For example:

  • Do you feature “\n” in the strings? Do you need to have a space before the “\n”? Are there rules to follow?
  • Are there certain characters that you cannot support? Best to catch them before they go in.
  • Quotation marks: which type can be used - “…” or “…”?
  • Perhaps you need to ensure that an ellipsis “…” is three separate full stops as opposed to the auto character that can be generated.
  • Is anything in square brackets to be left untranslated?

The more the merrier on these guidelines. If the game translator is fully aware of the limitations and rules, then the number of errors found at localization QA stage can be greatly reduced!

Pro tip: Prepare the glossary of terms and style guide. Simply do it in an excel or google spreadsheet, and share it with your game translator. Not only will you receive your translations faster but also this will eliminate the errors in a localized game.

Step 4: Provide string descriptions

When translators are provided with a file containing a collection of strings with no description or context, they find that there are so many unknowns when wanting to provide appropriate translation. What do they do? Use guesswork.

Sometimes context can be worked out if the String ID has a clear structure and points to where it will be used like “STR_KillEnemyBarkOrder001” or “STR_Xbox360ButtonPressOK”.

All too often, it’s not possible.

This is where description/information on strings is key. The earlier you provide it, the fewer questions you’ll receive from translator later.

A few examples for you:

  1. FIRE. What does it mean? Fire (as in ‘to shoot’, verb) or fire (as in the ‘logs/coal burning hot thing’, noun)?
  2. WATCH. To observe something or the timekeeper on your wrist?
  3. KICK. To kick an enemy protagonist or to eject a player from your mplayer game?

Then there are things like HAT and CHAIR (to provide two examples).

You should be clear in what kind of hat or chair it is as any languages will have specific words for different meanings. Is it a hat or a cap? Is it a top hat, deerstalker or bowler? With regards to chair, is it a dining chair, armchair, office chair, etc?

Clarity and context is key, it’s not the greatest advert for your game if the player is told to find a hat and the translation for this hat is very different to what they are looking for.

Step 5: Identify platform-specific strings

You cannot rely on the translation for a string being the same for an identical string in English. For example, the word “button” in Italian is different on PlayStation and Xbox. So you may have “Press a button” and assume that the translation for this will be fine for any platform. It will not.

Do try to get away from creating “this is for all platforms” strings.

You should, therefore, ensure that there are specific strings for each platform, and clearly label which platform they are for. Yes, there will be a fair amount of duplication, however, this is preferable to being told at the last minute that there are differences in the translation. You now have to code a new string into the mix to allow for the difference. This is something that can be avoided if planned for early in the process.

It is ideal if the target platform is included in a string description column or, at least, in the string ID.

Ensure that you have separated and duplicated strings with references to “Tap”, “Touch” and “Press” depending on the platform. “Tap” and “Touch” are regular terms when it comes to mobile platforms but very rarely used on consoles. If the game translation team regularly notifies the development team to point out an inaccuracy, the developers have to create a specific string which is a pain and can be mitigated earlier in the dev cycle.

Any problems found once in submission can jeopardize release date and corresponding PR and marketing you may have planned. A little extra effort in preparing your strings will result in minimizing the potential for this catastrophic event.

Ideally, your localized game and the following updates should be translated by the same person to maintain a solid style and keep track of adaptations. You don’t want users to be confused by different terminology on the fly after one of the updates, right?

That’s why it’s better to create a stylebook where you’ll fix all the localized names, buttons etc. and share with the localization experts.

Also, keep in mind that, on average, one translator does 2,000-2,500 words per day, so don’t leave your localization part until the last day before updates implementation.

In the next blogs, we’ll talk about preparing your script strings, max text length and how to work with game translators in the most efficient way.