Localization for Game Development

Today’s topic is going to be on localization. Even though it does not directly relate to Unity, and is a general game development topic, it still covers an important game development step that can give you a huge boost to your audience. I highly recommend localizing your game into as many languages as you can afford, generally the cost of localization is far less than the total cost of developing your game, and can be a good way to squeeze some extra money out of your finished game.

Localization in gaming is the process of translating and releasing your game in other languages. Localization lets your game reach a larger audience, increasing your fan base and potential sales. With proper planning and setup, it can also be relatively inexpensive to localize a game. Because I am an English speaker, I am going to largely write this from that perspective. If your primary language is not English, hopefully you can swap languages around in your head as you read this article and have it still make sense.

Why do you want to localize your game? This Wikipedia page breaks down languages by number of native speakers: http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers. If you look at just Spanish and Portuguese, two languages that mostly share an alphabet with English, they add up to over 500 million speakers. While not all countries will spend as much on average on gaming as the US, that is still a gigantic boost in audience for a relatively small investment of supporting two more languages. Support more of that list, and your audience just keeps growing.

What languages should you localize to? Generally you want to start with the languages that share as many characters with the language you started with as possible. The big group of languages for this is often abbreviated to EFIGS: English, French, Italian, German, Spanish. In the past, when games were only physical goods that needed to be manufactured and shipped, these languages covered countries game developers could expect to ship games to. Nowadays, digital sales have allowed developers access to more countries than ever, and you are going to want to add Portuguese and any other languages that share much of the standard alphabet represented in the American Standard Code for Information Interchange (ASCII). Jumping alphabets can become expensive, you might need to upgrade your text rendering technology to support Unicode, and will need to source fonts for these alphabets. Fortunately this can also be lucrative, adding Korean, Japanese, or Chinese language support to your game brings a large number of potential customers. A final note on selecting localization languages, you might wish to do regional translations of the same language. Many games release with a separate localization for American, and United Kingdom English. This is done for spelling differences between the two, such as color and colour, as well as other localization concerns, maybe you want American voice acting for the US release of your game and British voice acting for the UK release. The final language set to think about is silly languages. Sometimes, when you have an entire localization pipeline figured out, you realize you can easily put in new languages, even if they are not spoken by anyone. The most common one developers choose is the “pirate” language, adding a lot of nautical puns and “arrrrs” to the text. The task of writing this language can also be done as a collaborative team building exercise, or as a side task people can work on when they need to blow off steam.

What is the best way to reduce localization costs? Remove as much content that will need to be localized as possible. For some games, such as RPGs, this is probably a poor idea, you probably want a lot of text. For other games, such as puzzle games, it might be possible to remove all in-game text, leaving your localization needs at only the app store description. It might seem difficult at first to remove text, especially from your tutorial. This is where iconography and animation can really help your game out. If you are building a card game, the first pass of your tutorial might have a popup that says “Drag a card from your hand to the play area.” This can be easily changed to remove the text dependency, by instead having a graphic of a hand on screen that mimes the action you wish the player to perform, making a pinching motion towards a card in their hand, then sliding up to the play area. These changes might even improve the quality of your tutorial in your native language, it can be easier to follow these icons in any language than following verbose text.

What features gets localized in games? You can break localization tasks into a few sub categories. Rendered text, speech, graphics with text baked into them, game content, and outside of game resources such as instruction manuals and app store descriptions. Everything but the content portion will involve translation, localized content is done to address issues with releasing your game within a country, such as the “no skeletons” rule for China, or changing blood to green for releasing in Japan.

You want to minimize the amount of content with text baked into it you will need to localize. It is very time consuming and costly to create multiple copies of art assets for different languages, and it is difficult to iterate on this content. Often times developers do cave in and have localized title screens, with a stylized rendering of the title of the game. It might seem obvious to avoid baking text into art assets, but an artist might want to put some humorous text onto the texture of a building, or design might want the hit response effect to have a visually stylized “POW” in it. An important thing to note here is you do not need to localize all text. It might not be worth the development cost of getting a stylized “POW” graphic created for every language you support, and the intended effect of the asset might still work for non-English players, anyways.

Speech and audio are a tougher thing to localize. You will have to go through the same process you went through for setting up the voice acting for your native language, choosing actors, and recording the dialogue, as you did with the voice actors for your native language. This can get expensive quickly, especially if your game is of the size you are working with Screen Actors Guild voice actors. The most professional option is going to be to fully voice your game in as many languages as you can. If this is out of reach, then what some developers do is leave all dialogue in English, and make sure to run subtitles throughout the game in all supported languages. The final option you have is disabling voice acting in languages you do not have dialogue for, replacing it with subtitles and text popups. The last option does not work if you have any pre-rendered movies or lip synced dialogue, as the moments where the camera is pointed at someone’s face while they are saying nothing will be off-putting. However, if your dialogue is only a narrator that is reading text printed on screen anyways, then it might not be a big deal to drop the voiced parts in other languages, as the text is still there on screen. I only recommend dropping the native language voice acting for no voice acting if there are reasons preventing you from releasing a game with English voice acting within a country, or if the contracts of the English voice actors make it difficult to do so.

