Fix a bunch of vale errors

Signed-off-by: Fredrik Adelöw <freben@gmail.com>

docs/features/kubernetes/configuration.md

@@ -441,7 +441,7 @@ Base64-encoded certificate authority bundle in PEM format. The Kubernetes client
 will verify that the TLS certificate presented by the API server is signed by
 this CA.
 
-This value could be obtained via inspecting the kubeconfig file (usually
+This value could be obtained via inspecting the `kubeconfig` file (usually
 at `~/.kube/config`) under `clusters[*].cluster.certificate-authority-data`. For
 GKE, execute the following command to obtain the value
 
@@ -619,7 +619,7 @@ The custom resource's group.
 
 #### `customResources.\*.apiVersion`
 
-The custom resource's apiVersion.
+The custom resource's `apiVersion`.
 
 #### `customResources.\*.plural`
 

docs/features/software-catalog/api.md

@@ -175,7 +175,7 @@ Some more real world usable examples:
 
 #### Ordering
 
-By default the entities are returned ordered by their internal uid. You can
+By default the entities are returned ordered by their internal `uid`. You can
 customize the `orderField` query parameters to affect that ordering.
 
 For example, to return entities by their name:

docs/features/software-catalog/extending-the-model--old.md

@@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box:
 
 We'll list different possibilities for extending this below.
 
-## Adding a New apiVersion of an Existing Kind
+## Adding a New `apiVersion` of an Existing Kind
 
 Example intents:
 
 > "I want to evolve this core kind, tweaking the semantics a bit so I will bump
-> the apiVersion a step"
+> the `apiVersion` a step"
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
-The `backstage.io` apiVersion space is reserved for use by the Backstage
+The `backstage.io` `apiVersion` space is reserved for use by the Backstage
 maintainers. Please do not change or add versions within that space.
 
-If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required)
+If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required)
 space of your own, you are effectively branching out from the underlying kind
-and making your own. An entity kind is identified by the apiVersion + kind pair,
+and making your own. An entity kind is identified by the `apiVersion` + `kind` pair,
 so even though the resulting entity may be similar to the core one, there will
 be no guarantees that plugins will be able to parse or understand its data. See
 below about adding a new kind.
@@ -57,7 +57,7 @@ Example intents:
 > thing that is a poor fit for either of the builtins."
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
 A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching
@@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition
 is to map things to these kinds, but sometimes you may want or need to extend
 beyond them.
 
-Introducing a new apiVersion is basically the same as adding a new kind. Bear in
+Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in
 mind that most plugins will be compiled against the builtin
 `@backstage/catalog-model` package and have expectations that kinds align with
 that.

docs/features/software-catalog/extending-the-model.md

@@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box:
 
 We'll list different possibilities for extending this below.
 
-## Adding a New apiVersion of an Existing Kind
+## Adding a New `apiVersion` of an Existing Kind
 
 Example intents:
 
 > "I want to evolve this core kind, tweaking the semantics a bit so I will bump
-> the apiVersion a step"
+> the `apiVersion` a step"
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
-The `backstage.io` apiVersion space is reserved for use by the Backstage
+The `backstage.io` `apiVersion` space is reserved for use by the Backstage
 maintainers. Please do not change or add versions within that space.
 
-If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required)
+If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required)
 space of your own, you are effectively branching out from the underlying kind
-and making your own. An entity kind is identified by the apiVersion + kind pair,
+and making your own. An entity kind is identified by the `apiVersion` + `kind` pair,
 so even though the resulting entity may be similar to the core one, there will
 be no guarantees that plugins will be able to parse or understand its data. See
 below about adding a new kind.
@@ -57,7 +57,7 @@ Example intents:
 > thing that is a poor fit for either of the builtins."
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
 A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching
@@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition
 is to map things to these kinds, but sometimes you may want or need to extend
 beyond them.
 
-Introducing a new apiVersion is basically the same as adding a new kind. Bear in
+Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in
 mind that most plugins will be compiled against the builtin
 `@backstage/catalog-model` package and have expectations that kinds align with
 that.

docs/tutorials/quickstart-app-plugin.md

@@ -246,7 +246,7 @@ const auth = useApi(githubAuthApiRef);
 
 2. The access token we need to make our GitHub request and the request itself is
    obtained in an asynchronous manner.
-3. Add the useAsync block inside the ExampleFetchComponent
+3. Add the `useAsync` block inside the ExampleFetchComponent
 
 ```tsx
 const { value, loading, error } = useAsync(async (): Promise<any> => {