Video Game Internationalization Issues

Internationalization Issue	Description
GENERAL
Think about localization at an early stage	It is easier to develop your code with localization in mind than it is to retro-fit your game for localization.
Separate localizable components from the rest of the game components	Store localizable components in unique directories, so that a localized version can be created by swapping in or out a number of specific directories.
Leave room for text expansion	Translated text can often be longer that the original text, as a guideline you should allow for a 25% increase in length in the localized strings. This is particularly relevant for user interface layouts; ensure that there is room for text expansion in any layout that is dense with information.
STRINGS
External string tables, no hard coded strings	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, unicode	All string tables, .ini files and any other file used to store localizable 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)
Avoid string and word concatenation(串联)	Concatenation of individual words to generate item names or sentences always poses problems for localization. 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 localization 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 version
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 localized versions. 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 localized 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 localized 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 localizing 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 allow 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).