Jon Stevens wrote:
> 
> on 6/2/01 9:20 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
> > Jon Stevens wrote:
> >>
> >> on 6/1/01 3:57 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
> >>
> >>> would it make sense to use the PullModel for localization?? (instead of
> >>> ResourceBundles??)
> >>
> >> The LocalizationService is already 99% of the way there. Just make it
> >> available in the context through a small PullTool wrapper and you are set.
> >
> > It looks like like you have to use ResourceBundles which forces you to
> > place
> > your localized messages in java sources files? Is this the case? If so
> > then
> > IMO the localization services needs some work.
> 
> Nope. That isn't the case.

Ok, I see that you can use Properties files too, but I think there are
problems with that too vis-a-vis encoding. This is dealt with now I
believe
in the ExtendedProperties class in the commons thank to Geir and Ilkka.
I assumed the requirement of java classes because this is what is
present
in Jyve and Jetspeed.

> 
> > I asked Craig to put the Struts MessageResources classes into the
> > commons
> > because I think that approach is better: one in which localized messages
> > can be taken from any source. This would allow, for example, localized
> > messages to be stored in XML files and these XML files could have a
> > known
> > DTD which would allow a non-programmer to work with a tool like XML Spy
> > to correctly produce a set of localized message resources.
> 
> Sounds just like another layer on top of ResourceBundles. Not a bad idea.

It's a replacement. Craig had this to say about it on the commons list:

  One meta-issue that I ran into with Struts (and the reason that I'm
not
  using ResourceBundle underneath) is that some app servers want your
  servlet context attributes (as well as your session attributes) to be
  Serializable.  This probably won't affect Turbine (which, I gather,
  prefers singletons using global statics for stuff like this), but will
  affect others who want to store message resources in the servlet
context.
 
What he says is true for now in the way we do localization, but maybe
in the future for some turbine application that uses heavy customization
a set of Resources may be stored in the session.

And there are the encoding issues too with properties files which make
them bad for any real localization requirements as Ilkka has remarked
on.

The localization service work perfectly, I would just rather use the
Resources
classes that will be developed in the commons rather than
ResourceBundles.

I think there will be a nice cross-pollenation of the Velocity resources
work
and the MessageResources work in Struts. I think this will make a very
powerful
set or resource classes that would be ideal for localization. With the
work
that has been done in Velocity and Struts we could, in very short order,
be
able to pull localized resources from file, XML, LDAP, and DB
repositories.

I definitely think it's something worth looking at.

> > I've never used ResourceBundles, but if it is the case that you have to
> > edit a java file and compile it to get localization to work than I don't
> > think that's even close to an ideal solution. Correct me if this is
> > not the case. I asked Craig to put his classes in the commons so that
> > we could eventually use them for the turbine localization service.
> 
> I'm correcting you.
> 
> -jon
> 
> --
> "Open source is not available to commercial companies."
>             -Steve Balmer, CEO Microsoft
> <http://www.suntimes.com/output/tech/cst-fin-micro01.html>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to