geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B.J. Reed" <bjre...@gmail.com>
Subject Re: using Resource Bundles for message strings
Date Tue, 26 Feb 2008 20:08:09 GMT
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


Mime
View raw message