There are several ways to localize databases. Sisulizer localization tool
support five different ways. They are

1) Field localization. You add language specific fields to table. It is easy
but you have to modify the table when you add new language
2) Database cloning. Sisulizer makes a copy of database and replaces the
values of the selected fields with translations
3) Table localization. You add language specific table that contains
translations of the original tables. This is not that practical but can be
used in some place

4) Row localization. Here you add language field as a part of primaty key.
This is the best localization method for DB.
Let has an example

I have table: (Id, Name, Description) and I want to localize Description. I
modify the table to (Id, Language, Name, Description). Id;Language is the
the primary key. So table can contains the same Id many time but with
different language id.

If I have table
0    Finland    Country of thousands lakes
1    Japan    Country of beautifull girls

After I add language field and localize to Finnish I will get
0    en    Finland    Country of thousands lakes
0    fi    Suomi    Tuhansien järvien maa
1    en    Japan    Country of beautifull girls
1    fi    Japani    Kauniiden naisten maa

You can add the localized rows and fill them up manually but using Sisulizer
will make this so much easier and safer. You can download it with samples
databases and documentation about database localization from
http://www.sisulizer.com/downloads.shtml

5) As above but Language id is not part of primary id. Primary id is autoinc
and in addition of that there is resource id that gives unique id for the
row. Use this if your primary key must contains only one field.

Best regards,
Jaakko

Jaakko discusses the basic solutions for localizing information that is
retreived from the database.   What often trips people up is the effect of
the localization upon the operation of the database (sorting, etc.)

One really tricky bit is if the information to be stored is in a language
such as Kanji wherein items are sorted by how they are pronounced, but each
glyph is pronounced differently based on the glyphs around it (which, as far
as I know, no database is capable of sorting).   Some solutions for the
problem use a second column of information which IS sortable by the database
and is entered and maintained separately from the "unsortable" strings.