| Localization | ||
|---|---|---|
 | Chapter 3. Tapestry Components |  |
| Localization | ||
|---|---|---|
| | Chapter 3. Tapestry Components | |
Tapestry has built in support for localization, designed to be easy to use. This localization support is defined in terms of transforming the user interface into a format appropriate the the locale of the user. This primarily takes the form of localized text (translated into the end-user's language), but can also affect other aspects of look and feel including colors, images and layout.
Tapestry has two different methods for supporting localization; developers are free to mix and match solutions according to their own preferences.
Each client connecting to the application will select a particular Locale.
When a page for the application is created, the locale is used to select the correct localized
resources.
Locales are defined by the ISO (International Standards Organization).
A locale consists of a language code (such as 'en' for English, 'de' for German or 'fr' for French)
and a country code (such as 'AU' for Australia, 'BE' for Belguim, or 'GB' for United Kingdom).
A client's initial locale is determined by analyzing HTTP headers provided with the initial request. An application may override this default, which records a client-side cookie identifyng the desired locale. An example of this is included in the Tapestry Workbench demonstration.
Each individual component may have a set of localized strings.
Remember that pages are just a specific kind of component.
This set is built, much like the properties of a ResourceBundle, from one
or more .properties files. These files are located on the classpath, in the same
directory as the component specification (the .jwc file).
The search for strings is much the same as with ResourceBundle, except
that only .properties files are considered (ResourceBundle also looks for classes).
Example: for a component /com/skunkworx/skunkapp/Border.jwc and a locale of
fr_BE would be:
/com/skunkworx/skunkapp/Border_fr_BE.properties
/com/skunkworx/skunkapp/Border_fr.properties
/com/skunkworx/skunkapp/Border.properties
Searching for individual keys works just as with ResourceBundle, the search starts in the most
specific file (Border_fr_BE.properties) and continues downward if not found.
Components can gain access to their container's localized strings
via the <string-binding>
element in the component specification.
Tapestry allows multiple versions of HTML templates and assets (described in a later section) to be deployed with the application.
The base template name is derived from the specification name,
by changing the jwc extension to html.
For example, component /com/skunkworx/skunkapp/Border.jwc
will have a base template name of /com/skunkworx/skunkapp/Border.html.
This resource name is used as the basis of a search that includes the locale.
Various suffixes are inserted just before the '.html' extension.
A French speaking Belgian visitor would provoke the following search:
/com/skunkworx/skunkapp/Border_fr_BE.html
/com/skunkworx/skunkapp/Border_fr.html
/com/skunkworx/skunkapp/Border.html
![[Note]](common-images/note.png) | Note |
|---|---|
This form of localization actually predates the alternate form, using localized strings. Localizing the strings seperately from the rest of the HTML template is generally a better and easier way. Localization of templates will, in the future, be used primarily when changing the layout of the template ... for example, to provide a right-to-left orientation in a Hebrew localization. |
| |  | |
| Tapestry and HTML Production |  | Assets |