You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Keith Fetterman <kf...@go2marine.com> on 2006/02/09 05:31:43 UTC
Struts internationalization best practices
We could use some help from people that have experience
internationalizing their Struts applications. I'd like to find out what
the best practice is for handling these three cases:
1. One or more large paragraphs of text.
2. Text that has markup language or HTML tags mixed in, for example
image tags, links or anchor tags, etc.
3. Text that has Struts or JSTL tags mixed in.
What has people found to be the easiest to maintain?
Is the markup language stored in the message resources file?
Or, is the text broken up into chunks, which is stored in the message
resources file and the markup language stays in the JSP files?
If the text is broken into chunks, what happens when the sentence
structure changes for a different language?
If a large paragraph of text is stored in messages resources file, is
there a way to wrap it so it is easier to maintain?
Are there any other pitfalls we need to look for?
I have researched this issue all day on the Web, and have found no
information that addresses these issues. I have also looked at several
books and they don't address them either.
Please share your experiences and practices. We greatly appreciated it.
Thanks,
Keith
--
-----------------------------------------------------------------
Keith Fetterman 206-780-5670
Mariner Supply, Inc. kfetterman@go2marine.com
http://www.go2marine.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts internationalization best practices
Posted by Torgeir Veimo <to...@pobox.com>.
On Wed, 2006-02-08 at 20:31 -0800, Keith Fetterman wrote:
>
> I have researched this issue all day on the Web, and have found no
> information that addresses these issues. I have also looked at
> several
> books and they don't address them either.
>
> Please share your experiences and practices. We greatly appreciated
> it.
Why don't you store the parapgraph long text as a velocity template?
They can contain constructs similar to JSP tags, but don't need to be
inside a JSP file, so you have more freedom to construct the pipeline
for the text to reach the page.
--
Torgeir Veimo <to...@pobox.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts internationalization best practices
Posted by Keith Fetterman <kf...@go2marine.com>.
Laurie,
Thanks a bunch for taking the time to respond. This helps us a lot. We
really appreciate it.
Keith
Laurie Harper wrote:
> Keith Fetterman wrote:
>> We could use some help from people that have experience
>> internationalizing their Struts applications. I'd like to find out
>> what the best practice is for handling these three cases:
>>
>> 1. One or more large paragraphs of text.
>
> Depending on how large the paragraphs are and how they need to be
> managed, you may want to look at storing them in a database or other
> alternative format, but storing them in your application properties will
> work perfectly well too.
>
>> 2. Text that has markup language or HTML tags mixed in, for example
>> image tags, links or anchor tags, etc.
>
> In general you should try to avoid that ;-) Some people feel more
> strongly than others on this issue, and it certainly can be useful
> sometimes to include markup in resource bundle text. But I would
> recommend that, if you have more than occasional need to do that, you
> localize your JSPs for those cases in addition to using resource bundles.
>
> The main mechanism for doing that in Struts is Tiles. You can set up a
> set of Tiles definitions, then modify them on a per-locale basis. I'd
> still recommend you externalize as much as you can into resource
> bundles, though, in order to minimize the need for repetition in
> localized JSPs.
>
>> 3. Text that has Struts or JSTL tags mixed in.
>
> In that case, you should *really* try to avoid doing it by structuring
> your pages appropriately. You can't use resource bundles for this, since
> text pulled from a resource bundle (with, for example, bean:message)
> isn't parsed for JSP custom tags. To handle this, you would have to fall
> back on using localized JSPs via Tiles or something similar.
>
>> What has people found to be the easiest to maintain?
>
> One JSP, with all localizable content held in, or referenced by,
> resource bundle strings. One tip is you can have a resource string
> that's a URL path pointing to, say, a localisable image or page
> fragment. That might be simpler than adding template/JSP
> internationalization via Tiles, etc.
>
>> Is the markup language stored in the message resources file?
>
> Not if I can help it, and not in large chunks.
>
>> Or, is the text broken up into chunks, which is stored in the message
>> resources file and the markup language stays in the JSP files?
>>
>> If the text is broken into chunks, what happens when the sentence
>> structure changes for a different language?
>
> Ugh, no, don't do that, ever :-) For small amounts of inline markup, put
> it in the resource bundle. If things get too messy, you can always have
> one resource bundle for plain text, and another for marked up text. Or
> break those parts of the page out into localized tiles or something.
>
>> If a large paragraph of text is stored in messages resources file, is
>> there a way to wrap it so it is easier to maintain?
>
> Yep, just use standard .properties file formatting conventions.
>
>> Are there any other pitfalls we need to look for?
>
> Many ;-) I highly recommend Java Internationalization (Andrew Deitsch &
> David Czarnecki; O'Reilly) to get a good foundation in the basics of I18N.
>
>> I have researched this issue all day on the Web, and have found no
>> information that addresses these issues. I have also looked at
>> several books and they don't address them either.
>
> See above. Most Struts books also include information on the
> Struts-specific features or localization.
>
> L.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts internationalization best practices
Posted by Laurie Harper <la...@holoweb.net>.
Keith Fetterman wrote:
> We could use some help from people that have experience
> internationalizing their Struts applications. I'd like to find out what
> the best practice is for handling these three cases:
>
> 1. One or more large paragraphs of text.
Depending on how large the paragraphs are and how they need to be
managed, you may want to look at storing them in a database or other
alternative format, but storing them in your application properties will
work perfectly well too.
> 2. Text that has markup language or HTML tags mixed in, for example
> image tags, links or anchor tags, etc.
In general you should try to avoid that ;-) Some people feel more
strongly than others on this issue, and it certainly can be useful
sometimes to include markup in resource bundle text. But I would
recommend that, if you have more than occasional need to do that, you
localize your JSPs for those cases in addition to using resource bundles.
The main mechanism for doing that in Struts is Tiles. You can set up a
set of Tiles definitions, then modify them on a per-locale basis. I'd
still recommend you externalize as much as you can into resource
bundles, though, in order to minimize the need for repetition in
localized JSPs.
> 3. Text that has Struts or JSTL tags mixed in.
In that case, you should *really* try to avoid doing it by structuring
your pages appropriately. You can't use resource bundles for this, since
text pulled from a resource bundle (with, for example, bean:message)
isn't parsed for JSP custom tags. To handle this, you would have to fall
back on using localized JSPs via Tiles or something similar.
> What has people found to be the easiest to maintain?
One JSP, with all localizable content held in, or referenced by,
resource bundle strings. One tip is you can have a resource string
that's a URL path pointing to, say, a localisable image or page
fragment. That might be simpler than adding template/JSP
internationalization via Tiles, etc.
> Is the markup language stored in the message resources file?
Not if I can help it, and not in large chunks.
> Or, is the text broken up into chunks, which is stored in the message
> resources file and the markup language stays in the JSP files?
>
> If the text is broken into chunks, what happens when the sentence
> structure changes for a different language?
Ugh, no, don't do that, ever :-) For small amounts of inline markup, put
it in the resource bundle. If things get too messy, you can always have
one resource bundle for plain text, and another for marked up text. Or
break those parts of the page out into localized tiles or something.
> If a large paragraph of text is stored in messages resources file, is
> there a way to wrap it so it is easier to maintain?
Yep, just use standard .properties file formatting conventions.
> Are there any other pitfalls we need to look for?
Many ;-) I highly recommend Java Internationalization (Andrew Deitsch &
David Czarnecki; O'Reilly) to get a good foundation in the basics of I18N.
> I have researched this issue all day on the Web, and have found no
> information that addresses these issues. I have also looked at several
> books and they don't address them either.
See above. Most Struts books also include information on the
Struts-specific features or localization.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org