Fix typos in .NET, PHP, Ruby SDK documentation (#4255)

bechols · claude · brianmacdonald-temporal · web-flow · commit 2a014ead09c4 · 2026-03-02T14:03:00.000-05:00
* Fix typos in .NET, PHP, Ruby SDK and top-level develop documentation

Co-Authored-By: Claude Opus 4.6 (1M context) &lt;noreply@anthropic.com&gt;

* Update docs/develop/php/core-application.mdx

---------

Co-authored-by: Claude Opus 4.6 (1M context) &lt;noreply@anthropic.com&gt;
Co-authored-by: Brian MacDonald &lt;brian.macdonald@temporal.io&gt;
diff --git a/docs/develop/activity-retry-simulator.mdx b/docs/develop/activity-retry-simulator.mdx
@@ -8,7 +8,7 @@ tags:
 ---
 
 Use this tool to visualize total Activity Execution times and experiment with different Activity timeouts and Retry Policies.
-For a list of Activity Task Execution times, use [this calculator](https://temporal-time.netlify.app/?initialInterval=1&maxInterval=100&maxReties=10&backoffCoeificent=2).
+For a list of Activity Task Execution times, use [this calculator](https://temporal-time.netlify.app/?initialInterval=1&maxInterval=100&maxReties=10&backoffCoefficient=2).
 
 The simulator is based on a common Activity use-case, which is to call a third party HTTP API and return the results.
 See the example code snippets below.
diff --git a/docs/develop/dotnet/core-application.mdx b/docs/develop/dotnet/core-application.mdx
@@ -114,7 +114,7 @@ Here are some known gotchas to avoid with .NET tasks inside of Workflows:
 
 In order to help catch wrong scheduler use, by default the Temporal .NET SDK adds an event source listener for info-level task events.
 While this technically receives events from all uses of tasks in the process, we make sure to ignore anything that is not running in a Workflow in a high performant way (basically one thread local check).
-For code that does run in a Workflow and accidentally starts a task in another scheduler, an `InvalidWorkflowOperationException` will be thrown which "pauses" the Workflow (fails the Workflow Rask which continually retries until the code is fixed).
+For code that does run in a Workflow and accidentally starts a task in another scheduler, an `InvalidWorkflowOperationException` will be thrown which "pauses" the Workflow (fails the Workflow Task which continually retries until the code is fixed).
 This is unfortunately a runtime-only check, but can help catch mistakes early. If this needs to be turned off for any reason, set `DisableWorkflowTracingEventListener` to `true` in Worker options.
 
 In the near future for modern .NET versions we hope to use the
@@ -247,7 +247,7 @@ Technically this can be multiple parameters, but Temporal strongly encourages a
 
 Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition).
 The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
-This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
+This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed]) in your Workflow Execution Event History.
 
 A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations.
 Activity implementation code should be _idempotent_.
@@ -285,7 +285,7 @@ These values are set in the Activity Options.
 
 **How to get the results of an Activity Execution using the Temporal .NET SDK**
 
-The Activity result is the returned in the task from the `ExecuteActivityAsync` call.
+The Activity result is returned in the task from the `ExecuteActivityAsync` call.
 
 ## Run Worker Process
 
