Create a globalized store

To create a globalized store:

1. Create a store

2. Manage your template

3. Add a language to the store

4. Create a globalized catalog

5. Manage globalized Web assets

6. Translate property files

Procedure

1. Creating a store

   There are two ways to create a store. We can create a store by publishing one of the starter store archives and editing the resulting store. We can also create a store by creating the storefront, business logic, and data assets separately.

   • Storefront: The external portion of the store, or the portion that displays to our customers, is known as the storefront. The storefront is consists of web assets such as HTML pages, JSP files, style sheets, images, graphics, and other multimedia file types.

   • Business logic: The portion of the store that processes customer requests, including the commands and customized code is known as the business logic.

   • Store data: The data assets that compose the store. To operate properly, a store must have the data in place to support all customer activities. For example, in order for a customer to make a purchase, the store must contain a catalog of goods for sale. Your store must also have a process to handle orders, the inventory to fulfill the request, and a shipping process. Your store must also have methods for processing and collecting payment.

2. Manage your template for a globalized site

   To manage static pages and dynamic templates in a globalized site, it is necessary to store files in a directory structure that allows for the quick and easy identification of the files. It is also important to note which locale they belong to.

   The file directory path is constructed based on the WebSphere Commerce instance, the store relationship that is contained within the store profile, and the registered file path. When creating a globalized site, you create multiple stores, each one representing a supported shipping jurisdiction of the site. The stores must also include a list of supported languages. Since the template files influence the look and feel of a site, the template files are stored under locale-specific directories. The locale-specific directories allow the files to be selected in a similar manner in which resource bundles are selected, by using a locale value. When the system selects a template to use for a particular language format, the locale is used to determine the language format to be used. This language format is used to determine the directory from which the file is retrieved.

   The WebSphere Commerce starter stores use the one template per store model.

   There are three models to store templates in a globalized environment as described in the following table:

   	One template for all stores and languages	One template per language	One template per store
   Customization	For most stores provide sufficient levels of customization between each store and each store language format.	Allows the maximum level of customization between each store and each language format.	Some level of customization between each store.
   Look and feel of pages	Pages look similar.	Pages can be different.	Pages have the same general layout.
   Maintenance	Allows for easy site-wide page-design changes since only one template must be changed. For most globalized sites, this model provides optimal levels of maintainability and scalability.	Must manage multiple copies of each template. Changes that affect all stores, or all language formats have to be made to every template.	Site-wide changes to the look of a JSP file have to be made across multiple templates.
   When to use	Use when the look and feel for each store and each language is similar.	Use when page look and feel and content between languages are very different. In this case, there is not much that can be shared across languages and it is easier to develop separate pages for each language.	Use when stores differ in look and feel significantly, but the store look and feel remains relatively the same regardless of the language.
   When not to use	Do not use if site is meant to look different between stores and languages	Do not use if pages are similar between stores and between language formats.	Do not use if stores look and feel are similar.
   Property files	Required. Each supported language also has its own property file included when the page is generated.	Not required. Each store and locale combination has its own JavaServer Page template.	Required. To allow for template sharing between each language format.
   Shopping flow	The shopping flow between languages and stores remains the same.	The shopping flow can change significantly between languages.	The shopping flow between languages and stores remains the same.

3. Adding a language to a store

   To add support for a new language to an existing store:

   1. Ensure that the language is available to the site. For a list of the 13 national languages that are supported, refer to Supporting globalization. If the language is available go to step 3b, if not, go to step 4.

   2. Create a display format for the language. Use the Store Profile notebook to add the language to the list of the languages that are supported by the store.

