Common Header and Footer with Editable Templates in multilingual site

[kamalc]

Hello

I searched long and hard everywhere but did not find a satisfactory answer to this. I'm using AEM 6.5 Editable Templates to build a site that will be translated to multiple languages.

What are some common techniques for creating a common Header & Footer that can be edited by content authors? The we-retail & wknd implementations seem extremely simple and not representative of real-world use cases.

Below are some use cases I can think of.

1. Extra content in menu drop-downs in Navigation.

2. Huge amount of content in the footer that needs to be editable per language.

3. Navigation that is different from url hierarchy.

I have experimented with Experience Fragments, but got stuck because I am not able to include an Experience Fragment in my Header component using sly-data-resource. My thinking is that I will alter the experience fragment path based on properties set on language root pages. But I couldn't get this to work.

I read about Global configs page, setting properties on the language root pages, etc, but there are no concrete examples showing how these are done.

Really appreciate any help you can provide in this regard. Thank you!

[smacdonald2008]

Did you watch our Ask the AEM Community webinar on this subject?

Scott's Digital Community: [Webinar |October] AtACE Session: Creating a site structure to support yo...

[kamalc]

I actually watched it. I found the link from one of your posts in reply to a similar question. Unfortunately, that session did not address the implementation aspect of this. It only talks about setting up the site structure based on the languages, countries and business model of an organization. It does not get into any implementation details.

[smacdonald2008]

I will ask the presenter to look here.

[jayQ]

Hello,

As an idea, If you are using editable templates the header and the footer experience fragments could be added on the template using the experience fragment component.

That component should be extended and customised in a way that is capable of, depending on the page language, retrieve the localised version of the experience fragment referred.

About this, the idea is quite similar to the experience fragment approach.
The root page of a country/language could contain the header component that can be edited by authors. Then on every other page you could approach by adding a hardcoded header component on the page component that references the configuration on the root page where the header configuration is, something like:

<header data-sly-resource="${'./path' @ resourceType='components/header'}"></header>

Where ./path points to the root page where the configuration is, it should be dynamically calculated.

[kamalc]

Hi, really appreciate your follow up on this. I actually implemented it more or less like what you have described.

Instead of extending the Experience Fragment component, I built a new component that I call 'Reference' component which is able to dynamically calculate the path of my header and footer based on the language root.

By doing this, my header can be a regular component on any page or an Experience Fragment. I found no advantage to using Experience Fragments so to speak other than being able to use header and footer on other websites in the company. Moreover, there are some weird 12px margins on the Experience Fragment component that make things imprecise when Header (logo, utility, nav, etc) is built and referenced using an Experience Fragment.

This is a major omission by Adobe and I hope they think about real world scenarios and augment the core components accordingly or simply make the Experience Fragment component language/site aware just like the core Navigation, Language Navigation, etc.

thanks!