Feature/fix typos

content/en/documentation/for-adopters/data-plane/_index.md

@@ -15,7 +15,7 @@ the data consumer. This section provides an overview of how data planes work and
 
 Although a data plane can be collocated in the same process as a control plane, this is not a recommended setup. Typically,
 a data plane component is deployed as a separate set of instances to an independent environment such as a Kubernetes cluster.
-This allows the data plane to be operated and scaled independently from the control plane. At runtime, a data plane must
+This allows the data plane to be operated and scaled independently of the control plane. At runtime, a data plane must
 register with a control plane, which in turn directs the data plane using the *Data Plane Signaling API*. EDC does not
 ship with an out-of-the-box data plane. Rather, it provides the *Data Plane Framework (DPF)*, a platform for building
 custom data planes. You can choose to start with the DPF or build your own data plane using your programming language

content/en/documentation/for-adopters/extensions/_index.md

@@ -76,7 +76,7 @@ The SPI pattern is further used to define *extension points*. An extension point
 
 ### Providing and Injecting Services
 
-The EDC module system assembles extensions into a runtime by wiring services to `ServiceExtensions` that require them and initialing the latter.  An extension can *provide* services that are used by other extensions. This is done by annotating a factory method with the `org.eclipse.edc.runtime.metamodel.annotation.Provider` annotation:
+The EDC module system assembles extensions into a runtime by wiring services to `ServiceExtensions` that require them and instantiating the latter.  An extension can *provide* services that are used by other extensions. This is done by annotating a factory method with the `org.eclipse.edc.runtime.metamodel.annotation.Provider` annotation:
 
 ```java
 public class SampleExtension implements ServiceExtension {
@@ -334,7 +334,7 @@ The EDC eventing system is a powerful way to add capabilities to a runtime. All
 - Contract negotiations
 - Transfer processes
 
-To receive an event, register and `EventSubscriber` with the `org.eclipse.edc.spi.event.EventRouter`. Events can be received either synchronously or asynchronously. Synchronous listeners are useful when executed transactionally in combination with the event operation. For example, a listener may wish to record audit information when an `AssetUpdated` event is emitted. The transaction and asset update should be rolled back if the record operation fails. Asynchronous listeners are invoked in the context of a different thread. They are useful when a listener takes a long time to complete and is fire-and-forget.
+To receive an event, register an `EventSubscriber` with the `org.eclipse.edc.spi.event.EventRouter`. Events can be received either synchronously or asynchronously. Synchronous listeners are useful when executed transactionally in combination with the event operation. For example, a listener may wish to record audit information when an `AssetUpdated` event is emitted. The transaction and asset update should be rolled back if the record operation fails. Asynchronous listeners are invoked in the context of a different thread. They are useful when a listener takes a long time to complete and is fire-and-forget.
 
 ### Monitor
 

content/en/documentation/for-adopters/identity-hub/_index.md

@@ -109,7 +109,7 @@ Many organizations prefer to manage identity resources centrally, as strict secu
 
 ### Per Dataspace Component
 
-Some organizations may prefer to manage their identity resources at the dataspace level. For example, a multinational may participate in multiple regional dataspaces. Each dataspace may be geographically restricted, requiring all data and resources to be regionally fenced. In this case, an Identity Hub can deployed for each regional dataspace, allowing for separate management and isolation.
+Some organizations may prefer to manage their identity resources at the dataspace level. For example, a multinational may participate in multiple regional dataspaces. Each dataspace may be geographically restricted, requiring all data and resources to be regionally fenced. In this case, an Identity Hub can be deployed for each regional dataspace, allowing for separate management and isolation.
 
 ### Embedded
 
@@ -166,7 +166,7 @@ When a key pair is created, it is not yet used to sign resources. When a key pai
 
 For security reasons, key pair resources should be periodically rotated and replaced by new ones. Identity Hub supports a staged rotation process to avoid service disruptions and ensure that existing signed resources can still be validated for a specified period.
 
-For example, let's assume private key A is used to sign Credential CA and public key A' is used to verify CA. If the key pair A-A' is immediately revoked, CA can no longer be validated, which may cause a service disruption. Key rotation can be used to avoid this. When the key pair A-A' is rotated, a new key pair, B-B', is created and used to sign resources. The private key A is immediately destroyed. A', however, will remain as a verification method in the DID document associated with the participant context. CA validation will continue to work. When CA and all other resources signed by A expire, A' can safely be removed from the DID document.
+For example, let's assume private key A is used to sign Credential CA and public key A' is used to verify CA. If the key pair A-A' is immediately revoked, CA can no longer be validated, which may cause a service disruption. Key rotation can be used to avoid this. When the key pair A-A' is rotated, a new key pair, B-B', is created and used to sign resources. The private key A is immediately destroyed. A', however, will remain as a verification method in the DID document associated with the participant context. CA validation will continue to work. When CA and all other resources signed by A expires, A' can safely be removed from the DID document.
 
 > It's important to perform key rotation periodically to enhance overall system security. This implies that signed resources should have a validity period less than the rotation period of the key used to sign them and should also be reissued on a frequent basis.
 

content/en/documentation/for-adopters/issuer-service/_index.md

@@ -104,7 +104,7 @@ This enables the IssuerService to link additional data to the holder, which may
 `credentialSubject` of the Verifiable Credential. Furthermore, the IssuerService can enforce that only known holders are
 allowed to request credentials.
 
-There may, however, be use cases where is is _not_ necessary, or even desirable, to pre-register holders in the
+There may, however, be use cases where it is _not_ necessary, or even desirable, to pre-register holders in the
 IssuerService. In such cases, the IssuerService can be configured to allow anonymous credential requests, i.e., holders
 can simply make a CredentialRequest without being pre-registered in the IssuerService.
 
@@ -244,7 +244,7 @@ Please check out the full [OpenAPI specification of the IssuerService Administra
 
 ## Deployment Options
 
-As all other EDC components, the IssuerService is comprised of a set of Java modules that can be packaged and deployed
+As all other EDC components, the IssuerService is composed of a set of Java modules that can be packaged and deployed
 in various ways.
 
 The clear recommendation is to deploy the IssuerService as a standalone runtime with its own HSM (vault) and its own

content/en/documentation/for-adopters/tuning/_index.md

@@ -13,7 +13,7 @@ weight: 80
 Out of the box the EDC provides a set of default configurations that aim to find a good balance for performances.
 The extensibility nature of the EDC permits the user to configure it deeply.
 
-We will explain how these settings can be fine tuned
+We will explain how these settings can be fine-tuned.
 
 ## State Machines
 At the core of the EDC there is the [`State Machine`](../../for-contributors/runtime/programming-primitives.md#1-state-machines) 
@@ -30,7 +30,7 @@ The most important settings for configuring a state machine are:
     pessimistically against mutual access, so for the time of the processing no other connector instances can read
     the same entities.
 - `send.retry.limit`
-  - how many time a failing process execution can be tried before failure.
+  - how many times a failing process execution can be tried before failure.
 - `send.retry.base-delay.ms`
   - how many milliseconds have to pass before the first retry after a failure. Next retries are calculated with an
     exponential function (e.g. if the first delay is 10ms)

content/en/documentation/for-contributors/_index.md

@@ -124,7 +124,7 @@ Detailed documentation about entities can be found [here](./control-plane/entiti
 
 ### 2.2 Policy Monitor
 
-The policy monitor is a component that watches over on-going transfers and ensures that the policies associated with the
+The policy monitor is a component that watches over ongoing transfers and ensures that the policies associated with the
 transfer are still valid.
 
 Detailed documentation about the policy monitor can be found [here](./control-plane/policy-monitor.md)

content/en/documentation/for-contributors/best-practices.md

@@ -35,7 +35,7 @@ This document is not an exhaustive list of prescribed steps, that will shield ad
 danger, but rather should serve as starting point for engineers to build upon.
 
 Finally, it should go without saying that the software of the EDC project is distributed "as is" and committers of EDC
-take no responsibility or liability, direct or indirect, for any harm or damage caused by the us`e of it. This document
+take no responsibility or liability, direct or indirect, for any harm or damage caused by the use of it. This document
 does not change that.
 
 ## 2. Security recommendations
