Developers - Make your game localization friendly: A few tips (Part 2)

This blog was originally posted on Localize Direct's blog on Sept the 10th, 2015.

Developers - Make your game localization friendly: A few tips (Part 2)

Intro

In the last blog about game localization I talked about making your game text localization friendly; focusing on introducing your game properly (overview, age rating, target audience, context of strings, special characters and platform specific text). It’s all very important if you are looking to achieve a high quality game localization. If you’d like to check the first localization step out you can find it here: Developers make your text translator friendly (Part 1)

In this blog I will focus on ensuring that dialogue is defined in the most appropriate way. I will look at max text length and include a quick note at the end on handing translator questions.

Dialogue

We often receive requests that have an amount of text that is dialogue related. Not necessarily to be recorded in the studio but perhaps to be used as subtitles, or perhaps used in place of the English text used in the game (also not audio). It’s regularly all in the same sheet/file and mixed in with all the other text. This creates a number of basic problems:

Those are just the basic issues. Then we have issues based on:

Setting up your strings

To tackle these issues, you initially need to plan where these strings will be stored. You could of course use a game localization tool (like our LocDirect system) that separates these strings into folders. However if you want to stick with old skool files then it’s best that you work in a spreadsheet. In my humble opinion please steer clear of .txt files.

Create one sheet that contains the “ingame” text and then another that contains “dialogue”. Alternatively if you want just the one sheet then you should clearly separate ingame and dialogue within that sheet. Your call but make it clear.

I’ll go with the separate sheet concept for now. The ingame sheet should contain columns for the String ID, Source text, String description and then Order. Some ingame text may have a specific order, however if the ID doesn’t feature that order then this can be missed.

The translator could decide to sort the text in a different way or perhaps use a separate system for translation which may order on ID. This is very possible!

For example:

Now if reordered on StringID:

OK it’s a pretty simplistic example but you can see that the “fire” ability will be translated differently depending on the understanding of how fire is used. Whether to start a fire or whether to open fire on the enemy. If you include an “Order” column then this can be used by the translator to understand context. Alternatively you can add a number prefix to all strings.

So even if sorted on ID they will be in the correct order. Note that you need to ensure that there are enough digits to allow an effective sort. If you have just 1, 2,11, etc. then these will not sort correctly as 0001, 0002, 0011, etc. would (obviously). I would recommend that you step in 10s instead of just 1. For example: string_0000, string_0010, string_0020 etc. This then allows you to add strings in-between without having to rename all strings or add an a,b…

Understanding the context of the dialogue

The string description column here is of great use. The order of the strings helps with an understanding of dialogue flow and context. However in many instances there may be additional information that you can provide so that the translator is aware of what is intended by the string. Is the person meant to deliver in an urgent manner? Is the person irate, joking etc.

Additional columns for dialogue

So we have the ingame sheet and all is looking good. Then we have our dialogue sheet. You should add at least two more columns here (of course up to you on whether you feel there are even more that would help with translation).

These are:

Speaker - Who the line is delivered by (add the gender of the character).

Recipient - Who the line is being delivered to (character name/group and gender needed).

An example here for you, note that not all columns from the dialogue sheet are shown here (no String ID, description etc.).

Of course putting this kind of information together can take some time but can certainly be worth the effort. You want to receive the best quality translations and minimise on error and translator questions. You may want to look at using a CMS system that allows you to add custom fields!

That said however you can scale this detail back if time really is against you. As a basic rule you certainly need the Speaker name (and gender) and Recipient gender information to help with translation quality.

Gender in dialogue

On the subject of gender, in some languages women use different words and styles than male counterparts. When you have M/M, M/F, F/M, and F/F dialogue, all of those can be very different strings. In some cultures men use a more forceful language and women more deferential, but then can reverse the forms in certain situations, like an older woman or mother speaking sternly to a young man. When it comes to three person and four person discussions, the gender of speakers can make things really tricky for translators.

Video/Audio reference

Supplying video or audio files separately is a great way to improve quality and cut down on questions. If you do supply these though, ensure that it’s easy for the translators to reference the string with the file. It’s extremely painful trying to find a string when it’s in a long video or in a large number of audio files.

If you do supply reference files then it’s a great idea to include a timecode column in the dialogue spreadsheet/tab.

Also note that sending massive 2GB files is a pain, the translators don’t need 1080p quality video to review audio (or even text). If you can compress then that’s a great idea.

Max text length

All too often the request is to “keep the translations to the English text length”. This is next to impossible to do. Most other languages are longer than English and if you have structured the display so that English fits “just right” then you are going to have problems. Check out this interesting blog on the subject: The "Same length as English, please" Fallacy

If you have a scaleable font then that will help, but you may find that the length of the string will mean that the text then becomes illegible. You should really budget for a 30% minimum additional space to accommodate other languages. Note that even this may not be enough.

Line breaks in subs

If you have a max text length for subtitles then you may want the translator to introduce line breaks. Note that the line breaks in translations are usually not going to be in the same place as the English so ensure you are flexible.

The best way is to use something like \n to denote where translators feel the line break should be. Line breaks performed at the developer should be discouraged as it regularly leads to phrasing that appears and sounds very clunky. It also sometimes break up phrases that shouldn’t be split. There are also instances where your code may split a word that has a hyphen and drops that second part to the next line. This results in a hyphenated word being split across two lines which looks pretty bad (and spoils flow).
 

Translator questions

So translator questions, unfortunately a necessary evil! Believe me, translators don’t particularly want to ask you questions. They are however professional and most want to do a great job for you. Asking questions isn’t fun and is actually a negative for them. It adds time and effort to the project and they aren’t paid any more for it. Just worth bearing that in mind. They have to ask them, you have to answer them. So the more information they can get at the start, the better for everyone involved!

That said however, even with the greatest preparation, there are almost always translator questions. And usually the larger the word count the greater the number of questions posed. That’s not a rule as such but certainly a trend I have experienced on many projects.

So how do you plan to receive, answer and return these queries?

You often find that what may appear to be a straight-forward string to one person may not be to another. However the query answered may then lead other translators to reconsider their original translation. It’s is therefore a great idea to expose these queries to all translators working on a project. You can do this by sending around an excel file but this is a massive massive pain. You need to coordinate the file and this is extremely time consuming. My suggestion is again to use something like our LocDirect tool or alternatively use an online spreadsheet. Something like a gdoc spreadsheet would do the trick. Then just give access to all the relevant people working on the project. The beauty being that it is easily accessed by the team, so there’s no need to send actual copies anywhere (and creating even more work).

So a few things to think about there, time spent on defining and providing information to translators is no waste at all. It will improve the translation quality, improve the player’s impression of the game (and ultimately perception of your studio) and also cut down on translator questions.

Hopefully you’ll have found some (if not all) of this of use. I will be following this up with another blog soon. We also have a number of other blogs on game localization on our website:

LocalizeDirect Blogs

If you would like to follow updates on Twitter then search for @LocDirect. More updates and posts to come.

All the best!

Mike