MSM, Live Copies and Translation#

#12 – MSM, Live Copies and Translation

Target: 3–4 years experienced AEM Developer Syllabus point covered (21): "What is MSM? Language copy, live copy, what is a blueprint? How is translation used in a project?" Project domain: a global energy technology company's marketing site.

#Before we start — why this topic fits your project story perfectly

Every other file in this repository has needed the energy domain as a backdrop. This one is the domain.

A global energy technology company sells transformers, HVDC systems and grid automation into dozens of countries. The product range is largely the same everywhere. The technical specifications are identical. But each country needs its own site, in its own language, with local contacts, local certifications and local pricing pages.

That is precisely the problem MSM exists to solve, and it is why URLs on sites like this look like /us/en/products-and-solutions/... and /in/en/products-and-solutions/... alongside a global site.

So when an interviewer asks about MSM, you have a genuinely natural story. The trick is getting the vocabulary exactly right, because this topic has four terms that people mix up constantly:

Blueprint. Live copy. Language copy. Rollout.

Section 2 pins each one down, and section 2.6 covers the relationship between the last two — which is the part almost everyone gets muddled, because a page can be both a language copy and a live copy at the same time.

#1. Introduction

#1.1 The problem MSM solves

Imagine our energy site without MSM.

You have a product page for a high-voltage transformer. It exists on the global site, and on the US site, and the German site, the Indian site, the Brazilian site — twenty countries. The technical specifications are identical everywhere.

Now a specification changes. Without MSM, someone edits twenty pages by hand. They will miss some. The sites drift apart. Six months later nobody knows which version is correct.

MSM — Multi Site Manager — is AEM's answer. You author once in a source site, and the other sites inherit from it. Change the source, push the change out, and every site that inherits gets it.

But — and this is the part that makes MSM interesting rather than trivial — inheritance has to be breakable. The German site genuinely needs a different local contact. The US site has a different certification statement. So MSM isn't simply copying; it is inheritance with controlled exceptions, and most of the complexity lives in those exceptions.

#1.2 The four terms, in one sentence each

Get these right and the rest follows:

The single most useful distinction:

A live copy is about place — same content, different site or region. A language copy is about language — same content, different words.

#1.3 A real project structure to describe

This is the standard AEM reference architecture for a multi-country site, and being able to draw it is worth a lot:

/content/energy/
│
├── language-masters/          ← authored + translated masters
│   ├── en                     ← THE source. Authored here.
│   ├── de                     ← language copy of en (translated)
│   ├── fr                     ← language copy of en (translated)
│   └── pt                     ← language copy of en (translated)
│
├── global/
│   └── en                     ← live copy of language-masters/en
│
├── us/
│   └── en                     ← live copy of language-masters/en
│
├── de/
│   └── de                     ← live copy of language-masters/de
│
├── ch/                        ← Switzerland: two languages
│   ├── de                     ← live copy of language-masters/de
│   └── fr                     ← live copy of language-masters/fr
│
└── br/
    └── pt                     ← live copy of language-masters/pt

Read that structure carefully, because it contains the whole answer.

Translation happens once, horizontally, inside language-masters. English is translated into German once — not once per German-speaking country.

Distribution happens vertically, from a language master out to every country using that language. Switzerland and Germany both take live copies of language-masters/de, so they share one translation.

A country page is therefore both — it is a live copy of a language master, and that language master is itself a language copy of English.

That two-layer structure is the thing to be able to explain. Almost every MSM question resolves to it.

#1.4 A real project example to adapt

"We run about twenty country sites off one codebase. The structure is a language-masters branch where English is authored and then translated into each language — so German is translated once, not once per German-speaking country. Then each country site is an MSM live copy of the relevant language master, so Germany and Switzerland's German site both inherit from language-masters/de.

Country teams can cancel inheritance where they genuinely need something local — a contact block or a certification statement — and we push them to cancel at the smallest scope possible, ideally a single property rather than a whole page, because a page-level cancellation means that page silently stops receiving every future update.

Translation goes through a Translation Integration Framework config pointing at our vendor, and subsequent updates use Update Language Copy so only changed content is sent for translation rather than the whole page."

That paragraph covers the structure, the translation strategy, the inheritance discipline and the cost model. It answers four follow-ups before they're asked.

#2. Core Concepts

#2.1 Blueprint — and the ambiguity in the word

"Blueprint" is used in two different senses, which is a genuine source of confusion. Being able to separate them is a good signal.

