[
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:
Allow to maintain basename hierarchies via OSGi configuration. In that case if
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:
Allow to maintain basename hierarchies via OSGi configuration. In that case if
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
# 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:
> Allow to maintain basename hierarchies via OSGi configuration. In that case
> if 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)
