2:49 a.m.
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.
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
3:17 p.m.
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).
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
3:35 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:31 p.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
--
James R. Perkins
JBoss by Red Hat
4:21 p.m.
On 02/26/2013 06: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).
Sorry, should have been more
clear. The idea would be to keep each
modules own logger/message bundle, but just have them all in a central
location. This doesn't include all the LocalDescription resource
bundles. Those should stay where they are as they don't require a build
to change any translations.
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
--
James R. Perkins
JBoss by Red Hat
4077
days inactive
4077
days old
4 comments
3 participants
participants (3)
-
Brian Stansberry -
James R. Perkins -
Scott Marlow