[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