Priority Queues for Translation Work

Translation queues become political the moment real launch work hits them. A large batch looks efficient when it starts, but then someone needs one urgent article, one pricing correction, or one release note translated right now.

If that small request waits behind hundreds of batch items, the system is technically fair and operationally wrong.

Not all queued work has the same urgency

Batch work is usually planned. It often represents a backlog, a migration, or a known launch scope. That work matters, but it can usually tolerate steady progress.

Single-entry work is different. It is often triggered because a person is looking at a specific page and trying to finish a specific task.

That difference should be visible to the queue.

The failure mode

When every translation request enters the same lane, large batches dominate the workers. The team sees progress, but it is the wrong progress:

• planned migration items keep moving
• urgent editorial fixes wait
• translators cannot validate one page quickly
• launch teams start working around the system

Once people believe the queue is unpredictable, they stop trusting it for time-sensitive work.

The better rule: single runs first

A practical translation queue should prioritize single-entry runs ahead of batch runs. That does not mean batches never move. It means batch work uses the remaining capacity after urgent direct work has been given a chance to start.

This matches how teams actually operate. A backlog migration should not block a production correction. A broad campaign batch should not block a single page that is ready for review.

What priority should protect

Queue priority is not only about speed. It protects confidence.

When a user starts a single translation from a content detail page, they expect that action to respond quickly. If it sits behind a long-running batch, the UI feels broken even if the workers are doing exactly what they were asked to do.

The system has to preserve the relationship between user intent and visible progress.

How to keep batches healthy

Prioritizing single runs does not mean starving batches forever. The queue still needs guardrails:

• batch workers should continue when no urgent single runs are waiting
• retries should keep the priority of the work they belong to
• push and publish jobs should not be confused with translation priority
• progress reporting should make paused or waiting work obvious

The goal is not to punish batches. The goal is to stop batches from becoming a wall.

The takeaway

Queues are part of the product experience. If urgent single-entry translation waits behind a giant batch, users do not experience "background processing." They experience being blocked.

Single runs should take precedence because they usually represent active human intent. Batches can keep moving in the background, but they should not own the front of the line.