Creating a globalized store

Procedure

  1. Creating a store

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

    • Storefront: The external portion of your store, or the portion that displays to your 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 your store that processes customer requests, including the commands and customized code is known as the business logic.
    • Store data: The data assets that compose your 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, your 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. Managing 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 you create 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 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.
  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 your 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.
    3. Copy the national languages file, for example, for ConsumerDirect, copy storetext_locale.properties to
      • WC_eardir/Stores.war/WEB-INF/classes/storedir
      • WebSphere Commerce Developer workspace_dir\Stores\WebContent\WEB-INF\classes\storedir
  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.
    • Introduced in Feature Pack 2If you need to price catalog entries differently within a store or between stores, such as within an extended sites store model, you can use price rules. For more information, see Price rules: An overview.
    • If you need to display catalog entry prices in different currencies, you must add support for each currency to the store. For more information, see Creating a globalized catalog.
    • If you need to display product descriptions in multiple languages, you 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.
      If you want to create a separate sales catalog for each language. 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 can display different product images to different customers.
      Select one of the following methods to create your catalogs:
      • Create a catalog by using the loading utilities or a catalog tool of your choice.
      • Create your catalog data in XML files and load it into the database by using the loading utilities. You can also publish it in a store archive format by using the Administration Console. For more information, see Creating a catalog.
      • Create your catalog by using the starter store catalogs as a base, and then change the information by 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. You can load CSV files with the Data Load utility or Catalog Upload feature in the Catalogs tool in Management Center. For more information, see Transforming, loading, and extracting data using the WebSphere Commerce loading utilities.

        Feature Pack 6 or laterYou can load XML files with the Data Load utility to load catalog data for multiple languages.

        Feature Pack 6 or laterThe massload utility is deprecated for WebSphere Commerce Version 7 Feature Pack 6. The Data Load utility is the recommended command-line loading utility. If you are currently using the mass load utility, you are recommended to switch to the Data Load utility to load your CSV and XML input files into your target database. If your system contains scheduled and automated processes that use massload, it is recommended that you update these processes to use the Data Load utility. Other WebSphere Commerce utilities that use the massload utility, such as the acpload utility, continue to use the massload utility in WebSphere Commerce Version 7 Feature Pack 6. If you have business reasons to continue using the massload utility, you can continue to use this utility. For more information about the Data Load utility, see Overview of the Data Load utility. You can switch to the Data Load utility by using the TableObjectMediator to load your data when no business object mediator exists for the data that you are loading. For more about the TableObjectMediator formation, see Data Load utility table-based mediator and builder.

      You can translate and populate many XML files by 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, you 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 that is displayed in your pages. Create multiple versions of some of these components, one for each language or culture that is supported by your 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 you 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. The native2ascii converter is in the following directory:
      • SolarisLinuxAIXWAS_installdir/java/bin
      • For IBM i OS operating system QIBM/ProdData/Java400/jdk13/ibm/bin
      • WindowsWAS_installdir\java\bin
      • WebSphere Commerce DeveloperWCDE_installdir\AppServer\java\bin

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