clean up docs typos

docs/apis-tools/spring-zeebe-sdk/configuration.md

@@ -170,7 +170,7 @@ public void handleJobFoo(final JobClient client, final ActivatedJob job) {
 }
 ```
 
-Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issues command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability.
+Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issued command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability.
 
 This is why the worker above showed a different pattern (using `exceptionally`). Often, you might also want to use the `whenComplete` callback:
 

docs/apis-tools/testing/connectors.md

@@ -197,7 +197,7 @@ public class MyProcessTest {
 :::tip
 You might need to wrap the invocation of the Connector in a retry loop, for example, by using [Awaitility](http://www.awaitility.org/).
 
-There can be a delay between verifying that the Connnectors event is active and opening the Connectors inbound subscription.
+There can be a delay between verifying that the Connectors event is active and opening the Connectors inbound subscription.
 :::
 
 ## Custom Connectors

docs/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r
 
 ## The Java greenfield stack
 
-The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371).
+The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371).
 
 Use the following stack:
 
@@ -135,7 +135,7 @@ Create your **development project**
 | Application point of view on process engine | Remote Server | Library | Library |
 | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote |
 | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java |
-| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. |
+| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. |
 | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) |
 
 In essence, the general recommendation is:

docs/components/best-practices/development/invoking-services-from-the-process-c7.md

@@ -47,7 +47,7 @@ Using external tasks comes with the following advantages:
 
 - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide.
 
-- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API.
+- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API.
 
 - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually.
 
@@ -121,7 +121,7 @@ One advantage of using Java delegates is that, if you develop in Java, this is a
 
 ### General recommendation
 
-In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweights the following downsides of external tasks:
+In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweighs the following downsides of external tasks:
 
 - A slightly increased complexity for Java projects, because they have to handle separate Java clients.
 - A slightly increased overhead compared to Java delegates, as all communication with the engine is remote, even if it runs in the same Java VM.

docs/components/modeler/bpmn/user-tasks/user-tasks.md

@@ -49,7 +49,7 @@ the value of the `assignee` must be the user's **unique identifier**.
 The unique identifier depends on the authentication method used to login to Tasklist:
 
 - Camunda 8 (login with email, Google, GitHub): `email`
-- Default Basic Auth (elasticsearch): `username`
+- Default Basic Auth (Elasticsearch): `username`
 - IAM: `username`
 
 These assignees are not related to user restrictions, which is related to the visibility of the task in Tasklist for Self-Managed. For more information, see [Tasklist Authentication](/self-managed/tasklist-deployment/tasklist-authentication.md).

versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -133,7 +133,7 @@ Create your **development project**
 | Application point of view on process engine | Remote Server | Library | Library |
 | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote |
 | Programming language | Polyglot (Java, NodeJs, C#, ...) | Java | Java |
-| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. |
+| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. |
 | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) |
 
 In essence, the general recommendation is:

versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r
 
 ## The Java greenfield stack
 
-The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371).
+The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371).
 
 Use the following stack:
 
@@ -135,7 +135,7 @@ Create your **development project**
 | Application point of view on process engine | Remote Server | Library | Library |
 | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote |
 | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java |
-| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. |
+| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. |
 | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) |
 
 In essence, the general recommendation is:

versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md

@@ -47,7 +47,7 @@ Using external tasks comes with the following advantages:
 
 - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide.
 
-- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API.
+- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API.
 
 - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually.
 

versioned_docs/version-8.2/components/modeler/bpmn/user-tasks/user-tasks.md

@@ -48,7 +48,7 @@ the value of the `assignee` must be the user's **unique identifier**.
 The unique identifier depends on the authentication method used to login to Tasklist:
 
 - Camunda 8 (login with email, Google, GitHub): `email`
-- Default Basic Auth (elasticsearch): `username`
+- Default Basic Auth (Elasticsearch): `username`
 - IAM: `username`
 
 :::note