# How to prepare a game for localization?

Many projects don't think about localization until the game is done. Then localization is done as a hack, and it's obvious that it was added on later. Some specific areas of concern:

• Text strings (obviously)
• Audio clips such as music and/or narratives
• Text rendered on textures (e.g. a label on a crate)
• Text rendered in frames in pre-rendered movies
• Fonts/Character sets for different languages
• Etc.

What are some good ways to prepare for these challenges in the initial development stages, so you can make it easier without incurring too much cost up front?

• I've been playing Dawn of Discovery - Venice lately, localized to English from German. It's about 99% correct . . . and every once in a while one of the characters inexplicably talks German for a line, or one of the building status reports has umlauts, or (once in a while) I'm informed that I can purchase a Debug Item from the local store. Whatever method you use, make sure it's easy to detect untranslated lines - if you have to read them over visually, or play the game and hope they show up, you're doing it wrong. – ZorbaTHut Jul 17 '10 at 13:58
• @ZorbaTHut Is the debug item a way to report translation errors, or did the DoD developers use a DLC to patch localization glitches? – Dan Neely Jan 18 '13 at 15:52
• Creating a fake language that your programmers can read and write can be beneficial. Google has a "hacker" language and Facebook has Pirate. Its fun for the developers, and it's something they can test on their own without learning a new language. – John McDonald Apr 24 '13 at 22:30
• To add to the above answers, I suggest you go through a round of pseudo-localization (essentially the formal name and process of the "Make missing localized text obvious" point in the top answer). You'll be able to eliminate potential implementation issues before translation even starts. – Anthony Jul 10 '18 at 3:30

I'm not an expert, but here's some basic stuff:

Make sure your strings can handle more than just ASCII

You're going to need some spécîål characters that don't fit in ASCII and your string class better not barf on them. UTF-8 is a common encoding because it's space-efficient. Whatever you do, test early and iron out the kinks.

It's a really good idea to use an actual string class and not just char * everywhere or you're going to be in a world of pain.

Don't forget your fonts. Make sure all of the fonts you're using have the characters you need.

Pull your strings out of code

This is the most important one. Make sure your text strings are all stored outside of code in some data file you can swap out. Getting a pipeline set up for this can be a chore up front, but will save you a ton of time later. You'll want some simple API so that any time you need a string in code, it's as simple as:

String text = Locale::getString("some unique identifier");


Don't concatenate or build strings in code

It's important not to make any assumptions about how a piece of text is built out of smaller words. Even something as innocuous as:

String currency = Locale::getCurrencyString() + money.toString();
// creates $123  is a problem because other languages may place the currency mark after the number. Instead, use format strings which are themselves localized like: String format = Locale::get("currency format"); // returns "${0}" in English
String currency = String::Format(format, money.toString());


That way, localizers can rearrange words within the format string.

Minimize the amount of text that appears in art, especially video

Forking art assets is a chore. You'll likely need to do it at least a little for some UI elements, but it's a hassle. Forking FMV is a huge pain because now you have to render and store duplicate copies of your FMV.

Test in different languages thoroughly

In most codebases, it's all too easy to just say printf("Hi there"); or loadTexture("someTexture"); and forget that those need to go through your localization API. Someone will forget and you'll end up with something that's correct in your primary language but wrong in others. The only way to find these is to have your testers test in non-primary languages.

Make missing localized text obvious

You typically translate your text late in the cycle, so for much of the time, there will just be no data for some languages. That's fine because it lets you iterate on your content without having to constantly retranslate. The downside is it means it's easy for you to miss things and forget to translate some stuff.

One cheap thing you can do is make missing text show up very obviously like "!!!TRANSLATION NEEDED FOR ID #blah blah!!!" in the game when it's missing.

Design your UI around the worst case language

Different languages tend to have longer or shorter words. A UI that looks beautiful in English may have text that runs past its boundaries, gets cropped, or wraps incorrectly in a longer language. You'll have to make UI changes to accommodate the worst-case language (or fork your UI, but that's probably not what you want to do.)

Annoyingly, English is often the shortest language of the ones typically localized, so your designers are probably inadvertantly designing for the best case. Make them use extra long text for their placeholders when they design. Assume any given piece of text can be about 30% longer than it is in English. Google Translate can be good for getting an approximate piece of text for placeholder.

Budget time for translation

Translating text usually happens late when the team is tired and doesn't really care. Nonetheless, you'll get a lot of bugs when it happens. Words will run past boundaries, translators will make mistakes, etc. To make matters worse, the turnaround time for iterating on text can be long if you have to send text to people overseas and wait for their changes. Allocate time for this work.

• Ah, concatenated strings. What a pain in the ass. Works great in the native language for building variety quickly and easily. But then you get into a language with a different grammar and it's a complete failure. All the other points are good ones too. 'Settings' in German was 'Einstellungen', which devours quite a bit of extra screen space when you need it. – Casey Wagner Jul 18 '10 at 5:41

In addition to other suggestions, one thing I've done in the past which helps greatly in finding translated text bleeding out of UI components is to have a special language mode for your game which, when displaying any string, looks at all the languages and picks the longest version of that string. That way, once you've made all the strings fit in that mode, you know that you've fixed all the text bleeds in every language.

Localizing a game correctly is damn hard.

