Project

General

Profile

Actions

Internationalization / Localization

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

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

Updated by Katja Luther almost 2 years ago · 10 revisions