[gatein-issues] [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war

[Minh Hoang TO (JIRA)]

     [ https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Minh Hoang TO updated GTNPORTAL-933:
------------------------------------

     Original Estimate: 6 hours
    Remaining Estimate: 6 hours
                Labels: sprint_36  (was: )


> Remove custom_*.* resource bundles from portal.war
> --------------------------------------------------
>
>                 Key: GTNPORTAL-933
>                 URL: https://jira.jboss.org/browse/GTNPORTAL-933
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.0-GA
>            Reporter: Patrice Lamarque
>            Priority: Minor
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> custom_* resource bundles are provided inside portal.war and contain a single entry (test=test).
> I guess that the intention of this file, like for Portal 2.5, is to provide an out-of the box extension point for custom i18n keys.
> for the record, in portal 2.x we used to override these bundle files at build time, effectively modifying these files in the portal.war.
> With GateIn's portal extension mechanism, I expect (maybe erroneously) to be able to add custom locales simply by putting some custom_*.properties files inside my own portal war (ex: csdemo.war!WEB-INF/classes/locale/custom.properties ). And rely on the classloader resolution provided by the extension mecanism.
> Strangely, it works well for all but english (en) locale. Actually, for english, the keys in my custom.properties are not resolved in my own gtmpl.
> For example, in my homepage's gtmpl, an expression such as <%=_ctx.appRes("UIHomePagePortlet.cs-community")%> will result in displaying the "cs-community"  which means the key was not resolved.
> I have several workarounds possible : 
> 1. copy-paste ALL custom*.* in my own portal war (ex: csdemo.war!WEB-INF/classes/locale/) then modify the bundles for the translations I have
> 2. define my own BaseResourceBundlePlugin for the ResourceBundleService component then xml conf change the "portal.resource.names" to add something like "locale.portal.csdemo" . Then provide csdemo.properties csdemo_en.properties and csdemo_fr.properties
> 3. remove portal.war!WEB-INF/classes/locale/custom*.* and only provide the bundles for the locales I want  (ex: custom.properties)
> 1. is not pratically doable (I can't guess how many languages are supported)
> 2. is the current workaround. but I'd like to avoid the duplicate custom.properties in custom_en.properties
> 3. is almost good except the need to modify portal.war in order to obtain the expected behaviour
> I'm not sure if this could qualify as a but, but none of the possible solutions is satifying in terms of extensibility.
> The quickfix for gatein would be simply to remove custom*.* from portal.war. By keeping the ResourceBundleService config as-is, it would make a very handy implicit extension point for customizations. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira