An Architectural approach towards designing i18n/l10n, globalization components in the Globalization Enterprise Platforms independent of technology. This provides a Best practices guide/pointers for Architects, designers, developers and QA folks. This is mapped to the use case based on Automotive customer for a global platform application.

1. i18n Architectural/Design Approach for Global
Enterprise Platform Architectures – A usecase from
Automotive domain customer from US Central:
Reddappa Gowd Bandi
15th
Nov 2006
Director Technology & Multibyte COE Head
Background of the System:
i18n is one of the Architectural requirement for a Global Enterprise projects which
supports single/double/multibyte inherently . This project is intended for China/Japanese
Kanzi/Multibyte and other 10 double byte and 7 single byte languages, specifically.
Initially this project is planned for phases. In the phase 1 project, the requirement says,
system will support for Chinese Traditional language at every aspect and at the same
time, application needs to support for other countries like North
America/Japan/Dutch/Portugese and etc.
As per Architectural discussions and artifacts, the Global Enterprise Workbench system
should support for both single byte and double/multibyte languages. This drastically
increases the ROI of the system when it will intend to support for other countries with
minimal configuration support.
I18n Scope within the System:
1. Different components in the Architecture space right from the client side to
Chordiant and DB need to support i18n.
2. CAFÉ (custom chordiant UI application) windows, CAFE UI Pages, CAFE Menu
items, Activities, offerings data, CAFE UI page level data, style sheets,
Javascripts, specific UI components if any should support for standard i18n
implementation & practices.
3. XML configurations and system/application level properties files should have
support for i18n.
4. Landing page & thumbnail JSF pages, UI components, Javascripts, CSS and
other components should have support for i18n.
5. The underlying DB should support for UTF-8/16 data and intern supporting for
i18n.
6. Chordiant workflows and Interaction control flows should support for i18n.
7. Chordiant services, Business objects and persistent layer (Hibernate
components) should support for i18n.

2. 8. Utility components and Business logic helper components should support for
i18n within the project.
9. Interfaces to the external systems like GVS, GGIS, GVUDS and RTE systems
should support i18n implementation.
Out of scope items from Phase 1:
1. Implementation of Address free formats.
2. Phone number free formats implemented partially and to one extent. The full
support for free formats deferred to the next phase.
3. Implementation of the couple of business level services and business logic
components are deferred to the next phase.
Technical Design Approach:
Standard i18n design procedures are considered in the GAA system for the different
components end to end in the Architecture like
1. I18n at UI side
2. I18n at workflows and Services side
3. I18n at third party interfaces
4. I18n at Hibernate side
5. I18n at DB side
i18n at UI side:
1. i18n implementation at UI side components like JSF pages, CSS, UI
components, Javascript are implemented based on UCS2.0 standards and
supports for UTF-8.
2. Standard Resource bundle approach is followed for locale sensitive data like UI
labels, page level data, validations, messages and images.
3. At the time of user login, user credentials are captured, there by application
knows the primary locale of the user at runtime, the same will be stored in the
session for first time and afterwards, locale will be referred from session.
4. Based on the locale from the session, the corresponding resource bundle and
other locale specific resources like Date formats, Time formats, validation
expressions (regular expressions) and etc. will be picked up by using JSF locale
framework.
5. And based on the locale, Charset and Encoding parameters at JSF page level
will be supplied through runtime framework. And the resources from the bundle

3. will be picked up by Key-value pairs from resource bundle objects. And the same
will be referred at the page level as Key names.
6. UI components like Calendar components and Date/Time formats will be picked
up the properties at runtime accordingly.
7. Locale specific Javascript code will be used in the JS components accordingly.
The JSON/XML transformations will be in UTF-8 accordingly.
8. For double/multibyte (Chinese) resource bundles, the native resource bundles
will be transformed to UTF-8 strings using native2Ascii tool so that JVM native
encoding will be matched with the Resource bundle objects. This step is needed
only when for JVM and Resource bundle native encodings are different.
9. Separate CSS files will managed for Chinese locale as page/UI/cell Layouts,
directions of the text and pixel widths completely driven by the locale.
10. Configuration XML files need to be changed accordingly for chinese locale.
i18n at Workflows and Services side:
1. Chordiant Business Process workflows will be designed accordingly which
supports for i18n operations.
2. UTF-8 will be data format will be considered in the flow interactions. And the
pre/post conditional logic should support i18n specifics.
3. Any business rules checks or execution of validations should consider them in
the UTF-8 format. Use locale specific API appropriately and at respective
locations.
4. Chordiant services and business objects should support the UTF-8 data transfer
as well as the service level operations should consider UTF-8 input data for any
business logic executions.
5. Data transport between the workflows and contexts will be UTF-8. Need to use
Collators/Rule based collators where and when necessary to check the objects,
comparisons and etc.
6. Well defined i18n coding practices are listed out in the coding guidelines
document. This will help in developing the code.
7. Data objects should support for linguistic sorting.
i18n at third party interfaces side:
1. Integrations with the third party systems like GVS, GGIS, GVUDS and RTE
Should support for UTF-8 data transfer. And also the data transport should
support in UTF-8.

4. 2. If any query string parameters are passed across, those will be encoded
accordingly.
3. Date/Time formats should definitely match with application specifics on both
sides. Programmatically force the serializations/deserializations and check for
match or enforce the locale specific Date formats accordingly.
4. JSON/XML operations in the Javascript side need to have special care while
developing methods. This is very much essential when interacting with GGIS.
i18n at Hibernate side:
1. Hibernate session should force to have UTF-8 encoding. Otherwise JVM native
encoding will take precedence.
2. Use UTF-8 as data transfer and for data objects to be handled.
3. Use the Hibernate synchronizer to generate the hibernate artifacts and need to
set the configurations matching to UTF-8.
4. In case if any detached objects are there, try to handle carefully while again
synchronizing back in the Hibernate session. Those always need to be in UTF-8
format.
5. XML Parsers internal to the Hibernate should have support for parsing multibyte
XML files.
i18n at DB side:
1. All the DB parameters set to UTF-8 and schemas are generated with appropriate
column widths.
2. If any columns with byte data type, need specific care and convert them to
appropriate multi byte lengths.
3. Making use of NLS features, follow the DB level case insensitive search features.
4. Create linguistic indexes and use linguistic Sort functionalities accordingly.

5. Language Translations & Development/Production implementation
Process:
1. Identify the locale sensitive data within the application/system which covers
entire application.
2. And then extract the locale sensitive data for translations from different parts of
the application into one repository and keep track of what data came from which
location.
3. Prepare the dictionary meaning for each Key value so that translation agency will
enforce those rules in translations. For example, translation should be within 10
characters.
4. Export the entire repository to Standard XLIFF format files and send it across to
the Translation Agencies. And also export supporting dictionary files with rules.
5. Translation Agency will put translations accordingly and send back those XLIFF
files back to development team.
6. Development team runs manual programs to import back all the XLIFF data into
repository and then to Resource bundle files. And these resource bundle files will
be in native Chinese.
7. These Chinese resource bundle files will be supplied to the native2Ascii tool for
converting multi byte Chinese strings to UTF-8 ASCII strings.
8. This can be automated through some build scripts. We need to use native2Ascii
ant task to do this job. And save those into other properties file.
9. The saved properties will be now as an input for the application as Resource
Bundle file in which Resource bundle objects will be created for further accessing
the resources through key value pairs.
10. And finally application will be run accordingly.
11. In case any tampered Chinese native files, we have to resend the entire file back
to translations agency and the above steps need to be repeated.

6. Language Translations & Development/Production implementation
Process:
1. Identify the locale sensitive data within the application/system which covers
entire application.
2. And then extract the locale sensitive data for translations from different parts of
the application into one repository and keep track of what data came from which
location.
3. Prepare the dictionary meaning for each Key value so that translation agency will
enforce those rules in translations. For example, translation should be within 10
characters.
4. Export the entire repository to Standard XLIFF format files and send it across to
the Translation Agencies. And also export supporting dictionary files with rules.
5. Translation Agency will put translations accordingly and send back those XLIFF
files back to development team.
6. Development team runs manual programs to import back all the XLIFF data into
repository and then to Resource bundle files. And these resource bundle files will
be in native Chinese.
7. These Chinese resource bundle files will be supplied to the native2Ascii tool for
converting multi byte Chinese strings to UTF-8 ASCII strings.
8. This can be automated through some build scripts. We need to use native2Ascii
ant task to do this job. And save those into other properties file.
9. The saved properties will be now as an input for the application as Resource
Bundle file in which Resource bundle objects will be created for further accessing
the resources through key value pairs.
10. And finally application will be run accordingly.
11. In case any tampered Chinese native files, we have to resend the entire file back
to translations agency and the above steps need to be repeated.