docs: Fix typos

Signed-off-by: Gabriel Dugny <gabriel.dugny@believe.com>

docs/backend-system/building-plugins-and-modules/08-migrating.md

@@ -237,7 +237,7 @@ The development server created above will be automatically configured with the d
 
 ```ts title="in dev/index.js"
 //...
-// This package should be installed as `devDependecies`
+// This package should be installed as `devDependencies`
 import { mockServices } from '@backstage/backend-test-utils';
 
 const backend = createBackend();

docs/features/kubernetes/authenticationstrategy.md

@@ -13,7 +13,7 @@ it also defines what authentication metadata about a Kubernetes cluster is retur
 
 ## Context
 
-Backstage includes by default some [Kubernetes Auth Providers](./authentication.md) to ease the authentication proccess to
+Backstage includes by default some [Kubernetes Auth Providers](./authentication.md) to ease the authentication process to
 kubernetes clusters, it includes:
 
 - `Server Side Providers` like `localKubectlProxy` or `serviceAccount` where the same set

docs/features/software-catalog/faq.md

@@ -29,7 +29,7 @@ On the user experience side, a Backstage experience without complete organizatio
 
 While it's possible to get hold of a catalog client via the `catalogServiceRef` from `@backstage/plugin-catalog-node`, it's almost never the right thing to do, and we strongly discourage from doing so.
 
-The catalog processing loop is a very high-speed system where your entire catalog cluster collaborates to race through all entities at the highest possible rate. The ideal processor does an absolute minimum of work, and immediately relinquishes control back. Performing asynchronous requests to external systems - including the catalog - from processors, can quickly become overwhelming for that external system and starve their resources if they aren't prepared to deal with very high rates of small requests. It also significantly slows down the procesing loop, when each step needs to wait for responses. This can lead to work "piling up" in the catalog and delays in seeing entities get updated. The [life of an entity](./life-of-an-entity.md) article shows the sequence of events that happen when an entity goes from original ingestion, through processing, and to becoming final entities.
+The catalog processing loop is a very high-speed system where your entire catalog cluster collaborates to race through all entities at the highest possible rate. The ideal processor does an absolute minimum of work, and immediately relinquishes control back. Performing asynchronous requests to external systems - including the catalog - from processors, can quickly become overwhelming for that external system and starve their resources if they aren't prepared to deal with very high rates of small requests. It also significantly slows down the processing loop, when each step needs to wait for responses. This can lead to work "piling up" in the catalog and delays in seeing entities get updated. The [life of an entity](./life-of-an-entity.md) article shows the sequence of events that happen when an entity goes from original ingestion, through processing, and to becoming final entities.
 
 See also [the related validation topic](#can-i-validate-relations-in-processors).
 

docs/features/software-templates/experimental.md

@@ -118,7 +118,7 @@ export const mockDecorator = createScaffolderFormDecorator({
   // give the decorator a name
   id: 'mock-decorator',
 
-  // define the schema for the input that can be proided in `template.yaml`
+  // define the schema for the input that can be provided in `template.yaml`
   schema: {
     input: {
       test: z => z.string(),

docs/features/software-templates/writing-custom-field-extensions.md

@@ -151,7 +151,7 @@ const routes = (
 
 ### Async Validation Function
 
-A validation function can be asyncronous and use [Utility APIs](https://backstage.io/docs/api/utility-apis/) via the `ApiHolder` in the [field validation context](https://backstage.io/docs/reference/plugin-scaffolder-react.customfieldvalidator). The example below uses the `catalogApiRef` to check if the submitted value (in this scenario an entity ref) exists in the catalog.
+A validation function can be asynchronous and use [Utility APIs](https://backstage.io/docs/api/utility-apis/) via the `ApiHolder` in the [field validation context](https://backstage.io/docs/reference/plugin-scaffolder-react.customfieldvalidator). The example below uses the `catalogApiRef` to check if the submitted value (in this scenario an entity ref) exists in the catalog.
 
 ```tsx
 import { FieldValidation } from '@rjsf/utils';

docs/features/software-templates/writing-templates.md

@@ -252,7 +252,7 @@ spec:
   type: service
 
   parameters:
-    - title: Authenticaion
+    - title: Authentication
       description: Provide authentication for the resource
       required:
         - username

docs/features/techdocs/how-to-guides.md

@@ -934,7 +934,7 @@ metadata:
 apiVersion: backstage.io/v1alpha1
 kind: Component
 metadata:
-  name: example-platfrom
+  name: example-platform
   title: Example Application Platform
   namespace: default
   description: This is the child entity

docs/frontend-system/utility-apis/02-creating.md

@@ -93,7 +93,7 @@ The extension ID of the work API will be the kind `api:` followed by the plugin
 
 ## Adding configurability
 
-Here we will describe how to amend a utility API with the capability of having extension config, which is driven by [your app-config](../../conf/writing.md). You do this by giving an extension config schema to your API extension factory function. Let's refactory the example above to also accept configuration, which will require us to use the [override method of the blueprint](../architecture/23-extension-blueprints.md#creating-an-extension-from-a-blueprint-with-overrides).
+Here we will describe how to amend a utility API with the capability of having extension config, which is driven by [your app-config](../../conf/writing.md). You do this by giving an extension config schema to your API extension factory function. Let's refactor the example above to also accept configuration, which will require us to use the [override method of the blueprint](../architecture/23-extension-blueprints.md#creating-an-extension-from-a-blueprint-with-overrides).
 
 ```tsx title="in @internal/plugin-example"
 const exampleWorkApi = ApiBlueprint.makeWithOverrides({
@@ -123,7 +123,7 @@ We wanted users to be able to set a `goSlow` extension config parameter for our
 
 Note that the expression "extension config" as used here, is _not_ the same thing as the `configApi` which gives you access to the full app-config. The extension config discussed here is instead the particular configuration settings given to your utility API instance. This is discussed more [in the Configuring section](./04-configuring.md).
 
-Note also that the extension config schema contained a default value fo the `goSlow` field. This is an important consideration. You want users of your API to be able to get maximum value out of it, without having to dive deep into how to configure it. For that reason you generally want to provide as many sane defaults as possible, while letting users override them rarely but with purpose, only when called for. If you have an extension config schema without defaults, the framework will refuse to instantiate the utility API on startup unless the user had configured those values explicitly. Since it had a default value, the TypeScript code and interfaces also don't have to defensively allow `undefined` - we know that it'll have either the default value or an overridden value when we start consuming the extension config data.
+Note also that the extension config schema contained a default value for the `goSlow` field. This is an important consideration. You want users of your API to be able to get maximum value out of it, without having to dive deep into how to configure it. For that reason you generally want to provide as many sane defaults as possible, while letting users override them rarely but with purpose, only when called for. If you have an extension config schema without defaults, the framework will refuse to instantiate the utility API on startup unless the user had configured those values explicitly. Since it had a default value, the TypeScript code and interfaces also don't have to defensively allow `undefined` - we know that it'll have either the default value or an overridden value when we start consuming the extension config data.
 
 ## Adding inputs