Video game internationalization is the process that enables game localization to take place seamlessly. For localization to be successful, you should have an internationalized product before you begin the actual localization process.
Game developers make the typical mistake of assuming that localization is “just” translation. They fail to prepare for localization during the initial planning stages and wait to develop the game in its native language fully.
Localizing video games will be easier if you follow video game internationalization best practices starting from the initial design stages.
What Is Video Game Internationalization And Why Should You Follow Best Practices?
Video game internationalization is the process that “prepares” your game for localization. Internationalizing your game will empower it’s code, architecture and user interface to process and render game content in multiple languages.
The chief purpose of video game internationalization is to eliminate the existence of any component in the code base that differs by “locale.”
Players expect the localized user interface to be exactly as interactive and the game just as engaging as the original. To achieve the same interactive and engaging experience, game programmers should adopt best practices during the initial stages of game design and development.
What Are The Best Practices For Video Game Internationalization?
If you are a game developer working on the design, it is good to know about video game internationalization best practices. You should adopt recommended video game development methodologies. Video game internationalization best practices fall into two categories:
- Localization Friendly Architecture: Deals with file structure, organizing assets, character encoding, memory issues, naming conventions
- Localization Friendly Programming: Deals with programming practices recommended for developers (UI, Regional Settings, Text)
This article covers best practices recommended for localization friendly architecture. Video game internationalization practices for programming methodologies deserve their full focus in a separate post.
Localization Friendly Architecture
Designing a localization friendly structure will help your game to be localized easily, quickly and accurately. For your game architecture to be localization friendly, you should internationalize your:
- File Structure
- Game Assets
- Text Assets
- Art Assets
- Voice-Over
- Memory
- Naming Conventions
1. Internationalize File Structure
It is standard practice to externalize all localizable game assets from the game code and organize them under separate language-specific folders. Doing this will enable easy hand-off of localizable content to your LSP (Language Service Provider), and the translated assets can be integrated into your game easily. This is an important video game internationalization practice that is simple yet powerful.
The example here shows a sample directory structure for organizing your game code and assets to prepare for game localization. Your development framework may provide specific video game internationalization directory structures. You should refer to their documentation for more details.
The code folder (“Game Code”) contains all your code files, using which it should be possible to create a localized master of the game. The assets folder (“Game Assets”) contains all text, art, audio, cinematics and other assets to be localized.
2. Internationalize Game Assets
Text assets, art assets and voice-over are the critical components of your game that should address internationalization requirements.
2.1 Internationalize Text Assets
Your in-game text and UI text are the primary localization targets. In an ideal scenario, you should externalize all localizable text (in-game text, UI text, console error messages, etc.) in different files, separated from the actual game code. You should also remember to organize all installer strings for the PC version in a centralized location.
Using external string tables to store localizable text makes it easy to organize and integrate translations. You can make it further simple for tracking changes to the strings during development, by using unique string IDs for every string.
2.1.1 Defining String Tables
The most simple and common approach is to store all text in a plain text file (for the source language). This text file can be readily handed over for localization, and the translated version can be integrated back into your game for the target language. If you are using plain text files, stick to localization friendly encoding such as UTF-8 or similar.
Sample Text Files
Regardless of how you store your strings, you will find it very useful to assign a unique string identifier against every text and refer to the text in your code using this string ID.
Example External Text File (contains all original text for a mission called MissionDD)
en-US/Text/Assets/MissionDD/Strings.txt DDSTRING_T1 Hi Jisto! Doing Good? DDSTRING_T2 Yeah, I am okay. DDSTRING_T3 Bye! See you later.
Example Japanese (translated) version of this file
ja-JP/Text/Assets/MissionDD/Strings.txt DDSTRING_T1 こんにちはレイチェル！よくやっている？ DDSTRING_T2 ええ、私は大丈夫です。 DDSTRING_T3 さようなら！じゃあまたね。
2.1.2 Already Developed Your Game?
If you have already developed your game without thinking about localization, then use some tool to extract all texts from the game files. Move them to a string table and assign every “text” with a unique “identifier.” The identifier will substitute every occurrence of the text in the game code.
2.1.3 Are you Developing a Game With a Lot of Text?
For games with an enormous amount of text, such as a large RPG game or adventure games, you could consider using a database. Ideally, the database should contain the following:
- IDs
- Text
- Notes (providing a context of the text)
- The Order Of The Text
- Maximum String Length
- Localized Entries For All The Text (when made available)
2.1.4 Using String Tables In Code
Your game engine loads the string table into memory. Hash tables are a commonly used data structure. If you are developing your game in C++, use the STL map container. Encapsulate the string table into a class that holds all the texts and define a static method that accepts the identifier and returns the translated text.
In the example below, GameDDStringTable is the class encapsulating the string table. The API getDDString(StringID) is to invoke and obtain the localized text for the string IDs (before using them in the code).
Code Without Internationalization
DDCHARACTER1.Talk(Hi Jisto! Doing Good?); DDCHARACTER2.Talk(Yeah, I am okay.); DDCHARACTER3.Talk(Bye! See you later.);
Internationalized Code
DDCHARACTER1.Talk(GameDDStringTable::getDDString("DDSTRING_T1"));
DDCHARACTER2.Talk(GameDDStringTable::getDDString("DDSTRING_T2"));
DDCHARACTER3.Talk(GameDDStringTable::getDDString("DDSTRING_T3"));
2.1.5 Retaining Readability
One of the drawbacks of externalizing all in-game text is that while looking at your code, you will find that it has lost readability. Therefore further script changes may become a little difficult.
For instance, DDCHARACTER1.Talk(GameDDStringTable::getDDString("DDSTRING_T1")); is not readable because of the absence of the actual text spoken by the character.
Some game development teams try to overcome this problem by retaining the original text (and use a unique string ID) in the code. They follow a pre-defined and unambiguous syntax as shown in the example below.
DDCHARACTER1.Talk(GameDDStringTable::getDDString("DDSTRING_T1|Hi Jisto, how are you?"));
DDCHARACTER2.Talk(GameDDStringTable::getDDString("DDSTRING_T2|Yeah, I am okay."));
DDCHARACTER3.Talk(GameDDStringTable::getDDString("DDSTRING_T3|Bye! See you later."));
In the above example, the scripts include both the texts and the identifier in the format
“STRING ID | original text”.
The static method getDDString() will read the ID (to the left of the pipe character) and return the translated text. If it cannot find the translated text, it will return the original text (to the right of the pipe character).
This approach makes your script readable. Also, in the absence of any string table, the game will not fail to run because there is an option to fall back. It will display the original text on the right side of the pipe character.
2.1.4 Notes for Translation
If you wish to streamline the translation process further, you should provide sufficient information about all localizable strings. You can provide these in the form of comments in your external string tables. You can also provide them as separate notes included in a specific documentation folder. This is a highly recommended video game internationalization best practice.
Notes help translators understand:
- The order of the text
- Context of the text in the game
- The maximum length of the string (after translation) that the engine will still support
- Any other string rules unique to your game
Video Game Internationalization – Developer Checklist For Text Assets
2.2 Internationalize Art Assets
Reduce the amount of time spent on localizing art assets by minimizing the amount of text that appears in your art. If you are using text in your art, follow these best practices:
2.2.1 Separate Layer For Text
In the image file, define the text in a separate layer. Such layered art files are easy to localize because you can integrate the translations quickly.
2.2.2 Render Text Programmatically (Runtime)
Another approach is to render the text in the image using fonts (programmatically). Externalize all text, that appears in the art assets, in a separate text file which can be easily localized. Your game engine can then pull appropriate text and display them on the images as required at runtime.
2.2.3 Organize Asset Folders
You should place all localizable art assets in appropriate folders as explained in the preceding sections.
2.2.4 Notes For Translation
As with text assets, it would be useful to include notes for translation.
Video Game Internationalization – Developer Checklist For Art Assets
2.3 Internationalize Voiceover
Game audio can be divided into three tracks namely voice over (VO), sound effects and music. It is good practice to store all VO tracks separately from the other two tracks because this will enable easy localization. If you logically organize all your VO files, you will find it very simple to integrate the localized VO into your game.
One approach is to name your VO sound files using the string identifier (assigned for the text in your string table). In our above example, the voiceover files could be named string_t1.mp3, string_t2.mp3 and string_t3.mp3. The benefit of this approach is you can code such that the voiceover for the string (displayed on the screen) is fetched and played.
Your script is the foundation for VO production. Therefore you must finalize the script very early in the game development and include as many technical aspects as possible (example: length, mono/stereo, etc.) along with a precise definition of the context.
The localization vendor should be able to understand how your story flows by reading your script. Video game internationalization for voiceover will help retain the original flavour in your localized game.
Subtitling System
If possible, implement a suitable subtitling system for your game. You can design such that subtitles appear on the screen along with the content of the VO files being played or replace VO recording with subtitling. You should remember to include all subtitled text in the localizable text assets (and ensure that you track them for translation).
Video Game Internationalization – Developer Checklist For Voiceover
3. Internationalize Memory
While loading the string table file, you can keep all the texts in memory because on an average this shouldn’t be more than one or two MBs for most of the games. You are more likely to run into memory issues if your target platform has limited memory. In this case, you can load and unload the specific set of texts as needed for every level of the game, etc.
If you are developing your game in English and your localization target language is Japanese or other Asian languages, you may find it difficult to fit their fonts set into memory. You can address this by loading the glyphs that appear in the specific part of the game into the memory as needed.
If you are developing your game in an Asian language (using double-byte character sets) you will find that for English and few other European languages, the strings may take up more memory.
For example, English uses about 1.5 characters more than Japanese and German uses double the letters of Japanese. To overcome these issues and avoid memory overflows it is best to stick to an encoding (such as UTF-8) that stores European characters as single bytes.
Such video game internationalization best practices for memory will ensure your game performs well in all languages.
4. Naming Conventions
You should name all localization specific folders and files in a manner that makes it easy to interpret the language/region they represent. Languages also have variants based on the regions. Therefore, it is a good idea to combine a 2-letter code for the language with a 2-letter code for the country. Example names are en-US (American English), ja-JP (Japanese), zh-CN (Simplified Chinese), zh-TW (Traditional Chinese), etc.
It is a good practice adhering to ISO standards, widely recognized across the globe.
It would be easy to understand the contents of the files, if you name them logically such that names are descriptive of the mission, character, etc. Example: UI.txt, Mission1.txt, Mission2.txt, etc.
All the above video game internationalization best practices for architecture aim at helping you design your game to be easily localized. Internationalization best practices for game programming are equally necessary to achieve your localization goals.
If you lay the foundation for localization during the very early stages of architecture, you will find that localization doesn’t have to be hard. Your game will be equally engaging in all localized versions and players won’t be able to tell that it wasn’t developed originally for their language.
Need help getting your video game internationalization or localization off the ground? Why not contact us today for a free quote?
