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

Talk:COSMOS Design 208593

Revision as of 10:14, 8 January 2008 by Popescu.ca.ibm.com (Talk | contribs)

Comments Paul Stratton 4 jan,2008

Jimmy

Your text includes most of the points that are covered in a general search on the web for internationalization requirements, and so is a good start.

Some additional points that come to mind:

1) Do we need to specify a target list of countries or Languages for which internationalization will be possible. Some languages require more effort to accommodate that others eg) BIDI, Multi Byte characters, Vertical text, Cyrillic etc

2) Some countries have cultural issues with certain colors and symbols … Do we need externalized graphics resource ?

--Popescu.ca.ibm.com 13:39, 4 January 2008 (EST)

  • To answer your question on where the XLIFF standard can be used : XLIFF is one option for localization support in xml documents. I think Sheldon has a few scenarios where xml documents need to be localized.
  • General comments :
    • We have to acknowledge that the COSMOS framework uses different environments already having a prescribed way for localizing messages. In these cases we should use the prescribed approach.
    • For example, any eclipse plugin should be localized using the Eclipse localization guidelines. If plugin content, such as jar files, are to be used outside of the Eclipse environment, then those jars need to be called out so that we identify an alternate way of offering translation support when the jars are not running in an Eclipse environment. A different approach should be taken for native code.
    • To be able to successfully test localization we need to have translation support..so we need bundles in different locales to validate some of the globalization items you list ( bidi, etc ). One open question is what languages we plan to support. Another question is who will provide this translation. Until these questions are answered we should just aim for making sure strings are separated from code.

Back to the top