[
https://issues.apache.org/jira/browse/SLING-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-12788:
------------------------------------
Description:
Currently the
[basename|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names]
does not allow to define any fallbacks to other basenames. However the
inheritance given by just the [resource resolver search path and
locale|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-hierarchies]
are not enough.
Example use case is a multi-tenant server where one app uses "keyA" with
message "A" while the other app uses "keyA" with message "a". Although
basenames can be used to isolate those against each other it is often
reasonable to have a default message which is common across all tenants (but
can be easily overwritten).
h2. Proposal 1:
Allow to maintain basename hierarchies via OSGi configuration.
Pro: Supports basenames with comma (Fully-backwards compatible)
Con: Requires additional configuration to maintain.
h2. Proposal 2:
Allow to give a comma-separated list of basenames to
https://github.com/apache/sling-org-apache-sling-api/blob/009ebd60999433438ab81a8edd4168a86cfb4ca8/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java#L285
that should be used as fallbacks.
Pro: Allows to define a hierarchy per lookup.
Con: Does no longer allow basenames containing a comma
h2. Proposal 3:
Add another overloaded method {{getResourceBundle}} to
{{SlingHttpServletRequest}} which allows to give multiple basenames.
Pro: Allows to define a hierarchy per lookup.
Con: Not leveraged by default by higher level API as HTL i18n option
h2. Lookup order
In case the key could not be found with the given {{basename}} for the specific
locale it would first look it up in the parent basenames before considering
super locales. That way hierarchies have three dimensions which are considered
in the following order
# super basenames
# dictionary paths (resource resolver search paths)
# locales
was:
Currently the
[basename|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names]
does not allow to define any fallbacks to other basenames. However the
inheritance given by just the [resource resolver search path and
locale|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-hierarchies]
are not enough.
Example use case is a multi-tenant server where one app uses "keyA" with
message "A" while the other app uses "keyA" with message "a". Although
basenames can be used to isolate those against each other it is often
reasonable to have a default message which is common across all tenants (but
can be easily overwritten).
h2. Proposal 1:
Allow to maintain basename hierarchies via OSGi configuration.
Pro: Supports basenames with comma (Fully-backwards compatible)
Con: Requires additional configuration to maintain.
h2. Proposal 2:
Allow to give a comma-separated list of basenames to
https://github.com/apache/sling-org-apache-sling-api/blob/009ebd60999433438ab81a8edd4168a86cfb4ca8/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java#L285
that should be used as fallbacks.
Pro: Allows to define a hierarchy per lookup.
Con: Does no longer allow basenames containing a comma
h2. Proposal 3:
Add another overloaded method to SlingHttpServletRequest which allows to give
multiple basenames.
Pro: Allows to define a hierarchy per lookup.
Con: Not leveraged by default by higher level API as HTL i18n option
h2. Lookup order
In case the key could not be found with the given {{basename}} for the specific
locale it would first look it up in the parent basenames before considering
super locales. That way hierarchies have three dimensions which are considered
in the following order
# super basenames
# dictionary paths (resource resolver search paths)
# locales
> Support configurable basename hierarchies
> -----------------------------------------
>
> Key: SLING-12788
> URL: https://issues.apache.org/jira/browse/SLING-12788
> Project: Sling
> Issue Type: Improvement
> Components: i18n
> Affects Versions: I18N Support 2.6.6
> Reporter: Konrad Windszus
> Priority: Major
>
> Currently the
> [basename|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-with-base-names]
> does not allow to define any fallbacks to other basenames. However the
> inheritance given by just the [resource resolver search path and
> locale|https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#resourcebundle-hierarchies]
> are not enough.
> Example use case is a multi-tenant server where one app uses "keyA" with
> message "A" while the other app uses "keyA" with message "a". Although
> basenames can be used to isolate those against each other it is often
> reasonable to have a default message which is common across all tenants (but
> can be easily overwritten).
> h2. Proposal 1:
> Allow to maintain basename hierarchies via OSGi configuration.
> Pro: Supports basenames with comma (Fully-backwards compatible)
> Con: Requires additional configuration to maintain.
> h2. Proposal 2:
> Allow to give a comma-separated list of basenames to
> https://github.com/apache/sling-org-apache-sling-api/blob/009ebd60999433438ab81a8edd4168a86cfb4ca8/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java#L285
> that should be used as fallbacks.
> Pro: Allows to define a hierarchy per lookup.
> Con: Does no longer allow basenames containing a comma
> h2. Proposal 3:
> Add another overloaded method {{getResourceBundle}} to
> {{SlingHttpServletRequest}} which allows to give multiple basenames.
> Pro: Allows to define a hierarchy per lookup.
> Con: Not leveraged by default by higher level API as HTL i18n option
> h2. Lookup order
> In case the key could not be found with the given {{basename}} for the
> specific locale it would first look it up in the parent basenames before
> considering super locales. That way hierarchies have three dimensions which
> are considered in the following order
> # super basenames
> # dictionary paths (resource resolver search paths)
> # locales
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
