diff --git a/content/documentation/explanations/dispatching.md b/content/documentation/explanations/dispatching.md
index 22470953..36f8d2c8 100644
--- a/content/documentation/explanations/dispatching.md
+++ b/content/documentation/explanations/dispatching.md
@@ -39,7 +39,7 @@ Below are some explanations on these dispatchers and associated dispatching rule
Changing `Dispatching Rules` or even the `Dispatcher` can be done by different ways:
* Via the web UI, selecting `Edit Properties` of the operation from the 3-dots menu on the right of the operation name. You should be logged as a repository `manager` to have this option (see [Managing Users](/documentation/guides/administration/users) how-to guide if needed),
* Via [Microcks' owns API](/documentation/references/apis/open-api) after being [connected to Microcks API](/documentation/guides/automation/api),
-* Via an additional [API Metadata](/documentation/references/metadada) artifact that allow this customization,
+* Via an additional [API Metadata](/documentation/references/metadata) artifact that allow this customization,
* Via Microcks [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions) that allow this customization as well.
## Advanced dispatchers and rules
diff --git a/content/documentation/explanations/multi-artifacts.md b/content/documentation/explanations/multi-artifacts.md
index d6f0a1db..bfb30401 100644
--- a/content/documentation/explanations/multi-artifacts.md
+++ b/content/documentation/explanations/multi-artifacts.md
@@ -35,7 +35,7 @@ Also, note that multiple artifacts for one API definition don't necessarily invo
{{< image src="images/documentation/artifacts-merging-overlay.png" alt="image" zoomable="true" >}}
-One specific case of the merging process - that can be used in combination with any other artifact as a `primary` one - relates to the [Microcks APIMetadata](/documentation/references/metadada) format. When importing such artifacts as secondary ones, the merging process involves the metadata of the API or Service and not the examples or tests, as illustrated below:
+One specific case of the merging process - that can be used in combination with any other artifact as a `primary` one - relates to the [Microcks APIMetadata](/documentation/references/metadata) format. When importing such artifacts as secondary ones, the merging process involves the metadata of the API or Service and not the examples or tests, as illustrated below:
{{< image src="images/documentation/artifacts-merging-metadata.png" alt="image" zoomable="true" >}}
diff --git a/content/documentation/guides/administration/organizing-repository.md b/content/documentation/guides/administration/organizing-repository.md
index 3916f0b3..968c9b69 100644
--- a/content/documentation/guides/administration/organizing-repository.md
+++ b/content/documentation/guides/administration/organizing-repository.md
@@ -97,7 +97,7 @@ As an administrator of the Microcks instance, you can now assign users to differ
## Wrap-up
-Walking through this guide, you have learned the different means available for organizing your API & Services repository thanks to `labels` ๐ท๏ธ. It's important to note that labels are saved into Microcks' database and not replaced by a new import of your Service or API definition. They can be independently set and updated using the [Microcks APIs](/documentation/references/apis/open-api), [Microcks Metadata](/documentation/references/metadada), [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions).
+Walking through this guide, you have learned the different means available for organizing your API & Services repository thanks to `labels` ๐ท๏ธ. It's important to note that labels are saved into Microcks' database and not replaced by a new import of your Service or API definition. They can be independently set and updated using the [Microcks APIs](/documentation/references/apis/open-api), [Microcks Metadata](/documentation/references/metadata), [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) or [AsyncAPI extensions](/documentation/references/artifacts/asyncapi-conventions/#asyncapi-extensions).
You may follow up this guide with the one related to [Managing Users](/documentation/guides/administration/users) or [Snapshotting/restoring your Repository](/documentation/guides/administration/snapshots)
diff --git a/content/documentation/guides/troubleshoot/_index.md b/content/documentation/guides/troubleshoot/_index.md
index b3d28ae1..57149298 100644
--- a/content/documentation/guides/troubleshoot/_index.md
+++ b/content/documentation/guides/troubleshoot/_index.md
@@ -15,7 +15,7 @@ Changing the log level depends on the way you installed Microcks.
Helm Chart
-When using the [Helm Chart](/documentation/references/configuration/helm-chart-config/) to deploy Microcks, there's a `microcks.logLevel`spec property you can set to `DEBUG`. Change it into your `values.yaml` file or as a command line argument using `--set microcks.logLevel=DEBUG` when redeploying the chart. This property changes both values for the main webapp and Async Miniong components.
+When using the [Helm Chart](/documentation/references/configuration/helm-chart-config/) to deploy Microcks, there's a `microcks.logLevel`spec property you can set to `DEBUG`. Change it into your `values.yaml` file or as a command line argument using `--set microcks.logLevel=DEBUG` when redeploying the chart. This property changes both values for the main webapp and Async Minion components.
@@ -45,7 +45,7 @@ After the next operator reconciliation, the log level is changed in both the mai
When using [Docker or Podman Compose](/documentation/guides/installation/docker-compose/) for running Microcks, you just have to add additional environment variables to the `microcks` and `microcks-async-minoin` containers.
-You just have to edit the `docker-compose.yml` file to uncomment/enable the correct environement variables:
+You just have to edit the `docker-compose.yml` file to uncomment/enable the correct environment variables:
```yaml
app:
diff --git a/content/documentation/guides/usage/custom-dispatchers.md b/content/documentation/guides/usage/custom-dispatchers.md
index 442caa6b..70941dcf 100644
--- a/content/documentation/guides/usage/custom-dispatchers.md
+++ b/content/documentation/guides/usage/custom-dispatchers.md
@@ -135,7 +135,7 @@ operations:
}
```
-Import this as a secondary artifact (via Importers or Upload). It will set or overwrite the dispatcher for the target operation. See [API Metadata Format](/documentation/references/metadada/#api-metadata-properties).
+Import this as a secondary artifact (via Importers or Upload). It will set or overwrite the dispatcher for the target operation. See [API Metadata Format](/documentation/references/metadata/#api-metadata-properties).
### 3.3 Using the Microcks API
@@ -163,5 +163,5 @@ Next steps and related topics:
- **Learn more about strategies**: [Dispatcher & dispatching rules](/documentation/explanations/dispatching)
- **Keep it in your artifact**: [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions)
-- **Manage separately**: [API Metadata](/documentation/references/metadada)
+- **Manage separately**: [API Metadata](/documentation/references/metadata)
- **See similar guides**: [Importing Services & APIs](/documentation/guides/usage/importing-content) ยท [Defining delays for mocks](/documentation/guides/usage/delays)
diff --git a/content/documentation/guides/usage/delays.md b/content/documentation/guides/usage/delays.md
index 9d807153..d47a823d 100644
--- a/content/documentation/guides/usage/delays.md
+++ b/content/documentation/guides/usage/delays.md
@@ -87,7 +87,7 @@ So cool! ๐ You have now defined a per-request delay that will change with the
Defining the **Default delay** view in the Microcks UI can be cumbersome. You have plenty of other ways to do so:
* Using our [OpenAPI extensions](/documentation/references/artifacts/openapi-conventions/#openapi-extensions) if you're dealing with REST APIs,
-* Using an additional [APIMetadata artifact](/documentation/references/metadada/#api-metadata-properties) if you don't want this information to be mixed with your API definition or if you're dealing with GraphQL or gRPC services,
+* Using an additional [APIMetadata artifact](/documentation/references/metadata/#api-metadata-properties) if you don't want this information to be mixed with your API definition or if you're dealing with GraphQL or gRPC services,
* Via the [Microcks API](/documentation/references/apis/open-api/) using the `PUT /services/{id}/operation` directly.
## Wrap-up
diff --git a/content/documentation/references/artifacts/grpc-conventions.md b/content/documentation/references/artifacts/grpc-conventions.md
index ac21464f..9e4ac4e6 100644
--- a/content/documentation/references/artifacts/grpc-conventions.md
+++ b/content/documentation/references/artifacts/grpc-conventions.md
@@ -99,6 +99,6 @@ The next step is now to create a bunch of examples for each of the requests/oper
If the default inferred dispatchers don't match with your use-case, you'll need an additional step for assembling data coming from gRPC Protofile and Postman Collection is to define how to dispatch requests. For gRPC, your can typically use a `JSON_BODY` or a `SCRIPT` dispatcher as mentionned above.
-You can use a [Metadata artifact](/documentation/references/metadada) for that or directly edit the dispatcher in the Web UI. Here-after we have defined a simple rule that is routing incoming requests depending on the value of the `firstname` property of the incoming message.
+You can use a [Metadata artifact](/documentation/references/metadata) for that or directly edit the dispatcher in the Web UI. Here-after we have defined a simple rule that is routing incoming requests depending on the value of the `firstname` property of the incoming message.
{{< image src="images/documentation/grpc-dispatch-rule.png" alt="image" zoomable="true" >}}
diff --git a/content/documentation/references/container-images.md b/content/documentation/references/container-images.md
index d487a10a..c22eabf2 100644
--- a/content/documentation/references/container-images.md
+++ b/content/documentation/references/container-images.md
@@ -20,7 +20,7 @@ Microcks images repositories are primilarly located on  explanations.
+Here is below the list of available container images. For more information on their role in the architecture, you may check the [Architecture & deployment options](/documentation/explanations/deployment-options) explanations.
### Microcks App
diff --git a/content/documentation/references/metadada.md b/content/documentation/references/metadata.md
similarity index 100%
rename from content/documentation/references/metadada.md
rename to content/documentation/references/metadata.md
diff --git a/content/documentation/tutorials/getting-started.md b/content/documentation/tutorials/getting-started.md
index e90d6b13..5ec901bc 100644
--- a/content/documentation/tutorials/getting-started.md
+++ b/content/documentation/tutorials/getting-started.md
@@ -11,7 +11,7 @@ weight: 1
In this tutorial, you will discover Microcks mocking features by re-using a simple REST API sample. For that: you will run Microcks on your local machine, then load a sample provided by the Microcks team, explore the web user interface and then interact with an API mock.
-The easiest way to get started with Microcks is using [Docker](https://docs.docker.com/get-docker/) or [Podman](https://podman.io/) with our ephemral all-in-one Microcks distribution.
+The easiest way to get started with Microcks is using [Docker](https://docs.docker.com/get-docker/) or [Podman](https://podman.io/) with our ephemeral all-in-one Microcks distribution.
In your terminal issue the following command - maybe replacing `8585` by another port of your choice if this one is not free:
)