Managing translations in AEM by both content authors and developers | Community
Skip to main content
A
Alexander_Prikhodko
Level 2
March 13, 2021
Solved

Managing translations in AEM by both content authors and developers

  • March 13, 2021
  • 3 replies
  • 1416 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

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?

 

 

3 replies

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
March 13, 2021

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?

 

 

    A
    Alexander_PrikhodkoAuthor
    Level 2
    March 13, 2021

    @joerghoh 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
      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      March 13, 2021

      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
      Community Advisor
      arunpatidarCommunity Advisor
      Community Advisor
      March 13, 2021

       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>

       

       

       

      Arun Patidar
        Terms & ConditionsAccessibility statement

        Loading footer...