Java Reference
In-Depth Information
name="StripesResources"/>
in the layout JSP after the
taglib
import, and
the text will come from
StripesResources
. For example:
<%@include file="/WEB-INF/jsp/common/taglibs.jsp"%>
<fmt:setBundle basename="StripesResources"/>
<s:layout-definition>
<!
DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<!-- ... -->
<s:layout-component name="menu">
<fmt:message key="layout.welcome"/>
</s:layout-component>
<!-- ... -->
</html>
</s:layout-definition>
Those keys will now be found in the
StripesResources
bundle:
layout.welcome=Welcome to Stripes Webmail
layout.welcome=Bienvenue au WebCourriel Stripes
You can also use the
StripesResources
bundle in this manner for a JSP
that's being used by more than one action bean. By doing this, you
avoid having to duplicate the keys used by that JSP in each action
bean's corresponding .
properties
file.
Très Bien!
Supporting multiple languages in an application doesn't have to be a
complicated task. Using the Stripes key lookup patterns and resource
bundles (either the defaults or your own), you can make your appli-
cations available in multiple languages without a Herculean effort. As
your application grows, you can keep your translated text organized,
whether it's in one or more resource bundles. You can also implement
your own resource bundle strategy—the choice is yours.
Regardless of how we organize your resource bundles, all localized text
is isolated from the rest of the code. We still have one JSP per page,
no matter in how many languages we translate the application. Adding
another language at a later stage is not a problem either—we need only
to add the locale code to the list of supported languages and translate
the resource bundles.
Search WWH ::
Custom Search