Create a globalized store

Develop > Controller layer > Application developer > Support globalization > Program models for globalized stores

Create a globalized store

To create a globalized store:

Create a store

Manage the template

Add a language to the store

Create a globalized catalog

Manage globalized Web assets

Translate property files

Procedure
Create a store
You can either create a store by publishing one of the starter store archives and editing the resulting store, or you can create the storefront, business logic, and data assets separately.

Storefront: The external portion of the store, or the portion that displays to the 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. In order 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, 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.

Manage the 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 and which locale they belong to.
The file directory path is constructed based on the WCS instance, the store relationship contained within the store profile and also the registered file path. When you create a globalized site, you create multiple stores, each one representing a supported shipping jurisdiction of the site, and each one having 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 so that they can be selected similar to the manner in which resource bundles are selected, 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 that will be 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 provides 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 will look similar. Pages can be very different. Pages have the same general layout.
Maintenance Allows for easy site-wide page-design changes since only one template needs to 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 will have to be made across multiple templates.
When to use Use when the look and feel for each store and each language is very 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's look and feel remains relatively the same regardless of the language.
When not to use Do not use if site is meant to look very different between stores and languages Do not use if pages are very similar between stores and between language formats. Do not use if stores look and feel are very similar.
Property files Required. Each supported language also has its own property file that is 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.

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

Verify the language is available to your site. For a list of the thirteen national languages supported, refer to Support globalization. If the language is available go to step 3, if not, go to the next step.

Create a new display format for the language. Use the Store Profile notebook to add the language to the list of those supported by the store.

Copy the national languages file, for example, for ConsumerDirect, copy storetext_locale.properties to

WC_EAR/Stores.war/WEB-INF/classes/ storedir

workspace_dir\Stores\Web Content\WEB-INF\classes\ storedir

To create a flexible online catalog that is suitable for a globalized site, include multiple details about each product, one for each language or culture to support. 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 using a period.

For each language that the store supports create a catalog. Select one of the following catalog creation methods:

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

Create the catalog data in XML files and load it into the database using the loading utilities, or publish it in a store archive format using the Administration Console. For more information, see Creating a catalog.

Convert the existing catalog to an XML file format, suitable for use with the loading utilities, and then load the information into the database. For more information, see loading utilities.

Create the catalog using the starter store catalogs as a base, and then change the information using the Product Management tools (this works for small amounts of data only).

For each catalog that you create 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

You may want to display different product images to different customers.

There are many other XML files that need to be translated and populated using the massload utility, such as tax.xml, store.xml, fulfillment.xml, catalog.xml, businesspolicy.xml, contract.xml, accesscontrol.xml, and shipping.xml.

Manage globalization Web assets
To manage the Web assets, it is recommended that you employ a globalized programming model that uses one JSP template for all stores and languages, including the basic design of each page along with any culturally neutral information. The remaining culturally sensitive text is added to the pages at run time through the use of 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 the pages. Create multiple versions of some of these components, one for each language or culture supported by the site. For an example how assets can be managed in a globalized store, refer to a starter store.
Translate property files
Open the property file using any text editor.
Translate the text in the property file noting the following:
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, only translate 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
Optionally, translate comments, that is, any line that begins with the pound sign (#).
Save the property file as text. If you are using a programming model where:

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

Save the file to the correct directory

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

If the property file contains characters which 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 will make the data contained within the property file platform independent. The native2ascii converter is...

WAS_HOME/java/bin

QIBM/ProdData/Java400/jdk13/ibm/bin

WAS_HOME\java\bin

WCDE_INSTALL\AppServer\java\bin

For additional information about the native2ascii converter, refer to www.java.sun.com
Related concepts

Support globalization
Program models for globalized stores
Cultural considerations
Localized store assets
Globalized store design

Related tasks

Use resource bundles in store pages
Create a new display format

Related reference

Globalization tips
massload utility (Server environment)

+
Search Tips | Advanced Search

	One template for all stores and languages	One template per language	One template per store
Customization	For most stores provides 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 will look similar.	Pages can be very different.	Pages have the same general layout.
Maintenance	Allows for easy site-wide page-design changes since only one template needs to 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 will have to be made across multiple templates.
When to use	Use when the look and feel for each store and each language is very 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's look and feel remains relatively the same regardless of the language.
When not to use	Do not use if site is meant to look very different between stores and languages	Do not use if pages are very similar between stores and between language formats.	Do not use if stores look and feel are very similar.
Property files	Required. Each supported language also has its own property file that is 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.