Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS Design 208593"

('''GUI Considerations''')
('''Message Handling Considerations''')
Line 132: Line 132:
 
== '''Message Handling Considerations''' ==
 
== '''Message Handling Considerations''' ==
  
The COSMOS Messages must consider the following guidelines to support i18n:
+
The COSMOS messages must consider the following guidelines to support i18n:
  
# Dynamic user elements should be used when displaying simple layouts and text messages
+
# Prefix each message with unique message-ids
# Dynamic user elements should not be used when special and complicated layout configurations are needed
+
# Label 3rd party messages when shown from application
# Allocating extra space as translated text may be much longer than the English text
+
# Do not split multi-byte characters
+
  
 
== ''' Test Coverage ''' ==
 
== ''' Test Coverage ''' ==

Revision as of 00:44, 4 January 2008

Internationalization Support - programming model

Change History

Name: Date: Revised Sections:
Jimmy Mohsin 01/3/2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 1 Jimmy Mohsin
Code (not part of this ER) 4 Dev Team
Test (not part of this ER) 4 QA Team
Documentation (not part of this ER) 1
Build and infrastructure (not part of this ER) 1
Code review, etc. (not part of this ER) 1
TOTAL 12

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:

Term Definition
Internationalization The process of generalizing the design of a product so that it can handle multiple languages and cultural conventions without the need for making code changes for each language. COSMOS 1.0 will be internationalized for its eventual adoption and deployment
Localization The process of taking an internationalized product and making it linguistically and culturally appropriate to the target locale (country/region and language) where it will be used. COSMOS 1.0 will not be localized for any non-US English languages, this is something that the adopers will need to do.
Translatable Elements Everything intended to be locale and language dependent. These items may need to be modified for different locales, e.g. date formats, time formats, word lists for content controls, and so on.
Non-user elements Everything not intended for end-users to see and understand. This fits into two categories, proper names and internal elements. Examples of internal elements are command line commands and options, debug strings, registry keys, program file names, comments, and so on. Examples of proper names are product name, company name, and so on.
User Elements Everything intended for end-users to see and understand, e.g. menus and menu items, dialog boxes, windows, program groups, error messages, installation scripts, icons, buttons, "Display Name" and "Description" fields for services we create on Windows, and so on.

Purpose

This enhancement is associated with bugzilla 208593.

The data visualization component does not follow a consisten design pattern to support internationalization. There are serveral components within the visualization project that require internationalization support:

  1. Dojo widgets
  2. Servlet data feeds
  3. XML configuration files
  4. ANY OTHER COMPONENTS ???
Dojo widgets do support i18n, as documented on http://dojo.jot.com/WikiHome/Internationalization?revision=18. For each of these components there are best practices to support internationalization; however, a common methodology is needed.

Requirements

The following is the list of requirements that this enhancement will address:

  1. Checking the conformance of a CMDBf query against its schema
  2. Checking the conformance of a CMDBf registration request against its schema
  3. Transformation of CMDBf XML query from/to a POJO representation
  4. Transformation of CMDBf XML registration from/to a POJO representation
  5. A common method of processing a CMDBf query
  6. A common method of processing a registration request

Codebase Considerations

The COSMOS code must consider the following guidelines to support i18n:

  1. Externalize all translatable elements(i.e. no hardcoding)
  2. Put translatable elements in language modules separated from executables
  3. Generalize design to support any language
  4. Dynamically select and load language module at run time
  5. Separate build process for language modules from executable
  6. Gracefully handle missing language resources
  7. Handle regional settings
    1. Date Format and Time Formats
    2. Number Formats
    3. Currency
    4. Paper Size
    5. Sort Order
  8. Clearly identify which strings should or should not be translated
  9. Avoid string concatenation
  10. Not embed text in icons and bitmaps

GUI Considerations

The COSMOS GUI must consider the following guidelines to support i18n:

  1. Dynamic user elements should be used when displaying simple layouts and text messages
  2. Dynamic user elements should not be used when special and complicated layout configurations are needed
  3. Allocating extra space as translated text may be much longer than the English text
  4. Do not split multi-byte characters

Message Handling Considerations

The COSMOS messages must consider the following guidelines to support i18n:

  1. Prefix each message with unique message-ids
  2. Label 3rd party messages when shown from application

Test Coverage

Unit tests will need to perform the following tests:

  • Transform a RegisterRequest POJO to XML and back to a POJO, and compare the start and end POJOs
  • Transform a RegisterResponse POJO to XML and back to a POJO, and compare the start and end POJOs
  • Process an empty query
  • Processing a query with just one item
  • Processing a query with a relationship and no items
  • Processing a query with matching items and an unmatched relationship
  • Processing a query with matching items and a matched relationship
  • Processing a query with a relationship that has cardinality
  • Processing a query with unregistered selector handlers
  • Processing an empty registration request
  • Processing a registration request with one item
  • Processing a registration request with matched items and missing relationship
  • Processing a registration request with matched items and a relationship
  • Processing a registration request with a relationship and no items
  • Processing a registration request with missing registration handlers

Task Breakdown

The following section includes the tasks required to complete this enhancement .

CMDBf-PertChart-v1.png


  1. Refactor plugin, package and class names in cmdbf.query plugin to represent the 5 different jar configurations
  2. Refactor the JUnits for the query transformation
  3. Create graph representation of registration request and response
  4. Create the registration input transformer
  5. Create the registration output transformer
  6. Add in JUnits for the registration transformer
  7. Add in the APIs for processing a CMDBf query
  8. Implement a generic implementation of the CMDBf query processor
  9. Add in JUnits for the CMDBf query APIs
  10. Modify the SML repository to make use of the new API set
  11. Add in the APIs for processing a CMDBf registration request
  12. Implement a generic implementation of the CMDBf registration processor
  13. Add in JUnits for the registration APIs

Open Issues/Questions

All reviewer feedback should go in the Talk page for 208593.


Back to the top