You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hermod Opstvedt <he...@opstvedt.com> on 2006/03/29 22:46:50 UTC
Struts 1.3 and Internationalization
Hi
What's the status of the Struts 1.3 branch with respect to
internationalization? In the 1.2 branch this was a "won't touch" issue. What
I am thinking about is amongst other things the ability to use comma as
decimal separator. Or is still "English only, please".
Also, and I know this is the wrong forum, does anybody know if validator
know supports "ALL" the struts specified resource bundles (including I18N).
Hermod
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
SV: Struts 1.3 and Internationalization
Posted by Hermod Opstvedt <he...@opstvedt.com>.
Hi
I know that that was one of the issues, and I use converters for this. OK,
maybe I will set up a test with the latest Struts and see If it is still an
issue, and if so file r.f.e
Hermod
-----Opprinnelig melding-----
Fra: Hubert Rabago [mailto:hrabago@gmail.com]
Sendt: 29. mars 2006 23:40
Til: Struts Developers List; hermod@opstvedt.com
Emne: Re: Struts 1.3 and Internationalization
This is a BeanUtils issue. It comes into play after you get your
ActionForm inside your Action.execute(), and you call
BeanUtils.copyProperties() to copy your form field's String value onto
your business object's field.
You can look at BeanUtils' converters and registering locale-aware ones.
Of course, for me, I use FormDef to handle formatted inputs like these.
This is a user-list topic and should probably move there.
Hubert
On 3/29/06, Hermod Opstvedt <he...@opstvedt.com> wrote:
> Hi
>
> Not quite - If you have an html:text field, and enter a number with a
comma
> as decimal separator, and then try to access it in your action from the
form
> it will be null. Just go ahead and try it. As far as I remember, the "wont
> touch" reasoning had to do with some code deep down in Struts not being
able
> to access the locale from the request, and adding support would mean no
> backward compatibility. Correct me if I am wrong. It is quite some time
> since I ran into this (1.2.2 or something), and I solved it by hacking the
> html:text tag and some other places I do not remember.
>
> Hermod
>
>
> -----Opprinnelig melding-----
> Fra: Don Brown [mailto:mrdon@twdata.org]
> Sendt: 29. mars 2006 22:50
> Til: Struts Developers List
> Emne: Re: Struts 1.3 and Internationalization
>
> Struts, from the beginning has taken internationalization very seriously.
> You are probably referring to the validation
> of numeric values. This was a longstanding struts issue that has been
> resolved since Struts 1.2.7. There are new
> validators that will serve your interests.
>
> Don
>
> Hermod Opstvedt wrote:
> > Hi
> >
> > What's the status of the Struts 1.3 branch with respect to
> > internationalization? In the 1.2 branch this was a "won't touch" issue.
> What
> > I am thinking about is amongst other things the ability to use comma as
> > decimal separator. Or is still "English only, please".
> >
> > Also, and I know this is the wrong forum, does anybody know if validator
> > know supports "ALL" the struts specified resource bundles (including
> I18N).
> >
> > Hermod
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 and Internationalization
Posted by Hubert Rabago <hr...@gmail.com>.
This is a BeanUtils issue. It comes into play after you get your
ActionForm inside your Action.execute(), and you call
BeanUtils.copyProperties() to copy your form field's String value onto
your business object's field.
You can look at BeanUtils' converters and registering locale-aware ones.
Of course, for me, I use FormDef to handle formatted inputs like these.
This is a user-list topic and should probably move there.
Hubert
On 3/29/06, Hermod Opstvedt <he...@opstvedt.com> wrote:
> Hi
>
> Not quite - If you have an html:text field, and enter a number with a comma
> as decimal separator, and then try to access it in your action from the form
> it will be null. Just go ahead and try it. As far as I remember, the "wont
> touch" reasoning had to do with some code deep down in Struts not being able
> to access the locale from the request, and adding support would mean no
> backward compatibility. Correct me if I am wrong. It is quite some time
> since I ran into this (1.2.2 or something), and I solved it by hacking the
> html:text tag and some other places I do not remember.
>
> Hermod
>
>
> -----Opprinnelig melding-----
> Fra: Don Brown [mailto:mrdon@twdata.org]
> Sendt: 29. mars 2006 22:50
> Til: Struts Developers List
> Emne: Re: Struts 1.3 and Internationalization
>
> Struts, from the beginning has taken internationalization very seriously.
> You are probably referring to the validation
> of numeric values. This was a longstanding struts issue that has been
> resolved since Struts 1.2.7. There are new
> validators that will serve your interests.
>
> Don
>
> Hermod Opstvedt wrote:
> > Hi
> >
> > What's the status of the Struts 1.3 branch with respect to
> > internationalization? In the 1.2 branch this was a "won't touch" issue.
> What
> > I am thinking about is amongst other things the ability to use comma as
> > decimal separator. Or is still "English only, please".
> >
> > Also, and I know this is the wrong forum, does anybody know if validator
> > know supports "ALL" the struts specified resource bundles (including
> I18N).
> >
> > Hermod
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SV: Struts 1.3 and Internationalization
Posted by Martin Cooper <ma...@apache.org>.
On 3/29/06, Hubert Rabago <hr...@gmail.com> wrote:
>
> On 3/29/06, Joe Germuska <Jo...@germuska.com> wrote:
> > I started to believe this, but now I disagree.
> >
> > It is only solvable with the current code if your application runs in
> > one Locale. Struts does not provide a way to register instantaneous
> > conversion parameters (like the current Locale) -- registering a
> > converter with ConvertUtils has application-wide (actually JVM-wide)
> > scope, and would not be correct in the case that the same application
> > was handling floats that would have different decimal separators (to
> > use Hermod's example).
> >
> > The active locale must be passed in to RequestUtils.populate(...),
> > and in this case, compatibility seems like a lame excuse.
> >
> > Here's where the action happens:
> >
> > entrance to RequestUtils.populate(...):
> >
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341
> >
> > The actual place where ActionForm properties are set:
> >
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451
> >
> > I see no reason why all this code couldn't be pushed to a method
> > which takes a locale as an argument, and this method amended to call
> > that one with the system default locale.
>
> I would agree if we weren't recommending that people use Strings in
> the ActionForm [1].
Exactly. The "best practice" ever since Struts was created has been to use
strings for form fields, specifically so that you have the exact original
value to present to the user in an error situation. Once you bring other
data types into the picture, you can no longer guarantee that you can
redisplay exactly what the user (mis-)typed.
--
Martin Cooper
What I'm saying is that your form should have String values and
> RequestUtils.populate() will populate it whatever your user typed in,
> and then in your Action you can use BeanUtils or FormDef to properly
> parse that into your business object typed field.
>
> You can see this in action in the locale.war demo of FormDef [2].
>
> > Joe
>
> Hubert
>
> [1] "... properties used with the html:text tag should still be String
> properties."
> http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> [2] http://www.rabago.net/struts/formdef/downloads.htm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: SV: Struts 1.3 and Internationalization
Posted by Hubert Rabago <hr...@gmail.com>.
On 3/29/06, Joe Germuska <Jo...@germuska.com> wrote:
> I started to believe this, but now I disagree.
>
> It is only solvable with the current code if your application runs in
> one Locale. Struts does not provide a way to register instantaneous
> conversion parameters (like the current Locale) -- registering a
> converter with ConvertUtils has application-wide (actually JVM-wide)
> scope, and would not be correct in the case that the same application
> was handling floats that would have different decimal separators (to
> use Hermod's example).
>
> The active locale must be passed in to RequestUtils.populate(...),
> and in this case, compatibility seems like a lame excuse.
>
> Here's where the action happens:
>
> entrance to RequestUtils.populate(...):
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341
>
> The actual place where ActionForm properties are set:
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451
>
> I see no reason why all this code couldn't be pushed to a method
> which takes a locale as an argument, and this method amended to call
> that one with the system default locale.
I would agree if we weren't recommending that people use Strings in
the ActionForm [1].
What I'm saying is that your form should have String values and
RequestUtils.populate() will populate it whatever your user typed in,
and then in your Action you can use BeanUtils or FormDef to properly
parse that into your business object typed field.
You can see this in action in the locale.war demo of FormDef [2].
> Joe
Hubert
[1] "... properties used with the html:text tag should still be String
properties." http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
[2] http://www.rabago.net/struts/formdef/downloads.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SV: SV: Struts 1.3 and Internationalization
Posted by Paul Benedict <pa...@yahoo.com>.
I thought Commons Validator contained a locale attribute
so that certain validations could apply accordingly.
Wouldn't this help him out?
--- Hermod Opstvedt <he...@opstvedt.com> wrote:
> Hi
>
> And now bells start ringing - It is starting to come back to me now, and
> RequestUtils.populate was one of the places I hacked to solve my specific
> problem back then (this is 2 years ago). I know that this was raised as an
> issue not only by me, but also by others back then. I'll see if I can dig up
> something from the archives
>
> Hermod
>
>
> -----Opprinnelig melding-----
> Fra: Joe Germuska [mailto:Joe@Germuska.com]
> Sendt: 30. mars 2006 00:17
> Til: Hermod Opstvedt; 'Struts Developers List'
> Emne: Re: SV: Struts 1.3 and Internationalization
>
> At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
> >This is a BeanUtils issue. ...
> >
> >This is a user-list topic and should probably move there.
>
> I started to believe this, but now I disagree.
>
> It is only solvable with the current code if your application runs in
> one Locale. Struts does not provide a way to register instantaneous
> conversion parameters (like the current Locale) -- registering a
> converter with ConvertUtils has application-wide (actually JVM-wide)
> scope, and would not be correct in the case that the same application
> was handling floats that would have different decimal separators (to
> use Hermod's example).
>
> The active locale must be passed in to RequestUtils.populate(...),
> and in this case, compatibility seems like a lame excuse.
>
> Here's where the action happens:
>
> entrance to RequestUtils.populate(...):
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
> ils.html#341
>
> The actual place where ActionForm properties are set:
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
> ils.html#451
>
> I see no reason why all this code couldn't be pushed to a method
> which takes a locale as an argument, and this method amended to call
> that one with the system default locale.
>
> Then, the few places where RequestUtils.populate is called could be
> refactored to pass in the session locale if it is available, then
> line 451 cited above could be changed to make a new instance of
> LocaleBeanUtilsBean with the current locale. (I've never used the
> localized bean utils code, but I think this is basically how it is to
> be done...)
>
> and that method is only called in three places, one of which passes
> along from an alternate signature in RequestUtils. The other two
> places are in the base RequestProcessor and the PopulateActionForm
> command (which essentially obsoletes the RequestProcessor.)
>
> One possible compatibility issue would be with how instances of
> LocaleBeanUtilsBean interact with statically registered converters --
> if people have existing apps that register converters statically, I
> don't think that those would be picked up by a newly instantiated
> LocaleBeanUtilsBean -- which would bring up the deeper issue of
> registering converters for different situations, which may well be
> where things got mired down before? I don't recall earlier
> discussion of the issue.
>
> If nothing else, Hermod, could you check issues.apache.org for any
> possibly existing ticket, and if you don't find one, create one? It
> would be better to have this discussion in the bug tracker so that it
> is archived in conjunction with the actual enhancement request.
>
> Joe
>
>
>
> At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
> >Hi
> >
> >Not quite - If you have an html:text field, and enter a number with a comma
> >as decimal separator, and then try to access it in your action from the
> form
> >it will be null. Just go ahead and try it. As far as I remember, the "wont
> >touch" reasoning had to do with some code deep down in Struts not being
> able
> >to access the locale from the request, and adding support would mean no
> >backward compatibility. Correct me if I am wrong. It is quite some time
> >since I ran into this (1.2.2 or something), and I solved it by hacking the
> >html:text tag and some other places I do not remember.
>
>
> --
> Joe Germuska
> Joe@Germuska.com * http://blog.germuska.com
>
> "You really can't burn anything out by trying something new, and
> even if you can burn it out, it can be fixed. Try something new."
> -- Robert Moog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
SV: SV: Struts 1.3 and Internationalization
Posted by Hermod Opstvedt <he...@opstvedt.com>.
Hi
And now bells start ringing - It is starting to come back to me now, and
RequestUtils.populate was one of the places I hacked to solve my specific
problem back then (this is 2 years ago). I know that this was raised as an
issue not only by me, but also by others back then. I'll see if I can dig up
something from the archives
Hermod
-----Opprinnelig melding-----
Fra: Joe Germuska [mailto:Joe@Germuska.com]
Sendt: 30. mars 2006 00:17
Til: Hermod Opstvedt; 'Struts Developers List'
Emne: Re: SV: Struts 1.3 and Internationalization
At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
>This is a BeanUtils issue. ...
>
>This is a user-list topic and should probably move there.
I started to believe this, but now I disagree.
It is only solvable with the current code if your application runs in
one Locale. Struts does not provide a way to register instantaneous
conversion parameters (like the current Locale) -- registering a
converter with ConvertUtils has application-wide (actually JVM-wide)
scope, and would not be correct in the case that the same application
was handling floats that would have different decimal separators (to
use Hermod's example).
The active locale must be passed in to RequestUtils.populate(...),
and in this case, compatibility seems like a lame excuse.
Here's where the action happens:
entrance to RequestUtils.populate(...):
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
ils.html#341
The actual place where ActionForm properties are set:
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
ils.html#451
I see no reason why all this code couldn't be pushed to a method
which takes a locale as an argument, and this method amended to call
that one with the system default locale.
Then, the few places where RequestUtils.populate is called could be
refactored to pass in the session locale if it is available, then
line 451 cited above could be changed to make a new instance of
LocaleBeanUtilsBean with the current locale. (I've never used the
localized bean utils code, but I think this is basically how it is to
be done...)
and that method is only called in three places, one of which passes
along from an alternate signature in RequestUtils. The other two
places are in the base RequestProcessor and the PopulateActionForm
command (which essentially obsoletes the RequestProcessor.)
One possible compatibility issue would be with how instances of
LocaleBeanUtilsBean interact with statically registered converters --
if people have existing apps that register converters statically, I
don't think that those would be picked up by a newly instantiated
LocaleBeanUtilsBean -- which would bring up the deeper issue of
registering converters for different situations, which may well be
where things got mired down before? I don't recall earlier
discussion of the issue.
If nothing else, Hermod, could you check issues.apache.org for any
possibly existing ticket, and if you don't find one, create one? It
would be better to have this discussion in the bug tracker so that it
is archived in conjunction with the actual enhancement request.
Joe
At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
>Hi
>
>Not quite - If you have an html:text field, and enter a number with a comma
>as decimal separator, and then try to access it in your action from the
form
>it will be null. Just go ahead and try it. As far as I remember, the "wont
>touch" reasoning had to do with some code deep down in Struts not being
able
>to access the locale from the request, and adding support would mean no
>backward compatibility. Correct me if I am wrong. It is quite some time
>since I ran into this (1.2.2 or something), and I solved it by hacking the
>html:text tag and some other places I do not remember.
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: SV: Struts 1.3 and Internationalization
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
>This is a BeanUtils issue. ...
>
>This is a user-list topic and should probably move there.
I started to believe this, but now I disagree.
It is only solvable with the current code if your application runs in
one Locale. Struts does not provide a way to register instantaneous
conversion parameters (like the current Locale) -- registering a
converter with ConvertUtils has application-wide (actually JVM-wide)
scope, and would not be correct in the case that the same application
was handling floats that would have different decimal separators (to
use Hermod's example).
The active locale must be passed in to RequestUtils.populate(...),
and in this case, compatibility seems like a lame excuse.
Here's where the action happens:
entrance to RequestUtils.populate(...):
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341
The actual place where ActionForm properties are set:
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451
I see no reason why all this code couldn't be pushed to a method
which takes a locale as an argument, and this method amended to call
that one with the system default locale.
Then, the few places where RequestUtils.populate is called could be
refactored to pass in the session locale if it is available, then
line 451 cited above could be changed to make a new instance of
LocaleBeanUtilsBean with the current locale. (I've never used the
localized bean utils code, but I think this is basically how it is to
be done...)
and that method is only called in three places, one of which passes
along from an alternate signature in RequestUtils. The other two
places are in the base RequestProcessor and the PopulateActionForm
command (which essentially obsoletes the RequestProcessor.)
One possible compatibility issue would be with how instances of
LocaleBeanUtilsBean interact with statically registered converters --
if people have existing apps that register converters statically, I
don't think that those would be picked up by a newly instantiated
LocaleBeanUtilsBean -- which would bring up the deeper issue of
registering converters for different situations, which may well be
where things got mired down before? I don't recall earlier
discussion of the issue.
If nothing else, Hermod, could you check issues.apache.org for any
possibly existing ticket, and if you don't find one, create one? It
would be better to have this discussion in the bug tracker so that it
is archived in conjunction with the actual enhancement request.
Joe
At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
>Hi
>
>Not quite - If you have an html:text field, and enter a number with a comma
>as decimal separator, and then try to access it in your action from the form
>it will be null. Just go ahead and try it. As far as I remember, the "wont
>touch" reasoning had to do with some code deep down in Struts not being able
>to access the locale from the request, and adding support would mean no
>backward compatibility. Correct me if I am wrong. It is quite some time
>since I ran into this (1.2.2 or something), and I solved it by hacking the
>html:text tag and some other places I do not remember.
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
SV: Struts 1.3 and Internationalization
Posted by Hermod Opstvedt <he...@opstvedt.com>.
Hi
Not quite - If you have an html:text field, and enter a number with a comma
as decimal separator, and then try to access it in your action from the form
it will be null. Just go ahead and try it. As far as I remember, the "wont
touch" reasoning had to do with some code deep down in Struts not being able
to access the locale from the request, and adding support would mean no
backward compatibility. Correct me if I am wrong. It is quite some time
since I ran into this (1.2.2 or something), and I solved it by hacking the
html:text tag and some other places I do not remember.
Hermod
-----Opprinnelig melding-----
Fra: Don Brown [mailto:mrdon@twdata.org]
Sendt: 29. mars 2006 22:50
Til: Struts Developers List
Emne: Re: Struts 1.3 and Internationalization
Struts, from the beginning has taken internationalization very seriously.
You are probably referring to the validation
of numeric values. This was a longstanding struts issue that has been
resolved since Struts 1.2.7. There are new
validators that will serve your interests.
Don
Hermod Opstvedt wrote:
> Hi
>
> What's the status of the Struts 1.3 branch with respect to
> internationalization? In the 1.2 branch this was a "won't touch" issue.
What
> I am thinking about is amongst other things the ability to use comma as
> decimal separator. Or is still "English only, please".
>
> Also, and I know this is the wrong forum, does anybody know if validator
> know supports "ALL" the struts specified resource bundles (including
I18N).
>
> Hermod
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 and Internationalization
Posted by Don Brown <mr...@twdata.org>.
Struts, from the beginning has taken internationalization very seriously. You are probably referring to the validation
of numeric values. This was a longstanding struts issue that has been resolved since Struts 1.2.7. There are new
validators that will serve your interests.
Don
Hermod Opstvedt wrote:
> Hi
>
> What's the status of the Struts 1.3 branch with respect to
> internationalization? In the 1.2 branch this was a "won't touch" issue. What
> I am thinking about is amongst other things the ability to use comma as
> decimal separator. Or is still "English only, please".
>
> Also, and I know this is the wrong forum, does anybody know if validator
> know supports "ALL" the struts specified resource bundles (including I18N).
>
> Hermod
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org