The traditional method of displaying text is to hard code strings throughout the application. Whilst it is perfectly acceptable and quick to do this, it can be better to store the text in a properties file so it is all in one place. For example, where the code used to do this:
logger.error(“License has expired. Please renew and run again.”);
messages.properties file:
error.licenseExpired=License has expired. Please renew and run again.
Java file:
logger.error(messageSourceAccessor.getMessage(“error.licenseExpired”));
A separate messages.properties file has the advantage that it can processed by a spell checker. Hard coded text scattered through java source code cannot easily be parsed, and some programmers are notoriously poor spellers.
If internationalization is important, then a language-related property file is mandatory.
Tip: sort the messages alphabetically so duplicated text can be easily seen.
For applications that have little text and no international requirements, save the effort and avoid some runtime errors where messages are not found. You can't check at compile time if a referenced message is in the .properties file, so there is an added risk of a lookup failing when the program runs.
Tip: prefix all similar messages with the name of the application and then the same word that relates them. ie. Errors with “myapp.error....”, titles with “myapp.title....” etc. You won't regret consistency in naming:
# Browser window titles for pages
# Note! These are in alphabetical order - please keep that way
myapp.title.addComment=Add Comment
myapp.title.addItem=Add Item
myapp.title.addPicture=Add Picture
myapp.title.errorNonOwner=Error - Not Owner
myapp.title.unexpectedError=Unexpected Error
