Background-job localization is the translation of work the user often cannot see directly. A system may be importing records, generating a report, resizing media, synchronizing accounts, rebuilding an index, sending a batch of messages or running a scheduled task after the screen that started it has already disappeared. Searches for background job localization, queue localization, scheduled task translation, retry status localization, worker job status translation and asynchronous processing UI localization all point to the same problem: language has to explain hidden execution without inventing progress, certainty or control.
Good localization for background jobs, queues and scheduled tasks preserves the operational truth of the system. “Queued”, “waiting”, “scheduled”, “running”, “paused”, “retrying”, “completed”, “partially completed”, “failed” and “cancelled” are not interchangeable labels. They describe different states, and each state can imply different next actions, billing effects, data consequences, retry rules and expectations. A fluent translation that collapses those distinctions can be more dangerous than an awkward translation because it makes the interface confidently wrong.
This guide explains how to localize background processing without hiding what is actually happening. It covers asynchronous jobs, queue position, worker ownership, scheduled execution, retries, backoff, idempotency, partial completion, cancellation, progress, timestamps, recurring jobs, rate limits, dead-letter states, notifications, logs, administrator views, user-facing status and the final release question: would a reader in the target language make the same decision about waiting, retrying, cancelling or investigating as a reader of the source?
This article belongs to eduKateSG’s Master Art of Translation architecture. It owns the language boundary around asynchronous execution and complements the existing guides for logs and observability, API limits and quotas and continuous localization pipelines rather than replacing them.
Quick answer: localize the explanation, preserve the execution model
A background job is a unit of work whose execution can be separated from the request or screen that initiated it. A queue stores work waiting for processing. A scheduler decides when work becomes eligible to run. A worker performs the work. A retry policy decides whether and when a failed attempt should happen again. Those concepts may be presented differently across products, but the localization rule is stable: translate labels and explanations while keeping state, timing, identifiers, thresholds and actions aligned with the actual system.
- Map: identify the real state machine before translating status labels.
- Protect: keep job IDs, queue names, cron expressions, timestamps, error codes and machine fields exact where they function as identifiers.
- Differentiate: preserve queued, scheduled, running, retrying, failed and cancelled as distinct states.
- Time: distinguish “starts at”, “eligible after”, “next retry”, “deadline” and “estimated completion”.
- Recover: make retry, resume, rerun and restart describe the action the system really performs.
- Verify: test the target language against real state transitions, not screenshots alone.
1. Start with the state machine, not the string list
The most important translation asset is not the glossary. It is the job lifecycle. A product may move work from created to queued to reserved to running to succeeded. Another may add delayed, blocked, retry-wait, cancelled, timed-out, dead-lettered or partially completed. If translators receive only isolated strings, two states that look like synonyms can be merged accidentally.
A practical localization brief should show each state, what event enters it, what event leaves it and what actions are permitted while the job is there. “Waiting” may mean waiting for a worker, waiting for a future scheduled time, waiting for another dependency or waiting for a manual approval. Those are different facts. Use one target term only when the user consequences are genuinely equivalent.
Verification: place every translated state back on the diagram. If two target labels become indistinguishable while the system treats the states differently, the terminology needs another pass.
2. Separate queued from scheduled
A queued job is generally eligible for a worker but has not yet been processed. A scheduled job is intentionally held until a particular time or condition. Users care about the distinction because “queued” can imply congestion while “scheduled” can imply deliberate timing.
Imagine an invoice export requested at 09:00. If it is queued, the product is saying the export is waiting its turn. If it is scheduled for 18:00, the product is saying the system plans to wait until the evening. Translating both as a generic “pending” hides the reason for the delay and can trigger unnecessary support requests.
Verification: test a target-language user view containing both states side by side and ask whether the user can explain why one might start soon while the other should not.
3. Distinguish pending from blocked
Pending is often broad. Blocked is causal. A blocked job cannot proceed because something else is missing: a dependency, approval, quota, lock, credential, source file or upstream task. The target text should preserve that causal relationship where the product exposes it.
“Waiting for approval” is better than a vague “pending” when approval is the actual gate. “Waiting for source upload” is better when the file does not yet exist. Clear localization reduces false debugging because it tells the operator whether time alone may solve the problem or whether another action is required.
Verification: remove the blocker in a test environment and confirm the wording changes when the job becomes eligible to run.
4. Treat running as a claim about execution
“Running” should normally mean some worker or service has actually begun execution. It should not be used merely because the user clicked Start. Some systems optimistically change a button label before the server accepts the work, creating a localization problem that is really a product-state problem.
Translators should ask what evidence supports the state: worker reservation, process start, lease acquisition, task heartbeat or another authoritative signal. The interface can say “Request submitted” before execution begins, then “Running” after the worker owns the job. That sequence remains clear in every language.
Verification: delay worker pickup deliberately and confirm the target language does not claim execution during the queue wait.
5. Translate progress without inventing precision
Background work often has weak progress signals. A file import may know that 40 of 100 records were read but not how expensive the remaining records will be. A report generator may know its current stage but not a meaningful percentage. Localization should not turn approximate progress into exact progress.
If the system has stage-based progress, use stage language: “Validating data”, “Processing images”, “Generating report”, “Finalizing”. If it has count-based progress, show counts. If it has trustworthy percentages, translate the label around the numeric value without changing the calculation. Avoid words equivalent to “almost done” unless the system can justify them.
Verification: compare target-language progress messages with telemetry from slow, fast and skewed workloads.
6. Keep estimated completion separate from guaranteed completion
An estimate is a forecast. A deadline is a requirement. A scheduled time is an intended start or eligibility time. A service-level target may be an operational commitment. These different time concepts are easy to flatten when translating short labels.
“Estimated to finish in 5 minutes” must remain probabilistic. Do not translate it as “will finish in 5 minutes.” Likewise, “must complete by 17:00” should not become “expected around 17:00.” The grammatical choice can change how strongly the product commits itself.
Verification: review every time-related string and classify it as actual timestamp, planned timestamp, estimate, limit, deadline or relative duration before approving the translation.
7. Preserve absolute timestamps and localize their presentation
Job systems frequently store time in UTC or another canonical form while presenting it in a user or organization time zone. The localization layer may change date order, month names, digits and time notation, but it must not move the underlying instant.
A “next run” time is especially sensitive because daylight-saving transitions can make local times ambiguous or nonexistent. Product logic should decide the instant; formatting should explain it. When a time zone matters, name it or provide enough context that the user does not interpret a local display as a global schedule.
Verification: test a recurring schedule across time-zone changes and confirm the target language reflects the same instants as the source.
8. Do not translate cron expressions as prose
Cron expressions, schedule identifiers and machine configuration values are syntax. A human explanation such as “every weekday at 09:00” may be localized, but the expression itself should remain exact unless the scheduling system explicitly defines a different localized syntax.
This distinction also applies to task names that are actually code identifiers. A visible friendly label can be translated; an identifier used in configuration, API calls or logs generally should not. Protecting the machine value makes troubleshooting possible across languages because operators can still match the UI to documentation and logs.
Verification: copy the displayed configuration from the localized interface and confirm it remains valid when pasted back into the system.
9. Explain recurring schedules in human terms
Users should not need to read cron syntax to understand a recurring task. The localized UI should convert the schedule into natural target-language phrasing while preserving frequency, days, time, time zone and exceptions.
“Every 2 weeks on Monday at 08:30” is not the same as “twice a month.” “On the last business day” is not the same as “on day 30.” Small wording changes can alter the recurrence model. If the product supports skip rules, holidays or paused intervals, those should be visible where they materially affect the next run.
Verification: generate the next five occurrences from the system and compare them with what a target-language reader would predict from the text.
10. Separate attempt from job
A single logical job may be attempted several times. The job can remain active while one attempt has failed. If localization uses “job failed” for an intermediate attempt, users may think the overall operation is over when the system is about to retry automatically.
Use wording such as “Attempt failed; retry scheduled” where the product exposes both facts. Administrator views can show attempt number, latest error and next retry time. User-facing views may simplify the detail, but they should still avoid declaring terminal failure before the retry policy is exhausted.
Verification: force a recoverable error and watch the target-language state from failed attempt through retry to eventual success.
11. Preserve retry semantics
Retry can mean automatic retry of the same job, manual resubmission, recreation of a new job or continuation from a checkpoint. These behaviors are operationally different even when the button is only one word.
The translation brief should define what Retry actually does. Does it reuse the same input snapshot? Does it re-read current source data? Does it keep the same identifier? Does it charge again? Does it start from the beginning? A target term should not imply “resume” if the system restarts from zero, or “repeat” if it continues from the last durable checkpoint.
Verification: compare before-and-after job IDs, inputs and progress when the localized Retry action is used.
12. Translate exponential backoff as policy, not mystery delay
Many systems wait longer between repeated failed attempts. Users do not necessarily need the term “exponential backoff”, but the interface should not make the increasing delay look arbitrary.
A simple message such as “Retrying automatically in 8 minutes” communicates the next action. Administrator help can explain that delays increase after repeated failures to reduce load or give an external dependency time to recover. The important invariant is the actual next retry time and whether the user needs to act.
Verification: trigger several retries and confirm the target text updates with the real delay rather than a fixed generic sentence.
13. Keep automatic retry distinct from manual retry
Automatic retry means the system will act without the user. Manual retry means the user must request another attempt. The distinction determines whether someone can safely leave the page.
Languages differ in how they mark agency, so pronouns and verb forms matter. “We’ll retry” and “Retry now” have different subjects and obligations. If the target sentence loses the actor, users may press a button unnecessarily or wait for an action that will never happen.
Verification: test both variants with the action button hidden and shown. The sentence alone should still make clear whether the system or the user acts next.
14. Make cancellation semantics explicit
Cancel can mean prevent a queued job from starting, request a running worker to stop, mark future work as unwanted while allowing the current step to finish, or disable future recurrence. Those are not the same operation.
A strong interface distinguishes “Cancel job”, “Stop after current step”, “Pause schedule” and “Disable future runs” where the backend does. If running work cannot be interrupted safely, the target language should not imply immediate termination. A confirmation dialog can explain what has already happened and what will not happen next.
Verification: cancel during queue wait, active execution and recurrence, then compare the resulting data and next-run state.
15. Treat partial completion as its own outcome
Batch jobs can succeed for some items and fail for others. A single green “Completed” message can hide missing output; a single red “Failed” message can hide useful work that was produced.
Where partial success matters, report counts and consequences: “842 records imported; 18 rejected.” Explain whether retrying processes only failed items or all items again. This is especially important when repeated processing can create duplicates, charges or side effects.
Verification: create a mixed batch with valid and invalid items and confirm the target-language summary matches the actual stored results.
16. Use idempotency language carefully
Idempotent work can be repeated without changing the result beyond the first successful application, under the conditions the system defines. That does not automatically mean every retry is harmless. Inputs may change, external services may not be idempotent and user-visible side effects may occur.
User copy should avoid promising “safe to retry” unless the product team can support that claim. Administrator documentation can be more precise: identify which operation uses an idempotency key, which window applies and what is deduplicated. Translate the explanation; preserve keys and machine identifiers.
Verification: replay the same operation under the documented conditions and inspect both the intended output and side effects.
17. Keep queue position honest
Some systems can show a queue position; others cannot because priority, multiple workers, sharding or new high-priority work can change order. Localization should not turn a soft estimate into a first-in-first-out promise.
If the backend reports “12 jobs ahead”, translate that factual count. If the product only knows “waiting in queue”, do not invent a position. If priority can reorder work, help text can explain that position may change. Users usually prefer an honest uncertainty to a precise number that repeatedly proves wrong.
Verification: submit normal and priority jobs together and observe whether the localized position language remains truthful.
18. Localize priority without turning it into social importance
Queue priority is a scheduling attribute. Terms such as high, normal and low may sound like judgments about the user or content if translated carelessly. The text should make clear that priority controls processing order or resource allocation.
Where priorities have fixed numeric values or classes, preserve the mapping. If an administrator selects “High”, the target label must correspond to the same machine value. Do not reorder dropdown items simply because another language’s adjectives sort differently unless the interface sorts semantically rather than alphabetically.
Verification: create one job at each priority and confirm the localized selector sends the intended values.
19. Explain worker ownership without exposing unnecessary internals
Operators may need to know which worker, node or region is processing a job; ordinary users usually do not. Localization should follow the audience. A support console can retain technical identifiers while a consumer interface can say simply “Processing”.
When worker names are identifiers, do not translate them. Translate labels such as “Worker”, “Assigned node” or “Last heartbeat”. If infrastructure terms are meaningful only to specialists, explain them in help text rather than replacing them with vague everyday words that lose diagnostic value.
Verification: ask whether a support engineer can match the localized interface to logs using the preserved identifiers.
20. Treat heartbeats and leases as liveness evidence
Distributed job systems often use heartbeats or leases to decide whether a worker is still alive. A stale heartbeat may cause a job to be reclaimed. These are backend concepts, but administrator interfaces sometimes expose them.
Translate them by function. “Last heartbeat 45 seconds ago” is evidence about liveness, not a human message. “Lease expires in 15 seconds” describes temporary ownership. Do not translate lease as a financial or property lease if the technical audience would misunderstand the term; a controlled glossary can preserve the domain-specific meaning.
Verification: stop a worker and confirm the target-language liveness fields move through the same stale and reclaim states as the source.
21. Keep timeout separate from failure
A timeout means the system stopped waiting after a limit. The underlying external action may or may not have completed. Treating every timeout as a simple failure can encourage unsafe retries.
Consider a payment-related background call: the client times out, but the remote service may still finish. The same pattern appears in exports, uploads and provisioning. Target-language recovery text should reflect uncertainty when it exists: “We could not confirm completion” is different from “The operation did not happen.”
Verification: simulate a response timeout after the downstream operation succeeds and confirm the localized error does not assert a false outcome.
22. Localize dead-letter and terminal states for the real audience
Jobs that exceed retry rules may be moved to a dead-letter queue or another terminal holding area for inspection. The term may be familiar to engineers but meaningless or alarming to general users.
In an operator console, preserving the established technical term with a concise explanation can be appropriate. In a customer view, “Needs attention” or “Could not be completed” may be clearer if it maps to the same underlying terminal condition. Do not use euphemism if action is required; the language must still communicate that automatic processing has stopped.
Verification: exhaust retries and confirm the target interface stops promising another automatic attempt.
23. Preserve error codes and localize the explanation around them
Error codes help support teams correlate user reports with logs and documentation. They should generally remain stable across locales. The human explanation, suggested action and contextual labels can be translated.
A good pattern is “Import failed — E1427 — Source file no longer available.” The code remains searchable; the explanation becomes readable. If codes are not public, the product can expose a correlation ID instead. Either way, avoid translating or reformatting machine identifiers as if they were ordinary prose.
Verification: copy the code from the localized UI and find the same incident in support tooling.
24. Keep job IDs, correlation IDs and queue names exact
Identifiers provide continuity across UI, logs, APIs and support tickets. Translating them can break that continuity. Even capitalization changes can matter in systems that treat identifiers as case-sensitive.
Make the visual distinction clear: labels translate, values do not. “Job ID” can become the standard target-language label, while `job_7H4K2` remains exact. The same rule applies to queue names when they are configuration identifiers rather than friendly display names.
Verification: copy identifiers from the target-language interface into API or log search and confirm they resolve correctly.
25. Coordinate queue status with rate limits and quotas
A job may wait because the queue is busy, because a tenant has reached a concurrency limit or because an external API is throttling requests. Those reasons have different recovery paths. Linking everything to “system busy” hides actionable information.
Where appropriate, explain the constraint: “Waiting for available processing capacity”, “Paused until API quota resets”, or “Concurrency limit reached”. This article’s scope is the job state; the detailed policy belongs in the existing API rate-limit and quota localization guide.
Verification: trigger each kind of constraint and confirm the target text identifies the correct cause without exposing misleading implementation details.
26. Write notifications from authoritative job state
Email, SMS and push notifications may arrive after the user leaves the application. They should be generated from the authoritative current state, not from a stale assumption captured when the job began.
Suppose a job fails, retries and then succeeds before a delayed push notification is sent. A notification saying “Your export failed” becomes wrong. The localization team should ask whether messages are event-based or state-based and whether delayed delivery can create contradictions. If needed, wording can include the relevant timestamp or final state.
Verification: delay notification delivery while forcing rapid state changes, then inspect what the target-language user actually receives.
27. Keep administrator controls distinct from user controls
Administrator consoles may expose force retry, requeue, release lock, move to another queue, discard, replay or edit schedule. These actions can be destructive or operationally significant. Consumer-facing labels should not be reused automatically.
Translate each admin action from its actual backend behavior. “Requeue” may preserve the job record and return it to eligibility; “rerun” may create a new job; “replay” may reuse an event payload. A glossary that treats all three as “retry” creates avoidable operational mistakes.
Verification: record the before-and-after state for every localized admin action in a non-production environment.
28. Translate batch controls around scope
Bulk actions introduce scope risk. “Retry failed” may mean all failed jobs in the current filter, selected rows only, the current page or one tenant. The target language must preserve that scope.
Confirmation messages can restate the object and count: “Retry 18 selected jobs?” is safer than “Retry all?” when the selection model is complex. If filters remain active, the product should make that visible. Translators should test pluralization with real runtime counts rather than static examples.
Verification: select subsets under filters and confirm the localized confirmation count matches the objects that will actually be affected.
29. Keep recurring task history separate from schedule definition
A recurring task has at least two kinds of information: the rule that creates future runs and the history of individual runs. Changing the schedule should not rewrite the meaning of past executions.
The interface can say “Schedule: every day at 02:00” and separately list “Run 14: completed at 02:07”. If the schedule is changed to 03:00, past entries should remain understandable. Target-language labels should help users distinguish the template from the instances it produced.
Verification: change a schedule after several runs and confirm the localized history still represents past facts accurately.
30. Handle paused schedules as future-state control
Pausing a recurring schedule usually affects future creation or execution, not necessarily a job already running. If the translation implies the current job stops immediately, users may assume work or charges have ceased when they have not.
Use confirmation copy that states the boundary: “Pause future runs. The current run will continue.” If the system behaves differently, say so. The key is to describe exactly what is frozen: schedule trigger, queue dispatch, worker execution or user-visible recurrence.
Verification: pause while a run is queued and while one is actively running, then compare behavior with the target-language promise.
31. Design empty states that explain why no jobs appear
An empty jobs table can mean no jobs have ever existed, filters exclude all jobs, the user lacks permission, the date range is empty or data has not loaded. One generic “No jobs” translation cannot cover every cause safely.
Use contextual empty states: “No jobs in this date range”, “No failed jobs”, “No jobs match these filters”. If permission limits visibility, avoid implying the system contains no work. Clear empty-state localization helps operators trust the interface rather than wonder whether data disappeared.
Verification: test each empty-state cause separately and confirm the target message identifies the actual condition.
32. Preserve accessibility during live status updates
Background-job screens often update without a full page reload. Screen readers need meaningful announcements, but announcing every percentage change can become overwhelming.
Localize concise state changes that matter: queued to running, running to completed, retry scheduled, action required. Use accessible names that include enough context to distinguish several jobs. Translation length matters because verbose live-region text can interrupt users repeatedly.
Verification: run representative jobs with a screen reader and listen to the target-language announcement sequence from start to terminal state.
33. Make support escalation language evidence-based
“Contact support” should not appear simply because a job takes longer than average. It should appear when the product has evidence that user action or support investigation is appropriate.
Good recovery copy can include what to provide: job ID, time, source object or error code. It can also say when waiting is appropriate: “Retry is scheduled automatically; no action is needed.” This reduces duplicate requests and helps support teams receive usable evidence when escalation is necessary.
Verification: review support guidance against each terminal and non-terminal state to make sure the localized call to action is neither premature nor missing.
34. Use one terminology system across UI, email, logs and help
A user may see “queued” in the app, “pending” in email, “waiting” in documentation and “ready” in a support screenshot. Even if the source product has drifted, translation should not multiply the confusion.
Build a compact state glossary tied to backend meanings, then map each surface to it. Some technical logs may keep internal terms, but user-facing materials should explain how those terms correspond. Consistency is especially valuable in incidents because people move quickly between interfaces while trying to understand what happened.
Verification: search the target locale across product strings, help centre, notification templates and operator UI for competing terms for the same state.
35. Test state transitions, not static screenshots
A screenshot captures one state. Background processing is a sequence. Many serious localization failures occur at the transition: the label changes too early, the notification arrives too late, the retry timer uses the wrong unit or a cancelled job still displays a success action.
Create test scenarios that force transitions deliberately. Slow a worker, inject a recoverable failure, exhaust retries, cancel at several stages, pause a schedule, change time zone and create partial success. Watch the target-language UI from beginning to end. The test should answer not only “is every string translated?” but “does the story told by the interface remain true as the system changes?”
Verification: record the target-language transition sequence and compare each message with authoritative backend state.
A repeatable background-job localization workflow
The strongest workflow starts from operational truth and moves outward to language. It avoids the common mistake of translating the string catalogue first and discovering only later that the same English word represented several backend states.
- Draw the lifecycle for one representative job from creation to terminal state.
- List all states, transitions, actions and timing fields.
- Mark machine identifiers and configuration syntax as protected.
- Separate user-facing language from operator-only terminology.
- Define retry, resume, rerun, replay, cancel and pause from actual behavior.
- Map time values to their semantics: schedule, estimate, timeout, deadline or retry.
- Create examples for success, partial success, recoverable failure and terminal failure.
- Translate with enough context to preserve agency and certainty.
- Exercise plural rules for job counts, item counts and attempt counts.
- Run live state-transition tests in each target locale.
- Compare UI, notifications, support text and operator terminology.
- Add failures found in production to a regression set.
Worked scenario 1: a report export waits, runs, retries and succeeds
A user requests a large report. The application immediately creates job `report_84K2`, but all workers are busy. The correct initial message is “Queued” or an equivalent target-language term that says the work is accepted and waiting. It is not “Running” because no worker has started. It is not “Scheduled” because there is no intentional future start time.
Two minutes later a worker claims the job. The interface changes to “Generating report”. That is a stronger claim: execution has begun. After processing several sections, the worker encounters a transient storage error. The first attempt fails, but the job policy schedules another attempt in 60 seconds. The customer view says “Retrying automatically” and shows the next attempt time. The operator view can additionally show attempt 1 of 4 and the error code.
The second attempt succeeds. The final message is “Report ready” with the actual completion time. A poor localization could have told the user “Report failed” during the intermediate error, encouraging a duplicate manual request. The stronger localization tells one coherent story: accepted, waiting, processing, temporarily interrupted, retrying, completed.
Worked scenario 2: a recurring import is paused during an active run
An administrator has a nightly inventory import scheduled for 01:00. At 01:05 the current run is still processing. The administrator selects Pause schedule because tomorrow’s source feed is expected to be invalid. The schedule control should explain that future runs are paused while the current run continues unless the product explicitly supports interrupting it.
The localized confirmation might say: “Pause future inventory imports? The run that started at 01:00 will continue.” This sentence protects three facts: the object being changed is the schedule, the effect applies to future runs and the active job is unaffected. A generic translation of “Pause” that sounds like immediate execution suspension would be operationally wrong.
After confirmation, the schedule status becomes Paused and the current run remains Running. Its history later records Completed. The next-run field should not show a misleading future timestamp while the schedule is paused; it may instead say “No next run while paused”.
Worked scenario 3: a batch import partially succeeds
A customer imports 1,000 records. Nine hundred and seventy-eight are valid; twenty-two fail validation. If the product says “Import failed”, the user may repeat all 1,000 records and create duplicates. If it says “Import completed”, the user may never notice the missing records.
The stronger summary is explicit: “978 records imported. 22 could not be imported.” The action should match the backend. If Retry failed records processes only the twenty-two rejected items, say so. If the system requires the user to fix a file and upload it again, do not call the action Retry because the workflow is different.
Localization should also preserve number formatting and plural rules without changing counts. A target language with several plural categories may need different grammatical forms for 1, 2, 5 and 22 records. Runtime message formatting should handle those variants rather than concatenating translated fragments.
Worked scenario 4: a timeout leaves the outcome uncertain
A background task sends a request to an external service. The local worker waits thirty seconds and times out. The external service might still be processing. The interface must not translate the timeout into a definite statement that “nothing happened” unless the system has another source of truth.
A safer message is “We could not confirm completion. Check status before retrying.” If the product has an idempotency key and can safely poll the downstream service, the recovery can be more automated. The localization should follow that actual recovery model, not generic assumptions about what timeout means.
This is a good example of why translation quality depends on systems knowledge. The sentence is short, but the right wording comes from understanding uncertainty, duplicate side effects and the evidence available to the application.
Release checklist for background-job localization
- Every visible state maps to one defined backend state or controlled group of equivalent states.
- Queued and scheduled are distinct where the product treats them differently.
- Running is not shown before execution actually starts.
- Progress wording matches the quality of available progress data.
- Estimates are not translated as guarantees.
- Timestamps preserve the same instants across locales and time zones.
- Cron expressions, IDs, codes and configuration values remain exact.
- Attempt failure is distinguished from terminal job failure.
- Automatic and manual retry remain distinct.
- Retry, rerun, resume and replay match real backend behavior.
- Cancellation wording states what stops and what may continue.
- Partial completion is visible when it changes the user’s next action.
- Queue priority and position are described without false promises.
- Timeout text preserves uncertainty when the downstream outcome is unknown.
- Dead-letter or terminal states stop promising automatic recovery.
- Notifications are consistent with authoritative state at send time.
- Bulk-action scope and counts are clear.
- Recurring schedule history remains distinct from the schedule definition.
- Live status changes are usable with assistive technology.
- Target-language transition tests cover success, retry, cancellation and failure.
Frequently asked questions
Is “pending” a good universal translation for background work?
Usually not. Pending can hide whether work is queued, deliberately scheduled, blocked, awaiting approval or waiting for a retry. If those states lead to different user expectations or actions, preserve the distinction in the target language.
Should queue names be translated?
Friendly display names can be translated when they are presentation-only. Configuration identifiers used by workers, APIs, logs or documentation should remain exact. If both exist, translate the label and preserve the machine value.
What is the difference between retry and rerun?
There is no universal product definition, so localization must follow the system. Retry often means another attempt of the same logical job; rerun often suggests starting the operation again. Some products use the words differently. Define the backend behavior first, then choose target terminology.
Can a failed attempt belong to a job that has not failed?
Yes. A job can remain active while one attempt fails and an automatic retry is scheduled. Customer-facing copy should avoid declaring terminal failure until the policy says no further automatic recovery will occur.
How should “cancel” be translated?
Translate the actual effect. If cancel prevents a queued job from starting, say that. If it merely requests a running worker to stop when safe, avoid wording that promises immediate termination. If it disables future recurrences, make the future scope explicit.
Should progress percentages always be shown?
No. Show percentages only when the system can calculate them meaningfully. For uneven work, stage labels or processed-item counts may be more truthful. Localization should never add precision the backend does not have.
Why are timeout messages difficult to translate?
Because a timeout describes the observer’s limit, not necessarily the downstream outcome. If the system cannot confirm whether the remote action completed, the target language must preserve that uncertainty rather than convert it into a definite failure claim.
What should be tested first?
Test the lifecycle, not isolated strings. Force one job through queue wait, running, recoverable failure, retry and success; then force another through cancellation and terminal failure. If the target-language sequence remains coherent and truthful, the terminology is much more likely to be sound.
Final principle: hidden work still needs visible truth
Background processing is invisible by design, which makes language unusually important. The interface becomes the user’s window into work that may be happening on another process, another machine, another region or at another time. When the wording is vague, the user fills the gap with assumptions.
Professional localization therefore begins with the execution model. Preserve state, actor, timing, scope, uncertainty and recovery. Translate the explanation so it feels natural in the target language, but never make the job more complete, more certain, more immediate or more controllable than the system really is. That is how a multilingual product keeps asynchronous work understandable without turning invisible execution into invisible risk.