diff --git a/docs/develop/dotnet/debugging.mdx b/docs/develop/dotnet/debugging.mdx
@@ -20,7 +20,7 @@ tags:
 This page shows how to do the following:
 
 - [Debug in a development environment](#debug-in-a-development-environment)
-- [Debug in a development production](#debug-in-a-development-production)
+- [Debug in a production environment](#debug-in-a-development-production)
 
 ### Debug in a development environment {#debug-in-a-development-environment}
 
@@ -30,9 +30,9 @@ In developing Workflows, you can use the normal development tools of logging and
 In addition to the normal development tools of logging and a debugger, you can also see what’s happening in your Workflow by using the [Web UI](/web-ui) or [Temporal CLI](/cli).
 The Web UI provides insight into your Workflows, making it easier to identify issues and monitor the state of your Workflows in real time.
 
-### Debug in a development production {#debug-in-a-development-production}
+### Debug in a production environment {#debug-in-a-development-production}
 
-**How to debug in a development production using the Temporal .NET SDK**
+**How to debug in a production environment using the Temporal .NET SDK**
 
 You can debug production Workflows using:
 
diff --git a/docs/develop/dotnet/index.mdx b/docs/develop/dotnet/index.mdx
@@ -159,13 +159,13 @@ Configure and use the Temporal Observability APIs.
 
 - [Emit Metrics](/develop/dotnet/observability#metrics): Each Temporal SDK is capable of emitting an optional set of
   metrics from either the Client or the Worker process.
-- [Set up Tracing](/develop/dotnet/observability#tracing): Explains how the Go SDK supports tracing and custom context
+- [Set up Tracing](/develop/dotnet/observability#tracing): Explains how the .NET SDK supports tracing and custom context
   propagation.
 - [Log from a Workflow](/develop/dotnet/observability#logging): Send logs and errors to a logging service, so that when
   things go wrong, you can see what happened.
 - [Use Visibility APIs](/develop/dotnet/observability#visibility): The term Visibility, within the Temporal Platform,
   refers to the subsystems and APIs that enable an operator to view Workflow Executions that currently exist within a
-  Terminal Service.
+  Temporal Service.
 
 ## [Debugging](/develop/dotnet/debugging)
 
diff --git a/docs/develop/dotnet/message-passing.mdx b/docs/develop/dotnet/message-passing.mdx
@@ -320,7 +320,7 @@ To send an Update to a Workflow Execution, you can:
     wf => wf.SetCurrentLanguageAsync(GreetingWorkflow.Language.Chinese));
   ```
 
-- 2. Use `StartUpdateAsync` to receive a handle as soon as the Update is accepted.
+2. Use `StartUpdateAsync` to receive a handle as soon as the Update is accepted.
      It returns an `UpdateHandle`
 
   - Use this `UpdateHandle` later to fetch your results.
@@ -714,7 +714,7 @@ When working with Updates, you may encounter these errors:
 - **No Workflow Workers are polling the Task Queue**:
   Your request will be retried by the SDK Client indefinitely.
   Use a `CancellationToken` in your [RPC options](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowUpdateOptions.html#Temporalio_Client_WorkflowUpdateOptions_Rpc) to cancel the Update.
-  This raises a [Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException.html) exception .
+  This raises a [Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException.html) exception.
 
 - **Update failed**: You'll receive a [`Temporalio.Exceptions.WorkflowUpdateFailedException`](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateFailedException.html) exception.
   There are two ways this can happen:
diff --git a/docs/develop/dotnet/observability.mdx b/docs/develop/dotnet/observability.mdx
@@ -241,5 +241,5 @@ var myTextAttributeKey = SearchAttributeKey.CreateText("MyTextAttribute");
 // Add/Update the keyword one and remove the text one
 Workflow.UpsertTypedSearchAttributes(
     myKeywordAttributeKey.ValueSet("SomeKeywordValue"),
-    myTextAttrbiuteKey.ValueUnset());
+    myTextAttributeKey.ValueUnset());
 ```
diff --git a/docs/develop/dotnet/schedules.mdx b/docs/develop/dotnet/schedules.mdx
@@ -31,9 +31,9 @@ This page shows how to do the following:
 
 **How to Schedule a Workflow using the Temporal .NET SDK**
 
-Scheduling Workflows is a crucial aspect of any automation process, especially when dealing with time-sensitive tasks. By scheduling a Workflow, you can automate repetitive tasks, reduce the need for manual intervention, and ensure timely execution of your business processes
+Scheduling Workflows is a crucial aspect of any automation process, especially when dealing with time-sensitive tasks. By scheduling a Workflow, you can automate repetitive tasks, reduce the need for manual intervention, and ensure timely execution of your business processes.
 
-Use any of the following action to help Schedule a Workflow Execution and take control over your automation process.
+Use any of the following actions to help Schedule a Workflow Execution and take control over your automation process.
 
 ### Create a Scheduled Workflow {#create-a-workflow}
 
diff --git a/docs/develop/dotnet/temporal-client.mdx b/docs/develop/dotnet/temporal-client.mdx
@@ -438,7 +438,7 @@ public static class LoadFromFile
 
 <TabItem value="code" label="Code">
 
-You can also provide connections options in your Go code directly. To create an initial connection, provide the
+You can also provide connections options in your .NET code directly. To create an initial connection, provide the
 Namespace and API key values to the ` TemporalClient.ConnectAsync` method.
 
 ```csharp
diff --git a/docs/develop/dotnet/temporal-nexus.mdx b/docs/develop/dotnet/temporal-nexus.mdx
@@ -396,7 +396,7 @@ See the [Nexus cancellation sample](https://github.com/temporalio/samples-dotnet
 
 ## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud}
 
-This section assumes you are already familiar with how  to connect a Worker to Temporal Cloud.
+This section assumes you are already familiar with how to connect a Worker to Temporal Cloud.
 The `tcld` CLI is used to create Namespaces and the Nexus Endpoint, and mTLS client certificates will be used to securely connect the caller and handler Workers to their respective Temporal Cloud Namespaces.
 
 ### Install the latest `tcld` CLI and generate certificates
diff --git a/docs/develop/php/asynchronous-activity-completion.mdx b/docs/develop/php/asynchronous-activity-completion.mdx
@@ -32,8 +32,8 @@ Calling `yield` on promise blocks until a result is available.
 > Activity promise also exposes `then` method to construct promise chains.
 > Read more about Promises [here](https://github.com/reactphp/promise).
 
-Alternatively you can explicitly wrap your code (including `yield` constucts) using `Workflow::async` which will execute nested code in parallel with main Workflow code.
-Call `yeild` on Promise returned by `Workflow::async` to merge execution result back to primary Workflow method.
+Alternatively you can explicitly wrap your code (including `yield` constructs) using `Workflow::async` which will execute nested code in parallel with main Workflow code.
+Call `yield` on Promise returned by `Workflow::async` to merge execution result back to primary Workflow method.
 
 ```php
 public function greet(string $name): \Generator
diff --git a/docs/develop/php/core-application.mdx b/docs/develop/php/core-application.mdx
@@ -253,7 +253,7 @@ The `#[ActivityInterface("file_activities.")]` is an attribute that tells the PH
 
 Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition).
 The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
-This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
+This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed]) in your Workflow Execution Event History.
 
 A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations.
 Activity implementation code should be _idempotent_.
@@ -393,9 +393,9 @@ A Worker Entity contains a Workflow Worker and/or an Activity Worker, which make
 The [RoadRunner application server](https://roadrunner.dev/) will launch multiple Temporal PHP Worker processes based on provided `.rr.yaml` configuration.
 
 Each Worker might connect to one or multiple Task Queues.
-Worker poll _Temporal service_ for tasks, performs those tasks, and communicates task execution results back to the _Temporal service_.
+Workers poll the _Temporal Service_ for tasks, perform those tasks, and communicate task execution results back to the _Temporal Service_.
 
-Worker code are developed, deployed, and operated by Temporal customers.
+Worker code is developed, deployed, and operated by Temporal customers.
 To create a worker use `Temporal\WorkerFactory`:
 
 ```php
@@ -435,7 +435,7 @@ You can configure task queue name using first argument of `WorkerFactory`->`newW
 $worker = $factory->newWorker('your-task-queue');
 ```
 
-As mentioned precedingyou can create as many Task Queue connections inside a single Worker Process as you need.
+As mentioned preceding, you can create as many Task Queue connections inside a single Worker Process as you need.
 
 To configure additional WorkerOptions use `Temporal\Worker\WorkerOptions`:
 
@@ -509,5 +509,5 @@ If you want to clean up some resources after activity is done, you may register
 after each activity invocation:
 
 ```php
-$worker->registerActivityFinalizer(fn() => $kernel->showtdown());
+$worker->registerActivityFinalizer(fn() => $kernel->shutdown());
 ```
diff --git a/docs/develop/php/debugging.mdx b/docs/develop/php/debugging.mdx
@@ -19,7 +19,7 @@ tags:
 
 In addition to the normal development tools of logging and a debugger, you can also see what's happening in your Workflow by using the [Web UI](/web-ui) or [Temporal CLI](/cli).
 
-### How to debug in a development production {#debug-in-a-development-production}
+### How to debug in a production environment {#debug-in-a-development-production}
 
 You can debug production Workflows using:
 
diff --git a/docs/develop/php/enriching-ui.mdx b/docs/develop/php/enriching-ui.mdx
@@ -136,7 +136,7 @@ All Workflow details support standard Markdown formatting (excluding images, HTM
 
 ### Event History
 
-Individual events in the Workflow's Event Gistory display their associated summaries when available.
+Individual events in the Workflow's Event History display their associated summaries when available.
 
 Workflow, Activity and Timer summaries appear in purple text next to their corresponding Events, providing immediate context without requiring you to expand the event details. 
 When you do expand an Event, the summary is also prominently displayed in the detailed view.
diff --git a/docs/develop/php/message-passing.mdx b/docs/develop/php/message-passing.mdx
@@ -81,7 +81,7 @@ interface FileProcessingWorkflow
 Note that name parameter of Workflow method attributes can be used to specify name of Workflow, Signal and Query types.
 If name is not specified the short name of the Workflow interface is used.
 
-In the precedingcode the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`.
+In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`.
 
 ### How to handle a Signal {#handle-signal}
 
@@ -253,7 +253,7 @@ interface FileProcessingWorkflow
 Note that name parameter of Workflow method attributes can be used to specify name of Workflow, Signal and Query types.
 If name is not specified the short name of the Workflow interface is used.
 
-In the precedingcode the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`.
+In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`.
 
 ### How to handle a Query {#handle-query}
 
@@ -773,7 +773,7 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount
   You'll receive a [`ServiceClientException`](https://php.temporal.io/classes/Temporal-Exception-Client-ServiceClientException.html) in case of a server connection error.
   [How to configure RPC Retry Policy](/develop/php/temporal-client#configure-rpc-retry-policy)
 
-- **RPC timout**:
+- **RPC timeout**:
   You'll receive a [`TimeoutException`](https://php.temporal.io/classes/Temporal-Exception-Client-TimeoutException.html) in case of an RPC timeout.
   [How to configure RPC timeout](/develop/php/temporal-client#configure-rpc-timeout)
 
diff --git a/docs/develop/php/temporal-clients.mdx b/docs/develop/php/temporal-clients.mdx
@@ -17,7 +17,7 @@ description: Connect a Temporal Client to a Temporal Service and start Workflow
 This guide introduces Temporal Clients.
 It explains the role and use of Clients and shows you how to configure your PHP Client code to connect to the Temporal Service.
 
-The pages shows how to do the following:
+This page shows how to do the following:
 
 - [Connect to a local development Temporal Service](#connect-to-a-dev-cluster)
 - [Connect to Temporal Cloud](#connect-to-temporal-cloud)
diff --git a/docs/develop/plugins-guide.mdx b/docs/develop/plugins-guide.mdx
@@ -345,7 +345,7 @@ The Replayer allows Workflow authors to validate that their Workflows will work
 
 The Replayer runs on a Workflow History created by a previous Workflow run. Suppose something in the Workflow or underlying code has changed in a way which could potentially cause a non-determinism error. In that case, the Replayer will notice the change in the way it runs compared to the history provided. 
 
-The Replayer is typically configured identically to the Worker and client. Ff you’re using `SimplePlugin`, this is already handled for you.
+The Replayer is typically configured identically to the Worker and client. If you’re using `SimplePlugin`, this is already handled for you.
 
 If you need to do something custom for the Replayer, you can configure it directly. Here's an example of how to do that with Python:
 
diff --git a/docs/develop/ruby/failure-detection.mdx b/docs/develop/ruby/failure-detection.mdx
@@ -132,8 +132,6 @@ result = my_client.execute_workflow(
 A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience.
 
 Use a [Retry Policy](/encyclopedia/retry-policies) to automatically retry Workflow Executions on failure.
-Workflow Executions do not retry by default.
-
 Workflow Executions do not retry by default, and Retry Policies should be used with Workflow Executions only in certain situations.
 
 The `retry_policy` can be set when calling `start_workflow` or `execute_workflow`.
diff --git a/docs/develop/ruby/index.mdx b/docs/develop/ruby/index.mdx
@@ -160,13 +160,13 @@ Configure and use the Temporal Observability APIs.
 
 - [Emit Metrics](/develop/ruby/observability#metrics): Each Temporal SDK is capable of emitting an optional set of
   metrics from either the Client or the Worker process.
-- [Set up Tracing](/develop/ruby/observability#tracing): Explains how the Go SDK supports tracing and custom context
+- [Set up Tracing](/develop/ruby/observability#tracing): Explains how the Ruby SDK supports tracing and custom context
   propagation.
 - [Log from a Workflow](/develop/ruby/observability#logging): Send logs and errors to a logging service, so that when
   things go wrong, you can see what happened.
 - [Use Visibility APIs](/develop/ruby/observability#visibility): The term Visibility, within the Temporal Platform,
   refers to the subsystems and APIs that enable an operator to view Workflow Executions that currently exist within a
-  Terminal Service.
+  Temporal Service.
 
 ## [Debugging](/develop/ruby/debugging)
 
diff --git a/docs/develop/ruby/message-passing.mdx b/docs/develop/ruby/message-passing.mdx
diff --git a/docs/develop/ruby/temporal-client.mdx b/docs/develop/ruby/temporal-client.mdx
diff --git a/docs/develop/ruby/versioning.mdx b/docs/develop/ruby/versioning.mdx
