Smart Rendering – Enhancing User Experience

Adobe Experience Manager (AEM) comes equipped with the powerful ‘Communities’ feature. It enables the development of a relationship with the site visitors that informs through blogs, Q&A and event calendars, while gaining insights through forums, comments, and other community content, often referred as User Generated Content (UGC).

With the release of AEM 6.2, users would further get an enhanced experience in translating the UGC. This has become possible because of this new feature – Smart Rendering. It lets one translate the complete User Generated Content, present on a community site, while loading the page.

In this blog, I would explain how to enable this feature and how to manage what language you’d see after the translation.

Let us start by learning as to How to enable Smart Rendering

When a user creates a community site in the ‘Author’ instance, using the Community site Creation Wizard and publishes it, Smart Rendering is not set. To do so, we need to publish and open the site in ‘Publish’ instance.

  1. Go to ‘Profile’ tab on the community as depicted below:


  1. Click on ‘Edit Profile’ button and you will find an option that says ‘Always show contributions in my preferred language’. Choose ‘On’ from the drop down menu


Now, we have successfully enabled the Smart Rendering.

Let us now learn as to how do we manage the ‘Target Language’

There are various factors that can affect the outcome you are going to see after the translation. To decide it, the system considers three options

  • User Language (ul)
  • Browser Language (bl)
  • Page Language (pl)

The User language is given highest priority. If you open ‘Profile’ tab for the first time, you’d notice that the user language (ul) is not set. If you click on the ‘Edit Profile’ settings, the system will set the user language to English (en) by default. You can choose from the drop down menu any language as your preferred language and the UGC will get translated into that language.


Suppose, at first, the User Language is not set, the system gives preference to Browser Language (bl). It can be found under the language settings in your respective browsers.

Page language (pl) is the language of the page or technically, the language of the community site. It is set while creating community site and given the least priority while translation happens.

This feature that makes it very convenient to enable Smart Rendering and set-up language preferences. Stay tuned for more on this!!

This blog post has been authored by Arun Rajan (AEM Translation Team).

XML Documentation Add-On for Adobe Experience Manager

Adobe recently launched a new Add-On Package to Adobe Experience Manager, specifically targeted at bringing technical communication closer to Adobe Experience Manager. The new package is being marketed as “XML Documentation Add-on for Adobe Experience Manager” and on The Add-On provides the capability of managing DITA content and publishing it from AEM. If you have ever worked on Technical Documentation, you would be conversant with DITA. From a very long time, AEM did not have a solution for natively handing Technical Communication content. However, this Add-On seems to be a step in this direction. It will open doors for large enterprises that manage documentation in DITA to publish directly via AEM without having to go through the conversion process – which was one off and had to be repeated.

Apart from the basic ability of publishing DITA content, Adobe seems to be positioning this as a CCMS (Component Content Management System). This is very interesting and intriguing. In some form, AEM with it components was already a Component Content Management System. However, AEM has always pushed the envelope when it comes to web and connected experiences. It would be really interesting to see how this evolves and helps promotes content reuse. There was a key feature added in AEM 6.2 called Content Fragments, which could also be looked as a step in the direction of content reuse. From a strategy perspective, it is very clear that Content reuse is something that Adobe is now serious about.

What I like the most is the idea of a single Content Management System for both Marketing and Technical Communication. It is a huge benefit for large enterprises and system integrators like us offering the following key benefits:

  1. Standardizations of content platform and processes: Enterprises can now think about putting AEM at the center of all things Content. They can invest in building standardized content workflows and processes across the organization – Review workflows, SEO/SEM workflows, Translation workflows and Publishing workflows. This opens up immense opportunities for standardization.
  2. Reduction in Costs: Develop once and use across all sites and content. No duplication of assets (templates); look and feel etc. Integrate once and with one platform. Integration of other services like Analytics, SEO/SEM, personalization, translation is a huge effort and cost. By having one platform, we are saying that it needs to be done once.
  3. Consistency:There is consistency at both levels – for users of the Platform and end customers. For authors (marketing content authors and Technical documentation authors), it is the same system. The experience is consistent and same. The reports and processes are the same. For an end customer, it is going to provide a consistent experience when they move from Marketing section to Help and Learning section. We are already seeing the boundaries blur and this is going to help even more.
  4. Upsell Opportunities: One trend that we see in the market is the option to upsell offering while you are struggling with a problem – In-context Upsell offers. One single platform opens up the possibility of sharing Technical Documentation insights with the marketing side of the house to provide Upsell offers.

The more I think about this option, the more excited I get. I am going to peel this onion in next few days and will continue to share insights here in this blog.

Multilingual Search(MLS) – Breaking the Language Barrier

Adobe is committed to provide its AEM customers the ability to serve people across different countries and regions with a streamlined product. In its endeavor to achieve the goal for no-language barrier, the AEM team at Adobe has introduced the feature of Multilingual Search (MLS) with the release of AEM 6.2

Lets try to better understand it through an example.

Suppose an automobile giant in Germany uses AEM as a comprehensive content management platform solution. We have three people here to demonstrate how it works:

  • A businessman in London
  • An engineer in Germany
  • A car enthusiast in China

The businessman is having some trouble with his car’s transmission system and he goes to the online community for help. Here is how the conversation  between the three gentleman goes like:

Businessman: Hi! I am facing problem with my transmission system. The shiftsare making unusual noise. Any help?

Engineer searches for Getriebe problem (Transmission problem) to see all the queries people might have and he will see this post.

Engineer: Wann war das letzte Mal Sie das Motoröl geändert  (When was the last time you changed the engine oil)

Meanwhile, the Car enthusiast from China responds to this:

Car Enthusiast: 即使我面一些与我汽速器,我他写了和它取代 (Even I face some issue with my car’s transmission, I wrote to them and got it replaced.)

Businessman: I did change it recently. I guess I would go for complete replacement. Thank you.

Conversation Over.

The businessman comes back and searches for ‘Transmission system’ and he gets all the above replies, even though they were written in different languages.

This was a simple demo, how MLS works.

AEM 6.2 and FP4 for 6.1 come equipped with this powerful feature. It is being offered in two variants

  • Simple MLS
  • Advances MLS

The major difference between these two is the ability of the latter  to detect, modify the query language and search in appropriate index. It should also be noted that for MLS to work, currently, only Mongo Backend is supported along-with SOLR as a search platform.

Whenever a user makes a contribution, for example a comment, reply or question/answer, the User Generated Content(UGC) gets stored in the verbatim_default index. Once the system detects the language, it gets stored in verbatim_en, verbatim_fr and verbatim_de etc.

If we have Simple MLS deployed, the system searches in the following indexes:

  • Verbatim_default
  • Verbatim_lang ; where lang: user preference language

The user has the liberty to choose the language from the dropdown. Suppose he chooses, German(de), then the indexes that would be searched:

  • Verbatim_default
  • Verbatim_de

Sample Query Generated by AEM for the search text –“sprechen Sie laut”

