I18nTaxeditor » History » Revision 9
Revision 8 (Patrick Plitzner, 02/23/2017 05:35 PM) → Revision 9/10 (Patrick Plitzner, 08/09/2017 02:51 PM)
# 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 adapt the path** 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