Documentation

Intermittent failure of custom PageEvent handler in bulk translation jobs in AEMaaCS

Last update: Mon May 25 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

In Adobe Experience Manager as a Cloud Service (AEMaaCS), custom post-processing for translated pages doesn’t consistently trigger after bulk translation jobs complete. As a result, alias updates and preview replication don’t run for some translated pages even though translation completes successfully. The issue occurs when custom logic fails to detect completed translations during bulk processing. To resolve the issue, detect completed translations using supported job-level APIs.

Description description

Environment

  • Product: Adobe Experience Manager as a Cloud Service (AEMaaCS) – Sites
  • Scenario: Bulk translation jobs executed using third-party translation connectors, such as Lionbridge
  • Constraints: The issue occurs intermittently and affects only specific environments, including stage and production

Issue/Symptoms

  • The alias setting isn’t applied to some translated pages after a bulk translation completes.
  • Preview replication isn’t triggered for certain translated pages.
  • The issue occurs intermittently and doesn’t affect every page within a bulk translation job.
  • All affected pages appear fully translated and display correct JCR properties.
  • The event handler and related post-processing pipeline are not invoked for the affected pages.

Resolution resolution

To resolve the issue, follow the steps below:

  1. Review the detection logic used by the custom PageEvent handler and note that the current implementation incorrectly relies on PageModification.getUserId() matching a specific service user and on detecting internal properties such as cq:translationStatus in modification paths.
  2. Be aware that on AEM as a Cloud Service, PageModification.getUserId() can return oak:unknown, making user-based checks unreliable, and that internal properties like cq:translationStatus are not consistently present in all modification events due to batching and asynchronous translation write‑back.
  3. Update the translation completion detection approach by avoiding reliance on internal or undocumented JCR properties or specific user IDs, as these mechanisms are unsupported and subject to change, and instead use supported signals such as Translation Job events together with the public Translation REST API.
  4. Detect completed translations programmatically at the page level by querying translation job status through the supported Translation REST API endpoints documented by Adobe Experience Manager APIs and using the returned job status to trigger required post‑processing actions such as alias updates or preview replication.
  5. Note that if an internal Java API is preferred over HTTP calls, no supported internal Java API currently exists for this purpose, and an enhancement request has been filed with Adobe engineering to address this limitation.
  6. Verify that after updating the detection logic to rely only on supported APIs and signals, all intended post‑processing actions run reliably following bulk translation jobs.

Notes:

  • Relying on internal JCR property changes or specific service users for event handling is unsupported and may break with platform updates.
  • The public Translation REST API currently supports out‑of‑the‑box translation projects, and support for third‑party connector projects may remain limited until future enhancements.

getTranslationJob

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f