Background-job localization is state-machine localization. When work happens asynchronously, the user cannot see the worker, queue or scheduler directly. The translated status becomes the interface to reality: queued, scheduled, running, retrying, paused, cancelled, failed or complete. If those states blur together, users can duplicate work, cancel the wrong task or wait for a retry that will never happen.
Searches for background job localization, queue status translation, scheduled task localization, job retry localization, async processing translation, cron schedule localization, worker queue UI and job status internationalization point to one requirement: translate the human explanation while preserving the exact state, timing, attempt count and machine identity of the work.
This guide explains how to localize background jobs, work queues and scheduled tasks without hiding what is running, waiting, retrying or failed. It covers finite states, retries and backoff, recurrence, cron syntax, progress, partial success, cancellation, queue priority, dependencies, time zones, errors, notifications, permissions, accessibility and lifecycle QA.
This article extends eduKateSG’s Master Art of Translation architecture. It is intentionally narrower than the existing owners for telemetry, notifications, RBAC, status pages and general software localization.
Quick answer
Treat a job as a structured object with a stable ID and real state. Localize the label and explanation around that state; do not invent or merge states for fluency. Protect schedule syntax, queue keys, error codes and identifiers. Make retry, cancellation and partial-success semantics explicit because those are the moments when language can cause duplicate or lost work.
- State: map translations to real backend states, not generic adjectives.
- Time: preserve schedule instants, recurrence rules and time zones.
- Retry: say whether retry is automatic, scheduled or manual.
- Scope: explain whether cancel or retry affects the whole job or only part of it.
- Evidence: keep IDs, error codes and audit events stable across locales.
Why asynchronous work is a localization problem
Background work separates the user’s action from the system’s completion. A person can press “Import”, “Generate report” or “Send campaign” and leave the page while processing continues elsewhere. That means translated status text becomes the user’s only window into a state machine they cannot directly see.
If “queued”, “running”, “retrying”, “scheduled”, “paused”, “cancelled”, “failed” and “completed” drift into loose synonyms, users can take the wrong action. They may submit a duplicate job, cancel work that is almost complete, or assume a failed job will automatically retry. Localization must preserve operational state, not merely emotional tone.
Model jobs as stateful objects
A job should have a stable identity and structured state before any human-facing text is generated. Useful fields can include job ID, type, creator, creation time, scheduled time, current status, attempt count, progress, queue, priority, result location and error code. Localization renders those fields; it should not infer them from prose.
This architecture also helps when the same job appears in a dashboard, notification, audit log and support conversation. The human sentence can change language while the underlying job ID and state remain the same. A multilingual team can therefore discuss one job without relying on translated wording as the identifier.
Define a finite status vocabulary
Start with the real application states, not a generic translation list. One system may distinguish created, queued, reserved, running, waiting on dependency, retry scheduled, succeeded, failed, cancelled and expired. Another may have only pending, processing and done. The localization glossary should match the actual state machine.
Avoid adding semantic precision that the backend does not possess. If the system only knows “processing”, the translation should not claim that a file is currently uploading, validating or indexing. Conversely, do not collapse distinct states when users need to act differently. A failed job and a retry-scheduled job are not the same outcome.
Queued is not the same as scheduled
A queued job is normally eligible to run when a worker becomes available, while a scheduled job is intentionally held until a defined future time or condition. Translating both as “waiting” hides the reason for the delay.
The interface should communicate whether the user needs to do anything. “Queued — waiting for capacity” and “Scheduled for 09:00 UTC” describe different expectations. When a scheduled time is shown, localize the date and time presentation while preserving the actual instant and time zone.
Running is not necessarily progressing
A job can be marked running even when its work is blocked on an external service, a database lock or a long computation. Progress percentages can also be estimates rather than exact measurements. Localized copy should not promise steady progress unless the system can support that claim.
Use neutral state language when progress is indeterminate. A spinner labelled “Working” may be more accurate than “50% complete” if the backend cannot calculate a denominator. If a job is waiting on another system, distinguish that condition so users know the worker has not simply stopped.
Retries need attempt-level meaning
Retry language is especially easy to mistranslate. “Retrying” can mean the system will make another attempt automatically, that a retry is scheduled later, or that the user must press a button. Those are different contracts.
Expose the actor and timing when possible: “Retry 2 of 5 will start in 30 seconds”, “Automatic retries exhausted”, or “Retry manually”. Preserve the attempt count and any backoff interval as structured values. Never let a target-language verb imply user action when the system will act automatically, or vice versa.
Backoff is a behavior, not just a delay
Many job systems increase the delay between repeated failures. Kubernetes Jobs, for example, expose retry limits and backoff behavior rather than treating every failure as an immediate final state. A product may implement a different policy, but the localization problem is the same: the user needs to understand whether another attempt is expected.
Do not translate “backoff” literally if that would be meaningless to the audience. Describe the effect in plain language: the next automatic attempt will occur after a delay. Keep the technical term in developer-facing documentation when it is part of the API or configuration model.
Attempt count and failure count are not always identical
Some systems count retries, some count total attempts, and some count failed executions. A label such as “3 retries” can be ambiguous if the original run is included in the number. Localization should preserve the source definition and, when possible, phrase the UI in terms of a concrete sequence such as “Attempt 3 of 4”.
This matters in support and billing contexts. Users may be charged per run, per task or per processed item. A translated counter that changes the counting model can create disputes even if the underlying system behaved correctly.
Scheduled tasks need a time-zone rule
Recurring jobs introduce date and time complexity. “Every day at 09:00” is incomplete unless the product defines which time zone controls the schedule. The account time zone, user time zone, resource-region time zone and UTC can all differ.
Show the governing time zone near the schedule. If the system adjusts for daylight-saving time, document that behavior. If the schedule is UTC-based, do not translate it into a local clock time without also preserving the source instant. The user should be able to predict the next run from the localized interface.
Recurrence language must preserve the actual rule
Natural-language schedules can hide important distinctions: every weekday, every five business days, every Monday, every 24 hours and once per calendar day are not equivalent. The translation should be generated from or validated against the structured recurrence rule.
For complex schedules, pair a friendly sentence with a precise next-run preview. “Runs every Monday at 09:00” becomes easier to trust when the interface also shows the next date and time. This catches both translation errors and schedule-parsing errors before they affect production work.
Cron expressions and schedule syntax are machine data
Developer and admin tools may expose cron expressions or other scheduling syntax. Strings such as 0 9 * * 1 are configuration, not prose. Do not translate tokens, spacing or field order.
The surrounding help can be localized. Explain what each field means, show an interpreted preview and state which cron dialect the product uses if relevant. The safe pattern is the same as with API identifiers: keep the machine expression exact and translate the human explanation around it.
Queue names may be identifiers or labels
A queue called critical-email may be an internal routing key, while “High priority” may be a display label. Localizers need to know which kind of string they are handling. Renaming an identifier can send work to nowhere; leaving a user-facing label untranslated can make the dashboard difficult to use.
Store machine queue names separately from localized display names. If support teams refer to the machine name, consider showing it in secondary text. The user can read the queue naturally while still providing the exact identifier when troubleshooting.
Priority words need product definitions
High, normal and low priority sound intuitive, but the actual scheduling effect may be subtle. “Urgent” might mean a separate queue, a higher numeric weight or merely a visual flag. Translation should not intensify or weaken the guarantee.
Document what priority controls. If it changes ordering but not a completion deadline, avoid language such as “immediate”. If the system uses service levels, link the priority label to the defined policy rather than letting translators invent expectations from everyday meanings.
Cancellation must say what can still happen
Cancelling a queued job is usually straightforward, but cancelling a running job may be best-effort. A worker could already have sent messages, written records or created files before it receives the cancellation signal. “Cancelled” can therefore refer to future work, not necessarily a rollback of completed effects.
Localized confirmation text should explain the boundary: cancel remaining work, stop after the current item, or request cancellation. If partial side effects remain, say so. Do not use “undo” unless the system actually reverses the completed operation.
Pause and cancel are different controls
A paused queue intends to resume later. A cancelled job is normally terminal. Translation that uses one word for both can be costly because users may expect a cancelled import or campaign to continue when the queue reopens.
Show the future expectation. “Paused — can be resumed” and “Cancelled — will not resume automatically” remove ambiguity. If administrators can pause an entire queue while individual jobs remain queued, keep queue state and job state visually distinct.
Expired and timed out are not the same as failed
A job can fail because its work encountered an error, time out because it exceeded a duration limit, or expire because it was never started before a deadline. These states may lead to different retry and support actions.
Preserve the cause category. A localized “failed” bucket may be convenient visually, but detailed screens should retain the specific terminal reason when the backend provides it. Users can then decide whether to retry, extend a timeout, change a schedule or correct the input.
Dependencies create waiting states
Complex workflows often contain jobs that cannot start until other jobs finish. “Waiting” in this context is not queue congestion; it is dependency state. Show the dependency name or condition when that helps the user.
If a prerequisite fails, the downstream job may become blocked, skipped or cancelled. Those terms should map to explicit workflow semantics. “Skipped” can mean intentionally not run, while “blocked” can mean still eligible if the dependency changes. The translation should preserve that distinction.
Batch jobs need item-level outcomes
A batch can partially succeed. For example, 9,800 of 10,000 records may import correctly while 200 fail validation. A single translated status of “completed” or “failed” hides useful information.
Expose total, succeeded, failed, skipped and pending counts as structured values. Use clear labels and preserve number formatting without changing the mathematics. The overall job can be complete while containing failed items; the interface should say so rather than forcing one emotional status over a mixed result.
Progress bars need a defined denominator
A percentage is meaningful only when the system knows what 100 percent represents. It might represent items processed, bytes uploaded, stages completed or estimated time. Localization cannot fix a misleading metric, but it can avoid making the metric sound more precise than it is.
When progress is based on stages, use stage names as well as the percentage. When the denominator can grow, consider an indeterminate state. The user should never interpret a translated label as a guarantee that completion time is proportional to the visible percentage.
Results and artifacts need stable identity
Completed jobs often produce files, reports, exports, models or other artifacts. The result link should be bound to the job ID and artifact ID, not reconstructed from translated filenames or titles.
Localize the display name and explanatory text while preserving the underlying resource. If an artifact expires later, show that retention period and date clearly. A user who returns in another locale should still reach the same result or receive the same expiry explanation.
Error codes should remain exact
Developer-facing background systems frequently attach an error code, exception class or worker message to a failed job. Machine codes belong in a protected field. Translators can explain the problem but should not alter the diagnostic token.
This mirrors the existing eduKateSG owner for logs, telemetry and error-code localization. The job guide owns the state and recovery path; the observability guide owns diagnostic presentation in depth.
Retry buttons should be explicit about scope
A “Retry” action might retry the entire job, only failed items, the current stage or a single attempt. The localized label should make scope obvious when the difference matters.
For batch work, “Retry 200 failed items” is safer than a generic “Retry” if repeating successful items would create duplicates. For workflows with side effects, the confirmation can warn that the operation may not be idempotent. Localization should preserve the same caution as the source rather than smoothing it away.
Idempotency changes the risk of retries
Some jobs are designed so that repeating the same request produces the same end state. Others may send a second email, charge again, create a duplicate record or append data twice. The user interface should not encourage blind retries when repetition can have side effects.
If the product knows an idempotency key or deduplication policy, describe retry safety in the appropriate developer documentation. In user-facing copy, state whether repeating the job can create additional effects. The translation should not convert “may create duplicates” into a vague “try again”.
Dead-letter queues need terminal language
Some systems move repeatedly failing messages or jobs into a dead-letter queue for later inspection. This is not the same as an ordinary queued retry. The work has been removed from the normal processing path because the configured failure policy was reached.
User-facing language should explain whether the item will remain there until an administrator re-drives, repairs or deletes it. The technical queue name can remain unchanged while the interface uses a clear localized label. A vague status such as “waiting” would falsely imply normal processing will eventually continue.
Duplicate delivery needs explicit semantics
Distributed queue systems may deliver the same message more than once even when the user created one logical job. Applications often defend against this with idempotency, deduplication or state checks. Localization should not turn an implementation detail into a misleading user count.
If the dashboard reports attempts, distinguish them from logical jobs. “Three attempts for one job” is different from “three jobs”. This matters when users investigate duplicate side effects and when support staff compare UI history with worker logs.
Worker ownership should not be confused with user ownership
A job can have a human creator and a current worker, executor or node. Those are different identities. Translating both fields as “owner” makes operational dashboards harder to interpret.
Use role-specific labels: submitted by, created by, assigned worker, processing node or service account as appropriate. Protect machine worker IDs and hostnames while localizing the explanatory labels. A global team should be able to see who requested the work and which system component executed it.
Retention of job history needs clear dates
Platforms often delete old job records, logs or downloadable artifacts after a retention period. A completed job can therefore remain visible after its result file has expired, or disappear entirely from the dashboard while business data remains elsewhere.
Translate retention language precisely: what is deleted, when, and whether the user can extend or export it. Show an absolute expiry date when that helps. Do not use broad phrases such as “kept for a while”, especially when job history is needed for audit or troubleshooting.
Notifications must reflect the final job state
Email, SMS or push notifications can arrive after the user has left the job page. They should identify the same job and use the same status vocabulary as the dashboard. A translated notification that says “completed” while the dashboard says “completed with errors” creates avoidable confusion.
Include job name, time and a stable link or identifier where appropriate. The existing eduKateSG guidance on transactional messages covers channel constraints; the job article ensures the state conveyed through those channels remains correct.
Audit history should record who changed the job
Scheduling, cancellation, manual retry, priority change and queue pause are administrative actions. Preserve actor, timestamp, job ID and action type as structured audit data, then localize the readable event description.
This allows a global operations team to reconstruct what happened even when members use different interface languages. A localized sentence can say “Aisha cancelled job 8124”, while the underlying event remains machine-comparable across regions and locales.
Permissions must not masquerade as job states
A button can be disabled because a job cannot be retried in its current state, because the user lacks permission, or because the feature is unavailable. Those are different reasons and should not all become “Unavailable”.
Tell the user whether the limitation is state-based or access-based. This is another place to cross-link the RBAC localization owner rather than expanding the job article into a permissions manual.
Queue dashboards need stable filtering and sorting
Operations teams filter by status, owner, queue, date, priority and job type. Localized labels can change sorting order without changing the underlying filter values. The system should apply filters to structured fields, not translated strings.
Test multi-select filters, saved views and bookmarked URLs after language changes. A saved filter for failed jobs should remain the same logical query even if the displayed word for “failed” changes. This protects monitoring workflows that users build over time.
Pagination and live updates need state continuity
A busy queue can change while the user is viewing it. Jobs move from queued to running to complete, and new rows appear. Localization should not reset filters or selection when the table refreshes.
Keep row identity bound to job IDs. If a translated status label becomes longer and changes layout, ensure it does not cause users to click the wrong row during a live update. Real-time UI behavior is part of localization quality because visual instability can change operator actions.
Long-running tasks need honest time estimates
Products often show “a few minutes”, “about one hour” or estimated completion times. These estimates may depend on queue load and job size. Translators should preserve uncertainty instead of making the time sound guaranteed.
If the estimate is generated numerically, localize the duration format and pluralization. If it is a qualitative band, use controlled wording. Avoid adding culturally reassuring phrases such as “soon” when the source does not promise it.
Scheduled maintenance can affect jobs without failing them
A queue may be paused during maintenance, causing jobs to wait longer without being failed. The status should distinguish platform maintenance from job-level errors so users do not repeatedly resubmit work.
Link to a service-status explanation when relevant. The existing eduKateSG status-page localization guide owns public incident wording; the job UI should consume that status without rewriting its meaning.
Worked example: a CSV import
A user uploads a CSV and sees “Queued”. Five minutes later it becomes “Running — 4,200 of 10,000 rows processed”. The worker encounters 50 invalid rows but continues, finishing with 9,950 imported and 50 rejected. The job itself is complete, yet the result contains errors.
A strong localization shows both levels: “Completed with 50 errors” plus a downloadable rejection report. It does not call the whole operation “failed”, because most data imported successfully, and it does not call it simply “successful”, because action is still required on the rejected rows.
Worked example: a scheduled report
An administrator schedules a report for every Monday at 09:00 in the organisation’s time zone. The schedule page shows the governing time zone and the next run. A daylight-saving transition changes the UTC offset but not the intended local wall-clock time.
The translation should preserve that recurrence model. If the interface language changes, the schedule remains attached to the same zone and next-run instant. A localized date format can change; the underlying schedule cannot.
Worked example: automatic retry
A data export fails because an external storage service returns a temporary error. The platform schedules another attempt in two minutes. The correct status is not simply “Failed”. It is “Retry scheduled” or an equivalent phrase that tells the user another attempt is expected.
If all retries are later exhausted, the state becomes terminal and the action changes. The interface can then offer manual retry or support guidance. The translated words should track that change so the user does not intervene too early or wait forever for a retry that will never happen.
Worked example: cancellation with partial side effects
A messaging job has already sent 3,000 of 10,000 notifications when the user requests cancellation. The worker stops after the current batch. The interface should not imply the 3,000 sent messages were undone.
A precise status might say “Cancelled after 3,000 messages sent”. The remaining count helps the user understand the effect. A generic translated “Cancelled successfully” is technically true but operationally incomplete.
Test the job lifecycle end to end
Localization QA should create real jobs and move them through every reachable state: queue, schedule, start, pause, retry, partial success, failure, cancellation and completion. Inspect the visible UI, notifications, audit log and API values.
Use jobs with short and long names, large counts, zero counts, one item and multiple items to catch pluralization and layout defects. Switch languages while a job is running and confirm that its ID, progress and state persist. The question is not whether every string reads well in isolation; it is whether the lifecycle remains understandable.
Test race conditions and fast state changes
Some jobs move through states so quickly that users may only glimpse a label. Others update while a confirmation dialog is open. A cancellation request can race with completion. A retry can begin before the page refreshes.
QA should simulate these edges. If a job finishes before cancellation is accepted, the target-language message should explain the final state rather than showing contradictory success banners. State-driven copy must be resilient to asynchronous reality.
Accessibility needs full state information
Screen readers should receive the job name, status and meaningful progress without being flooded by every refresh. An accessible live region may announce major transitions such as queued to running or running to failed while quieter percentage updates remain available on demand.
Translated accessible names must match the visible semantics. If a visual icon means paused, the accessible label should not say stopped. Keyboard users should be able to reach retry, cancel and result actions in a predictable order even when translated buttons become wider.
Right-to-left layouts can expose queue UI defects
Queue tables often combine status text, timestamps, numbers, IDs and progress bars. In right-to-left interfaces, machine identifiers and numeric values need directional isolation so they remain readable and copyable.
Test pagination arrows, progress direction, timeline order and icon placement. A mirrored layout should not imply that a job sequence itself has reversed. Preserve chronological meaning even when the visual flow changes.
Use official platform concepts without copying platform-specific rules
Kubernetes documents Jobs with completion, failure and retry concepts, including backoff limits. Other job systems implement different semantics. The useful lesson for localization is not that every product should copy Kubernetes wording; it is that job state and retry policy are structured system behavior.
Build the translation around your product’s real implementation. Reference authoritative technical documentation internally when a UI exposes platform-specific fields. A vendor-neutral public explanation can then teach the general localization method without pretending all queues behave identically.
Common failure patterns
Typical defects include translating queued as scheduled, translating retrying as failed, hiding attempt counts, changing a cron expression, using the same word for pause and cancel, promising an exact completion time from an estimate, calling a partial success fully successful, or offering a retry that repeats already-completed side effects.
These failures emerge when language is detached from state. The repair is architectural: finite status values, structured timestamps and counters, stable job IDs, protected machine syntax, explicit action scope and end-to-end lifecycle testing.
How this guide fits the wider translation architecture
Background-job localization touches notifications, status pages, logs, permissions, data tables and API documentation. Those topics already have specialist owners in the eduKateSG translation architecture. This guide owns the asynchronous work state itself: what is running, waiting, retrying, scheduled or terminal.
Keeping that boundary clear avoids duplication and makes internal links useful. A reader can follow outward for observability, RBAC or notification details while this article remains the practical owner for queues, scheduled tasks and job-state language.
Operating checklist
Define the actual job state machine. Separate queued from scheduled. Separate running from waiting. Preserve attempt counts, retry policy and terminal reasons. Protect job IDs, queue keys, cron expressions and error codes. Make time zones explicit. Clarify whether cancellation is best-effort. Expose partial results. Bind filters to structured values. Keep notifications and audit logs aligned with the same states.
Then test real jobs in every supported locale. Switch languages mid-run, trigger retries, cancel at awkward moments, exhaust retry limits, run mixed-result batches and verify the backend state against every visible message. A translation is complete only when the user can operate the asynchronous system correctly without seeing the source language.
FAQ
Is queued the same as scheduled? No. Queued normally means eligible to run when capacity is available; scheduled means intentionally held until a future time or rule.
Should cron expressions be translated? No. They are machine syntax. Translate the explanation and preview, not the expression.
What does retrying mean? It should mean exactly what the product implements: another automatic attempt is in progress or planned. If the user must act, use different wording.
Can a completed job still contain errors? Yes. Batch work can finish with some failed items, so show both job completion and item-level outcomes.
What is the highest-risk wording? Cancellation, retry and partial-success language because each can cause duplicate work or incorrect assumptions about side effects.
Conclusion
Professional localization of background work turns an invisible state machine into understandable language without changing the machine. Job IDs, schedules, counters, error codes and retry rules remain stable; labels, explanations and recovery guidance become natural in the target language.
The standard is practical: a user should know whether work is waiting, scheduled, running, blocked, retrying, complete, partially complete or terminally failed, and should know what action is safe next. When those distinctions survive translation, queues and scheduled tasks remain dependable even when the work continues long after the original click.