docs: fix typos in the documentation (#2633)

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

@@ -18,7 +18,7 @@ Backstage natively supports tracking of the following component
 Since these types are likely not the only kind of software you will want to
 track in Backstage, it is possible to
 
-It is possible to add your own software types that fits your organization's data
+It is possible to add your own software types that fit your organization's data
 model. Inside Spotify our model has grown significantly over the years, and now
 includes ML models, Apps, data pipelines and many more.
 
@@ -30,7 +30,7 @@ catalog.
 ## The Other type
 
 It might be tempting to put software that doesn't fit into any of the existing
-types into Other. There are a few reasons why we advice against this; firstly,
+types into Other. There are a few reasons why we advise against this; firstly,
 we have found that it is preferred to match the conceptual model that your
 engineers have when describing your software. Secondly, Backstage helps your
 engineers manage their software by integrating the infrastructure tooling

docs/features/software-catalog/index.md

@@ -84,7 +84,7 @@ registered in the catalog.
 ### Static catalog configuration
 
 In addition to manually registering components, it is also possible to register
-components though [static configuration](../../conf/index.md). For example, the
+components through [static configuration](../../conf/index.md). For example, the
 above example can be added using the following configuration:
 
 ```yaml

docs/features/software-catalog/references.md

@@ -67,7 +67,7 @@ be left out in its own yaml file because that's the default value there too),
 and name `pet-managers`.
 
 The entries in `implementsApis` are also references. In this case, none of them
-need to specify a kind since we know from the context that that's the only kind
+needs to specify a kind since we know from the context that that's the only kind
 that's supported here. The second entry specifies a namespace but the other ones
 don't, and in this context, the default is to refer to the same namespace as the
 originating entity (`external-systems` here). So the three references
@@ -79,7 +79,7 @@ there to exist three API kind entities in the catalog matching those references.
 
 This is a more verbose version of a reference, where each part of the
 kind-namespace-name triplet is expressed as a field in a structure. This format
-can be used where necessary, such as if either of the three elements contain
+can be used where necessary, such as if either of the three elements contains
 colons or forward slashes. Avoid using it where possible, since it is harder to
 read and write for humans.
 

docs/features/software-catalog/well-known-annotations.md

@@ -57,7 +57,7 @@ spec:
 
 This annotation allows to fetch an API definition from another location, instead
 of wrapping the API definition inside the definition field. This allows to
-easitly consume existing API definition. The definition is fetched during
+easily consume existing API definition. The definition is fetched during
 ingestion by a processor and included in the entity. It is updated on every
 refresh. The annotation contains a location reference string that contains the
 location processor type and the target.

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

@@ -5,7 +5,7 @@ description: Documentation on Adding your own Templates
 ---
 
 Templates are stored in the **Service Catalog** under a kind `Template`. The
-minimum that the a template skeleton needs is a `template.yaml` but it would be
+minimum that the template skeleton needs is a `template.yaml` but it would be
 good to also have some files in there that can be templated in.
 
 A simple `template.yaml` definition might look something like this:
@@ -30,7 +30,7 @@ spec:
   templater: cookiecutter
   # what does this template create
   type: website
-  # if the template is not in the current directory where this definition is kept then specfiy
+  # if the template is not in the current directory where this definition is kept then specify
   path: './template'
   # the schema for the form which is displayed in the frontend.
   # should follow JSON schema for forms: https://jsonforms.io/
@@ -107,7 +107,7 @@ This should then have added the catalog, and also should now be listed under the
 create page at http://localhost:3000/create.
 
 The `type` field which is chosen in the request to add the `template.yaml` to
-the Service Catalog here, will be come the `PreparerKey` which will be used to
+the Service Catalog here, will become the `PreparerKey` which will be used to
 select the `Preparer` when creating a job.
 
 ### Adding form values in the Scaffolder Wizard

docs/features/software-templates/extending/create-your-own-preparer.md

@@ -17,7 +17,7 @@ location protocols:
 These two are added to the `PreparersBuilder` and then passed into the
 `createRouter` function of the `@spotify/plugin-scaffolder-backend`
 
-An full example backend can be found
+A full example backend can be found
 [here](https://github.com/spotify/backstage/blob/d91c10f654475a60829fa33a5c81018e517a319a/packages/backend/src/plugins/scaffolder.ts),
 but it looks something like the following
 
@@ -98,4 +98,4 @@ const preparers = new Preparers();
 preparers.register('gcs', new GoogleCloudStoragePreparer());
 ```
 
-And then pass this in to the `createRouter` function.
+And then pass this into the `createRouter` function.

docs/features/software-templates/extending/create-your-own-publisher.md

@@ -8,10 +8,10 @@ Publishers are responsible for pushing and storing the templated skeleton after
 the values have been templated by the `Templater`. See
 [Create your own templater](./create-your-own-templater.md) for more info.
 
-They receive a directory or location where the templater has sucessfully run and
-is now ready to store somewhere. They also are given some other options which
-are sent from the frontend, such as the `storePath` which is a string of where
-the frontend thinks we should save this templated folder.
+They receive a directory or location where the templater has successfully run
+and is now ready to store somewhere. They also are given some other options
+which are sent from the frontend, such as the `storePath` which is a string of
+where the frontend thinks we should save this templated folder.
 
 Currently we provide the following `publishers`:
 

docs/features/software-templates/extending/create-your-own-templater.md

@@ -147,4 +147,4 @@ const templaters = new Templaters();
 templaters.register('handlebars', new HandlebarsTemplater());
 ```
 
-And then pass this in to the `createRouter` function.
+And then pass this into the `createRouter` function.

docs/features/software-templates/extending/index.md

@@ -11,13 +11,13 @@ You're at the right place.
 This guide is going to take you through how the Scaffolder in Backstage works.
 We'll dive into some jargon and run through what's going on in the backend to be
 able to create these templates. There's also more guides that you might find
-useful at the bottom of this document. At it's core, theres 3 simple stages.
+useful at the bottom of this document. At its core, there are 3 simple stages.
 
 1. Pick a skeleton
 2. Template some variables into the skeleton
 3. Send the templated skeleton somewhere
 
-These three steps are translated to the folllowing stages under the hood in the
+These three steps are translated to the following stages under the hood in the
 scaffolder that you will need to know:
 
 1. Prepare
@@ -38,7 +38,7 @@ the router to pick the correct `Preparer` to run for the `Template` entity.
 
 **Templater** - The templater is responsible for actually running the chosen
 templater on top of the previously returned temporary directory from the
-**Preprarer**. We advise making these Docker containers as it can keep all
+**Preparer**. We advise making these Docker containers as it can keep all
 dependencies--for example Cookiecutter--self contained and not a dependency on
 the host machine.
 
@@ -82,7 +82,7 @@ Once that has been posted, a job will be setup with different stages, and the
 job processor will complete each stage before moving onto the next stage, whilst
 collecting logs and mutating the running job.
 
-Here's some futher reading that you might find useful:
+Here's some further reading that you might find useful:
 
 - [Adding your own Template](../adding-templates.md)
 - [Creating your own Templater](./create-your-own-templater.md)

docs/features/software-templates/installation.md

@@ -240,7 +240,7 @@ scaffolder:
 
 You can configure who can see the new repositories that the scaffolder creates
 by specifying `visibility` option. Valid options are `public`, `private` and
-`internal`. `internal` options is for GitHub Enterprise clients, which means
+`internal`. `internal` option is for GitHub Enterprise clients, which means
 public within the organization.
 
 ### Running the Backend

docs/features/techdocs/getting-started.md

@@ -13,7 +13,7 @@ If you haven't setup Backstage already, start
 ## Installing TechDocs
 
 TechDocs is provided with the Backstage application by default. If you want to
-set up TechDocs manually, keep follow the instructions below.
+set up TechDocs manually, keep following the instructions below.
 
 ### Adding the package