Game Localisation Tips
Avoiding common localisation pitfalls
Most people are aware that developing any commercially successful game or software project requires quality localisation. Yet, localisation is frequently slapped on carelessly moments before release and teams are often overwhelmed by the amount of effort that goes into localising a game to a high standard.
Localising well is hard. I would argue that it’s one of the most challenging parts to get right during development. It involves multiple disciplines (Engineering, Art, UI, Design). It requires knowledge of cultural differences and norms, commonly used local gaming terms, and a strong command of linguistics.
Excellent localisation is much more than just having words on the screen translated into the correct language. You’ll need to navigate through tricky problems, even if you are working with an external partner.
Having worked on many projects that involved multiple languages, I’d like to share with you some things you should consider for your next game.
Winners start early
Begin the localisation process as early as possible. Decide which languages to support and which fonts to use as soon as you can. Come up with a solid localisation workflow for Designers and Engineers.
You make fewer compromises by starting early — I once worked on a project where localisation was an afterthought, and we only began implementation a month before launch. By the time the translators got back to us, we only had a few days to localise the game. Starting late led to issues like languages not rendering as intended, text bleeding over UI elements, and missing translations.
Knowing what languages you’ll need to support early on has a huge impact — this will determine which fonts you use, how to design your UI, and what parts of your game should or should not be translated.
Take some time early on to plan your localisation strategy, so that you spend less time fixing issues later. This can save you a ton of time, money, and tears, and avoid painful situations like needing to overhaul your UI, or replacing scripts and fonts in the middle of the project.
Test often, and test in different languages
Regular and frequent testing might be the most important tip of all. Text is often translated while features are still being prototyped, so translators don’t have the full context of how the text will be shown in the game.
Where possible, get your team to test the game in different languages throughout the development process. You can’t rely solely on an external Localisation QA team to catch all the issues. The turnaround time might be too long, and your own team understands the needs of your game much better than an external vendor.
At Mighty Bear Games, we are fortunate to have a diverse team with good coverage of native speakers for many languages. Look for friends or family that can speak the language, even if they are not experts. They can often be good sounding boards for whether or not certain phrases seem off or out of place.
Don’t hard-code text
“Hard-coding” is a software development practice where you embed information or data within your game which can’t be modified or replaced easily without altering the code of the game.
Text changes often during a project. You’ll continuously be updating, modifying and testing new strings. Embedding text in code makes it hard to move fast. You’ll want to store your text in a file that can be easily accessed or modified by anyone. This can be anything from a .csv or even a Google Doc. Set up a good workflow for working with these files with your team. This also helps you prevent versioning or redundancy issues (where people in the team aren’t working with the latest version of the file) and keeps your engineers and translators happy.
Fonts
Select which fonts you want to use for your project early. Not all fonts are created equal. Many typefaces are not capable of displaying spécîål characters and some might not support all of the languages you are localising to.
While most well-designed typefaces support a large number of languages, it’s not likely you’ll be able to find a single typeface that covers every language, especially if you need to support Cyrillic and Asian characters. Google Fonts maintains an excellent catalogue of fonts, so it’s usually a good place to start.
Character encoding also plays a big role when you are optimising your game for performance. Some languages might contain thousands of glyphs that need to be stored in memory and will affect the performance of your game. Work closely with your engineering team to decide the most efficient way to support all the languages that are required. Depending on how text-heavy the game is, you might choose to only support a limited set of commonly used characters. Whatever you do, test early and iron out the kinks.
Pro tip: One of the ways we reduce font size in memory is by using Signed Distance Field fonts(SDF) and rendering. These support multiple sizes and styling, and use a single bitmap along with a shader to render the font. To find out more click here.
Stop putting text on images!
Sometimes, having a large amount of text in the game cannot be prevented; what you can avoid is embedding text directly onto images or art assets. Text that is baked into images or promotional art cannot be localised or updated easily, so it should generally be avoided. Even if your UI artist thinks it’s a fantastic idea.
Dates, Times and Units
Don’t assume that times, dates, and units don’t need to be localised. In fact, don’t make any assumptions about how a piece of text is built out of smaller words. For example, some languages show the currency symbol at the end of rather than the beginning. ($1000 vs.1000€) The terminology used to denote date and time also differs from language to language (e.g., The standard format for dates in China is 2020年1月15日, in the US it’s 1/15/2020 and in the most of the rest of the world the same date will look like 15/1/2020).
Make sure you consider how these strings are displayed in your game and ensure translators have the necessary freedom to rearrange these as required.
Right to left, left to right
Some languages require you to support right-to-left script. (e.g., Arabic, Hebrew, Urdu). You’ll need to pay special attention when supporting these as they can be tricky to implement correctly.
In a right-to-left script, the text is justified to the right instead of the left. This affects the look of your UI, so it’s essential to factor it into your design. Most of your numbers, dates and units will remain left-to-right if you use modern numerals. Punctuation may sometimes not render in the correct order as well.
Ensure that your entire pipeline is set up to handle right-to-left script correctly, and test frequently and often. Triple-check the text when copying or pasting it from one document to another as some text editors don’t handle right-to-left text correctly.
Pro tip: You can avoid a world of pain if you need to support both right-to-left and left-to-right by centering your text.
##REPLACE THIS PLACEHOLDER STRING##
Typically, the text is only finalised and translated late during development. It is common for most teams to include placeholder text for many features as the game is being developed. However, it is easy to miss placeholders and sometimes forget to translate them. These issues can be hard to discover during testing if the tester does not realise that the text is a placeholder.
Pro tip: One easy thing to do is to make missing text extremely obvious. You can build code that displays placeholder text in neon pink or mark the text as clearly placeholder (e.g. ##PLACEHOLDER STRING##). This will make sure you don’t miss untranslated text strings.
Plan your UI around the worst-case language
It’s easy to assume that if your UI works in English, it will work across all languages. But that’s not often the case.
It is hard to compare the number of characters and words used across languages. Some languages will have a much bigger character count (sometimes 3x more— I’m looking at you, Finnish!) than others.
UI which is designed and planned specifically around one language rarely looks good in others. Even the most basic button can break and cause issues if you fail to factor in localisation early during the design process. This might cause you to have to go back and make changes to your UI layout, change the width of buttons, or even re-write the offending text altogether.
Unfortunately, English is usually one the easiest of the languages to design around. If you’re not careful, your designers will inadvertently end up designing UI for the best-case scenario. English is one of the shorter Latin-based languages, and other languages typically contain longer words.
Pro tip: Make sure your UI can accommodate at least twice as many characters than what’s needed for English if you’re supporting German, Finnish, or Russian.
Asian Languages also contain complex glyphs that might become too hard to read if the font size is too small. Test often, and test in other languages. It’s worth repeating that having friends or colleagues that can read and experience the game in another language is remarkably helpful in weeding out these issues.
A solid glossary goes a long way
Establishing a solid list of commonly used terms in your game can go a long way. Game developers are a creative bunch, and sometimes your game may contain some complicated jargon and terms.
Keeping an updated glossary keeps everything well defined and consistent. It gives your team and translators more context, which helps produce more accurate translations.
A good index of terms can also prevent over-translation — not everything needs to be localised. For example, it’s generally a bad idea to translate brand names, abbreviations, or even the name of your game. In some cases, keeping the source word in English is more appropriate than trying to translate it. Defining these helps speed up the translation process and keeps costs down by not translating terms unnecessarily.
Handling language-specific jokes and puns
Generally, translators should be given some creative freedom to translate jokes and puns to make them more culturally relevant. Experienced translators often have a local and culturally-sensitive point of reference, and they should have a strong command of the language. Sometimes, translators do such an excellent job with the translated versions of names and jokes that we adapt them back to the source text!
Still, it’s essential to define some rules and structure with your translators at the beginning of the project. Make sure to check that translators have not translated things on a whim. It can also be challenging to keep the tone of the text consistent across languages. Work with your translators and educate them on the universe of your game, and help them understand why names and terms are written in a certain way.
I’ve heard horror stories of translators going rogue when given too much freedom. Over sexualising text, trying to sneak in false words, and even changing the name of the game to something else! Make sure you proofread translations — get a second opinion. You don’t want to release your game globally only to have it pulled from the store for something that was lost in translation.
Engaging separate vendors for translation and Localisation QA is usually a good idea. You’ll get different opinions on translation and improve quality. This also removes any incentive for the Localisation QA team to cover the translator’s mistakes.
Localisation may seem like a huge and daunting task. Still, if you start early and plan out an effective framework with your team, it can be highly rewarding. You’ll not only expand your games reach but also allow players to connect and experience your game more intimately through their native language. Good localisation has a powerful impact on player loyalty and engagement.
I do have one last tip — treat all languages as if they were your native language. You should never treat any of your players as second class citizens. If you localise in a language, do it correctly and commit to excellence. If an issue appears in one language, it should be treated just like the source text. Players appreciate when you treat their source language with respect, and it’s an excellent way to build trust with your community.
I hope that you’ve found the article useful. With these tips, you should spend less time wrangling with localisation and more time developing your next billion-dollar idea! Please share your own experiences in the comments, and let me know if you have any questions.
Game Localisation Tips was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
