Developers - Make your text translator-friendly - A few tips (Part 1)

This blog was originally posted on Localize Direct's blog on Feb the 12th, 2014.

Developers - Make your text translator-friendly - A few tips (Part 1)

Intro

Putting together a file with all your strings may sound like enough to then push into Loc. You’ve put it all together and it’s in a nice excel/gdoc/loc tool etc. Right then, time to send out. Although a word of warning, is it all really ready to go? Will you get the best possible translations back? And will it all be accurate and bug free? Here are a few tips to help you along the way. This blog contains the first two sections, Game Introduction and Importance of context/description on strings.

Introducing your game properly

The translator has your file, been told the title and hopefully provided with some info on the game and platforms. Is that enough? This can suffice if you plan to receive a basic translation result. If you want to receive superior quality the translator needs to have a greater understanding of the 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 translator with as much information as possible. 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 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. Most translation companies will have a trusted team (under NDA) that work on the text.

So with regards to the game 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 require. If you just asked for Chinese then most LSPs will ask which flavour you desire. However if you haven’t researched which you need in advance, then this will delay kicking off the translations (obviously).

Overview: Tell the translator about the game, 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 then 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 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). It’s quite an error if you have a character called “Demon Bob” in the first game who has now changed to “Devil Bob” in the sequel.

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 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 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?

3. Perhaps you need to ensure that an elilipsis “…” is three separate full stops as opposed to the auto character that can be generated.

4. Is anything in square brackets to be left untranslated?

The more the merrier on these guidelines. If the 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 such they find that they are none the wiser when it comes to appropriate translation. Should they speculate and use guesswork to base their translations on? Hmm, I 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 to localise your game 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 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 also 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 PS 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 translators will regularly notify the team to point out an inaccuracy. Once pointed out then the 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.

End