You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Eric Norman (Jira)" <ji...@apache.org> on 2021/02/10 23:55:00 UTC

[jira] [Created] (SLING-10135) Add the ability to locate non JCR based ResourceBundle resources

Eric Norman created SLING-10135:
-----------------------------------

             Summary: Add the ability to locate non JCR based ResourceBundle resources
                 Key: SLING-10135
                 URL: https://issues.apache.org/jira/browse/SLING-10135
             Project: Sling
          Issue Type: Improvement
            Reporter: Eric Norman
            Assignee: Eric Norman
             Fix For: i18n 2.5.16


The sling.i18n ResourceBundle discovery mechanism appears to be utilizing a JCR centric xpath query that is used to locate the resources that contain the resource bundles strings.  Specifically: "//element(*,mix:language)[@jcr:language]"

This means that any resources provided by a non-JCR backed resource provider like the Sling-Bundle-Resources technique are not discovered and used.  The non-JCR provider implementations usually don't supply an "xpath" QueryLanguageProvider implementation that would understand the query that the sling.i18n bundle is running.   

 

What I propose is to supply a new osgi.extender technique in sling.i18n so that a bundle can declare certain paths that should be traversed to locate ResourceBundle resources.

For example, the bundle providing the resources could define something like this:

 
{code:java}
Require-Capability: osgi.extender;filter:="(&(osgi.extender=org.apache.sling.i18n.resourcebundle.locator.registrar)(version<=1.0.0)(!(version>=2.0.0)))"

Provide-Capability: org.apache.sling.i18n.resourcebundle.locator;paths="/libs/i18n/path123";depth=1{code}
 

The "Provide-Capability" instruction would define which (csv) resource paths to traverse and how deep to drill down (depth=1 by default) looking for candidates.

 

The sling.i18n bundle would supply the "org.apache.sling.i18n.resourcebundle.locator.registrar" capability that would track any bundles added/removed that contain the new "locator" paths.   Those new locator paths would be traversed to augment the set of potential language roots when a ResourceBundle is requested.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)