[
http://www.stripesframework.org/jira/browse/STS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11353#action_11353
]
Gérald Quintana commented on STS-552:
-------------------------------------
I thinks it's the same as the one I opened some times ago:
http://www.stripesframework.org/jira/browse/STS-458
> Stripes's LocalizationTag Strategy is Inconsistent with JSTL Tag Strategy for
> Locating and Resource Bundle
> ----------------------------------------------------------------------------------------------------------
>
> Key: STS-552
> URL: http://www.stripesframework.org/jira/browse/STS-552
> Project: Stripes
> Issue Type: Bug
> Reporter: Wendy Cameron
>
> The strategy for locating a resource bundle through the following class that
> is used through out the Stripes tags, may be flawed from jsp point of view.
> net.sourceforge.stripes.localizationDefaultLocalizationBundleFactory
> This factory for stripes always gets the bundle using one of the following
> two methods:
> ResourceBundle.getBundle(this.errorBundleName);
> ResourceBundle.getBundle(this.errorBundleName, locale);
> ResourceBundle.getBundle(this.fieldBundleName);
> ResourceBundle.getBundle(this.fieldBundleName, locale);
> However consider the following scenerio:
> {code}
> <fmt:bundle basename="com.orchestral.common.translation.client.Configuration">
> <stripes:select name="selectedToy">
> <stripes:options-collection
> collection="${actionBean.list}" value="id" label="name" />
> </stripes:select>
> </fmt:bundle>
> {code}
> I want the resource bundle to be used to be the one currently in scope, tags
> need to check for an tag ancestor that from fmt:bundle and use the bundle
> from there.
> If no ancestor fmt:bundle tag then the tag should use the bundle in the page
> context which should already have been resolved based upon the locale.
> However stripes circumvents this to provide an error bundle and a fieldName
> bundle. Which cannot be scoped, this is in contravention of the intention of
> the fmt:bundle tag, and the pattern laid out in most jstl tags.
> The stragey employed by most jstl tags is:
> {code:java}
> Tag t = findAncestorWithClass(this, BundleSupport.class);
> if (t != null) {
> // use resource bundle from parent <bundle> tag
> BundleSupport parent = (BundleSupport) t;
> locCtxt = parent.getLocalizationContext();
> prefix = parent.getPrefix();
> } else {
> locCtxt = BundleSupport.getLocalizationContext(pageContext);
> }
> {code}
> This is an issue for us because we want different bundle behavior for
> configuration text verses standard text. We have the scenario where we get
> back from the data base a label, that then needs to be translated, we allow
> users to set up english phrases and provide french and spanish translations
> for these, these translations are looked up using the label. So essentially
> we have some unique translation requirements, and we dont want to rewrite all
> the stipes tags providing two sets and creating confusion. However it is
> increasing looking more and more likely that we will have to rewrite all
> these tags to do something more sensible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
