Head of Product Engineering in CognifideMateusz joins Wordbee for a guest post about localizing Adobe AEM content. Mateusz is responsible for maintaining a whole in-house product development lifecycle for AEM Zen Garden, the first-ever AEM accelerator. He started as an AEM developer, working with CQ 5.4 on a remote team. Then, as a team leader, he successfully designed and ramped up a multi-brand platform for a large pharma company. He has worked with all of the AEM versions since 2011. Technical interests: user experience, platform design, permission management Personal interests: bread baking, wines
Localization in Adobe AEM: The benefits of AEM dictionaries and Template Processors in one easy solution
The functionality of Translation Memory (TM) is well known and used widely in all translation houses. For a while, I thought of this as simply the way in which translation vendors streamline their internal work. Until one of our clients challenged our AEM solution, questioning its cost-effectiveness.
Once we looked under the hood, it became obvious that we had been translating the same words (button labels, call to action wording etc.) and phrases over and over again. AEM implementations are not cheap, but that shouldn’t be an excuse to overlook any potential cost savings. When it comes to creating and propagating changes on localised content branches, using TM-like storage inside AEM can reduce costs significantly.
The AEM product helps you with out-of-the box solutions but still gives you huge space for bespoke design. The AEM dictionary (still using the Classic UI), claims to be the ultimate solution. It has a major flaw though; it tightly couples your component logic with an entry within the glossary. It is only useful if your component toolbox is large and the building blocks are designed for one purpose only.
You can always arm your authors with template placeholders, to be replaced later by the actual text value. These are widely used in all the Template Processors. The biggest advantage here is that you can create a truly generic set of components. The trade-off is that you expose a really technical and error-prone feature to your, presumably, non-technical content creators.
The ideal solution would merge both. The authoring convenience, taken from the dictionary solution and the freedom of usage in the Template Processors approach. Being a limited effort task, a dialog enhancement allowing users to insert a placeholder from a Campaign-like widget is now my favourite option. By adding an extra button next to each field in a dialog, as you would in Adobe Campaign integration, your authors can mix static content provided manually with content taken from the reused storage. If this functionality is available across the whole platform, the content re-use can be really high.