Creating translatable plug-insAdded by IBM on October 4, 2010 | Version 1 (Original)
|You may have to customize your plug-in to make it display appropriately for international audiences.
You may have to customize your plug-in to make it display appropriately for international audiences.
- Separating out all hard-coded text strings that appear in the user interface, in error messages, message boxes, or titles that display in title bars
- Enabling the date and number objects you use to be formatted based on the user‘s preferred locale
To ensure that a plug-in is translatable, do the following:
- Define all translatable strings in a .properties file associated with the plug-in. For example, instead of defining the name of the plug-in in the plugin.xml file, define it in a file called plugin.properties, which associates the .properties file to the plugin.xml file. For example, define the name of the plug-in in the plugin.properties file as follows:
- In the plugin.properties file, include the following text to define the %plugin.name keyword:
plugin.name = My Super-useful Plugin
- Use the Rational® Software Delivery Platform or a similar product to search your source code for all translatable strings. Replace each string with a keyword and define the keyword in a .properties with the same name as the file that contained the translatable string.
- Identify the locale-specific objects in your plug-in, then organize them into categories and store them in different ResourceBundle objects accordingly. For example, you can store a series of String objects in a PropertyResourceBundle, which is backed up by a set of properties files, or you can manage all locale-specific objects using a ListResourceBundle, which is backed up by a class file. Though the ListResourceBundle object requires you to code and compile a new source file to support any additional locales, ListResourceBundle objects are useful because unlike properties files, they can store any type of locale-specific object, not just text objects.
- Use the standard Java library classes that localize the formatting for numbers, dates, times, and currencies. None of these object types can be displayed or printed without first being converted to a String. The formatting classes enable you to use the proper format for the user‘s locale when converting an object into a String object. For example, if you use the factory methods provided by the icu4j.jar package NumberFormat class, you can get locale-specific formats for numbers, currencies, and percentages. The DateFormat class provides predefined formatting styles for dates and times that are locale-specific and easy to use.
- Create a plug-in fragment to contain all .properties files associated with a specific language group. IBM® uses the following convention when naming the language fragments:
Language pack fragment containing IBM Group 1 languages =
Language pack fragment containing IBM Group 2 languages =
- Provide a feature to group the Language packs you are including in your application. Use the following convention when naming the features:
Language pack feature containing IBM Group 1 languages =
Language pack feature containing IBM Group 2 languages =
Specify any translatable text in the feature.xml
file in an associated feature.properties
See the eclipse.org Web site for more details on internationalizing a plug-in at http://www.eclipse.org/articles/Article-Internationalization/how2I18n.html
Parent topic: Globalizing your application: XPD621