How background processing works

WordPress browser requests are too short for reliable complete-site translation. Translator creates a job, divides content into bounded text batches, processes them through the WordPress background system and saves validated checkpoints. Closing the administration page does not cancel an active job.

Read the status panel correctly

• Queued: the job exists and is waiting for the background worker.
• Running: a batch is being processed or a continuation is scheduled.
• Retry scheduled: a temporary provider/connection condition is being retried after backoff.
• Completed: validation succeeded and the target result was saved.
• Failed: the job stopped without a valid complete result; open technical details.
• Cancelled: no new batches should start, but a request already finishing may still save its validated result.

Why progress can pause

Provider latency, rate limits, a low-traffic WP-Cron site, hosting process limits, blocked loopback requests or slow database operations can delay the next callback. A percentage is not a stopwatch. Use the last-update time and retry message to distinguish normal waiting from a stalled worker.

Temporary provider errors

1. Do not create a duplicate job.
2. Wait for the displayed retry time.
3. Check provider status, billing, rate limits and model access.
4. Confirm the server can make outbound HTTPS requests.
5. If all retries fail, correct the cause and use the result card’s retry action.

Completed checkpoints are preserved. A retry should continue from safe state rather than paying to translate the entire item again.

Safe cancellation

Use Cancel when the wrong item, language or queue was selected. Cancellation is cooperative: it records the request and prevents later callbacks, but cannot reverse a provider call or database transaction completed milliseconds earlier. Always check Jobs & Logs afterward. If the result is Completed, review it normally; if it is incomplete or failed, the source remains authoritative.

Diagnose a queued job

1. Confirm WordPress Site Health does not report a loopback or scheduled-event failure.
2. Load another admin page to allow normal WP-Cron traffic.
3. On production, use a real server cron if traffic is too low for WP-Cron.
4. Check that maintenance mode, security plugins and firewalls do not block admin-ajax or REST callbacks.
5. Keep the small-run item count at one on restrictive hosting.

Diagnose a final failure

1. Open Technical details.
2. Record the safe error code and affected content ID.
3. Determine the category: licence, provider authentication, rate limit, connection, worker, validation, language or content structure.
4. Correct only that cause.
5. Retry the target translation once.
6. Preview the result before publishing.

Recovery without damaging originals

Never overwrite or delete the original to force a retry. For Polylang/WPML, remove only an incorrect target-language draft after confirming its language relationship. For TranslatePress, inspect the exact dictionary strings. Use Rebuild inventory when the list is stale; it scans state and does not edit content.

Evidence for support

• Translator, WordPress, PHP and multilingual-plugin versions.
• Content ID, source and target languages.
• Job/result ID, timestamps and safe error code.
• Whether WP-Cron and outbound HTTPS work.
• Reproducible steps.

Never send licence keys, API keys, passwords or confidential page content.