Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Preparing games for localization involves a lot more than separating content from code. Here's a primer on designing for, and working with translations, and how to avoid come common pitfalls.
Torgar's Quest is my first title to be published in other languages than English. I am stoked and nervous at the same time, because seeing my game in other languages is just awesome, but in my day job I work as test lead in localization testing, so I also know how many things can go wrong.
To help myself and other game developers who are considering getting their games localized, I have put this list of Dos and Don'ts together.
The first thing you need to do, if you want to localize your game, is to replace all hardcoded strings with a script that pulls it from a data source. When a string is needed, that script is called using a reference to pull the right bit of text.
For Torgar's Quest, I have a script that takes 2 arguments; a filename and a number. The filename refers to which file the string is in (see below for more on that), and the number indicates which line the string is on in that file. The game loads the language setting into a variable at the beginning, and this variable is used in the script, to pull the right translation.
To stay organized, consider splitting the text assets into multiple files, divided by area in the game (or in some other logical way). For instance, you can keep all menu strings in one file, and the in-game story strings in another. Splitting content into categories like this, makes it easier to find specific strings and to reference them in the code and when communicating with translators/testers. Staying organized is key once you start asking others to work on the localized content.
Many things you take for granted in English might be completely different in other languages. English uses a lot of short words, for example, but this is not true everywhere. For instance, German has lots of really long words that may not fit on tight buttons. Japanese is different again, with its own rules for text wrapping. These are things to research and keep in mind when designing menus and UI elements.
Quick tip: Use W to see how many characters fit in a text box, as it is the widest character in the Latin character set.
Besides making room in the UI, you will also want to make sure that the fonts you are using contain all special characters and diacritics used by the languages you intend to include. Obviously, trying to display characters not included in the font set, will not work out in your favor.
Metric system vs. Imperial? If your game uses distance, weight or other measurements, you better make sure the right format is supported. Don't assume that a Swedish gamer is familiar with how far a mile is (and just to make things even more complicated, try looking up how long a Swedish mile is). The same goes for time. You might be used to a 12-hour clock (am/pm), but in many countries the 24-hour clock is standard.
Date formats and decimal separators also differ from region to region. For example, in the US people are used to seeing MM/DD/YYYY as the standard date format, whereas in Europe it is typically DD/MM/YYYY. When displaying a date like 1/10/2015, this distinction becomes important. Decimals and thousand separators are a similar difference. In the US, people use a format like 1,234.5 but in other countries it might be 1.234,5.
Never rely on translation without context. If you can't provide a copy of the game itself, at the very least provide some screenshots and a design document, describing the game. This is important, because words can often be translated in many different ways, some of which will certainly not match the context of your game. These issues will not be caught by a spellcheck, or someone looking at a list of strings, and could end up making your translation nonsensical or even involuntarily hilarious when seen in the game.
On that note, do not ever rely on auto translation. Google translate does not understand what your game is about, nor can it look at a screenshot, and it's just not good. Don't do it. Ever.
Context is also helpful in cases where you are using puns, pop-culture references or other linguistic finesse in your content. Such strings may need a complete retranslation to work in the intended market, which a good translator should be able to do - but only if they are aware of when it is needed.
Once you begin separating the content, you will probably realize that there is a lot more written content that you thought. These take time to translate, and after you've integrated the localized content, you are still only halfway done. Next up is the localization testing.
In a perfect world, you will have someone who is a native speaker, but not the same person who translated the content, testing the game with its localized assets implemented. This person will need to cover every area of your game, and see every single string in place, to check for things like consistency (did you translate XP the same way everywhere?), grammar and typos, things out of context or strings you missed, when you were separating the content.
Each issue needs to be described, logged, evaluated and fixed. Then the fix needs be put in, so a new build can be sent back to the tester for verification. This process takes even more time. Make sure you plan for it. These are some tips that will hopefully put you on the right path.
As for which tools to use, that depends on the size of your team and your project. I use a combination of spreadsheets, text documents and Trello, which I may cover in a later post.
This post was originally published on rasmusrasmussen.com.
Read more about:
Featured BlogsYou May Also Like
