Triage Failed Translations Without Losing the Release

In a multilingual release, "failed" is not one condition.

The model request may have failed. The translation may be ready but unable to push to Contentful. The localized entry may be updated but not published. Grouping all three under one red status makes the dashboard simpler and the recovery work harder.

Start with the failed phase

Translation, push, and publish are separate operations with different dependencies.

A translation failure may come from a provider timeout, invalid model response, or protected-content validation. A push failure may involve permissions, field validation, or a Contentful version conflict. A publish failure may reflect entry state, environment configuration, or publishing mode.

The first triage filter should answer: which phase needs attention?

That immediately narrows ownership and next steps.

Show the scope of impact

A failed request needs enough identity to support a decision:

• entry name and ID
• source and target locale
• batch
• failed phase
• most recent error
• attempt count and last attempt time
• whether later phases ever started

Without that context, operators open each request individually and reconstruct the release by hand.

The batch view should also distinguish partial failure from total failure. If 49 of 50 locales succeeded, the team should be able to move forward with the completed work while recovering one request.

Retry from the right boundary

A retry should resume the failed phase, not repeat every successful phase before it.

If translation succeeded and push failed, preserve the reviewed translation and retry the push. If Contentful was updated and publish failed, retry publish against the current entry state.

Restarting from translation can create different copy, invalidate review, increase cost, and hide the original problem.

Phase-aware retries keep successful work stable.

Separate transient and permanent failures

Some failures are good candidates for automatic retry:

• provider timeouts
• rate limits
• short network interruptions
• recoverable version conflicts

Others need a person:

• invalid content configuration
• missing locale enablement
• permission denial
• protected structure that cannot be restored
• a target field changed after review

Retry policy should be bounded and visible. After the automatic limit is reached, the request belongs in a human queue with the last useful error intact.

Keep the failure list lightweight

Operations screens are used when something is already going wrong. They should not trigger deep CMS hydration for every row or poll so aggressively that the page creates more load than the workers it monitors.

Return stable request metadata first. Fetch full entry detail only when an operator opens the request.

Fast filtering is part of recovery.

The takeaway

A red badge is not a recovery system.

Separate failures by phase, show the affected scope, and retry only the operation that failed. Automate transient recovery within clear limits and preserve actionable errors for everything else. Teams can tolerate individual failures when the workflow makes the next decision obvious.