Managing translations in AEM by both content authors...

[Alexander_Prikhodko]

Hello all,

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?

Alexander Prikhodko

Veeam Software

[Jörg_Hoh · Accepted solution]

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?

[Alexander_Prikhodko]

@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

[Jörg_Hoh]

In both cases it seems to me that you have a type of content, for which the i18n system seems a good solution from the technology point of view, but is problematic in the handling and the content processes.

Regarding the first requirement: Either it's a development artefact or a content artefact. Just to ease the handling of these and also the processes, it would give the ownership either to the developers or the content managers. And the i18n was never really designed to be used by content managers (although there's a UI for it)...

Regarding the second requirement: In one of my projects we did the same, but we created custom dictionaries (today they would reside below /conf) with a custom UI for it. But in the end it seemed to me, that it would have been easier if we would have written that functionality ourselves, because the i18n framework comes with functionality we never required (and which also had some subtle bugs we had to workaround until they were fixed).

Another factor: When you consider migrating to AEM as a Cloud Service, the i18n libraries are read-only, because they reside below /libs or /apps. That means you would have to rethink your approach anyway.

[arunpatidar]

 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.

e.g.

ui.apps/src/main/content/jcr_root/apps/myproj/components/content/component1/i18n/de.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    jcr:language="de"
    jcr:mixinTypes="[mix:language]"
    jcr:primaryType="nt:folder">
    <myproj.component.comoponent1.component.name
        jcr:primaryType="sling:MessageEntry"
        sling:message="Comp1"/>
    <myproj.component.comoponent1.dialog.tab.general.label
        jcr:primaryType="sling:MessageEntry"
        sling:message="Tab1"/>
</jcr:root>