Sense 1 — informally, the source of a live copy. If /content/energy/us/en is a live copy of /content/energy/language-masters/en, people call the latter "the blueprint." That is the everyday usage.

Sense 2 — formally, a Blueprint Configuration. This is an actual configuration object that points at a source path.

What does a Blueprint Configuration actually give you? Two things:

1. The Rollout action from the source side. Without a blueprint config, you can only pull from the live copy ("Synchronize"). With one, an author standing on the source page can push to all its live copies ("Rollout"), and see which live copies exist.
2. It appears in the Create Site wizard, so new sites can be created from it.

The important consequence, which interviewers probe:

You do not need a blueprint configuration to create a live copy. A live copy works fine without one. What you lose is the ability to roll out from the source side and to see the live copy relationships from there.

The interview answer:

"The word is used two ways, which trips people up. Informally, the blueprint is just the source page a live copy inherits from. Formally, a Blueprint Configuration is a separate configuration pointing at a source path.

The configuration isn't required to create a live copy — a live copy works without one. What it gives you is the Rollout action from the source side, so an author on the blueprint page can push to all its live copies and see which ones exist. Without it you can still synchronise, but only by pulling from each live copy individually, which doesn't scale to twenty countries."

#2.2 Live copy — how the relationship is actually stored

A live copy is a copy that stays connected to its source.

The connection is stored in the repository, and knowing where is a strong detail.

When you create a live copy, its root page's jcr:content gets a cq:LiveSyncConfig child node:

/content/energy/us/en/jcr:content/
    └── cq:LiveSyncConfig
         ├── cq:master = "/content/energy/language-masters/en"
         ├── cq:isDeep = true
         └── cq:rolloutConfigs = ["/libs/msm/wcm/rolloutconfigs/default"]

cq:isDeep is worth understanding. With it true, the whole subtree below this page participates — pages added to the blueprint later appear here. With it false, only this page is connected, and new blueprint pages do not propagate. For a country site you almost always want deep.

The relationship is tracked per page, not just at the root, which is what allows an individual page deep in the tree to have its inheritance cancelled while its siblings continue inheriting.

#2.3 Rollout — pushing changes out

A rollout is the act of copying changes from the blueprint to its live copies.

Two directions, and the vocabulary differs:

What actually happens during a rollout is decided by the rollout configuration, not by MSM itself. That is the next section, and it is the part people skip.

#2.4 Rollout configurations and synchronization actions

This is where MSM stops being simple, and it is the depth question in this topic.

A rollout configuration is a named set of synchronization actions plus a trigger.

The trigger says when a rollout happens:

The default — "Standard rollout config" — uses the manual trigger. So by default, editing a blueprint page does not automatically update live copies. Someone has to roll out.

That default is deliberate and worth explaining: automatic rollout on every modification means every keystroke-level save propagates to twenty sites, which is both a performance problem and a governance one — half-finished edits reaching live sites. Manual rollout means someone decides when the change is ready to distribute.

The synchronization actions say what happens:

referencesUpdate is the one that causes real production problems when it's missing.

Think about it: a page on the blueprint links to /content/energy/language-masters/en/products/transformers. Roll that out to the US site without referencesUpdate, and the US page still links to the language master — so a US visitor clicks a link and lands on the wrong site, or on a path that isn't published at all. With the action, the reference is rewritten to /content/energy/us/en/products/transformers.

Where rollout configs live: out-of-the-box ones under /libs/msm/wcm/rolloutconfigs, and custom ones in your project under /apps/msm/wcm/rolloutconfigs.

#2.5 Inheritance and cancellation — the heart of the topic

MSM would be useless if inheritance were absolute. The German site genuinely needs a different contact; the US site has different certification wording. So MSM lets authors break inheritance — and at what scope is the critical decision.

Three scopes, from smallest to largest:

Property level. A single field stops inheriting; everything else on the page continues. Stored as a cq:propertyInheritanceCancelled property — a multi-value list of the property names whose inheritance is cancelled.

Component level. One component stops receiving rollouts. Its siblings on the same page carry on inheriting.

Page level. The whole page stops inheriting. Two flavours in the UI:

• Suspend — pause inheritance, resumable later. The relationship still exists.
• Detach — permanently break the live relationship. This is not reversible in the same way; the page becomes an ordinary page.

The discipline that matters — and this is the answer that shows experience:

Cancel at the smallest scope that solves the problem.

