G11N Half Pager

1. Introduction

1.1. Project/Component Working Name:

GlassFish Open Source Edition 3.1 globalization

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Georges Murr: georges.murr@oracle.com

1.3. Date of This Document:

06/02/2010

2. Project Summary

2.1. Project Description:

Globalization readiness of GlassFish Open Source Edition 3.1

2.2. Risks and Assumptions:

Translatable files need to be ready on time for translation.
Need RE support to build l10n packages.
Module owners need to follow i18n guidelines.

3. Interfaces:

3.1 Exported Interfaces

N/A

3.2 Imported interfaces

GlassFish Open Source Edition 3.1 IPS Packages

4. Scope

4.1 Translation languages

Translation languages fr, de, es, ko, ja, zh_CN, zh_TW, pt_BR

4.2 Localization Scope

Admin GUI, CLI, Installer, OLH, Upgrade tool
We will not translate log messages, docs.

5. Packaging

There is one-to-one mapping between EN packages and l10n packages. If a base packahe contain files that need to be localized, there will be a corresponding l10n package for it.

5.1 l10n packages naming convention

l10n packages use the following naming convention: <base package name>-l10n

5.2 Dependencies

Each l10n package depend on the corresponding EN base package

6. l10n module description

The l10n module is located in its own workspace. It contain the EN files that need to be translated and the l10n files. The l10n module is self contained; which means we do not need to checkout glassfish worksapce in order to build l10n packages. EN files are extracted from maven repository using dependency plugins.
l10n module contain a packager sub-module to create l10n packages. l10n packages are published into maven repository. ml build process is integrated into glassfish build system. glassfish build automatically produces ml bits at the same time as EN bits by using the l10n packages that are published in maven repository.

7. Testing impact

We will perform i18n testing before translations to make sure modules are ready for localization.
Modules to be localized will be tested on supported platforms. Since the matrix is too large, 8 x supported platforms, we create a testing matrix that distributes certain languages to certain platforms.
i18n functional testing will also be performed on modules with APIs relevant to i18n testing: Web container, EJB container, etc..