Internationalization / Localization¶

This site describes the conventions for i18n and L10n of our projects.

• Table of contents
• Internationalization / Localization
  • Taxonomic Editor
    • Project structure
    • Conventions

Taxonomic Editor¶

Project structure¶

Each plugin has the following structure:

<plugin_root>
 |-src/main/java
 | \-eu.etaxonomy.taxeditor.xyz
 |  \-l10n
 |   \-Messages.java
 |    |-messages_xx.properties
 |    |-messages_yy.properties
 |    \-messages.properties
 \-OSGI-INF
   \-l10n
    |-bundle_xx.properties
    |-bundle_yy.properties
    \-bundle.properties

• xx, yy, etc. stand for the single country codes
• the .properties files without country code are the default files used if no locale is specified
• bundle.properties are for externalized string from the plugin.xml (mostly labels for menus, toolbar, context-menus)
• messages.properties are for Java classes (mostly exception texts and user interaction, dialogs, etc.)
• Messages.java is used to access the externalized strings in Java classes. It "connects" the messages.properties files to the Java code
• Note: When externalizing Java classes with Eclipse (right-click->Source->Externalize Strings) you have to adapt the path to Messages.java and the properties file or Eclipse will create a new Messages.java and messages.properties file in the current package

Conventions¶

• For sustainable future updates it is always recommended to keep the language specific .properties files in sync with the default one
  • Try to do the translation directly if you know the language
  • If you don't know the language at least copy the newly created key-value pairs into the language specific .properties file
• For comparison it is much easier if the .properties files all have the same order of key-value pairs
• Do not include technical strings into the externalization process like e.g. "; " or exception messages like "IEditorInput received a null selection"
  • even if this is displayed to the user, translating it would probably make it worse
  • if it is shown via the MessagingUtils the user can just copy the message and send it to us
• Use some meaningful suffixes for the externalized string
  • Eclipse automatically starts every variable with the class name and then just appends numbers (CdmDataSourceViewPart_2)
  • if the string would be "Confirm deletion" call it _CONFIRM_DELETE or something similar. This improves the readability of the code a lot.
• Before starting the automatic externalization look for:
  • repeated strings and try to refactor them to constants in that class
  • unify string that are split to several string because of line breaks
  • use String.format() if the string contains variables