@@ -65,12 +65,12 @@ purpose of performing authentication, authorization, rate limiting, IP blacklist
 There is a plethora of ready-made components available, both commercial and open-source, therefor the EDC project _will
 not provide that functionality._ Feature requests and issues to that effect will be ignored.
 
-In the particular case of the DSP API, the same principle holds, although with the exception of authentication and
+In the particular case of the DSP API, the same principle holds, although except for authentication and
 authorization. That is handled by the [DSP protocol
 itself](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol).
 
 We have a rudimentary token-based API security module available, which can be used to secure the connection API gateway
-<-> connector if so desired. It should be noted that it is _not designed to act as a ingress point!_
+<-> connector if so desired. It should be noted that it is _not designed to act as an ingress point!_
 
 > TL;DR: don't expose any APIs if you can help it, but if you must, use available tools to harden the ingress
 
@@ -79,7 +79,7 @@ We have a rudimentary token-based API security module available, which can be us
 Typically, JVMs ship with trust stores that contain a number of widely accepted CAs. Any attempts to package additional
 CAs/certificates with runtime base images are _discouraged_, as that would be problematic because:
 
-- scalability: in a heterogenous networks one cannot assume such a custom CA to be accepted by the counterparty
+- scalability: in a heterogeneous networks one cannot assume such a custom CA to be accepted by the counterparty
 - maintainability: TLS certificates expire, so there is a chance that mandatory software rollouts become necessary
   because of expired certificates lest the network breaks down completely.
 - security: there have been a number of issues with CAs