There are various ways to set up SQL-based content repositories to store content for multiple site locales. For example, you can set up a separate repository for each locale, or you can store content for all locales in a single repository and add locale-specific attributes to each repository item.
Multiple Repositories
With this method, you create a separate content repository for each locale. Then you write separate targeting rules for each locale, with each rule referencing the appropriate repository.
One advantage of this method is that it lets you target different pieces of content to different locales. For example, site visitors from Germany might not be interested in the same news articles as site visitors from the US; with separate targeting rules or scenarios for each locale, you can display only those articles that are relevant to each visitor.
Disadvantages include the need to maintain multiple copies of each item (each item is duplicated in each locale-specific repository). In addition, storing separate values for each locale-sensitive property can take more space in the database than storing a single value.
Single Repository
With this method, you configure a single repository that holds content for all locales, and you include a locale attribute for each repository item. Then you write a targeting rule or scenario that matches the RequestLocale’s localeString property to the locale attribute of the content repository item, thereby allowing you to display content that is appropriate for each user’s language preference.
Locale-specific properties of each item are stored in multi-valued tables that hold many different language versions of the same information. This method therefore has the advantage of requiring you to maintain only one copy of each repository item, avoiding the duplication of the multiple repository method.
Disadvantages include the need to use a single character encoding that is appropriate for all content locales in the repository. In addition, a large repository that contains items for multiple locales might be less convenient to work with than a set of smaller repositories, each containing items for only one locale.
For more advantages and disadvantages of each method, and for a detailed description of how to set up SQL content repositories for an internationalized site, refer to Designing a Multi-Locale Product Catalog in the ATG Commerce Programming Guide.
The Motorprise demo application (ATG Business Commerce) uses the single repository method to store content in two languages, English and German. For information, refer to Localizing Custom Catalogs in the ATG Business Commerce Reference Application Guide.
The Quincy Funds demo application stores content for four locales in a single repository, which is a combination SQL/file system repository. All content is encoded in UTF-8. For more information, refer to the ATG Quincy Funds Demo Documentation.
Using the EncodingTyper Component with Content Repositories
If you use the EncodingTyper component to determine character encodings, you must configure it to match the locale-based repository directories to encodings; the mapping works in the same way as the EncodingTyper mapping of page directories to encodings. See Using the EncodingTyper to Set the Character Encoding for more information.
Localizing an SQL Content Repository Definition File
The configuration file that defines an SQL content repository contains various values that are used in the content repository editor in the ATG Control Center. For example, each item has a displayname property and a description property whose values are labels that can be used to identify them in the editor. You can localize the definition file so that these values appear in a different language. For detailed information, refer to Localizing SQL Repository Definitions in the ATG Repository Guide.