Because cancellation is silent and permanent in effect. A page-level cancellation means that page stops receiving every future update — including ones nobody anticipated. A year later, the blueprint gets a new compliance section, it rolls out to nineteen countries, and one country silently doesn't get it. Nobody notices, because a rollout that skips a cancelled page is working exactly as designed.

The failure is invisible, which is what makes it dangerous.

The interview answer:

"Inheritance can be cancelled at three scopes — a single property, a component, or the whole page. Property level is stored as cq:propertyInheritanceCancelled, a multi-value list of the property names that no longer inherit. At page level you can either suspend, which is resumable, or detach, which permanently breaks the relationship.

The discipline I'd push for is cancelling at the smallest scope that solves the problem. If a country needs a different phone number, cancel that property — not the component, and definitely not the page.

The reason is that cancellation is silent. A page-level cancellation means that page stops receiving every future update, including ones nobody has thought of yet. So a year later the blueprint gets a new compliance block, it rolls out to nineteen countries, and one silently doesn't get it — and nothing reports that, because a rollout skipping a cancelled page is behaving exactly as designed. That's the classic MSM production problem, and it's why we audit cancellations rather than treating them as a local decision."

#2.6 Language copy versus live copy — the comparison

This is the crux of your syllabus point, and where most candidates get muddled.

And now the part that confuses people:

A page can be both. In the standard structure, language-masters/de is a language copy of language-masters/en, and de/de is a live copy of language-masters/de.

Why the two-layer structure exists — this is the reasoning to give:

"You translate horizontally and distribute vertically.

If Germany and Switzerland each took a live copy of the English master and translated separately, you'd pay for the same German translation twice, and the two would drift apart in wording.

So instead you translate English into German once, in language-masters/de. Then Germany and Switzerland both take live copies of that. One translation, many countries, and a specification change flows from English through the German master out to both."

The follow-up that's worth pre-empting: "So what happens when the English master changes?"

"The English change has to be translated into German before it reaches the German-speaking countries. That's what Update Language Copy is for — it identifies what's changed since the last translation and sends only that for translation, rather than resubmitting whole pages. Once the German master is updated, a rollout pushes it out to Germany and Switzerland."

#2.7 Translation — how it actually works on a project

Translation in AEM has three parts, and knowing all three is what makes the answer complete.

Part 1 — the Translation Integration Framework (TIF) configuration. A cloud configuration that says which translation provider to use and how. It sets whether translation is machine or human, and connects to the vendor's connector.

It lives under /conf/<site>/settings/cloudconfigs/translation and is referenced from page properties, so different parts of the site can use different providers or settings.

Part 2 — the language copy structure. Created through the Create Language Copy wizard, which builds the target language tree. This is structural — it creates the pages, it doesn't translate them.

Part 3 — Translation Projects. The actual workflow. Creating a language copy generates a translation project, which contains translation jobs. Each job is a batch of content sent to the provider, tracked through states — draft, submitted, in progress, ready for review, approved — and then imported back.

The full flow:

graph TD A["Author writes in<br/>language-masters/en"] --> B["Create / Update Language Copy"] B --> C["Translation Project created"] C --> D["Translation Job(s)"] D --> E{"Machine or human?"} E -->|Machine| F["Translated immediately<br/>by the connector"] E -->|Human| G["Sent to the vendor<br/>— days or weeks"] F --> H["Imported into<br/>language-masters/de"] G --> H H --> I["Reviewed and approved"] I --> J["ROLLOUT to<br/>de/de and ch/de"] J --> K["Activate"]

Notice the last two steps. Translation gets content into the language master. A rollout is still needed to distribute it to the country sites, and then activation to publish it. Candidates often stop at "it gets translated" and miss that translation and distribution are separate operations.

Machine versus human, and the honest framing:

For an energy site this distinction is genuinely important, and it makes a good point to raise: technical specifications and regulatory statements need human translation, because a machine mistranslation of a safety-critical specification is a real liability. Blog posts and news might be fine machine-translated with review.

Update Language Copy is the operation for subsequent rounds. It identifies content that changed since the last translation and sends only that — which matters enormously for cost, because re-translating whole pages every time a paragraph changes is how translation budgets get destroyed.

#2.8 Language roots

A small but practically important detail.

AEM identifies a language root by the page name being a valid language or locale code — en, de, fr, en_us, pt_br — and by the jcr:language property on the page's jcr:content.

Why it matters: the Create Language Copy wizard, translation tooling, and the language switcher component all rely on this. Name a language root english instead of en and the tooling stops recognising it.

That is a good "gotcha" to know, because it produces a confusing failure — everything looks right, and the language copy wizard just doesn't offer what you expect.

#2.9 MSM and the rest of AEM

Two connections worth making, because they show the files joining up.

MSM and templates (file 03). A country site can point at a different /conf folder via sling:configRef, which means different policies — so the same template can allow different components in different countries. The template structure is shared via cq:template, but what authors may place can differ per country.

MSM and dialog validation (file 11). A rollout writes values directly into the live copy. It does not go anywhere near a dialog, so no client-side validation runs. That is one of the concrete ways dialog validation gets bypassed, and it is a genuinely good example to cite in either topic.

#3. Internal Working

#3.1 What happens during a rollout

sequenceDiagram participant A as Author participant BP as Blueprint page participant RM as Rollout Manager participant RC as Rollout config participant LC as Live copy page A->>BP: edits and saves Note over BP,RM: With the DEFAULT config nothing happens yet —<br/>the trigger is manual rollout, not onModify A->>RM: Rollout RM->>RM: find live copies via cq:LiveSyncConfig RM->>RC: which synchronization actions apply? RC-->>RM: contentUpdate, referencesUpdate, orderChildren… loop for each live copy page RM->>LC: is inheritance cancelled here? alt cancelled at page level RM->>RM: SKIP this page entirely else cancelled at property level RM->>LC: update everything EXCEPT the cancelled properties else not cancelled RM->>LC: apply all actions end end Note over LC: The live copy is now updated on AUTHOR.<br/>It still has to be ACTIVATED to reach publish.

Three things to draw out of that:

The cancellation check happens per page and per property, which is what makes fine-grained exceptions possible — and also what makes a cancellation silently skip future updates.

The rollout config decides what happens, not MSM itself. Missing referencesUpdate means links stay pointing at the blueprint.

A rollout only updates the author instance. The live copy pages still need activating. That is a very common "the rollout didn't work" report — it did work, on author, and nobody published.

#3.2 How a live relationship is resolved

When AEM needs to know whether a page is a live copy and what it inherits from, it walks up the tree looking for a cq:LiveSyncConfig with cq:isDeep set.

/content/energy/de/de/products/transformers/oil-filled
                                              ↑ is there a LiveSyncConfig here?
                                    ↑ here?
                          ↑ here?
              ↑ HERE — cq:master = /content/energy/language-masters/de
                       cq:isDeep = true

The relationship is inherited down the tree from the live copy root. So a page five levels deep is part of the live copy because an ancestor declares a deep relationship — not because it has its own configuration.

That explains a common confusion: you look at a deep page in CRXDE, see no cq:LiveSyncConfig, and conclude it isn't a live copy. It is — the configuration is on an ancestor.

#3.3 Why a rollout "does nothing"

The most common MSM support ticket, and the diagnosis order is the answer:

graph TD A["Rolled out, the page didn't change"] --> B{"Is inheritance cancelled<br/>on that page or property?"} B -->|Yes| C["Working as designed —<br/>this is the classic cause"] B -->|No| D{"Did the rollout config include<br/>the right sync action?"} D -->|No| E["e.g. contentUpdate missing,<br/>or contentDelete for removals"] D -->|Yes| F{"Is the relationship DEEP?"} F -->|No| G["Only the root page participates"] F -->|Yes| H{"Was the live copy ACTIVATED<br/>after the rollout?"} H -->|No| I["It DID work on author.<br/>Publish just doesn't know."] H -->|Yes| J["Check the dispatcher cache"]

The first and last branches account for most real cases — cancelled inheritance, and a rollout that worked but was never published.

#8. Configuration Examples

#8.1 The live copy relationship in the repository

/content/energy/de/de/jcr:content/cq:LiveSyncConfig

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0"
          xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:LiveSyncConfig"

    <!-- The SOURCE this inherits from.
         Note it points at the GERMAN language master, not English --
         the German master is itself a language copy of English. -->
    cq:master="/content/energy/language-masters/de"

    <!-- DEEP: the whole subtree participates, so pages added to the
         master later appear here too. Without this, only the root
         page is connected and new blueprint pages never propagate. -->
    cq:isDeep="{Boolean}true"

    <!-- Which rollout configuration(s) apply -->
    cq:rolloutConfigs="[/libs/msm/wcm/rolloutconfigs/default]"/>

