How do you translate Cloudflare Workflows documentation when a workflow has started but the student, customer or colleague is still waiting for the finished result? The answer depends on which event really happened. A created instance is not a completed instance; a durable step is not a guarantee that every external side effect happened exactly once; and a resumed workflow may still have work ahead. Technical localization must keep these distinctions visible rather than smoothing them into a reassuring but inaccurate sentence.
This guide explains how to localize Cloudflare Workflows in clear international English and other languages. It covers workflow instances, durable steps, state, retries, sleeps, waitForEvent, timeouts, deployment versions, events, status APIs, idempotency, observability and operational recovery. Developers, translators, technical writers and support teams can use the examples to preserve executable identifiers while making the business consequences understandable. Every recommendation begins with the same question: what has the platform actually confirmed?
Consider an education platform that turns an uploaded lecture into accessible notes and localized captions. A Worker creates a workflow instance, one step stores the source file, another requests transcription, and a later step waits for editorial approval. A browser might receive a successful creation response within seconds, yet the accessible package may take hours to finish. The safe public message is that processing has started. The remaining milestones must be verified separately before anyone says the resource is ready.
Quick answer: durable orchestration is not instant business completion
Cloudflare Workflows coordinates long-running processes in Workers using instances and durable operations. It can preserve progress across execution interruptions and continue a process after a sleep or awaited event. That is a major practical benefit, but it does not erase the distinction between recording workflow progress and the effect of an API request on a different system. A payment processor, media converter or email provider has its own success criteria, acknowledgments and duplicate behavior. A localized guide should name the boundary where each success was observed.
Suppose an invitation workflow starts after a tutor accepts a new class. The instance can be queued, running, waiting or complete at different times. The tutor receives a workflow identifier before anyone knows whether every invitation reached its recipient. An administrator sees an instance status that says complete, but the external messaging service may still be delivering queued messages. The application should define exactly which outcome it counts as completion.
Never turn “instance created” into “invitation delivered”, “step completed” into “student accepted”, or “workflow resumed” into “review approved”. Translate stage verbs literally and add a plain-language explanation of the business milestone. Use “accepted for processing”, “waiting for response” and “completed the configured steps” only when those claims match the evidence. Preserve product terms in configuration examples.
A good status table therefore identifies the instance ID, workflow name, current state, last successful step, pending external dependency and time of the most recent confirmed result. When drafting a reader-facing sentence, choose the most conservative true row. If business completion is a separate record, link to that record rather than inferring it from the orchestration console.
Workflow definition, entrypoint and instance are different nouns
A workflow definition describes the code and sequence of work. Its entrypoint runs when an instance executes, and an instance is an individual execution with its own identity and progress. A translation that calls all three simply “the workflow” is readable at first and confusing at the first incident. Operators need to know whether they are changing code, inspecting a particular execution or referring to the service as a whole.
Picture a publisher that processes three hundred manuscripts. One deployed workflow definition may be shared by all those processes, but each manuscript needs its own execution context. A failed export for one manuscript is not evidence that every instance is broken. Conversely, a change to the workflow code may affect future execution without rewriting the complete history of already-running instances.
Use “definition” for the executable design and “instance” for a tracked execution. Keep `run` or other exact method names unchanged inside code. If translating an operational message, prefer “instance 8a2 is waiting for approval” to “the workflow is waiting” when the precise identifier is relevant. Do not imply that a deployment update restarts every execution unless the documented version behavior and actual configuration establish that.
Review the audience’s mental model with one test: can the reader distinguish a template, a running copy and the output delivered to a student? If not, add a diagram or a three-column explanatory table. The English words can be familiar while the underlying nouns still refer to different managed objects.
Durable steps: what persistence means
The `step.do` API lets the runtime treat a named operation as a step whose progress can be durably recorded. On resumption, completed step results can be reused rather than blindly repeating all preceding work. That behavior is valuable for tasks that would otherwise have to start from the beginning after a failure. However, an external operation may commit a side effect before a step’s success is recorded, leaving a window in which a retry can occur.
For example, an order workflow calls an outside fulfillment API. The provider accepts an order, but the network connection fails before the step records success. The runtime sees an unsuccessful attempt while the warehouse sees a new order. A retry can create a second order unless the API supports a stable request identifier or the application checks existing business records.
Translate “durable” as resistance to losing recorded workflow progress, not as a magical guarantee that all linked systems complete once and only once. Preserve the terms “step”, “attempt”, “external call” and “business operation” in troubleshooting explanations. In user-facing text, say “the request may be retried” rather than “the service will never duplicate this action”.
Evidence should include the step name, step output or failure, provider request ID, idempotency key and external order ledger. Those records reveal whether a repeated call actually caused a repeated effect. An accurate localization makes the investigation possible for someone who was not involved in the original deployment.
Stable step names and code identifiers
Named steps are part of the workflow’s execution model. Their identifiers are operational labels, not decorative headings to rewrite casually. Translators can explain a step such as `generate-preview` as “generate a preview” in surrounding prose while keeping the executable name unchanged wherever it appears in code, observability records or API examples. This matters especially when readers copy instructions into deployments or search historical logs.
Imagine a troubleshooting article translated into four languages. The engineer in one region searches for `request-transcript`, but the localized guide has replaced it with a translated phrase. A human understands the sentence, yet the search fails because the machine records use the original identifier. The team wastes time looking for a step that is present but named differently in the documentation.
Keep literal strings, keys, function names, paths and identifier values unchanged in executable contexts. Put a concise gloss after the token, not in its place. Distinguish a user-visible step description from a code identifier; only the former is freely translatable. If code itself is revised, treat that as a software change requiring testing, not an editorial adjustment.
A useful editorial check compares every identifier in the translated article with the deployed code and runbook. Look for changes in hyphens, capitalization and punctuation as well as obvious synonyms. Exact identifiers are often less forgiving than ordinary readers, and the localization must serve both.
Step retries, backoff and failure categories
Workflow steps can use configurable retry policies, including limits, delays and backoff. The purpose is to recover from failures that may resolve without manual intervention. Yet not all errors are transient. A temporary upstream outage is a different problem from a malformed payload, a revoked permission or a permanently invalid destination. Sending all failures through the same repeated attempt can make incidents noisier and more expensive.
Suppose an image-rendering provider returns a temporary service error. A bounded retry may help. If the same provider rejects the request because the content format is unsupported, additional attempts with unchanged data will reproduce the rejection. A bilingual support note should describe the likely category, the actual retry configuration and the conditions for operator intervention, not offer the comforting but unearned sentence that retries guarantee recovery.
Translate “retry attempt” as an additional attempt, never as a new confirmed job. Separate retries inside a durable step from application-level replays of an entire instance. Preserve backoff units precisely; milliseconds, seconds and minutes are not interchangeable. Avoid making claims about default retry numbers when a deployment has supplied its own policy or the documentation edition has changed.
For review, list the last error class, number of attempts observed, next eligible attempt time and evidence that the upstream dependency has recovered. Say that the workflow “will try again according to its policy” only if the policy and current state support that description. More retries are not inherently more reliability.
Sleep versus sleepUntil
A workflow can pause for a relative duration using `step.sleep` or until a specified timestamp using `step.sleepUntil`. Those are different scheduling ideas. Relative waiting measures an interval from a reference point, while an absolute deadline refers to a particular instant. A translation that treats both as “wait until later” loses information needed for billing, exams, publication windows and international operations.
A global webinar workflow may sleep for two hours after a registration arrives, or pause until a scheduled UTC start time. Participants in Singapore, London and Vancouver see different local clocks for one absolute instant. Daylight-saving changes can make a translated local time ambiguous unless the offset or named time zone and date are clear. Relative intervals do not remove the need to state exactly when measurement begins.
Use “sleep for two hours” for a duration and “sleep until 2026-11-01 10:00 UTC” for a fixed instant. Do not promise millisecond-exact execution at the wake-up boundary; downstream scheduling and system load can influence when the next action actually runs. Preserve API names while explaining the user-visible timing policy separately.
A reviewer should test a sample crossing midnight, a month boundary and a daylight-saving transition. Ask whether the translated sentence would still point to the same instant in every locale. If not, the copy is too vague to be used as an operational instruction.
Waiting for an external event
The `step.waitForEvent` mechanism lets an instance suspend while expecting an event with a specified type and optional timeout. It is not the same as repeatedly polling a database, and it is not itself proof that an event will arrive. The waiting step has a name, a matching event type and a lifecycle. The external party must still send a compatible event to the correct instance.
Consider a certification workflow that must wait for an assessor to approve a portfolio. The workflow enters a waiting state and the assessor’s portal later sends an approval event. If the portal never sends that event, the workflow cannot invent the missing approval. If the payload has the wrong event type or instance identifier, it may fail to satisfy the waiting step. A human-facing status should distinguish “awaiting assessor decision” from “assessor declined”.
Translate “waiting” as a known suspended state with an unmet condition, not as an error. Preserve the configured event type literally in examples; translate its meaning next to it if needed. Do not say that a waiting instance has completed. State what system is expected to produce the event and what the workflow does if the wait ends without a match.
To verify a case, compare the instance ID, expected event type, submission time, sender authentication and event receipt evidence. This is more helpful than asking whether someone remembers clicking a button. A sound translation lets support staff explain an incomplete process without attributing blame prematurely.
Timeouts: absence of response is not rejection
A wait timeout means the configured period ended without the awaited event satisfying the step. It does not necessarily tell us whether a human rejected a request, an email was lost or a webhook failed. Treating timeout as a business rejection can have serious consequences if a student’s appeal or a customer’s approval is still pending elsewhere.
Imagine an admissions officer who approves a document shortly after the workflow’s waiting deadline. The external approval may be real, while the workflow has already taken an expiry path. The application must define whether late approval is accepted, reconciled or sent for review. The technical writer must document that policy instead of presenting timeout as a universal denial.
Use the words “timed out while waiting” when the observation is technical, and reserve “rejected” for an explicit rejection outcome from the authorized decision-maker. Describe timeout periods with units and a clear starting boundary. In translation, avoid culturally convenient phrases such as “automatically cancelled” unless cancellation truly occurred in the downstream business system.
A diagnostic note should include the expected event, deadline, actual submission time and the state of the authoritative approval record. Those four facts can reveal whether the issue is delayed communication, mismatched identifiers or policy. The localized guide should keep those questions separate.
Instances and state transitions
Cloudflare exposes instance states such as queued, running, waiting, paused, errored, terminated and complete, with other transitional states available through the platform API. A state label is evidence about the orchestration instance at a moment in time. It is not automatically an outcome label for every service the instance contacted. Localized dashboards should use the official state vocabulary consistently, explaining its scope rather than rebranding states as user achievements.
A training-material workflow may have successfully generated a document and then wait for a human review. Its status is waiting even though an earlier task succeeded. Another instance may be complete while its generated package is still queued for an external distribution system. The two products have separate status machines. Users should see the meaningful customer milestone rather than a raw state label with an exaggerated interpretation.
Keep machine statuses unchanged in logs, API examples and filter expressions. In interface prose, a localized phrase can explain “paused” or “waiting”, but avoid assigning those words the same business meaning. “Terminated” is a lifecycle state; whether it means a fee is refunded or a request withdrawn depends on the application, not the Workflows API.
Before announcing completion, inspect the instance history and the downstream output ledger. If two systems disagree, name both observations and indicate where the remaining work sits. A transparent explanation can be brief without becoming false.
Creating an instance and the response to the caller
A Worker or API client can request a new workflow instance and receive an identifier or creation response. That response confirms an orchestration action, not necessarily execution of the first step. If the system queues instances because of capacity or prioritization, there can be a meaningful interval before the work begins. International users should not be told that a result was processed simply because the request returned successfully.
An instructor submits twenty classroom videos at once. The website can acknowledge each request and show an instance ID, while the first video enters processing and others remain queued. A translation of the confirmation banner that says “all videos were translated” would be misleading and likely to cause duplicate submissions. The better banner states that the jobs were accepted and provides a separate progress view.
Use “created”, “submitted” and “queued” according to the observed stage. If the application includes its own upload validation before starting the workflow, differentiate acceptance of the source file from acceptance of the processing task. Include a retrievable identifier for follow-up when appropriate, but never expose credentials, private event payloads or sensitive customer data.
The reader should be able to answer what was accepted, whether it has started, what remains, how to check and what to do if an instance never advances. Those practical questions are more valuable than a generic promise that a cloud platform is reliable.
Events sent to a running instance
A running workflow may receive a specified external event through an instance API. The event route requires the correct workflow identity, instance identity, event type and payload shape. Developers may treat sending as a successful API operation, while a business user understands it as granting approval or completing payment. Those are not always equivalent: a request can be sent, received or acted upon at different points.
In a multilingual publisher, a reviewer presses “approve” and the portal sends an event. A network timeout occurs after dispatch. If the portal retries without checking the instance or a business record, it could create confusing audit history. The workflow’s eventual state and the review database should be correlated before support staff tell the author that approval was lost or repeated.
Translate “event sent” as the transmission stage proved by the sender, not as “workflow resumed successfully” without receiving-side evidence. Avoid translating JSON event types or payload keys that must match the receiver. Human-readable approval labels may be localized, while the permission to send them must still be controlled and audited.
For incident review, use the sender log, authenticated request identity, event type, instance timeline and corresponding approval record. This shows whether the interface, event transport, orchestration engine or downstream application needs attention. Good copy makes that chain understandable without collapsing it into one status.
Idempotency: retries cannot be allowed to duplicate business effects
Idempotency means that repeated execution of the same intended operation does not multiply its business effect. It is an application-level property created through keys, conditional updates, transaction boundaries or reconciliation, not a synonym for durable workflow state. A workflow can reliably resume and still call an external API twice in a narrow failure window. Technical localization should explain that possibility without overstating how often it occurs.
A scholarship application workflow issues a certificate when assessment succeeds. A provider writes the certificate but its response never reaches the step. The retry must be able to recognize the earlier issuance. A stable application ID, version or operation key can protect that action; a freshly generated random key on every attempt cannot represent the same logical request reliably.
Distinguish “same attempt” from “same logical job” and “same resulting artifact”. When a guide promises exactly one certificate, require evidence of an atomic uniqueness rule in the certificate store. A message platform’s acknowledgment or the workflow’s recorded step alone cannot establish that business invariant. Localized incident notices should admit uncertainty until reconciliation completes.
Review concrete duplicates by comparing provider IDs and authoritative data, not merely counting retry log lines. Sometimes three attempts produce one effect; sometimes one ambiguous attempt produces an effect followed by another effect. The difference matters far more than the word “retried” in a status banner.
Versions and deployment changes
A workflow implementation is code and its behavior can evolve. New deployments may add steps, rename labels, modify event types or change business rules. Existing instances may have recorded progress associated with earlier code and durable step names. Documentation must explain the deployed version and compatibility policy rather than treating every instance as if it were always running the latest source tree.
Imagine an international course program that changes the approval process between cohorts. The latest runbook mentions two approvals, while an older instance was created under a different procedure. A translator using the newest handbook to explain the older case could invent a missing requirement. Both the code version and the source business policy need to be identified before describing why an instance follows a particular path.
Avoid broad promises that every deployment change seamlessly migrates every in-flight execution. Record version identifiers and test upgrade scenarios with instances paused at different steps. Keep step names stable where compatibility requires it. Translate surrounding descriptions, but do not silently change literal event names, environment variables or configuration keys.
A useful support checklist asks when the instance was created, which deployment handled it, which steps had completed and whether the next expected event matches the current application. This places a troublesome instance in historical context rather than assuming user error.
Observability: traces, logs and durable history
Long-running work is difficult to explain without a timeline. Logs may describe application requests, step history may describe orchestration progress, and outside providers may supply transaction references. No single log line necessarily proves the full sequence. A localized operations guide should teach readers to join these evidence streams by stable identifiers rather than encouraging them to search for emotionally reassuring phrases such as “success”.
An accessibility-processing pipeline reports “caption task done” in its Worker logs, but the video hosting provider still displays an earlier subtitle track. The workflow may have produced the new file and requested publication, while the hosting service has not committed the update. The right investigation correlates the workflow’s generated artifact, storage object version, provider publish request and public playback state.
Maintain timestamps in a defined zone and distinguish event time from ingestion time, step start from step completion and provider acknowledgement from customer availability. Never copy tokens, private headers or student records into troubleshooting examples. Pseudonymous identifiers and synthetic payloads are enough to teach the method.
For each incident, construct a six-row timeline: submission, instance creation, first durable step, last successful step, current wait or error, and latest downstream outcome. The unanswered interval becomes visible. This is much more powerful than translating one red error label in isolation.
Security and service boundaries
Workflows commonly interact with Workers, bindings, secrets, APIs and outside services. A credential that permits an instance to call a service is not proof that the human reader has permission to view or repeat that action. Sensitive data can appear in payloads, logs or returned outputs if an application is careless. Technical localization must make permission boundaries understandable without exposing operational secrets.
Suppose an administrative approval event can authorize the publication of examination results. If a support article includes a live bearer token or a real event payload containing personal records, translation has created a security incident rather than helped the reader. The right sample uses invented IDs and describes how administrators grant the minimum permissions required.
Preserve header names and authentication method tokens exactly in runnable examples. Describe which actor authenticates, which resource it can reach and which audit trail records the action. A translated word such as “public” must not be used to describe a secret-backed endpoint merely because the user interface is on a public website.
Review security claims separately from reliability claims. Successful authentication does not guarantee business completion, and durable retries do not fix forbidden access. A precise guide shows readers when to verify authorization, when to inspect provider policy and when to escalate through an approved channel.
Cancellation, termination and compensation
An operator may terminate a workflow instance or the application may decide that the requested process should no longer proceed. Stopping future orchestration steps does not necessarily undo an external payment, uploaded file, reserved seat or message already sent. Compensation is the application-specific process of reversing or offsetting previous business effects. A translated instruction that says “cancel the workflow to refund the student” invents a guarantee unless refund logic actually runs and is verified.
Consider a class booking that takes a deposit before a tutor confirms availability. If the workflow is terminated after payment, the payment processor may still hold the transaction. The application needs an explicit refund or void action with its own status and external reference. Users should see whether their booking was cancelled, whether a refund was initiated and whether the provider settled it.
Translate “terminated” as a workflow lifecycle action and “refunded” as a separate financial outcome. The distinction also applies to file deletion, notification recall and event withdrawal. Teach readers to inspect committed external effects before deciding that termination is enough. Never use technical cancellation language as an excuse to hide irreversible side effects.
A practical recovery record includes the stopping reason, completed steps, external commitments, compensation tasks and owner of each unresolved item. This allows an international support team to respond fairly without making promises it cannot verify.
Long waits and human approval workflows
Human steps introduce deadlines, organizational policy and authority into an otherwise technical sequence. A workflow can wait successfully for an approval that is never granted, and an approver can decide outside the system without sending the expected event. Neither condition is a runtime bug by itself. In translation, distinguish a pending decision from a missing technical acknowledgment and from an explicit rejection.
In a multilingual teacher review process, one editor approves educational accuracy while another checks accessibility. If the system expects two independent events, the first approval is not proof that the material is publishable. A translated dashboard saying “approved” after the first event would remove an essential qualification. Better wording names the completed review and the one still pending.
Document who can approve, what event represents the approval, whether a decision can be reversed and how the workflow handles deadlines or duplicate submissions. Localize role descriptions for humans but keep role IDs and required event types exact. Do not silently substitute a culturally familiar approval process for the one enforced by software.
When reviewing an unexpected wait, ask what rule has not been satisfied rather than who is to blame. An actionable explanation may be as simple as “content review complete; awaiting accessibility sign-off”, but it must be backed by separate recorded decisions.
Date localization for a global audience
International instructions can fail when they mix human calendar language with machine timestamps. Cloudflare Workflows sleeps and wakes around durations and instants; readers may work in regions with different date orders, offsets and seasonal time changes. The same instant can be Thursday night in one city and Friday morning in another. An ambiguous “next Friday at ten” can produce real scheduling mistakes.
For a course launch, the orchestration might sleep until a UTC timestamp while marketing teams communicate local times. If a release is postponed, the workflow’s existing wait schedule may not automatically follow an edited announcement. Translation should differentiate the actual configured timestamp from the audience’s display conversion and the business policy that determines when content becomes public.
Include year, date, clock time and time zone in precise operational notices. Prefer ISO 8601 when providing machine values, with a local display translation in a separate clause. Never translate an absolute timestamp by simply changing the zone label without converting the time. Preserve duration units in retries and waits.
Use one deliberately difficult test case for proofing: a scheduling boundary near daylight-saving adjustment. Ask two readers in different regions what instant they believe the instruction identifies. If they disagree, revise the guidance before publication.
Monitoring large batches without overstating progress
A service may create many instances rapidly while only a subset has completed. Batch progress needs a declared denominator and a precise status definition. Saying “ninety percent complete” is meaningless unless the reader knows whether that counts created instances, steps completed, files processed or outputs delivered. A localization editor should treat each percent sign as a claim requiring a named measurement.
A research archive submits one thousand documents for conversion. Nine hundred instances have started, eight hundred have produced a draft, and seven hundred have passed quality checks. All three numbers can be true. Reporting “ninety percent published” because nine hundred started would badly misrepresent progress, particularly for stakeholders funding the project.
Use separate labels such as submitted, executing, awaiting review, failed, completed and published. Define whether terminated items remain in the denominator. A workflow-complete count may still differ from a business-complete count when distribution takes place elsewhere. The final dashboard should communicate the user’s real next action, not merely mirror an orchestration status.
When translating dashboards, verify a sample item from each displayed state against its corresponding records. This catches misleading arithmetic and status words. A useful progress page makes uncertainty visible instead of hiding it behind one large number.
Operational recovery after a failed step
A failing step may need a retry, corrected credentials, repaired external data or human intervention. Recovery must begin with the failure boundary. Recreating the entire workflow without checking prior side effects can repeat payments, emails or file operations. Equally, ignoring an instance that remains errored can leave an approved request unfinished. Neither reflex is safe.
Imagine a report generation process that fails during final upload. The generated PDF already exists in internal storage. Starting the whole process again may waste computing time and produce inconsistent versions. An operator should first determine whether the upload can be retried safely, whether the artifact is still valid and whether a previous attempt partially succeeded.
Translate an error according to its observed cause, not its perceived severity. “Permission denied” warrants an access check; “deadline exceeded” warrants a timing investigation; “invalid request” warrants payload validation. The user should not be instructed to retry forever or to create another instance until the route to a safe outcome is understood.
The recovery note should capture what can be reused, what must be redone, which action is idempotent and what evidence confirms completion. A concise incident checklist can prevent a second outage caused by an overly broad replay.
A reader-facing glossary of states and promises
An international glossary is most helpful when it defines what a word does not establish. “Created” means a tracked execution exists, not that it has run. “Queued” means pending execution, not lost. “Running” means actively progressing, not finished. “Waiting” means a condition has not been met, not that someone rejected a request. “Complete” means the configured workflow reached its completed state, not necessarily that every downstream customer-facing delivery is complete.
“Retry” means another attempt; “durable” means recorded progress survives certain interruptions; “idempotent” means repeated logical operations do not multiply the intended effect. These words often appear together, but none is a substitute for the others. “Timeout” names elapsed waiting without the expected result. “Termination” stops or ends orchestration according to the platform, but is not an automatic reversal of outside operations.
When translating these terms, prefer stable definitions and concrete examples over catchy synonyms. For example, explain waiting with a pending approval, idempotency with a duplicate certificate and compensation with a refund. Preserve API state strings exactly wherever software parses or displays them as controlled vocabulary.
A glossary should be reviewed by a developer and someone who handles customer support. The developer checks platform truth; the support reader checks whether the explanation would cause a false expectation. Both perspectives are necessary for a world-facing guide.
Case study: an international course release
Follow a complete example. A content editor submits a course. The Worker creates an instance and records its ID. A durable step validates the source package. Another step requests caption generation. The instance sleeps while a specialist checks accessibility, then resumes after an authenticated approval event. A final step publishes references to the output and records the result in the course catalogue.
At each point, the user-facing message must match the stage: “request accepted”, “package validated”, “captions processing”, “awaiting accessibility review”, “approved for publication”, and finally “published” only after the catalogue and destination agree. One stage could fail while previous stages remain valid. If a retry calls the publisher twice, application-level deduplication prevents two contradictory catalogue entries.
This case also illustrates localization boundaries. The course title and reviewer instructions can be translated. The workflow instance ID, API event type, publication key, version number and log correlation token must remain unchanged. A deadline may be displayed in a local zone but traced to a single stored instant. The reader should understand both their human task and the technical state.
To audit the case, choose one course and follow its record from original submission through final public URL. Confirm each verb with evidence. That exercise is the simplest practical test of whether the article explains real operations or merely repeats platform vocabulary.
Frequently asked questions and practical decisions
Is a completed workflow the same as a delivered email? No. The email provider and mailbox delivery system have their own lifecycle. Is a durable step exactly-once processing? Not in the universal sense of external business side effects; use application safeguards. Does a timeout mean the approver rejected a request? No. It means the specified wait expired without the expected event satisfying it.
Should translators translate `step.do` and `waitForEvent`? No: keep runnable symbols exact and explain them in surrounding language. Can a sleeping instance run more steps during its sleep interval? It is suspended until the configured condition or time. Does a successful creation response show the job is finished? No. It identifies an accepted request or created instance according to that API call.
What is the best way to describe recovery? Identify the last completed stage, the failed boundary, the safe next action and the authoritative source of business truth. Can progress percentages be localized without checking them? Only if their denominator and definition have already been established. Is a terminated workflow an automatic refund? No; refunds require their own verifiable process.
The practical conclusion is straightforward: name the exact state, explain the human consequence, preserve executable values and be cautious about outcomes outside the service. With that discipline, a technical guide remains useful in any language without turning a helpful platform capability into an exaggerated promise.
Official sources and further reading
Cloudflare Workflows: Sleeping and retrying — https://developers.cloudflare.com/workflows/build/sleeping-and-retrying/ ; Workers API and waitForEvent — https://developers.cloudflare.com/workflows/build/workers-api/ ; Workflows instance states and API — https://developers.cloudflare.com/api/resources/workflows/ . Review the documentation for the version actually deployed before relying on defaults or limits.