> While I'm in favor of having alternative solutions to the
> same problem available (one size does *not* always fit all),
> you might want to take a look at the...
Craig, thanks for the response and the info on struts.
When I did the search before writing the tags, I didn't find the message tag
inside struts as it was quite well hidden inside the struts package rather
than located in the taglibs project where I was looking. :-) The struts
tag also didn't appear in a google search, though a few others did but they
didn't provide what I was looking for.
Another person today also pointed me to the struts package, and I have had a
chance to look at it (though only briefly at the tld and code for the tag)
and if I hadn't already developed a larger set of tags, I might have tried
to get by with it.
But since we do have this built now, I would note a number of advantages to
my submission over the struts message tag.
1. arguments are more flexible as a subtag rather than as hardcoded
"arg1".."arg4" tags, because you can allow any number of args and because
your args can be non-String objects.
2. using a distinct localize tag allows you to have an obvious place at the
beginning of the page to set the content-type on the response based on the
user's Accept-Language header. (it wasn't clear how the message tag was
accomplishing this, though I'll take your word for it that it does) I also
find putting the resource name inside the tag a bit more obvious than
putting it in the servlet's deployment descriptor, though I did make the
deployment descriptor option available when specifying a resource bundle for
the whole webapp.
3. I didn't see any functionality to evaluate or not evaluate jsp based on
whether a tag was defined for a given locale.
Besides, I think i18n tags should be placed in the taglibs project rather
than struts, so that it's easier for people to adopt regardless of whether
or not they're using struts.
Although I agree that one size does not fit all, shouldn't most of the
generic tags that Struts provides be placed in the taglibs project, and just
have Struts depend on the taglib project? (I mean, Struts is presumably
going to have similar dependencies for stuff like log4j.) We should do this
if only to prevent other people in the future from re-inventing tags that
are provided by Struts just because they couldn't find them in the taglibs
project.
> If you're willing to license this code under the Apache
> license, and organize
> the source as described on the Taglibs web site, this
> proposal can be voted on.
Licensing the code under the Apache license is the goal, so I will look at
the guide and send it out to this group shortly (is a zip file appropriate
or should I tar/gzip?). It should be pretty close -- I've already done all
the development using Ant and there are only a few classfiles plus the stuff
necessary to generate a sample webapp.
Thanks,
Tim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 20, 2001 12:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: internationalization tags (would like to submit)
>
>
> Tim Dawson wrote:
>
> > I looked for some good internationalization tags on the web
> and haven't been
> > able to find any that would work for what I'm trying to do:
> namely autosense
> > the user's browser language, pick up the appropriate bundle
> (based on their
> > prefernece order) and allow automatic formatting using
> > java.text.MessageFormat.
> >
>
> While I'm in favor of having alternative solutions to the
> same problem available
> (one size does *not* always fit all), you might want to take
> a look at the
> internationalization support in the Struts framework project
> -- the framework
> includes auto-sense (based on the user's Accept-Language header), a
> <bean:message> tag that pulls message strings from a
> resources object and
> applies MessageFormat translations, and a whole bunch more.
> Plus you get a nice
> framework for the business logic of your app as well.
>
> http://jakarta.apache.org/struts
>
> >
> > So we wrote our own, and decided it was in our best
> interest to submit these
> > to the taglibs project, so that others wouldn't have to
> dupliate this effort
> > and so that (assuming these tags are adopted) we'd be using
> the standard
> > rather than something we have to continue to maintain
> ourselves. The whole
> > maintenance argument is what really won this over with
> mgmt. :-) At the
> > bottom of this message is a high level description of the library.
> >
> > Please advise on how I might submit this to the appropriate
> channels.
> >
>
> I think you just did :-)
>
> If you're willing to license this code under the Apache
> license, and organize
> the source as described on the Taglibs web site, this
> proposal can be voted on.
>
> You've got my +1.
>
> >
> > Thanks,
> >
> > Tim Dawson
> > Chief Architect
> > WAM!NET Inc.
> >
>
> Craig McClanahan
>
>
