Translator_area

Internationalization is a lot of work. Every bit of displayed text on screen and in logs should appear in the target language. If images/icons/pictures are culturally sensitive (e.g. red cross vs. red crescent) or contain text, they need to be translated too. Same goes for sound files with spoken text. More subtle things depend on language as well: decimal formatting, date formatting, naming and numbering conventions for people and items.

I18n ( = "i" + 18 letters + "n") starts by avoiding hard coded Strings during development time and using enums wherever possible, see http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html for a quick intro to enums in java. Reasons for avoiding Strings:

• users should be able to switch language in mid-simulation, in that case String-comparisons would leed to unforseeable results
• enums increase type safety during development --> SkillType, ScienceType, UnitType instead of String
• enums increase typo safety: its easy to misspell a string by mistake, can be difficult to find such typos, but a misspelled enum value will throw errors at compile time
• when strings are repeated in different source files they are not easily changed, while the displayable internationalized string associated with an enum value need only be changed once to cover all occurances of the enum

Translations from all source files are stored as key/value pairs in a single resource bundle, the english default is called messages.properties and accessed with Msg.getString(key). The key naming conventions are quite obvious when you look at the existing keys. Translated properties files are marked with the target locale, example: german translation in messages_de, brittish in messages_en_UK, etc.

Use an eclipse plugin that can handle multiple properties files for easier editing: http://eclipse-rbe.sourceforge.net/ (open source resource bundle editor).

The Eclipse Resource Bundle Editor is now at a new location on GitHub:
http://essiembre.github.io/eclipse-rbe/

To prepare an actual java file for translation, right click in the .java-file editor in eclipse -> source -> externalize strings -> configure -> set to the following settings:

ResourceBundle accessor class
folder: mars-sim-core/src/main/java
package: org.mars_sim.msp.core
class: Msg
pattern: getString(${key})

property files location
folder: mars-sim-core/src/main/resources
package: <empty>
file: messages.properties

If there is an error message "invalid package", you'll temporarily need to adjust the project settings. In the eclipse project (for example: mars-sim-core), go to the main/resources directory and right click -> Build Path -> Configure Inclusion / Exclusion Filters, in the Inclusion and Exclusion Patterns dialog, remove the "" exclusion pattern from the main/resources directory. Press the Finish button, the project will rebuild. Now try externalizing strings again with the above settings. Chose sensible key names instead of the default numbers. Take a look at the existing keys to get a feel for the naming conventions. When finished, re-add the "" exclusion pattern to the main/resources directory (as in the first two steps). This is due to maven, which expects non-java files like properties in a resources directory, but the built-in string externalization tool expects a valid java package destination.