[jboss-as7-dev] AS 8 i18n Loggers and Message Bundles

Brian Stansberry brian.stansberry at redhat.com
Tue Feb 26 09:35:22 EST 2013


On 2/26/13 8:17 AM, Scott Marlow wrote:
> On 02/25/2013 08:49 PM, James R. Perkins wrote:
>> I've been thinking for a while now of creating a separate module for all
>> i18n loggers and message bundles. There are a few advantages to this;
>>
>>   1. To update translations you only need to build and deploy one module.
>>      This could possibly be used to limit the languages shipped too, e.g.
>>      a customer only wants English and Spanish no need to ship German,
>>      Chinese, Japanese and Brazilian Portuguese as well.
>>   2. Allow generic messages, e.g. "parameter_name is null", to be reused.
>>      I know support doesn't like the reuse, but it seems silly to have 50
>>      different methods that all the same thing that translators have to
>>      translate 50 times.
>>   3. Help stop messages id conflicts. I am going to use a new annotation
>>      to help with this too.
>>
>> The only real disadvantage I can think of is every module will have a
>> dependency on it. Also we would have be to strict about not letting
>> anything except loggers and message bundles be added to the module just
>> because it's shared across all modules.
>
> Different projects have their own messages, so it would be good to also
> allow for multiple bundles.
>
> Within the AS project, I'd rather not have one big message bundle that
> everyone is merging changes to.  IMO, it would be fine to group some of
> the bundles together (based on a logical grouping).
>

For sure we can't do a single big bundle. I don't think James has 
suggested that though. My guess is the "stop message id conflict" 
benefit is from having everything built at once; i.e. the conflict 
detection is scoped to a single maven module build.

TBH, I'm not thrilled with the idea. Not all messages associated with a 
given runtime will be in this module; only those for modules that were 
part of the AS build will be. Messages from add ons like Teiid, 
Switchyard, GateIn, etc will not be included. So I don't see much 
benefit in regards to how we distribute language support.

I don't want the .properties files that drive the management API 
metadata moved. An IDE can deal with moving the *Logger and *Messages 
files, but moving the .properties files means tedious manual work.

Note also that we are working on AS 8 but many of us will also be doing 
work porting stuff to EAP 6.x. The more the code bases diverge, the 
harder this task is going to be.

>>
>> Just wanted to open it up for discussion in case there is something I'm
>> missing before I open a JIRA for it.
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list