The three properties to be able to name. And note that a page deep in the tree has no cq:LiveSyncConfig of its own — it's part of the live copy because this ancestor declares a deep relationship. That's why looking at a deep page in CRXDE and seeing nothing is misleading.

#8.2 Property-level inheritance cancellation

On a live copy page's jcr:content, or on an individual component node:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0"
          xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="nt:unstructured"

    <!-- ONLY these two properties stop inheriting.
         Everything else on this node continues to receive rollouts.
         THIS IS THE SCOPE YOU WANT -- a page-level cancellation
         would silently stop ALL future updates. -->
    cq:propertyInheritanceCancelled="[contactPhone,contactEmail]"

    contactPhone="+49 30 1234 5678"
    contactEmail="[email protected]"

    <!-- These still inherit and will be updated on every rollout -->
    jcr:title="Leistungstransformatoren"
    productCode="TX-4000"/>

This is the good pattern, and worth showing as a contrast to a page-level cancellation. Two properties are local; everything else keeps flowing.

#8.3 A custom rollout configuration

/apps/msm/wcm/rolloutconfigs/energy-standard/.content.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0"
          xmlns:jcr="http://www.jcp.org/jcr/1.0"
          xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    jcr:primaryType="cq:RolloutConfig"
    jcr:title="Energy — Standard Rollout"
    jcr:description="Manual rollout with reference rewriting and versioning"

    <!-- TRIGGER: manual rollout only.
         NOT onModify -- that would propagate every  save to
         twenty live sites, which is both a performance problem and
         a governance one, since half-finished edits would go live. -->
    cq:trigger="rollout">

    <!-- The ACTIONS decide what actually happens. MSM itself does
         nothing without these. -->

    <!-- Create a version first, so there's a rollback point -->
    <versionCopy
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Create a version before overwriting"/>

    <!-- New pages in the blueprint appear in the live copy -->
    <contentCopy
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Copy new content"/>

    <!-- Changed content is updated -->
    <contentUpdate
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Update changed content"/>

    <!-- Pages deleted in the blueprint are removed here -->
    <contentDelete
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Delete removed content"/>

    <!-- CRITICAL. Rewrites internal links so a country page links to
         the COUNTRY equivalent, not back to the language master.
         Without this, every internal link on every country site points
         at /language-masters/ -- which works on author (where an
         authenticated author can read it) and 404s on publish (where
         that branch isn't published at all). -->
    <referencesUpdate
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Rewrite internal references"/>

    <!-- Child page ordering follows the blueprint -->
    <orderChildren
        jcr:primaryType="cq:LiveSyncAction"
        jcr:title="Apply page order"/>

</jcr:root>

The comment on referencesUpdate is the one to be able to explain, because it's story 2 and it's the action whose absence isn't visible until publish.

#8.4 Reading live copy information in Java

Occasionally needed — for a component that behaves differently in a live copy, or for an audit report.

package com.energy.core.services.impl;

import com.day.cq.wcm.msm.api.LiveRelationship;
import com.day.cq.wcm.msm.api.LiveRelationshipManager;
import org.apache.sling.api.resource.Resource;
import org.apache.sling.api.resource.ResourceResolver;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.jcr.RepositoryException;

@Component(service = LiveCopyInfoService.class)
public class LiveCopyInfoServiceImpl implements LiveCopyInfoService {

    private static final Logger LOG =
            LoggerFactory.getLogger(LiveCopyInfoServiceImpl.class);

    @Reference
    private LiveRelationshipManager liveRelationshipManager;

    @Override
    public boolean isLiveCopy(Resource resource) {
        // The relationship may be declared on an ANCESTOR with
        // cq:isDeep, so this walks up rather than checking only
        // the node itself.
        return liveRelationshipManager.hasLiveRelationship(resource);
    }

    @Override
    public String getBlueprintPath(Resource resource) {
        try {
            LiveRelationship relationship =
                    liveRelationshipManager.getLiveRelationship(resource, false);

            // ALWAYS null-check -- not every page is in a live copy
            if (relationship == null) {
                return null;
            }
            return relationship.getSourcePath();

        } catch (RepositoryException e) {
            LOG.warn("Could not read the live relationship for {}",
                    resource.getPath(), e);
            return null;
        }
    }

    /**
     * Used by an audit report: is this page still actually receiving
     * rollouts, or has someone cancelled inheritance?
     *
     * A cancelled page silently stops receiving EVERY future update,
     * and nothing reports it -- which is exactly why we audit.
     */
    @Override
    public boolean isInheritanceCancelled(Resource resource) {
        try {
            LiveRelationship relationship =
                    liveRelationshipManager.getLiveRelationship(resource, false);
            if (relationship == null) {
                return false;
            }
            return relationship.getStatus() != null
                    && relationship.getStatus().isCancelled();

        } catch (RepositoryException e) {
            LOG.warn("Could not read the relationship status for {}",
                    resource.getPath(), e);
            return false;
        }
    }
}

LiveRelationshipManager is the API name worth knowing. Being able to name it — rather than only describing the UI — is a useful signal.

#8.5 Finding cancellations — the audit

The practical response to story 1. A QueryBuilder query for property-level cancellations:

path=/content/energy
type=nt:unstructured
property=cq:propertyInheritanceCancelled
property.operation=exists
p.limit=-1

Note p.limit=-1 is fine for a one-off audit run by an administrator, but it's exactly what you would never put in a component — file 05's rule about unbounded results applies to anything on the render path.

The point to make: cancellations aren't reported anywhere by default, so if you care about them, you have to go looking. That's a governance answer, not a technical one.

#9. Common Mistakes

#10. Best Practices

On structure. Use the language-masters pattern. Translate horizontally, distribute vertically. Decide the structure before building, because restructuring later means auditing and reapplying every inheritance exception — which takes longer than the restructure itself.

On inheritance. Cancel at the smallest scope that solves the problem. Audit cancellations periodically, because they're silent by design. Make sure country teams understand the difference between property and page level — most over-broad cancellations are ignorance, not intent.

On rollout configs. Manual trigger by default. Always include referencesUpdate. Include versionCopy so there's a rollback point. Be explicit about contentDelete, because it's the one with destructive potential.

On translation. Human for technical, legal and regulatory content; machine with review is defensible elsewhere. Use Update Language Copy for subsequent rounds. Remember translation and distribution are separate steps.

On operations. Rollouts run on author and compete with authoring — scope large ones and run them out of hours. Remember activation is a separate step, and a large rollout means a large dispatcher flush.

#11. Debugging Tips

"The rollout didn't work" — check in this order:

1. Is inheritance cancelled? By far the most common cause, and remember it is not an error — there's nothing in any log. Check page properties, and cq:propertyInheritanceCancelled in CRXDE.
2. Was it actually activated? A rollout updates author only. This is the second most common cause and the one people are most embarrassed by.
3. Does the rollout config include the needed action? No contentUpdate means no updates; no contentDelete means removals don't propagate.
4. Is cq:isDeep true? If false, only the root page participates.
5. Dispatcher cache — activated, but the old page is still cached.

"The country site links to the wrong place": referencesUpdate is missing from the rollout config. Confirm by looking at an internal link's href on a country page — if it contains /language-masters/, that's it.

"We deleted a page and it came back": it's still inheriting, so the next rollout restored it. Either delete it in the blueprint or cancel inheritance for it.

"The German site is showing English": it was rolled out before it was translated. Translation and rollout are separate operations and can happen in the wrong order.

Useful places to look:

A habit worth describing: "When something's inconsistent across countries, my first question is always 'is inheritance cancelled somewhere' — because that's the failure mode that produces no error and looks exactly like normal operation."

#12. Performance Notes

A rollout on a large tree is heavy. It walks the structure, evaluates cancellation per page, and writes to every live copy. Rolling out the root of a twenty-country site is a significant operation.

It runs on author, competing with authoring. Scope large rollouts to a subtree and run them out of hours.

This is another argument against onModify — it turns every author save into a multi-site write operation.

Activation after a large rollout means a large dispatcher flush, which can cause a burst of cache misses on publish. On a big change, that's worth anticipating rather than discovering.

Translation jobs on large trees take real time and vendor capacity. Update Language Copy limits the volume by sending only changes, which matters for turnaround as well as cost.

#15. Comparison Tables

Live copy vs Language copy — the syllabus comparison

Blueprint — the two senses

Rollout triggers

Key synchronization actions

Cancellation scopes

Machine vs human translation

#Next topic

13-Users-Groups-and-Permissions — your syllabus point 22: users, groups, ACLs and how permissions are actually evaluated, closest-match and deny-wins, service users and Repoinit, and the standard AEM groups you should be able to name.

Topic 12 of the AEM Interview Preparation repository. Teaching style, energy-sector project domain.