Adobe Experience Manager Sites multilingual translation works best when language masters, language copies, translation projects, assets and public publishing are treated as one connected journey. This practical AEM Sites localization guide explains how to prepare language roots, create language copies, manage human or machine translation jobs, update translated pages and verify the website visitors actually use. It focuses on Experience Manager as a Cloud Service and on the editorial decisions that remain important regardless of translation vendor.
In AEM Sites, a language copy is not simply a separate translated document. Its relationship to the language master, the translation integration framework and any Multi Site Manager live copies affects which content travels where and how future revisions are propagated. A page may have a correct translation job while its linked image remains untranslated; a regional live copy may inherit changes that need local exceptions; or a language copy may have been created without the translation being completed. Understanding these distinctions prevents expensive, difficult-to-diagnose releases.
Quick answer: inventory the source site and language roots, identify which pages and assets need translation, configure the appropriate translation service and project workflow, create language copies, review each job’s output, publish approved pages and dependent resources, and test every real locale route. Keep translation across languages separate from region-specific reuse within a language, use a clear revision record, and verify the rendered journey rather than assuming a completed translation task means a finished website.
Practical overview
- Map language roots and content dependencies.
- Distinguish translation jobs from live-copy rollouts.
- Approve content, assets, facts and local exceptions.
- Test published URLs and user journeys.
The fundamental model: one meaning, several managed destinations
Imagine an international museum publishing exhibition information in English, French and Japanese. It needs a consistent exhibition title, dates, visitor rules, accessible image descriptions and the ability to update a changed closing time. The museum does not need three unrelated websites that slowly drift apart. It needs linked content structures and a disciplined process for sending approved changes to each language. AEM Sites offers a model for managing these relationships through language roots, language masters and language copies, but the museum still owns meaning and approval.
Begin by writing down the source of truth for each claim. A title may have an approved translation; a date has an authoritative schedule; an entry fee may vary by country or booking system. Translators can render the language naturally, but should not invent different opening hours. The right design distinguishes common facts, translatable prose and local information. This makes translation faster and makes future changes less risky.
Know the difference between language roots and language copies
AEM Sites organizes multilingual content using language roots. A language master contains the source material for translation; each target language needs a corresponding root for its copies. Without correct roots, automated workflows cannot be expected to identify the right language and hierarchy. For example, an English page under a language-master branch should not be translated into a random folder whose locale is inferred from its title. The structure expresses intent.
Before requesting any translation, inspect the actual content hierarchy in the Sites console. Identify the source root, the target roots, and the path where a public French or Japanese page is expected to live. Check that the language identifiers and routing conventions match the site implementation. Record the relationship between a source page and its destination, including child pages that should travel together. When a page does not appear in the expected target area, check structural preparation before asking a translator to redo the text.
Prepare a language master that can survive revisions
The source language should be stable enough to translate without becoming frozen forever. Editors often create a translation job while product teams are still rewriting the source. The translated result is then faithful to a page that no longer exists in production. A practical remedy is a source freeze for each translation batch, combined with an explicit mechanism for later corrections. This is not about delaying necessary updates; it is about knowing which revision every target version represents.
Before translation, check titles, headings, links, components, image rights, factual claims and references. Remove placeholder copy and resolve ambiguous language. If an English source says “available soon” without a date, translators may reproduce that vagueness in several markets. If it says “submit before 18:00,” clarify the timezone. Well-prepared source content is both easier to translate and easier to review. The source revision should accompany the translation request so reviewers have a precise comparison point.
Understand the Language Copy Wizard before using it at scale
Adobe’s Language Copy Wizard supports selecting source pages, choosing target languages, and creating either structure alone or a translation project. The option to include child pages is significant. Copying a parent without the needed children can leave incomplete navigation, whereas indiscriminately including an entire tree can send thousands of irrelevant pages for translation. An editor should know the intended scope before pressing Create.
Practice on a small section. In the Sites console, identify one approved source page, check whether child pages are required and select the target languages. Confirm whether the next step is structural preparation or actual translation. The wizard creates workflow objects and content relationships; it does not absolve the team of checking what was selected. Record how many pages and assets should be included, then compare that expected count with the resulting project. When a batch contains unexpected content, stop and correct the scope before commissioning or approving work.
Choose between creating structure and translating content
AEM allows content structure to be created for language copies even when translated text is not ready. This can be useful for a site migration, staged rollout or navigation planning. It also creates a dangerous possibility: stakeholders see the target hierarchy and assume the site is translated. A translated structure and a translated visitor experience are different deliverables. Treat each as a separate milestone with its own acceptance criteria.
Use structure-only creation when developers or editors need to test paths, templates and components before linguistic work begins. Do not expose these routes as finished language destinations unless the behavior is intentional and clear. For a public launch, require approved target content, accessible links and complete user journeys. Keep a report that distinguishes pages whose language-copy nodes exist, pages with translated content, pages approved for publication and pages verified in a browser. One percentage cannot represent all four states.
Configure the Translation Integration Framework carefully
The Translation Integration Framework connects AEM content workflows to translation services and determines how pages and assets are prepared for a translation provider. Different projects may use human translation, machine translation or an AI-related integration where available. The connector configuration, associated cloud configuration and translation method affect which content is sent and how results return. These settings are operational infrastructure, not simply preferences about writing style.
Ask an administrator to document the approved provider, environments, supported languages, credentials handling, data-transfer policies and failure procedures. Do not copy confidential source content into an unapproved external tool to solve a configuration problem. Confirm that the relevant source branch is associated with the intended integration configuration. If two departments use different providers or quality levels, define those boundaries explicitly. A mismatch can produce a successful job in the wrong workflow or a page that returns from a service not approved for the content’s sensitivity.
Treat translation projects and jobs as distinct records
In AEM Sites, translation projects collect resources and jobs provide the work and status information for moving those resources through translation. A project can be a long-lived governance object for a language and provider; jobs handle actual work items and updates. This distinction helps answer a common question: “The project exists, so why is my page still in English?” The project may be correctly configured while a job is incomplete, failed, unreviewed or not yet reflected in a published page.
For each batch, record the project, target language, selected resources, source revision, provider, job status and owner. When a job completes, inspect the returned content before making the public release. A status flag is evidence of workflow progress, not a guarantee of correct meaning. If a project contains the wrong pages, revise the scope through the intended controls rather than trying to fix its consequences by editing translated paragraphs one by one. Governance begins with knowing exactly what was requested.
Use human, machine and AI-assisted translation appropriately
Different text carries different risk. A brief editorial teaser may be suitable for a machine-assisted first pass followed by language review. Emergency instructions, clinical eligibility criteria, financial promises and legal consent text call for more demanding scrutiny. AEM’s translation workflows can connect different service methods, but the team must decide which review standard applies to each content class. Cheap and fast translation becomes expensive when it changes a condition the source never promised.
Develop a matrix mapping content type to allowed translation method and reviewer. For a promotional page, check tone and factual equivalence. For technical instructions, verify every step and number. For legal material, obtain domain-qualified review appropriate to the jurisdiction. Never equate a provider’s delivery with acceptance. The platform can move text and job status; it cannot determine whether the reader has understood the intended decision or whether a claim is permissible in a particular market.
Distinguish first-time translation from an update
The initial translation of a page creates a new target-language destination. A later source revision has to update an existing language copy without carelessly erasing approved local improvements. Adobe’s project guidance distinguishes creating and translating a missing page from updating language copies that already exist. That difference should shape the editorial workflow. A translation job for a change in opening hours is not identical to a new translation for a previously absent page.
Use revision comparisons. Identify what changed in the language master, what target-language content already exists and which fields were deliberately localized. If a paragraph was rewritten globally, send the changed meaning for retranslation. If an example differs legitimately by region, protect the local exception and confirm whether the change applies. Record each decision, including when a translated version remains unchanged because the source update is irrelevant. This avoids overwriting thoughtful localization during a mechanical refresh.
Understand Multi Site Manager without confusing it with translation
Adobe’s guidance makes a useful distinction: translation workflows produce content across languages, while Multi Site Manager can reuse a primary site’s content in related country or regional sites, typically within the same language. An English master may feed English variants for several countries, while a French master can feed French-language country sites. Treating every live copy as a translation or every translation as an MSM rollout obscures the real ownership of content.
Draw two dimensions on a planning sheet: language and market. Translation operates across the language dimension; regional reuse and exceptions operate within the market dimension. Define where each global fact is owned and where local teams may adapt wording, examples or offers. Avoid creating an unmanageable grid of copies that all diverge independently. The best architecture is not necessarily the one with the most reused content. It is the one where an editor knows how to correct one fact and can predict which public pages that correction will affect.
Manage blueprints, live copies and local exceptions
A live copy can inherit content from a blueprint, which reduces repeated editorial work. The danger appears when a region has an approved exception: a market-specific phone number, a tax statement, a shipping condition or a localized campaign. A global rollout may update copied material while the local team expects its exception to survive. Editors should understand rollout relationships and the intended behavior of inherited content before changing the master.
Keep a simple exception register. For each exceptional section, identify the page, locale, market, reason for divergence and local owner. Review that register before significant rollouts. A regional paragraph should not be detached merely because somebody wants a different adjective, but neither should a mandatory local warning be overwritten for global consistency. The governance question is not “Can this be synchronized?” but “Which content is allowed to change here, and who approves that change?”
Prepare reusable components for multilingual use
A modern AEM page may be assembled from text components, experience fragments, content fragments, teasers, cards and navigation elements. Their inclusion in a page does not automatically prove each has a correct translated counterpart or will be included in the relevant translation job. A landing page can look complete in an editor while a reusable quotation or promotional banner remains in English. The component model and translation rules determine the actual behavior.
Build a dependency list for the pilot page. Name each referenced fragment, asset and global interface element, then check its target-language state. Some resources should be translated once and reused; others need a separate market version because the content makes a local claim. Test both the first appearance and subsequent reuse. If a content fragment is embedded in many pages, include downstream owners in review. A single faulty shared translation may affect more public routes than a mistranslated page-specific paragraph.
Handle media and assets as part of the message
Images, PDFs, diagrams and videos are not neutral attachments. A poster may contain English text, a product diagram may label parts, or a PDF may contain a safety instruction never visible in the HTML page. AEM translation projects can include associated assets according to configuration and workflow, but editors still need to establish what the asset communicates and whether an equivalent is actually available for the target language.
Create an asset register for important pages. Record the visible caption, alt text, embedded words, source rights, translation need and target file. For an infographic, verify numerical labels and units against authoritative facts. For a video, confirm captions, dialogue and transcript requirements. For downloadable documents, test that a language-specific link retrieves the correct version rather than only displaying a localized filename. When an asset cannot be translated on schedule, communicate that limitation clearly and decide whether the page remains suitable for publication.
Write translation briefs that reduce ambiguity
A translator needs more than a list of strings. They need audience, purpose, subject context, tone, terminology, limits on change and examples of how the text appears. “Apply now” can refer to a job, scholarship, loan or product trial, each requiring different phrasing in some languages. Without context, grammatically fluent alternatives can misdirect the reader. In AEM workflows, the request is linked to content objects; the brief must still explain their meaning.
For a representative page, prepare a one-page brief stating the reader’s task, source revision, locales, approved names, prohibited edits, risk areas and where to ask questions. Include screenshots of interactive components and note when tokens or placeholders must remain intact. Encourage clarification of ambiguous source text before translation, rather than forcing a guess. The strongest briefs do not micromanage every sentence; they identify the few facts and commitments that cannot be changed and the natural tone the target audience expects.
Establish a terminology and style system
A multilingual site often contains recurring words that are not equivalent in every context: account, claim, course, plan, consent and service. Create a glossary with a source term, definition, context, target-language preference, forbidden alternative where necessary and named approver. For each locale, add examples showing correct use in a heading and sentence. A single source word can require more than one approved translation when its senses differ.
Style guidance covers capitalization, pronouns, formality, numerical presentation and how the organization addresses readers. It should also explain how to handle brand names and untranslated product identifiers. Review a small sample of returned AEM translation work against the glossary, then refine guidance before processing the full site. Language consistency is not achieved by replacing every repeated English word with one fixed target word. It comes from repeatedly expressing the same intended concept in a predictable, readable way.
Protect facts and controlled structured values
Suppose the source advertises enrollment until 12 October, a twelve-month warranty and a price that varies by market. These represent three different kinds of data. The date and warranty are fixed claims until an owner changes them; the price needs a market-specific authoritative source; surrounding explanation is translatable prose. A translation project should not decide on its own whether the number twelve becomes fourteen or whether a price should be converted.
Make a factual-control sheet covering dates, quantities, units, names, restrictions, identifiers and external references. Mark whether each value is invariant or intentionally localized. Compare the returned translation with the current authorized data before approval. When facts are stored in separate services, verify that the public AEM page is not hard-coding an obsolete value inside a translated component. This protects users from a particularly dangerous failure: polished language that confidently presents an incorrect commitment.
Review translation completeness without relying on a percentage
A project report may show that all expected text was returned while the real page still contains untranslated navigation, embedded asset labels, a missing linked fragment or an English error message. Coverage is not the same as usability. Build a completeness assessment around visible reader journeys and the content graph, not only around whether translation jobs finished. For a form-based page, the page body, required instructions, field labels, errors and confirmation must all be examined.
Use a test matrix with source URL, target URL, language, page status, referenced assets, forms, metadata and reviewer. Mark a field “intentionally shared” only with an explicit reason, not because the team ran out of time. For each language, include a deliberately missing resource case to learn how the site behaves. A clear exception log is preferable to a falsely perfect translation statistic. Users deserve to know what information they can depend on.
Check publishing beyond the translation project
A completed translation job and an approved page are prerequisites, not the finish line. Content must be released through the site’s publishing and deployment process so the public endpoint receives the intended version. Depending on the architecture, replication, caches, delivery services and frontend deployments can introduce additional checkpoints. A translated page visible in an authoring environment may still be absent or stale on the public website.
For each release, record the approved target-language path, the public URL, the publishing action and verification time. Open the URL in a fresh browsing context and compare a distinctive sentence or fact with the approved version. Check that linked resources are publicly available and not dependent on authoring permissions. If a page displays old text, determine whether the problem lies in the saved copy, publishing, delivery or caching before requesting another translation. A technical delay should not cause editorial work to be repeated.
Test language switchers and route parity
A language selector should help a visitor find the equivalent resource, not simply direct everyone to a target-language homepage. When a matching page exists, preserve the user’s context. When it does not, choose a clear, honest destination and communicate the limitation. AEM language roots make organized route planning possible, but the site’s routing and components determine actual navigation behavior.
Test the same page through direct entry, a menu, a translated internal link and the language switcher. Then test what happens when a target translation is missing. Inspect breadcrumbs, related links and search results. Do not assume that all site paths can be converted safely by replacing an English prefix with a French prefix. Some content may not exist in a market or may use a different public route. The accepted behavior must reflect actual information architecture and user expectations.
Treat multilingual SEO as a delivery responsibility
Search engines evaluate the rendered site rather than a translation project’s administrative status. Every public language version needs a suitable title, description, page language and canonical treatment. Where alternate-language annotations are used, they should connect real equivalent URLs and should not point to unpublished or unrelated content. A translated article’s search title should express what the target audience is likely to search, even if that requires a different grammatical order.
Inspect the HTML of representative pages in each language. Verify the title, meta description, canonical URL, hreflang values when implemented, indexability and language-specific sitemap entries. Confirm that internal links remain within the intended locale when appropriate. Distinguish translation from search-intent adaptation: an English keyword may not be the phrase a French reader would use. However, do not let SEO rewrites strengthen claims beyond the approved source. Meaning and accurate site behavior come first.
Make accessibility measurable in every language
Translation can break accessibility when a visible button is localized but its accessible name remains English, a screen reader receives the wrong page language, or an image description no longer corresponds to the visual. Form instructions can become longer and wrap awkwardly. Right-to-left languages add layout and directional concerns that a translation job alone cannot solve. These are design and implementation issues that need testing on the delivered page.
Choose one representative user journey per language and perform keyboard navigation, heading review, link-purpose checks, form error review and, where possible, assistive-technology testing. Inspect alt text and captions that carry essential meaning. Ensure no critical instruction is available only as text inside an untranslated image. Raise defects against the responsible component or content owner instead of hiding them under “translation polish.” A website is usable only when the intended reader can perceive and act on its information.
Use careful review for regulated and sensitive content
A page explaining medical eligibility, a financial product or a public service cannot be approved solely because a speaker finds the prose natural. Conditions, exclusions, side effects, deadlines and jurisdiction-specific obligations require specialist review. AEM’s translation workflow can move content efficiently, but it cannot grant legal or clinical authority to a translator or determine whether a marketing claim is permissible in every market.
Create a risk tier for content types. Low-risk explanatory pages can use a streamlined linguistic review; high-risk pages need source-fact verification and qualified local approval. For each sensitive statement, preserve the relationship between the translated wording and the authoritative source. If a target market requires a different statement, treat it as a controlled local adaptation with its own owner. Never silently alter a fact to make it appear culturally familiar. The point of localization is to help a reader make the right decision, not to make every market’s information look identical.
Troubleshoot a French page that still shows English fragments
Consider a French destination page whose body is translated while its hero teaser and customer quote remain English. The first question is not which translation service was used; it is where those fragments come from. They may be reusable components, content fragments, experience fragments, properties outside the translation configuration or assets containing embedded text. A job covering the main page does not prove every dependency was included.
Identify the exact component and its reference, inspect the relevant translation configuration and determine whether a target-language version exists. If one exists, check whether it is approved and published. If it does not, decide whether the content should be translated, omitted or explicitly offered as a fallback. Correct the dependency rather than pasting translated copy into a page-specific field that will later drift from the shared component. Test the original URL again after the fix, including the card’s destination.
Troubleshoot a source update that overwrites local wording
A marketing team may revise the English master and trigger an update while a regional team has intentionally adapted its own offer. A mechanically propagated change can make the regional page inaccurate or erase approved phrasing. Start by identifying whether the change belongs to global meaning, target-language translation or market-specific live-copy content. Those distinctions determine which workflow and owner should act.
Compare the old and new source versions and the current local version. Check whether Multi Site Manager rollout behavior is involved and whether a local exception has been documented. Apply global factual corrections wherever they must hold; preserve legitimate local detail where the business rule differs. For future releases, mark sensitive exceptions and require a review step before major rollouts. A change history that records both the reason and approval is far more useful than an unexplained “do not synchronize” label that nobody remembers months later.
Troubleshoot a completed job with no public translation
A translation provider returns a completed job, yet the public target page still displays old or source-language content. Possible causes include an unreviewed returned result, a target language copy not mapped to the intended path, an unpublished page, an asset omitted from release or stale content delivery. Do not send the same text for translation again before determining which boundary failed.
Trace one identifiable sentence from source revision through translation job, returned target content, approved page and public response. Inspect whether a new language copy was created when an update to an existing copy was intended. Confirm that the correct environment and URL are being tested. If the authoring copy is correct but the public response is wrong, focus on publication, delivery and cache behavior. If the target content itself is wrong, correct it with its owner. This simple chain of evidence prevents duplicate jobs and confused version histories.
Worked example: global product education across three countries
A manufacturer publishes an English safety and training guide, a French version for multiple countries and a regional Canadian French page that includes local service details. The source contains instructions, diagrams, a support number, a warranty statement and a downloadable checklist. Start by preparing the source language master and separating global facts from localized service information. Identify translation-ready pages and associated media. Decide which regional pages should inherit from a language master and which sections need deliberate local differences.
Create language copies for the intended target languages and send controlled resources through the approved translation workflow. Review technical terms, warning strength, diagrams and the downloadable document. Then use appropriate regional reuse and exceptions where required. Publish the approved content and test a complete learner journey: open the page, read a warning, download the checklist and contact the service team. Introduce a changed global instruction to test the update process. The project succeeds when future corrections can be safely propagated without altering local obligations or hiding untranslated essential material.
A four-week programme for a responsible rollout
Week one is inventory and risk assessment. Map language roots, source pages, target countries, reusable content, assets, current integration configuration and review owners. Choose a representative pilot rather than an entire department’s site. Week two is preparation and production: approve the source revision, glossary, localization brief and target language copies; launch a small translation project; inspect the returned content; and document unresolved questions.
Week three is publication and testing. Verify job completion, reviewer approval, content dependencies, public routes, alternate-language metadata, accessibility and real next actions. Week four is gradual expansion: onboard the next content set, measure defect categories, refine source writing and clarify the process for future updates. Report separately the number of destination structures created, pages translated, pages approved and public journeys verified. This makes progress visible without encouraging premature claims that a multilingual service is complete.
Frequently asked questions and practical decisions
Does the Language Copy Wizard translate everything automatically? No. It helps create structures and workflows according to settings and choices, and the resulting content still needs review and publication. Is a language copy the same as a Multi Site Manager live copy? No. Language translation and regional content reuse solve related but different problems. Can a translation project contain several resources? Yes, and the selected scope is precisely why dependency inspection matters.
Should source text be edited while a job is running? Prefer a clearly defined source revision and record urgent exceptions. What should editors do when a translated page looks right but the live site looks wrong? Compare authoring, approval, publishing and delivery states before rewriting the translation. How much review is enough? Decide by reader risk and content purpose, with qualified review for sensitive claims. A credible release means that a visitor can find correct information and complete the promised task.
Final checklist and authoritative reading
Before release, confirm that every intended target path belongs to the correct language root, the translation project includes its required resources, every material fact matches the approved source or an authorized local variant, and each critical asset is usable in the target language. Verify approval, publication, rendered HTML, language switching, accessibility, search metadata and the next action. Keep a record of what was tested and how source updates will be handled. Do not describe a structure-only copy or completed job as a finished translation.
Official AEM documentation explains the Language Copy Wizard, translation projects, MSM and translation, and multilingual translation overview. Confirm the current configuration and applicable product version before following a UI procedure. For broader principles, study The Master Art of Translation and the Translate Like a Pro index.