On screen text is where the brunt of localization occurs in games. For most developers, the first game they build they give no forethought to localization. The first time an opportunity comes up, these developers will quickly realize how frightening it will be to go through their entire codebase to find all the strings typed up of text. The first rule of localization for a game engine is you need a single funnel point that all text in the game goes through. This provides you an easy place to check what language the game is set to, and return text based on that. It also will vastly improve your workflow: all of the text in your game is now stored within a database instead of hardcoded. This lets you potentially re-use text strings, and makes it much easier for the development staff to change and update strings. A note on re-using text strings: while it might make sense to use the same word or phrase in two places in English, be aware that this might not be the case in other languages. This brings up another great addition to a text database: comments and notes for text strings. You will make the life of the people localizing your game much easier if you provide them context for where text strings are displayed in the game, and any special notes on them. Something most people don’t think about is, when you make a text handoff to localization, the order of the strings in the file is probably not the order they appear in the game, and there might be things the core dev staff know and understand that do not get told to the localization staff. An example of this would be if a character has a secret, unknown name for most of the game, and they are most often referenced by another moniker, such as “the great evil.” The localizers might not be aware of this, and might accidentally spoil the big reveal if you do not give them detailed notes, they might be going through the text file, unaware of which lines the player would know the name of the enemy, and which they only know the term “the great evil.” From this information, you probably have a mental picture of a fairly simple text database. Your game code that displays a line of text in a dialogue box might extract the string for this as “string textToDisplay = Localization.LocalizedString(keyValueForTextToDisplay).” The steps of checking your language and pulling this information out of the database are handled internally to the Localization class.

Not all language in a game is so static. Maybe you have a shopkeeper who says “Thank you for purchasing _specific item_!” whenever you make a shop purchase. The slow and expensive solution here would be to have that string entered into your text database for every potential item the player can buy. Localizers generally charge per word, or per line, so if you can avoid bloating out your localization database with unnecessary strings like this, you will save yourself money. The first solution you might attempt here is string manipulation. Maybe assemble the string as “textToDisplay = Localization.LocalizedString(ThankYouForPurchasingKey) + Localization.LocalizedString(ItemNameKey).” Grammar and sentence structure are not the same in every language, and even in English this might lead to some really awkward phrases in your text database just because someone wanted to add some strings together to form a text popup. What you want here is a system like String.Format that takes in special characters to build a more complex final string. The term MSDN uses for these are format items. This will take some extra work writing the “Localization.LocalizedString” function, but your writers and localizers will be so glad it exists. The previous thank you string might end up looking like this in your English database, “Thank you for purchasing {0}, have a nice day!” with a function call of “Localization.LocalizedString(ThankYouForPurchasingKey,/*argument 0*/ItemNameKey).”

Using format objects like this for your text system also will put you down the path on building other wonderful improvements to displaying strings in your game to the player. The next one you will probably want will be a color value, so you can put {Blue} {/Blue} around key words in dialogue to make them stand out. You can even eventually build this into a really fancy system, providing other visual effects, such as text that shakes or other ways of communicating the emotion of a word through how you render the text.

Generally the pipeline for localization is: game text is gathered into an excel spreadsheet file to be shared with the localizers. One column is the identifying string for the text, the key value in the database. The second column is the text in English. Any more columns in this original document are notes and comments to give the localizers information on where the string might appear in game, or the context of its use. I would also recommend adding a column on localization status of each string for each language. The first game you localize you might only be able to work out a single text drop from your localizers, but in future games you will hopefully be able to afford some back and forth and iteration on your localization. A localization status column lets you track what has already been translated when you do an updated text drop, and will let you keep the localizers from charging you for localizing strings they have already handled. Once this spreadsheet file is sent to the localizers, they will fill it out and send it back to you. At this point, someone on your team will update the localization status of your master localization spreadsheet, and will put the updated localized text into your game’s text database. The first game you build, the process of getting your game text to the spreadsheet and back might be a manual process. I do recommend automating as much as this process as possible. User error can be a big factor here, someone might forget to update a few strings from a specific language, or might accidently enter all the strings off by one index. Writing an Excel spreadsheet macro that can output your text to your in-game text database will prevent so many of these errors. Another recommendation I have is making the Excel spreadsheet the master text source, and force all text changes to be made in the game to happen there. Some people prefer to make this a two directional street, having the spreadsheet update from changes made to the in-game database so developers can more rapidly change strings. When it comes to pipeline, I prefer one directional movement. For any tools pipeline, the moment you allow users to make changes on either end, you have to write a vast amount of code that can identify changes made to one version of the data and update the other version. This is just personal preference though, and many developers prefer a pipeline, especially for localization, that allows changes to be made both in the spreadsheet and in the game development environment.

Multiplayer games, even if it is indirect and just some simple leaderboards or content sharing between friends, throws a large monkey wrench into the localization process. The easy answer might seem to be to lock things down by language, and not allow users to participate in multiplayer with users set to other languages. This is unfair to your users, as many people have friends who might have their system set to a different language. You might also run into users that play your game with the language set to a few different settings, maybe they try playing the game in their native language first, but if they don’t like the translation they switch to English. If most of your game just checks what the local language is set to, you do not have to worry about most of the steps of localization. The only part where multiplayer can become tricky is with custom content. If the users are able to input strings, the most common being a user name, then you will want to ensure that all languages can load up the complete fontset your game might support, so they can render the names of users from other regions. Worst case, if memory is a concern, and you only want to have native fonts, you can have a fallback character or string for when a user name comes across that a player cannot render with their loaded fonts.

That covers the basics of localization, and will hopefully bump you forward a few projects worth of iteration on localization ideas and techniques. I’m sure you’ll also have a much happier audience if you release in more languages than just English.

Advertisements
About

Joseph Stankowicz is a software engineer who has worked in the video games industry for over eight years. The last two years have had a heavy focus on Unity development, where he helped ship over eleven titles to iOS and Android platforms. He also is really excited about 3D printing, and keeps his Solidoodle 3 printing out stuff as often as possible. You can view his LinkedIn profile here http://www.linkedin.com/pub/joseph-stankowicz/60/294/420

Tagged with:
Posted in Unity3D
One comment on “Localization for Game Development
  1. […] East 2011 localization panel 22 Tips for Better Game Localization (Epic Sound Audio Production) Localization for Game Development (Joseph […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: