i18n Architectural/Design Approach for Global Enterprise Platform Architectures – A usecase from Automotive domain customer from US Central:

Reddappa Gowd Bandi15th 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.

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 side2. I18n at workflows and Services side3. I18n at third party interfaces4. I18n at Hibernate side5. 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

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.

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.

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.