I will implement both suggestions for the message key naming convention:
Dan's idea to move the I/E/W to the end to make it stand out more and
Donald's use the groupid + abbreviated class name for the prefix. I'll
also use Dan's suggestion to remove the key from the message in the
.properties file and just prepend it onto the message in the code.
I had started off looking at using one property file per module, but ran
into some early trouble with getting that to work. (I was trying to run
before I was walking). Now that I'm this far, I just tried and it is
pretty easy to set up so that each module/plugin will have its own
properties file in its own .jar.
-- B.J.
Donald Woods wrote:
Wasn't clear, but are you proposing a properties files per module? If
not, then placing all of the possible strings in one common file will
become a nightmare to maintain and breaks from our plugin architecture.
As far as the message prefix, how about using an abbreviated maven
artifact groupid along with a abbreviated class name?
ie. framework/modules/geronimo-core would be GFMCRxxxx, where
G = Geronimo
F = Framework
M = Modules
CR = geronimo-core and CM = geronimo-common
and plugins/axis2/axis2-deployer would be GPCADxxxx, where
G = Geronimo
P = Plugin
C = Config and M = Module
AD = Axis2-deployer and AX = axis2
-Donald
B.J. Reed wrote:
I have written a patch to get Geronimo messages from a common set of
resource bundles. Included in the patch is the
GeronimoMessageBundle.java, GeronimoMessageBundleTest.java, and the
start of the geronimo-messages.properties file.
The patch should be unzipped into the
trunk/framework/modules/geronimo-common directory. Please take a
look and provide suggestions/comments/etc. I would like to really
begin moving messages into this common file - probably a module at a
time.
Questions/Answers
1) How do I use the new class in the Geronimo code? So that we don't
load the list of messages and keys multiple times, the
GeronimoMessageBundle is a singleton. Simply make a call to
GeronimoMessageBundle.getInstance() and then make the appropriate
getMessage call. For starters, I have made the message key the
message number that will show up as part of the message. Also
provided is a way to substitute parts of the message with
substitution strings.
2) Is there a numbering standard for the key? The standard that I
have started for the message key is as follows:
mmmmlxxxx
mmmm - 4 char module name abbreviation
l - one char level (E - error, W - warning, I - information
xxxx - 4 digit error number
Since I haven't gotten very far...if there is a better suggestion,
then it will be easier to change this sooner rather than later.
3) Tell me more about the string substitutions. To make messages
more flexible, placeholders can be put in the messages that look like
{0} {1} etc. An ArrayList can be passed in to the getMessage method
that will be used to replace the placeholders. This way, if a
language needs the replacements in a different order, the code will
not need to be changed.
4) How do I add a language? At this time, the
geronimo-messages.properties is included in the geronimo-common.jar.
The easiest thing that I have found is to copy the .properties file
to an apprpriate locale named file (geronimo-messages_de.properties
(for German) or geronimo-messages_de_CH.properties for German in
Switzerland). Re-create the geronimo-common.jar file. Right now,
the machine locale is used. After we have several translations, we
may want to add something to the Admin Console to allow an
administrator to set the locale.
5) Is there a way to have the .properties file(s) outside of the
jar? I'm sure there is, but I haven't stumbled across it yet.
That's actually where I've been banging my head the last few days.
6) I also envision that when we have all the messages in the common
file, that it will be very easy to have a troubleshooting section on
our website that gives more in depth knowledge about each message.
I will begin writing 2.2 documentation from the above questions.
This is just for message translation, so I believe that we'll need to
come up with other methods for the Admin Console and possibly the
Eclipse plugin if we want to have everything translatable.
-- B.J. Reed
