Java Reference
In-Depth Information
<param-value>
translations/text
</param-value>
</context-param>
<filter>
<filter-name>
StripesFilter
</filter-name>
<filter-class>
net.sourceforge.stripes.controller.StripesFilter
</filter-class>
<!-- other init params...-->
<init-param>
<param-name>
LocalizationBundleFactory.FieldNameBundle
</param-name>
<param-value>
translations/fieldLabels
</param-value>
</init-param>
<init-param>
<param-name>
LocalizationBundleFactory.ErrorMessageBundle
</param-name>
<param-value>
translations/errors
</param-value>
</init-param>
</filter>
The resource bundle files must now be under
translations
within the class
path. For example:
/WEB-INF/classes/translations/errors.properties
/WEB-INF/classes/translations/errors_fr.properties
/WEB-INF/classes/translations/fieldNames.properties
/WEB-INF/classes/translations/fieldNames_fr.properties
/WEB-INF/classes/translations/text.properties
/WEB-INF/classes/translations/text_fr.properties
This gives us the possibility of using separate resource bundles for each
type of text and putting the files in the directories of our choice. Of
course, we can also use these configuration parameters to change the
name of the resource bundle from
StripesResources
to something else,
but we can use the same name for all three and use just one resource
bundle for all localized text.
Implementing a One-Resource-Bundle-per-Action-Bean
Convention
By implementing our own subclass of
ResourceBundle
, we can implement
just about any localization strategy you want. Let's look at how that
would work if we decided to organize resource bundles by using one
bundle for each action bean. The convention might be that the base
name of the resource bundle is the same as the package and class
Search WWH ::
Custom Search