henrykuijpers
commented
3 years ago Imho, this issue should be renamed to "i18n strings used are not editable on instances with immutable /apps content". I don't think the proposed alternative is a good one: We need something that is carried from Sling (or maybe AEM, though I think it's a Sling-thing). This means that new functionality needs to be developed.
The core components should only reuse that functionality. Since that new functionality will not be available in all AEM versions these core components are being used, I would propose to create some kind of bridge, so that backwards compatibility with older AEM versions can be maintained.
There are actually a few locations in AEM where this issue was probably also encountered:
- One pattern that relates to this issue is already "hacked" in AEM: com.day.cq.dam.core.impl.I18nResourceBundleProvider defines an aggregated resource bundle provider, that is able to collect multiple ResourceBundleProvider implementations and then query all of them to request ResourceBundles from them.
- The JcrResourceBundleProvider is already doing quite a lot of the work that is needed and could be updated to have multiple implementations that can find / detect ResourceBundles that should be used for that specific context. I18NFilter (that is also found in the i18n impl bundle) is also having this CombinedResourceBundleProvider implementation and it also has a RequestLocaleResolver, that can be used to detect the locale that should be used.
- com.adobe.granite.i18n.impl.bundle.PseudoTranslations is used to provide translations for the "zz" language, but is having a service ranking that makes sure it will not be picked up when a service is requesting the "best ranked" ResourceBundleProvider. It is probably only used in one of the aggregated ResourceBundleProvider implementations.
A few issues we have had in our projects are similar (and all received either a hacky solution, or a custom solution):
Translations for a locale are instance-wide, which means it is impossible for a specific context to override translations. Our use-case was a website that was tailored more to the "youth"-audience, where we wanted to use more informal sentences. We are able to solve this with a locale-variant called "youth", but it would be better if we can somehow define a bunch of translations (just like we do now, with a JSON file) and mark them as "youth". Then mark the context (that specific website area) as making use of the youth-translations.
It is indeed, as you mentioned, very cumbersome to use the "Translator"-tool to manage dictionaries. I think this can be improved (and should again be part of the AEM-product, not a Core Components-movement). In some projects we have chosen, for the ease of the solution, to just do a deployment with updated labels instead. Our CI/CD is fast enough. Which honestly sounds crazy, given the fact that those labels should indeed be authorable.
Since translations are instance-wide, when trying to change i18n texts in components (as you have mentioned when creating this issue), it is impossible to differentiate the translations between the various tenants. I.e. one tenant would like to have a button that says "Read more" and the other wants "See the article" (just an example). A solution that we have seen used quite a lot is to make the translation key not "read.more.text", but "tenanta.read.more.text" and "tenantb.read.more.text". This again screams for an OOTB solution.
Having seen all this, it really sounds like another layer should be "wrapped" around the i18n functionality of Sling, so that these contexts can be used. It could also leverage backwards compatibility, in the sense that being unable to detect any context, the old (current) way of finding the resource bundles is still used.
It would also be nice to set up a meeting, to discuss in more detail. And maybe move this issue from here to the Sling JIRA, for example, to be able to work out a more detailed proposal, involve more engineers and really have it integrated in the core of the system, instead of AEM (or even the Core Components only) putting a patch on it. WDYT @kwin ?
kwin
stefanseifert
nhirrle
Feature Request
All text visible to end users of the web site should be manageable without code deployment.
As i18n dictionary translation is no longer supported at run time with AEM as a Cloud Service (https://experienceleague.adobe.com/docs/experience-manager-cloud-service/sites/sites-cloud-changes.html?lang=en#capabilities-not-available-at-runtime) the HTL option i18n should no longer be used with texts/labels visible in the end user's HTML (e.g. https://github.com/adobe/aem-core-wcm-components/blob/dbdd2c84ad728a3249689a8802a43a60f4b39fd6/content/src/content/jcr_root/apps/core/wcm/components/embed/v1/embed/embeddable/youtube/youtube.html#L22)
A runtime editable alternative would be to leverage Context-Aware configurations for all i18n purposes affecting the end user / publish instance.