Translation Statuses Should Answer the Next Question

Translation systems produce plenty of state. Jobs queue, providers respond, drafts save, Contentful updates, entries publish, and retries start.

Showing all of that activity does not automatically make progress clear.

A useful status should answer the next question the editor has.

One request has several lifecycles

A multilingual request often moves through three main phases:

1. translate
2. push
3. publish

Each phase can be idle, queued, working, successful, skipped, or failed. Compressing those states into a single word loses important information.

"Completed" could mean the translation draft is ready for review, the target locale was written to Contentful, or the entry is live. Those are materially different outcomes.

The interface should name the phase and its state together.

Status and action belong together

Editors read status to decide what they can do next.

• A ready translation can be reviewed.
• An approved translation can be pushed.
• A successful push can be published.
• A transient failure can be retried.
• Active work may be cancellable.

If the available action does not match the displayed state, the product feels inconsistent. A publish button beside a request that never pushed is not merely confusing; it weakens trust in the underlying workflow.

The backend should determine availability from durable state and permissions, then the UI should reflect that decision consistently.

Progress counts need a stable denominator

Batch progress becomes misleading when each phase uses a different total without explaining it.

A batch with ten translation requests may have ten translations, eight pushes, and six publishes because some locales were review-only or automation was disabled.

Progress should distinguish:

• total requests
• requests eligible for the current phase
• completed, active, failed, and skipped requests

Skipped is especially important. It is a terminal decision, not unfinished work.

Preserve history without crowding the screen

The current state should stay compact, but operators still need history when something goes wrong.

An expandable event timeline can show when the request queued, which attempt failed, whether an automatic retry ran, and when Contentful accepted the update. That supports debugging without turning every table row into a log viewer.

Use human language for the main status and retain technical identifiers and timestamps in the detail view.

Terminal states should stay terminal

Polling and realtime events can arrive out of order. An older "working" event must not move a completed request backward. A refreshed page should not temporarily show queued after the database already records success.

State transitions need ordering and idempotency. The interface should merge updates using the authoritative timestamp or version, not simply accept the last message delivered to the browser.

The takeaway

Status design is part of the workflow, not decoration around it.

Separate translation, push, and publish phases. Pair each state with the action it enables, count skipped work honestly, and keep a detailed history close by. The best status is the one that makes the next decision clear.