251French, our database would look something like the simple example shown in
Table 5.2. Additional columns can be added for each new language your game
supports.
The exact format of this database is up to you. It might be as simple as
a Microsoft Excel worksheet that can be saved as a comma-separated values
(CSV ) fi le and parsed by the game engine or as complex as a full-fl edged Or-
acle database. The specifi cs of the string database are largely unimportant to
the game engine, as long as it can read in the string ids and the correspond-
ing Unicode strings for whatever language(s) your game supports. (However,
the specifi cs of the database may be very important from a practical point of
view, depending upon the organizational structure of your game studio. A
small studio with in-house translators can probably get away with an Excel
spreadsheet located on a network drive. But a large studio with branch offi ces
in Britain, Europe, South America, and Japan would probably fi nd some kind
of distributed database a great deal more amenable.)
At runtime, you’ll need to provide a simple function that returns the Uni-
code string in the “current” language, given the unique id of that string. The
function might be declared like this:
wchar_tgetLocalizedString(const char* id);and it might be used like this:
void drawScoreHud(const Vector3& score1Pos,
const Vector3& score2Pos)
{
renderer.displayTextOrtho(
getLocalizedString("p1score"),
score1Pos);
renderer.displayTextOrtho(
getLocalizedString("p2score"),
score2Pos);
// ...
}Id English French
p1score “Player 1 Score” “Grade Joueur 1”
p2score “Player 2 Score” “Grade Joueur 2”
p1wins “Player 1 wins!” “Joueur un gagne!”
p2wins “Player 2 wins!” “Joueur deux gagne!”Table 5.2. Example of a string database used for localization.
5.4. Strings