Game Localization Network Ltd. - How to internationalise a game
Sitemap
Localization adds linguistic color to your favorite game, that's our two cents! Localisation adds linguistic colour to your favourite game, that's our tuppence worth! Version française  
Game Localization Network Ltd. - Home Services provided by Game Localization Network Ltd. Game Localisation - targeting foreign markets Links - International game charts and game sites Contact - Game Localization Network Ltd.  
   
  Game Localization Network Ltd. - Home page
  Services - provided by Game Localization Network Ltd.
  Game Localisation - targeting foreign markets
  Overview of localisation
  Game localisation - general information and models
  Internationalisation - issues for coders
  Culture and legal - issues for designers
  Links - international game charts and sites
  Contact - Game Localization Network Ltd.
   
 
Localisation > Internationalisation
Internationalisation - information for developers
 

Internationalisation is a general term for the process of designing a game so that it will work correctly in all territories and so that the game can be localised efficiently. This term covers many things that affect a game at a technical or code level, including string table formats, time/date formats, keyboard/controller layouts, TV systems (NTSC, PAL, Secam), fonts, currency formats, text direction (some languages are written right-to-left), and many other issues.

The table below details some of the major issues addressed by internationalisation. If you require more specific information relating to your game then please contact info@gamelocalisation.net.

Internationalisation Issue Description
GENERAL  
Think about localisation at an early stage It is easier to develop your code with localisation in mind than it is to retro-fit your game for localisation.
Separate localisable components from the rest of the game components Store localisable components in unique directories, so that a localised game can be created by swapping in or out a number of specific directories.
Leave room for text expansion Translated text can ofter be longer that the original text, as a guideline you should allow for a 25% increase in length in the localised strings. This is particulurally relevent for user interface layouts, ensure that there is room for text expansion in any layout that is dense with information.
STRINGS  
External string tables All the in-game and user interface text should be contained in string tables that exist external to the .exe (i.e. that there is no hard-coded text embedded in the game code).
String table formats All string tables, .ini files and any other file used to store localisable text should be in Unicode format. At minimum the string table should have unique IDs and their associated string, however the ideal is that a database is used (containing IDs, strings, comments, maximum string lengths, etc. for each entry)
String and word concatenation Concatenation of individual words to generate item names or sentences always poses problems for localisation. If it is possible to avoid concatenation by using a small number of extra strings then do so, if you must use concatenation then early planning for localisation is essential.
Line-breaking and word-wrapping algorithms All line-breaking and word-wrapping algorithms must properly handle double byte characters (i.e. algorithms must not incorrectly wrap between the leading-byte and the trailing-byte of a double-byte character)
Text direction Some languages are written right-to-left.
AUDIO  
Implement a sub-titling system Implement a subtitling system for all spoken audio because this allows for the creation of a less expensive but equally effective subtitled game
Store all spoken audio files separately from other audio Store the voice files in specific directories that only contain voice files.
Keep information on filters applied to voice files Document sound effect and filter settings (save settings files if possible) so that the same settings can be used for the localised games. Document all files that have had an effect or filter applied to them.
Keep multi-track files for all voice files that use a sound effect or background track Keep multi-track files for all voice files that use an ambient sound effect or background music track. The localised voice file may be longer than the original (if identical timing is not strictly necessary), so please allow the background track to run on longer than the original voice track, it can then be trimmed on final output.
VIDEO AND ANIMATION  
Framerate - pre-rendered animation For console products be aware of NTSC and PAL framerates. You could consider outputting both 25fps and 30fps versions of your pre-rendered animations.
Framerate - game engine animation sequences Ensure that you use the correct timebase for animations played in the game engine, test playback on both PAL and NTSC systems.
Keep multi-track sound files for all animation sequences Keep multi-track sound files for all animation files that use voice mixed with ambient sound effects or background music tracks. The localised voice file will always be recorded to the exact length of the original voice so that the mix and visual edits work correctly.
FONT  
Language support Ensure that the fonts you use in your game support all the languages you are planning to release. The majority of commercially available fonts only support a subset of the full unicode range, so it is very likely that you will have to change fonts for certain languages. The usual, and most cost effective, solution is to use system fonts for any language that is not supported by your original fonts.
Font point size Asian ideographs (the characters used in Chinese, Japanese, Korean, etc.) are quite detailed and usually require an increase in font point size to make them legible. If you are localising a game that was originally developed in a latin character set, it is likely that the user interface layout will need to be modified to support the point size increase required for Asian ideographs. As a guide an increase of 2 point sizes is usually needed and this can have a serious impact on a tightly packed user interface.
PLAYER INPUT  
Player name fields Ensure all player name fields allow input of unicode characters so that players can enter their name in their own language. Ensure that the settings file that stores the specified player name is saved in unicode format.
Saved game names Ensure that saved game names allow input of unicode characters so that players can enter a descriptive name in their own language.
Multiplayer chat Ensure that the multiplayer chat fields allows input of unicode characters. You will also have to make decisions on how multi-language chat will get displayed. As an example if you want players of a German version of the game to be able to see that another player is chatting in Japanese (even if they do not speak the language) then the German version will need to have a font available that supports Japanese characters, otherwise the German player will just see garbled or null characters when anyone types in Japanese.
Input Method Editor (IME) Some languages utilize thousands of unique characters, however a computer keyboard cannot have thousands of keys. An Input Method Editor (IME) is the system that allows users to enter complex characters (Chinese, Japanese, etc.) by pressing a couple of standard keys in the appropriate sequence. Games that are planned for release in Asia must implement an IME, the most cost effective method is to use the IME that is native in the operating system.
International keyboard layouts There are subtle differences between keyboard layouts in different countries. For example a French keyboard has Q and A in reversed positions and W and Z in reversed positions (a French keyboard has AZERTY where a US keyboard has QWERTY and QSDF where a US keyboard has ASDF).
Hotkey mapping Due to different keyboard layouts you will need to be careful with hotkey mapping in order to ensure that the ergonomic layout is identical across languages. The best solution is to use the Keyboard Scan Code to define the hotkey, by doing so you are mapping to a fixed key position on all keyboard layouts. In the hotkey layout screen in your game you will also need to reference a string table entry for each keyboard character so that the appropriate character can be changed/displayed for the scancode.
REGIONAL SETTINGS  
Time format Some countries use the 12 hour format and some use the 24 hour format, it is best to set a switch so that this can easily be altered depending on local preference.
Date format Some countries use the day/month/year and some use month/day/year, it is best to set a switch so that this can easily be altered depending on local preference.
Number formats and currencies If it is relevant for your game, then be aware that separators for decimals and thousands can change from country to country. For example in the US commas are used to separate thousands and dots are used to define decimals but in Germany this system is reversed (e.g. in the US one million dollars and ten cents is written 1,000,000.10 however this is written as 1.000.000,10 in Germany).
PRINT MATERIALS  
Printed document paper sizes The increasing use of DVD format boxes has led to the standardization of manual sizes, however care should be taken to ensure that manuals, posters, quick reference cards, etc. are not laid-out in a paper format size that is unique to individual territories (i.e. the layout of a "US legal" sized document may have to be modified to achieve cost effective printing in other territories).

 

 
 

 

Game Localization Network Ltd. © 2012 ::: info@gamelocalisation.net ::: Powered by Electricity