Localising AEM Sites with Language Copies and Translation Workflows
Australia is one of the most linguistically diverse societies on the planet. Recent census data shows that more than a fifth of residents were born overseas and close to a quarter speak a language other than English at home, with Mandarin, Arabic and Vietnamese sitting alongside the long-established Greek and Italian communities. For digital platforms built on Adobe Experience Manager, that reality has direct consequences: every public-sector portal, bank login screen and university website eventually needs to speak more than one language, and the architecture decisions made early on determine whether that expansion is a weekend job or a multi-quarter ordeal.
AEM's i18n toolkit has matured considerably since the CQ5 era, and the modern approach combines language masters, language copies and translation projects into a single coordinated workflow. Understanding how the three pieces interact is the difference between a clean rollout across Sydney, Melbourne and Brisbane operations and a tangled mess of duplicated pages that drift further from the source every time the marketing team touches the English version. The patterns explored at technical gatherings such as CIRCUIT DevCon have evolved into practical blueprints worth studying closely because they reflect the real constraints encountered by developers shipping multilingual experiences.
Understanding the Building Blocks of AEM i18n
The first concept to grasp is the distinction between internationalisation (i18n) and localisation (l10n). Internationalisation is the engineering work that strips hard-coded strings, dates, currencies and layouts out of the codebase; localisation is the content work that fills those slots with values appropriate to each audience. AEM supports both, but they live in different parts of the platform, and treating them as the same thing is a common cause of project drift.
Within AEM, every translatable site begins with a blueprint. The blueprint owns the canonical content, and language copies inherit from it through the standard inheritance mechanism. When an editor updates the English version of a product page, the change cascades to the German, Japanese and Mandarin copies provided those fields have not been broken out of inheritance. That cascade is what allows a small editorial team in Pyrmont or Parramatta to maintain a sprawling global presence without proportionally growing headcount.
Locale codes follow the ISO 639-1 language standard plus an optional ISO 3166-1 country suffix, and the choice matters for markets where language and geography diverge. Australia itself illustrates the point: en-AU differs from en-GB and en-US in spelling conventions, date formatting and even decimal notation in some finance modules. Defining both the language and the country early avoids the awkward situation where an Australian user sees a US-style date alongside otherwise localised copy.
Setting Up Language Masters and Rolling Out Copies
Creating a language master is a one-time structural exercise that deserves serious attention. The hierarchy beneath /content must include a root per locale with its own jcr:language and jcr:country mixin properties, and the sites must be configured through the Translation Workflow under Tools > General. Skipping this step and merely duplicating pages by hand is the path most teams regret within a year.
Once the structure exists, language copies can be created in two ways. The Create Language Copy wizard under the reference site builds the full tree beneath the chosen locale root. A translation project, alternatively, scopes the rollout and provides a paper trail for compliance teams. For Australian government clients, the project approach is almost always required because auditability ranks as a top requirement after the Australian Government Digital Service Standard.
Inheritance is the feature most teams underestimate. Copy-from-blueprint inheritance works at the component level, which means a paragraph on the source page can be edited on a child locale without breaking the link on unrelated paragraphs. Site managers should document which areas are intentionally localised and which are meant to stay locked, especially where regulated text such as disclosure statements is involved.
Coordinating Human and Machine Translation Workflows
Translation projects sit on top of the structural foundation. They package a scope of pages into a job, dispatch it to a translation provider or in-house team, and accept the returned content back into the appropriate locale. AEM integrates with several commercial connectors out of the box, but a connector is optional; a simple human-in-the-loop workflow can be built with workflow models when the budget does not stretch to an enterprise TMS.
The choice between human translators, machine translation and a hybrid approach depends heavily on content type. Marketing copy benefits from professional linguists fluent in the target market; user interface strings inside i18n dictionaries can usually pass through machine translation engines with light review, which is the pattern many Australian agencies adopt for high-volume content. Recordings from the session videos archive walk through several practical implementations and remain one of the more efficient ways to compare strategies without running a full proof of concept.
For Australia specifically, NAATI certification of translators matters in regulated contexts such as community-services information and some healthcare content. The Australian Government also funds multilingual broadcast programming through SBS, and similar obligations elsewhere mean that provenance and translator credentials are part of what the workflow needs to capture, not just the resulting strings.
Metadata the workflow should retain for every job:
- Source and target locales, including the country variant
- Names and credentials of the assigned translators
- Reviewer approvals with timestamps
- Glossary hits for any term flagged for consistency
Pitfalls That Derail Multilingual Rollouts
Even careful implementations run into trouble. Replication errors are particularly common when staging and author tiers disagree on which locales exist, and they tend to surface only after a release goes live. Teams that document their replication topology and test language copies on the staging tier before promoting save themselves considerable weekend work. A practical resource for the deeper diagnostics is the replication errors walkthrough, which lists the causes that turn up most often in production environments.
Other frequent pitfalls include untranslated path segments, asset references that point only to the en-AU rendition, and dictionary keys that silently fall back to English when a typo creeps in. Performance is the subtler problem: deep language copy trees with hundreds of inherited components can tax the dispatcher cache, so the caching strategy needs to account for the locale dimension in its cache keys.
Time zones also bite Australian teams that contract translators in other hemispheres. Coordinating review windows between Sydney, London and Manila is harder than it looks, and a poorly timed cutoff in a translation project can add a day to every cycle. Building reviewer buffers into the project schedule is cheaper than rebuilding trust with stakeholders after a missed launch.
Front-End Practices That Keep Multilingual Sites Healthy
Sightly, AEM's HTML template language, exposes the current locale through the page object and several global objects, and using those accessors consistently is what keeps templates portable. Hard-coding English strings in component back-ends is the most common cause of a template that works in Melbourne but not in Munich, and lint rules in the project build can catch most offenders before they reach review.
Right-to-left support deserves a separate planning pass. If the rollout scope eventually includes Arabic or Hebrew, the CSS should be authored with logical rather than physical properties from the outset. Retro-fitting bidirectional support is expensive, and most Australian teams are well advised to plan for it even if the first wave of translations stays Latin-script.
Search and analytics must also follow the locale. Indexes built only against the en-AU content path will silently exclude everything else, and reports that segment by browser language rather than the page locale can mislead content owners about real Australian engagement patterns. A small investment in locale-aware analytics pays off for years after launch.
Habits worth standardising across the editorial team:
- Fill in the page title field for every locale, not only English
- Use the i18n dictionary rather than inline strings for UI labels
- Re-flag components for translation after substantial source edits
- Localise alt text on assets alongside the captions
Multilingual AEM is less about exotic technology than about consistency. The teams that succeed are the ones that treat language masters, translation projects and front-end locale handling as a single workflow rather than three independent concerns. If your roadmap includes an Asia-Pacific rollout, browse the event homepage to find the recordings, slide decks and speaker notes that match the stage you are currently planning through.