You can browse the internet, read blog posts, or StackOverflow answers; you can learn the traditional i18n frameworks such as gettext; read Wikipedia pages on internationaliztaion and game localization; consult the excellent Microsoft language guide – but localizing games is actually harder than that. In fact, with games it's probably harder than with any other application or web-interface. This because the games are so much more dynamic, more vibrant, more alive (well, at least good games are).

More to the point, the following steps will probably need to be taken:

Establish the boundaries.

You want to make an all-important decision for which languages you want to support early. The wider your choice, the more assumptions about how a language can behave will be broken. Often these assumptions are so deeply imprinted in our brains, that we cannot even imagine that they may be incorrect without someone pointing them out. Which brings us to the next point:

Find the experts for each language you want to support.

Expert means someone who has sufficient analytic skill and knowledge of the language, that he would be able to point you which assumptions an English speaker does that do not hold in his own language. Then you'll need to come up with a strategy how to work around those assumptions.

As an example: in Western languages we justify text in a paragraph by inserting extra space between words. In Arabic language the text is justified by inserting kashida characters inside the words. It might look like this.

Another example: in Russian, there are 2 plural forms for the majority of words. Thus for example you would translate "1 coin" / "3 coins" / "5 coins" as "1 монета", "3 монеты", but "5 монет" . The actual procedure to decide the correct plural form looks like this:

function LocalRU::GetPlural(n, form0, form1, form2) {
return (n%10) == 0 || (n%100) >= 5 && (n%100) <= 20? form0 :
(n%10) == 1? form1 :
(n%10) <= 4? form2 : form0;
}


Create a context-aware translation module.

You're probably aware that translation always depends on the context. And you know that the context within a game changes all the time. What happens if we put these two statements together? In general your translations should be as dynamic as your game.

For example, a simple phrase "I agree" translates into Russian as one of "Я согласен" / "Я согласна" / "Я согласно", depending on the gender of the speaker (male / female / transgender|queer|questioning). If this is one of your dialog lines, then the language module will have to pick one of the possible translations at run-time depending on the gender of your character (assuming you offer your players such a choice).

The same phrase when translated to Japanese will again have different translations, depending on the level of formality of the relationship between the speaker and the listener. Thus, if you introduce in your game the idea of reputation, or friendship, or varying level of superiority (say, your character may evolve from Rookie to General), then you'll have to take this into account when forming the translation. (Actually, this is not Japanese-specific. Even in English, in the army you never say "Sir, yes, sir!" to someone below you in rank.)

Have a way to jump into the context.

Your translators should have the ability to see the context where a particular phrase appears. Sometimes the context is obvious, sometimes you have to see / hear / experience it yourself in order to translate something correctly.

Even such simple sentence as "This book is blue." cannot be unambiguously translated without me looking at the book and seeing which particular shade of blue it is.

Avoid word play, puns, and other language-specific elements.

Or maybe don't avoid, but at least have a strategy in mind for what to do when the wordplay cannot be translated. Because probably it won't.

At the very least you shouldn't create any quests / puzzles / game objects which rely on certain words having double meaning, or being similar to some other words. Because once translated you'll break your own game. (For example, in an old game Fallout2 the main quest was to find the object called GECK; there also were numerous "Gecko" monsters (mutated lizards) around the game; naturally they created multiple references and quests around this similarity of names, which made good translations extremely hard).

Cheer up!

Localizing a game is hard. But it's hard for everyone. If you make an effort and do it correctly, it won't go unnoticed by game critics in your target country. A game with good translation will stand out, and earn higher profits. After all, text is just as important for creating atmosphere in the game, as the graphics (this is why old text-based RPGs were so immersive).

• Alternative to "avoid word play" is to include a creative writer in a language translation team and allow them to modify the literal meanings. FFXIV does this extraordinarily well for their English version, as a good example. – Patrick Hughes Feb 13 at 0:28

Wil Shipley has by far the best guide on localization I've ever read. Unfortunately it's iPhone specific, but one can still derive commonly useful information. Further, he addresses the localization of assets and the UI - two of the bigger challenges in game localization I can imagine.

Always, ALWAYS treat the source language as a localized language.

So if your source language is EN then keep all EN assets and strings in a separate EN folder and pull from there.

Pull EN assets through your intended localization pipeline.

By doing this one simple thing you'll catch maybe 80% of localization issues and be set for a much easier localization process.

I've localized many games and always lead with this nugget.

I see some really great tips here!

I'll try to make a list of the most common mistakes that can range from making your localization harder to completely ruining your game:

• Thinking of localization as the last step of game development
• Not isolating your text strings from the source code
• Concatenation/linebreaks in the middle of a sentence.
• Assuming times, dates and units don't need localization
• Not providing enough reference material to translators/Not answering their questions
• Assuming all text from your game will be in ASCII
• Having text in visuals
• Having rigid text/UI boxes
• Assuming all languages have the same length as English
• Ignoring cultural factors
• Not allocating enough budget for localization

Localization should be integrated to the development as early as possible and you should always keep it in mind when designing a game.

With the right planning and careful market research, you will save yourself a lot of trouble and expenses further down the line.

I happen to be the founder of a game localization company and we covered the preparation of a game for localization a couple of months ago in our blog.

Here's the infographic that sums up that post: https://magic.piktochart.com/output/18317297-9-steps-to-cheaper-game-development-with-localization

The link to the full post that covers those tips in more details is at the bottom of it.

## protected by Community♦Feb 12 at 15:45

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).