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

[James R. Perkins]

On 02/26/2013 06:35 AM, Brian Stansberry wrote:
> 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.
That is true and really I just see at as an added benefit more than 
anything. The main benefit I see is for changing translations or fixing 
say spelling there's only one module that needs to be built and 
replaced. As it is now to fix a translation, you have to rebuild each 
module that needs to be fixed and replace them. Since the core modules 
have more logic it seems more fragile.
>
> 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.
Agreed there for sure. I do think it should only be the *Logger and 
*Messages in this module. All the LocalDescriptions should be left where 
they are and nothing with those should change.
>
> 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.
That is a good point. The idea came from some (GSS I think) people being 
concerned that to fix translations a build is needed. This is something 
that can wait until either late in the AS 8 build cycle, be delayed 
until AS.next or even vetoed all together.

Thinking a little further into this, it might not work anyway. If a 
subsystem has a custom exception or a parameter that is only in that 
subsystem, this wouldn't work at all. So maybe I just vetoed it myself :-)
>
>>> 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
>>
>

-- 
James R. Perkins
JBoss by Red Hat