Start Page » Game Development with the Drag[en]gine » Localization using language packs
Localizing a game is always a time consuming process especially if the game has not been designed with this goal in the first place. The Drag[en]gine provides a simple system to localize games. The advantage of this system is the transparency to the game developer. Adding a new language to a game consists of simply adding a new language resource file, loading the file and using it to retrieve translations from. The localization system composes of two major components.
A language pack resource provides the translations of text for a given language. This is a list of mappings of Unicode text strings to ASCII keys. A key identifies the translation entry and is therefore stored as ASCII. There are no restrictions on the way the key is constructed but a good rule is to use the same naming conventions as for programming languages. Each language pack is identified using a unique name ASCII string. In addition a description is provided in the native language ( Unicode string ) and a missing text ( Unicode string ). The missing text is returned if a translation entry can not be found.
While language packs provide the raw text mappings the translators provide support to query these texts in an organized way from a language pack. Usually you use one translator for your game. To change the language of your game simply assign a new language pack to the translator. Everything else works the same as before. Translators store a list of sections containing translation entries. Using sections you can avoid storing an index for each text. For example if you have objects in your game for which you store 5 text strings you can create a section for each object and add the translation entries in the same order. This way you just have to store the section for each object since the order of the text is always the same. This is also the main advantage of the translators. You organize the text in the translator accessing them afterwards by indices which is fast. The translator then maps your text ordering to the entries in the language pack. Since this ordering is not always the same you would have to track it whenever you change a language pack. This way you setup your environment and the translator does the hard work for you.
So for example you could have this setup:
The door would store 0 as it's section and desk 1. Now independent of the language pack assigned you can query the description of the door using section(0)-entry(1) or for the desk using section(1)-entry(1). You could also use one section for your entire game and add each text as an entry in this section. Using the sections though you need only 2 indices instead of 6 in this example which is easier to work with.