Game translation is more than putting together a text file with the game text, to then be pushed into a game localization tool like LocDirect. You’ve put all the game text together in a nice Excel, gdoc or game localization tool and that’s a great start for your game localization project. But that doesn’t mean your game is ready for game translation.

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

This game localization blog post contains two sections: Introduction to game localization and Importance of context and description on strings during game translation.

Introducing your game properly

The translator has your file with your 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 to receive basic game translation quality. If you want to receive superior game translation quality the game translator needs to have a greater understanding of the game source text.

We sometimes receive a huge amount of information and that’s great. It’s all too regular however that the request comes in, very basic info is provided and that is all. It really makes a lot of sense to provide the game translator with as much information as possible before and during the game localization process. It is greatly appreciated and you really don’t need to be too worried about security. If it’s something super secret then by all means get the game translators to sign an NDA. That said however, the game 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. Most game translation companies will have a trusted game translation team (under NDA) that work on the game text.

So with regards to the game translation information, are you able to supply the following?

Game name: Nice easy one eh? Although do you want this to be localised? Or perhaps just the tag line? Or perhaps you want the English in brackets after the localised title?

Platforms: Now that’s an easy one.

Languages: Ensure that you have been specific enough with which languages you wish to translate your game into. If you just asked for Chinese then most LSPs Game Localization Project Managers will ask which flavour you desire. However if you haven’t researched which you need in advance, then this will delay kicking off the game translation (obviously).

Overview: Tell the game translator about the title, the game genre, who the main protagonist is, what the aim is, etc.

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?

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 localised to suit. Swearing guidelines vary in each country so a clear indication is key.

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.

Screenshots/Video of UI: If you can provide a short video that contains footage of the UI then that really helps too. The game translator can then understand how much space they have to play with. It will also help with context of strings (see below).

Previous translations: Is this a sequel? 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). 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).

What should and shouldn’t be localised: If this is a first-time translation then you should have a list of what you do and don’t want localised. You may not however be the best person to make this call, so speak with your game localisation partner.

You may however have other reasons for not wanting to localise certain elements. For example, certain text may feature in graphical elements which would take an age (and great effort) to localise. Point these out and let the guys know. An example is if 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 localised form for example, when the player looks for this town they will have no idea where or what to look for.


Guidelines on special characters and variables:

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:

  1. Do you feature “\n” in the strings? Do you need to have a space before the “\n”? Are there rules to follow?

  2. Are there certain characters that you cannot support. Best to catch them before they go in.

For example, only a certain type of quotation mark can be used?

  1. Perhaps you need to ensure that an ellipsis “…” is three separate full stops as opposed to the auto character that can be generated.
  2. 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 later can be greatly reduced!

Description and Context

All too often translators are provided with a file containing a collection of strings with no description or context. As a result they find that there are so many unknowns when wanting to provide appropriate translation. Should they speculate and use guesswork to base their translations on? Hmm, we don’t think they should. Sometimes context can be worked out if the String ID has a clear structure and points to where it will be used.

“STR_KillEnemyBarkOrder001” or “STR_Xbox360ButtonPressOK”. All too often however, it’s not possible. This is where description/information on strings is key. You may think that this is a pain and not really worth it. It really is worth it. If you are willing to spend money on game localization then shouldn’t it contain the correct translations? Providing the context and further information will also cut down on the number of translator questions you receive later on, isn’t that worth it?

A few examples for you:

  1. FIRE. What does FIRE mean? Fire (as in to shoot) or Fire (as in the logs/coal burning hot thing)?
  2. WATCH. To observe something or the time keeper 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. Many languages will have specific words for the type of hat or chair. It it a hat or 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.


Platform specific text

How will the game translator be able to tell which platform the text is for? This is a very popular type of problem that generates a large number of translator questions. Again if in the String ID then that certainly helps. If the target platform is included in a string description column then that is ideal.

Do try to get away from creating “this is for all platforms” strings. You cannot rely on the translation for a string being the same for an identical string in English. For example, 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. 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.

You also need to ensure that you have separated and duplicated strings with references to Tap, Touch and Press depending on the platform (for example). Tap and Touch are regular terms when it comes to mobile platforms but very rarely used on consoles. Again a popular area where game translation team will regularly notify the development team to point out an inaccuracy. Once pointed out then the dev team have to create a specific string which is a pain and can be mitigated earlier in the dev cycle.

It’s extremely important that these platform specific strings are identified. Any problems found once in submission can jeopardise release date and corresponding PR and marketing you may have planned. The importance cannot be overstressed. A little extra effort in preparing your strings will result in minimising the potential for this catastrophic event.

In the next Blog; preparing your script strings and max text length considerations.