EDIT

# 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 <class_name>_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