Introduction

This document gives a short guideline for localization-aware Intershop 7 programming. It introduces the current (still limited) standard localization approach and points out what code artifacts are, consequently, subject to localization.

Motivation

Why bother at all?

• Intershop claims to be an international company that produces enterprise software for global markets. As "global" does not mean "English everywhere", Intershop developers must be aware that their software is potentially localized (= translated) to any language, including some completely different from English or German. That means, our traditional, well-known "phrase-building practices" may not work at all, so that any text shown in the UI should be completely separate (or, at least, completely separable) from the code. (You may say, this is commonplace. But still: It is not general practice yet.)
• Internationalized (= localization-aware) software helps reducing implementation and maintenance costs in international (or just German) projects. This way, it helps partners and customers to get ahead with Intershop software ("enables" them).
• "Localization" was rank 12 (Mar 2012 - Mar 2013) of the most frequently asked search phrases of the (external) Knowledge Base, so it seems to be important out there.

Localization Approaches

Externalized Strings

Language-specific elements are externalized from the code and kept, managed and localized individually. To this end, Intershop 7 has introduced the localization framework, which allows to separate the language-specific elements from implementation artifacts (currently, Java and ISML).

Find more information about the framework and some corresponding how-tos in Concept - Localization and Cookbook - Localization (valid to 7.9).

In order to retrieve the texts to be localized, the current approach involves a file system search for externalized ISML strings and pagelet properties.

Static Text in ISML

Static, localizable text within the ISML code is to be externalized using a specific tool in Intershop Studio'sISML editor. For details, refer toGuide - 7.4.6 Externalize Texts from ISML Templates.

Localized Artifacts

Code

The current localization approaches already tell which code artifacts are currently localized: ISML templates and pagelet properties. That is: If you want to be sure that your (potentially localizable) texts are subject to the standard product localization, they must be either

• externalized ISML texts, which must be located in *_en.properties in <cartridge>/../localizations,
• static text within ISML, which can be processed by tLoc (see Cookbook - tLoc (valid to 7.4)), or
• pagelet names/descriptions as shown in the back office, which must be located in *.properties in <cartridge>/../pagelets.

Data

Currently, there is no clear definition of "demo data". Actually, the current localization approach only applies to code, that is, text strings that are part of a back office application or a storefront application. There are, however, strings that customers/partners seem to consider some sort of "standard data", which is not removed or replaced in their installations but used (e.g., shipping data like regions, role names/descriptions, and other).

As this data is located in sub-directories other than localizations or even in the ucm_demo cartridge, it is not localized. Whether this is correct or not is to be discussed with PM/RE.