There is no single "correct" method of planning a database that will interact with localized web sites. The ultimate decision about how to organize your database will depend on what works best for you and your localizers.

Here is the English-only version of a Microsoft Access database for a fictional American company, Chuzzlewit Brothers Chocolates.

The database for Chuzzlewit Brothers Chocolates is made up of five tables: CARAMELS, BUTTERCREAMS, NUTS, SOLIDS, and TRUFFLES. Each table contains detail information about the different types of chocolates within these categories. For example, the CARAMEL table contains the name, price per pound, description, and photo path for each type of chocolate-covered caramel in the database.

When you create a database that you eventually intend to localize, you should plan for minimal changes to each table's structure. Use altered versions of the table names for your localized tables, and retain the original development language (English) for internal column names. For example, the English/Swedish database for Chuzzlewit Brothers Chocolates has distinct English tables and Swedish tables for each product category.

To denote Swedish content, the web developer has appended _SW to each Swedish table name. The Swedish tables, however, contain the original English column names. Here is the Swedish table CARAMELS_SW.

The web developer plans to use these English-language column names when she builds her UltraDev application. This particular database structure provides a great advantage in UltraDev because it minimizes change requirements to the code. In the next section you will see a practical example of how minimizing changes to your table structure results in an optimized localization workflow.