We manage our company's website in AEM, and there are two teams on which I'd like to focus here: content managers and developers. Developers create new templates and components, and content managers use both developed and out-of-the-box components ti create and update pages.
Both teams use localization strings via AEM Translator: content managers manage them in the production instance, developers on dev and test ones. To minimize issues in newly developed code, developers would like a convenient way to have up-to-date translations from production at their local instances.
So far we have tried two approaches:
- keeping content managers' and developers' translations in separate dictionaries, the second one is not allowed to edit in production translator. Drawback: need a code deployment every time there is a change needed in the developers' dictionary
- building a package with production translations when a developer needs it, so he can install it locally. Drawback: as most of the team does not have access to Package Manager in production, the resulting solution is rather complicated technically (I can describe it if needed)
Can you see other solutions or improvment points in the ones above?
My first question is: what do you translate and where/how are these translations used?
For me content managers use the AEM authoring UI to create and manage pages/assets in AEM. If they translate "content", it is page content. It is nothing which you would use the AEM translator UI for.
The AEM translator functionality is feeding into the i18n subsystem. Basically it can replace placeholders in a UI by with a language-specific strings (or it is used in combination with dynamic data to build such strings) to support internationalization (i18n) of applications. But these strings rarely appear with regular AEM pages (maybe except for areas where logic is heavily intertwined with processed data), so for me this is not a job I would ask a content manager to do. It is rather the job of a translator service to translate labels and everything else, because it's not content in the first place, but I would consider it to be rather a development asset.
So, can you elaborate why your content managers use the translation UI on the production environment. And where do these translations eventually appear in your system?
I think, there is a gap here between developer and requester(business/content Author).
Whenever there is a requirement to create a new component or modifying an existing one. The translation for label, description etc. should be handover to the developer so that they can create language-specific keys with translation.
The component translation should not be customized by the Author instead should request to change.
Develop can easily manage translation for a component by just created i18n folder with the keys. The standard approach for the component label, dialog translation is to create an i18n folder within the component and create a language node with translation keys and values.
@Jörg_Hoh There are two cases when our content managers use Translator:
Updating translations of labels in custom components (so we don't need a deployment to adjust a label to marketing needs)
Updating translations that are used in the content of custom components (it's a custom-made feature: e.g. in our version of Text there can be references to translation keys). However it's a good point that it should be content translation, I am going to duscuss it with our content managers