Introduction

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

Motivation

Intershop is an international company that produces enterprise software for global markets. As "global" does not mean "English everywhere", Intershop 7 developers (both internal and partners/customers) 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 any code functionality.

Internationalized (= localization-aware) software helps reducing implementation and maintenance costs in international (or just German) projects. This way, it helps implementation partners and customers to get ahead with Intershop software.

Localization is not a feature but (must be) common practice.

Localization Approach

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.

If you still have static localizable text in custom ISML templates, Intershop strongly recommends to extract these stringsusing a specific tool in Intershop Studio'sISML editor (seeGuide - 7.4.6 Externalize Texts from ISML Templates) instead of using tLoc, as this contradicts thecontinuous integration approach introduced with Intershop 7.4 CI (seeConcept - Continuous Delivery Tools (valid to 7.10)).

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, or
pagelet names/descriptions as shown in the back office, which must be located in *.properties in <cartridge>/../pagelets.

All other code artifacts that may contain localizable texts are not currently localized by default.

Data

Currently, there is no clear definition of "demo data". The current localization approach only applies to code, that is, text strings that are part of a management application or a storefront application. There are, however, strings that customers/partners consider "standard data", which is not removed or replaced in their implementations but just used (e.g., shipping data like regions, role names/descriptions, rule snippets and other).

As this data is located in sub-directories other than localizations or in demo orinit cartridges, it is not localized by default. If you intend to localize this data as well, be sure to extend your file system search to other locations like javasource/../dbinit/data.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.