Skip to main content

Notice: This Wiki is now read only and edits are no longer 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 QA Criteria"

('''Is COSMOS 1.0 well-formed software?''')
('''Message Handling Considerations''')
Line 103: Line 103:
 
## We need to specifiy details of this capability
 
## We need to specifiy details of this capability
  
== '''Message Handling Considerations''' ==
+
== '''Ensure COSMOS 1.0 is a consumable entity''' ==
  
The COSMOS messages must consider the following guidelines to support i18n:
+
To ease the adoption of COSMOS 1.0, the following  
  
# Prefix each message with unique message-ids
+
# Asses install documentation, i.e. is there enough information on the download page to be able to install the required functions ?
# Label 3rd party messages when shown from COSMOS
+
# Asses Update Manager capabilities (not there yet…)
 +
# Are the offered packages fully functional, i.e. the content described on the install page matches the downloaded package
 +
# Assess case for COSMOS 1.0 to Executive Management
 +
# Assess package for adopting developers
 +
# Asses package for other types of adopters, if applicable
 +
# Evaluate prerequisite definition
 +
# Evaluate upgrade and patch process for COSMOS 1.0
  
 
== '''i18n Checklist''' ==
 
== '''i18n Checklist''' ==

Revision as of 02:17, 8 January 2008

COSMOS QA Creiteria

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
Initial specification 2 Jimmy Mohsin
Review by COSMOS team 2 COSMOS Team
Review and sign-off 1 QA Team
TOTAL 5

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

The QA Creiteria will be specified by the COSMOS team; and will be used to specifiy the exit for all COSMOS 1.0 iterations going forward. The intent is to apply these criteria to i9 onwards.

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.

Ensuring COSMOS 1.0 is well-formed software

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

  1. Assess the JUnits as well as any other type of tests
  2. Evaluate the integration tests
  3. Evaluate the iteration and milestone close processes
  4. Assess the open source tooling used to test COSMOS 1.0

Identify all the end-to-end tests

All COSMOS 1.0 iterations must pass the following end-to-end tests:

  1. Scalability
    1. We need to specifiy details of this capability
  2. Performance
    1. We need to specifiy details of this capability
  3. Concurrency
    1. We need to specifiy details of this capability
  4. Availability
    1. We need to specifiy details of this capability
  5. Stress testing
    1. We need to specifiy details of this capability

Ensure COSMOS 1.0 is a consumable entity

To ease the adoption of COSMOS 1.0, the following

  1. Asses install documentation, i.e. is there enough information on the download page to be able to install the required functions ?
  2. Asses Update Manager capabilities (not there yet…)
  3. Are the offered packages fully functional, i.e. the content described on the install page matches the downloaded package
  4. Assess case for COSMOS 1.0 to Executive Management
  5. Assess package for adopting developers
  6. Asses package for other types of adopters, if applicable
  7. Evaluate prerequisite definition
  8. Evaluate upgrade and patch process for COSMOS 1.0

i18n Checklist

Here is a check list to determine whether COSMOS is i18n-ready or not:

  1. Menus, dialogs and web layouts can tolerate text expansion
  2. Development language strings are reviewed for meaning and spelling to reduce user confusion and lessen translation errors
  3. Third-party software used in the product is examined for i18n support
  4. Consistent terminology is used in messages
  5. COSMOS runs properly in its base language in all target locales
  6. Strings are not assembled by concatenation of fragments
  7. Source code does not contain hard-coded character constants, numeric constants, screen positions, filenames or pathnames that assume a particular language
  8. String buffers are large enough to handle translated words and phrases
  9. East Asian editions support line-breaking rules
  10. All international editions of the program are compiled from one set of source files
  11. Localizable items are stored in resource files, message tables or message catalogues
  12. All language editions share a common file format
  13. Program handles non-homogeneous network environments where machines are operating with different encodings
  14. No assumptions are made that one character storage element represents one linguistic character
  15. Code does not use embedded font names or make assumptions about particular fonts being available
  16. Program displays and prints text using appropriate fonts
  17. Sorting and case conversion are culturally correct
  18. Application works correctly on localized editions of the target operating system(s)
  19. Specific for web internationalization:
    1. Check middle-tier components for internationalization compliance
    2. Ensure that information about encoding and locale of data is passed correctly between presentation and backend tiers

Task Breakdown

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

  1. TBD

Open Issues/Questions

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

--Popescu.ca.ibm.com 13:23, 4 January 2008 (EST)XLIFF is one option for localization support in xml documents.


Back to the top