4. To create a flexible online catalog that is suitable for a globalized site, include multiple details about each product. Consider that there are often differences between cultures that go beyond just language, such as the way certain types of data are represented. For example, in some cultures, a decimal number is represented by a comma, whereas in others it is represented by a period.

   • If you need to price catalog entries differently within a store or between stores, such as within an extended sites store model, we can use price rules. See Price rules: An overview.

   • If you need to display catalog entry prices in different currencies, add support for each currency to the store. See Creating a globalized catalog.

   • If you need to display product descriptions in multiple languages, we can add the descriptions in multiple languages within a single catalog or create a separate sales catalog for each language. For more information about adding descriptions in multiple languages to a catalog and adding multiple currencies to a store with Management Center, see Creating a globalized catalog.For each catalog created, consider how to present the following types of information.

     Online catalog products

     There are multiple language descriptions for each catalog entry.

     Product descriptions

     Language and phrasing of the descriptions can be varied, highlighting different features to different groups of customers.

     Prices

     Prices can be varied to reflect tariffs and other shipping expenses, and can be expressed in different currencies.

     Cultural formats

     Dates, names, measurement units, and other data can be formatted to suit cultural expectations.

     Product images

     We can display different product images to different customers.

     Select one of the following methods to create the catalogs:

     • Create a catalog using the loading utilities or a catalog tool of your choice.

     • Create the catalog data in XML files and load it into the database using the loading utilities. We can also publish it in a store archive format using the Administration Console. See Creating a catalog.

     • Create the catalog using the starter store catalogs as a base, and then change the information using the Product Management tools. It is important to note that this technique works for small amounts of data only.

     • Convert your existing catalog to an XML or CSV file format, suitable for use with the loading utilities, and then load the information into the database. We can load CSV files with the Data Load utility or Catalog Upload feature in the Catalogs tool in Management Center. See Extract and load data.

       We can load XML files with the Data Load utility to load catalog data for multiple languages.

     We can translate and populate many XML files using the massload utility, such as tax.xml, store.xml, fulfillment.xml, catalog.xml, businesspolicy.xml, contract.xml, accesscontrol.xml, and shipping.xml.

5. Manage globalization web assets

   To manage your web assets, we can employ a globalized programming model that uses one JSP template for all stores and languages. This JSP template includes the basic design of each page along with any culturally neutral information. The remaining culturally sensitive text is added to your pages at run time by using resource bundles or property files.

   Determine which web assets to translate. This list might include: banners, images, applets, text, messages, and other culturally sensitive content displayed in your pages. Create multiple versions of some of these components, one for each language or culture that is supported by the site. For an example how assets can be managed in a globalized store, refer to a starter store.

6. Translate property files

   1. Open the property file with a text editor.

   2. Translate the text in the property file:

      • Do not translate the keyword. The keyword is the content to the left of the equal sign.

        Source: lastName.Label=Last Name 
        Translation: lastName.Label=Nom de famille

      • For option attributes, translate only the values to the right of the semi-colon (;).

        Source: title.Options=MR;Mr.|MRS;Mrs.|MS;Ms. 
        Translation: title.Options=MR;M.|MRS;Mme.|MS;Mlle. 
        
        Source: publishPhone.Options=Y;Yes|N;No 
        Translation: publishPhone.Options=Y;Oui|N;Non

      • Translate comments, that is, any line that begins with the number sign (#).

   3. Save the property file as text. If we are using a programming model where:

      1. Property files have the same name but are stored in locale-specific directories

         • Save the file to the correct directory

      2. Property files are stored in the same directory but the locale is appended to the name

         • Append the appropriate locale to the file name. The extension must be .properties

   4. If the property file contains characters that are non-Latin 1 and non-Unicode, use the native2ascii converter to convert the data from non-ascii format to Unicode ASCII representations. This process makes the data that is contained within the property file platform independent.

      Note: The native2ascii tool is included in both the SUN Java2 SDK and IBM JDK. The JRE, which is the runtime environment only, does not include native2ascii. The native2ascii converter is in the following directory:

      • (AIX) (Linux) WAS_installdir/java/bin

      • (IBM i) QIBM/ProdData/Java400/jdk13/ibm/bin

      • (Windows) WAS_installdir\java\bin

      For more information about the native2ascii converter, see native2ascii - Native-to-ASCII Converter.

Related concepts
WebSphere Commerce configuration file (wc-server.xml)
Outbound messaging system
Globalized catalog content
Cultural considerations
Localized store assets
Globalization in the messaging system
Programming models for globalized stores
Globalized store design
Supporting globalization
Globalized tools framework

Related tasks
Adding a currency to WebSphere Commerce
Address and name formatting in the tools
Use resource bundles in store pages
Creating a new display format
Creating a language selection drop-down list
Creating and using resource bundles in the tools framework
Currency and number formatting
Date and time formatting
Setting the dir attribute for bidi specifications
Encoding for e-mail transmission
Formatting addresses and names in the tools
Name and address formatting

Related reference
Globalization tips