INFO – 2016-07-26 10:19:51.171; org.apache.solr.core.SolrCore; [collection1]webapp=/solr path=/selectparams{q=%2B(cqtags_ss(sprechen+Sie+laut)+author_username:sprechen+Sie+laut+verbatim_default:(sprechen+Sie+laut)+verbatim_de:(sprechen+Sie+laut)+title_t:(sprechen+Sie+laut)+author_display_name(sprechen+Sie+laut))+%2Bprovider_id:\/content/usergenerated/asi/mongo/content/sites/checkMLS/en/*+%2Bresource_type_s:*&df=provider_id&el=de&start=0&trf=verbatim&sort=timestamp+desc&fq={!cost%3D100}report_suite:mongo&rows=10&wt=javabin&version=2} hits=1 status=0 QTime=4

In case of Advanced MLS:

The system itself detects the language of the query and after some modification,generate a query which will search in the desired index and we will get search result.

Sample Query Generated in this case – –“sprechen Sie laut”

INFO – 2016-07-26 10:47:53.633; com.adobe.tat.LangDetectRequestHandler; FOR TAT LOG,params:{params(q=%2B(cqtags_ss:*(sprechen+Sie+laut)+author_username:sprechen+Sie+laut+verbatim_default:(sprechen+Sie+laut)+verbatim_en:(sprechen+Sie+laut)+title_t:(sprechen+Sie+laut)+author_display_name(sprechen+Sie+laut))+%2Bprovider_id:\/content/usergenerated/asi/mongo/content/sites/checkMLS/en/*+%2Bresource_type_s:*&df=provider_id&start=0&trf=verbatim&bl=en&sort=timestamp+desc&fq{!cost%3D100}report_suite:mongo&pl=en&rows=10&wt=javabin&version=2),defaults(df=text&echoParams=explicit&rows=10)}

INFO – 2016-07-26 10:47:53.633; com.adobe.tat.LangDetectRequestHandler;

FOR TAT LOG, q={+(cqtags_ss:*(sprechen Sie laut) author_username:sprechen Sie lautverbatim_default:(sprechen Sie laut) verbatim_en:(sprechen Sie laut) title_t:(sprechen Sielaut) author_display_name:(sprechen Sie laut))+provider_id:\/content/usergenerated/asi/mongo/content/sites/checkMLS/en/*+resource_type_s:*}INFO – 2016-07-26 10:47:53.633; com.adobe.tat.LangDetectRequestHandler; translate fileds name :verbatim

INFO – 2016-07-26 10:47:53.633; com.adobe.tat.langdetect.ShortTextLangDetector; There are signals for this language detector

INFO – 2016-07-26 10:47:53.636; com.adobe.nlp.core.processor.AdobeNLPComponentRunner; using: 2315431 ns, to run process method: processINFO – 2016-07-26 10:47:53.636; com.adobe.tat.LangDetectRequestHandler;new_q={+(cqtags_ss:*(sprechen Sie laut) author_username:sprechen Sie lautverbatim_default:(sprechen Sie laut) verbatim_de:(sprechen Sie laut) verbatim_en:(sprechenSie laut) title_t:(sprechen Sie laut) author_display_name:(sprechenSie laut))

While these sample queries above may look all gibberish and be in-comprehendible to the naked eye, with MultiLingual Search, Adobe has certainly broken the language barriers across the community members speaking different languages. Stay tuned for more insights into this!!

I would like to thank Arun Rajan for his major contribution to this blogpost.


Global Site Structure: Part 3

This blog post is in continuation of the Global Site Structure Series. This is the third blog in the Global Site Structure Series. In case you haven’t read the first two, here are quick links:

In this blog, let’s take a step further and think through how would we set up such a site in Adobe Experience Manager (AEM). What I will try to do is set-up a site using We.Retail sample that ships with AEM 6.2 and can be found here:

AEM has two important concepts – Live Copy and Language Copy. Most often a lot of information architects and developers confuse these two concepts. My colleague Gaurav Garg has covered the these concepts in this blog: Language Copy or Live Copy | An Important Decision. Here is a thumb rule that I use:

  • Sites (partial sub sites included) in same language – use LIVE COPY. Useful for Corporate > Dealer or Company > Reseller kind of scenarios.
  • Sites in different language – use LANGUAGE COPY. Useful for global sites, when the same content is translated in multiple languages. These can be updated as well via Update Language Copy

For most organizations, that I have worked with, most authoring (95+ percent) happens in a single language. And usually authoring happens for a particular geography. In case of We.Retail, let’s assume that primary authoring happens for North American market (USA to be specific) and in English language. The first and foremost thing that we will do is to set up the primary Authoring Branch. This the the primary authoring language. This is how it would look in AEM:


And this is the view in CRX:


Since this site contains USA specific content, we will create an International copy. We will create a Live Copy from the authoring site. We will create this under We.Retail Language Masters under en_gb locale folder. You can use en as well, in case you want it to be agnostic to the dialect. After the Live Copy has been created, we will break inheritances for any content that was US specific. We shall ensure that the content is truly common and can be shared across different geographies and markets. Here is a picture that describes how to set up International English


One important thing to note is that that We.Retail Authoring Site is not identical to International English Site. It has common content that applies to all geographies and markets.

Next we are going to translate the common content to various languages. For illustration, we will set up only four additional languages –  Spanish (es_es), French (fr_fr), German (de_de) and Italian (it_it) and will will set up five countries – USA, Canada, France, Germany and Switzerland.

We use International English as the source and translate content in four languages – Spanish (es_es), French (fr_fr), German (de_de) and Italian (it_it) using Language Copies functionality in AEM. In order to create Language Copies, create language roots in all these four languages. Language roots are nothing but blank pages named using these specific locales.

Language Copies require a specific structure. Things that you need to take care off are:

  • The Language Root name must be a language ISO locale. You can use either two letter locales (en, fr, de), or five letter locales (en_us, en_gb, fr_fr, fr_ca). You can choose to use dashes instead of underscores as well (en-us, en-gb, fr-fr, fr-ca).
  • All the Language Roots need to be at the same level. In our setup, we are going to use five letter underscores, and set them up under language-masters node. Please note, most companies use dashes. I will write another blog post to talk about those.


Once these Language Roots have been created, these will start appearing in the References Panel, under Language Copies. You can invoke Create Language and Update Language Copy workflows from References Panel.

Once the Language Copies have been created, we will now go ahead and create Country Sites. I am skipping a lot of details about how to configure and kick of translation as well as Update Translations. It will be a topic for another blog post. It has been covered fairly well in the AEM documentation as well:

Here is a pictorial representation of the progress so far:


Next we are going to create country Sites. We are again going to use Live Copy functionality (MSM) to set up country websites. We will set up Live Copies between the Language Copies under Language Masters to specific Country Sites. Let’s first set up country sites for Canada, France, Germany and Switzerland. We are intentionally skipping US for a moment.

Here is a pictorial representation of the setup for We.Retail Canada and We.Retail Schweiz (the ones that have more than one language):


Here is what we did for setting up country sites for Canada, France, Germany (Deutschland) and Switzerland (Schweiz):

  • Live Copy from International English (/content/language-masters/en_gb) to We.Retail Canada English (/content/ca/en_gb) and We.Retail Switzerland English (/content/ch/en_gb)
  • Live Copy from French Master (/content/language-masters/fr_fr) to We.Retail Canada French (/content/ca/fr_fr), We.Retail Switzerland French (/content/ch/fr_fr) and We.Retail France (/content/fr/fr_fr)
  • Live Copy from German Master (/content/language-masters/de_de) to We.Retail Deutschland (/content/ca/de_de) and We.Retail Switzerland German (/content/ch/de_de)
  • Live Copy from Italian Master (/content/language-masters/it_it) to We.Retail Switzerland German (/content/ch/it_it)

After the Country Sites have been created, they will contains all the common content. We all know that each geography has country specific content as well. Now marketing managers can go ahead and create additional country specific content in each of the country sites. You can have local contact addresses, campaigns, event information etc.

Let’s now talk about USA site. Since we already have adaptations for the US market in the authoring site, we are going to leverage that. So for English, rather than creating a Live Copy from International English, we will create a Live Copy from the main authoring site.

These are the steps that we follow for creating the USA english site.

  • Live Copy from Spanish Master (/content/language-masters/es_es) to We.Retail USA Spanish (/content/us/es_es)
  • Live Copy from We.Retail Authoring Site (/content/we-retail/en) to We.Retail USA English (/content/us/es_us)

This is one way of setting up the structure. I have to admit, this has been a long post. I hope you will like this useful. I would love to hear your feedback.