Internationalization Support

{{#eclipseproject:technology.higgins}}

This page is information for active committers and contributors about Internationalization of the Higgins project.

Overview

This page is the description for the active proposal and implementation of the beta Internationalization guidelines for Higgins projects.

All components and solutions must support internationalization. The goal is to have Higgins code internationalized, such that other users could localize the code to their native deployment requirements. Eclipse Globalization Guidelines. Two proposals were reviewed at the 19-June-08 Higgins Developer call; see proposal summary at bottom of this page. After discussion and review at this meeting, it was decided that Proposal 2 would be the one Higgins would adopt for the next step (phase 1 noted below) to adopt I18N requirements for Higgins components.

Higgins Internationalization Proposed Implementation Plan

1. Phase 1 - There will be several parts to this first pilot phase:
   • David to drive the I18N requirements and code changes for IdAS API package in support of his project. This will be the pilot project to run through the current proposed I18N standard as noted here. UPDATE 25-Jul: completed this pilot work and details can be found here. The plan is to get this reviewed and included in an upcoming Higgins 1.1 milestone build (M3 or M4).
   • Once David and team are done with this project, they will document on wiki their findings and summary.
   • During this phase it is incumbent on other Higgins committers and/or component owners to review and voice any opinions, concerns or provide input on the general I18N requirements that are being applied in this pilot phase. The intent would be to learn from this pilot and then apply this standard and process across all Higgins components in future phases.
2. Phase 2 - Brian/Mary will leverage the phase 1 work to do the following:
   • Host/broadcast any updates to the I18N standard that come out of phase 1 pilot experience to the Higgins community.
   • Help identify/prioritize the next Higgins components that should next adopt/update their code to support the I18N requirements and facilitate/drive getting these next round of components compliant with the I18N standard. UPDATE: David to propose the next Higgins components of interest to work on adopting this standard.

Notes from Beta Implementations

JNDI-CP Internationalization

• Prakash completed the internationalization of the Higgins JNDI-CP from the M2 stable build version
• The following are the progression of steps used for this deliverable:
  1. Created a new package org.eclipse.higgins.idas.cp.jndi.I10n under org.eclipse.higgins.idas.cp.jndi
  2. Added a file JNDIContextMessages.java in package org.eclipse.higgins.idas.cp.jndi.I10n of jnid-cp component. (This class is extended from NLS class defined in org.eclipse.osgi.util.NLS comes with eclipse installation c:\eclipse\plugins\org.eclipse.osgi_3.3.2.R33x_v20080105.jar)
  3. Added new methods in JNDIContextMessages class to support message parameterization.
  4. Added JNDIContextMessages.properties message bundle in package org.eclipse.higgins.idas.cp.jndi.I10n
  5. All message id that are defined in above properties file has to be defined as string types in JNDIContextMessages class.
  6. JNDI-CP doesn’t contain any plugin.xml file , or else any plugin.xml can be globalized by adding a corresponding plugin.properties file as per eclipse globalization guide lines. (This is applicable if the plugin.xml contains any hard coded user specific messages which needs translation )
  7. All usage in JNDI-CP java files are replaced with JNDIContextMessages class’s message id and all parameterized args are handled through bind API defined in JNDIContextMessages class.
• Extra dependency and performance advantages:
  • As per old eclipse globalization guide lines we don’t need the extra jar file for building and running the component to be globalized. But for better performance during searching string using message Id , the message class corresponding to properties file has to be extended from org.eclipse.osgi.util.NLS class . This stores all the strings defined in properties file in the memory through corresponding string type member in message class as done in JNDIContextMessages.java file during the class load operation. This makes possible in accessing the messages from the memory instead of searching the message from the property file during querying the message through message id key.
  • The extra dependency jar file that comes with Eclipse 3.1 or higher version of Eclipse IDE has to be used during build of this component and also has to be shipped with IdAS components if the above approach needs to be followed for globalizing all Higgins IdAS components.

Other Internationalization Consideration

Other coding practices

Other coding practices from the guidelines should be followed. Automated testing on internationalized configurations should be considered.

Internationalization of the Browser Plug-ins should follow the same conventions, but may be constrained by the browser conventions.

Babel

Actual translations and language packs can be provided by consumers. An incubator project, Babel, supplies a set of tools to import *.property files from projects and make the translation possible through a community of translator. Translations could also be contributed by consumers. Babel should be explored to see if the Higgins could exploit the translator community for language pack development. Babel project/tools in Eclipse found here.

Babel RCP plug-in could be used to help localize messages, check for errors.

Proposal Options

Proposal 1

Use a Higgins common messages package and place all translatable strings in this properties file. The STS component is using org.eclipse.higgins.messages. This creates a common component, but makes translation a little less flexible and all components would carry the strings for all packages. This might make managing Higgins translation packs easier, when using multiple components in a solution.

Proposal 2

Because the Higgins components are packaged as OSGi bundles (plugins) the Eclipse guidelines for Internationalization would apply (many of the guidelines would still apply, if using Proposal 1). Guidelines and 'how to' instructions for development and testing located here.

Each Higgins OSGi Plug-in would have its own properties file containing the translatable strings. the messages can be translated component by component. There are more files to handle, but it makes the component translation more independent.