some more small doc fixes

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

.github/vale/config/vocabularies/Backstage/accept.txt

@@ -21,9 +21,9 @@ asciidoc
 async
 Atlassian
 autofix
+autologout
 automations
 autoscaling
-Autoscaling
 autoselect
 Avro
 backend's
@@ -47,6 +47,7 @@ bundler
 bundlers
 bursty
 callout
+camelCase
 CDNs
 Chai
 Chainguard

docs/backend-system/core-services/http-auth.md

@@ -104,7 +104,7 @@ or [contribute](https://github.com/backstage/backstage/blob/master/CONTRIBUTING.
 
 ### Custom token extraction logic
 
-In some cases, you might want to customize how tokens are extracted from incoming requests. It might be that you want to extract tokens from a different location in the request. To support this you can supply your own slightly modified httpAuth service. The `DefaultHttpAuthService` class is exported from `@backstage/backend-defaults/httpAuth` and it's static `create` method can be used to pass in a custom `getTokenFromRequest` extraction function.
+In some cases, you might want to customize how tokens are extracted from incoming requests. It might be that you want to extract tokens from a different location in the request. To support this you can supply your own slightly modified `httpAuth` service. The `DefaultHttpAuthService` class is exported from `@backstage/backend-defaults/httpAuth` and it's static `create` method can be used to pass in a custom `getTokenFromRequest` extraction function.
 
 ```ts
 import { DefaultHttpAuthService } from '@backstage/backend-defaults/httpAuth';

docs/backend-system/core-services/root-http-router.md

@@ -162,7 +162,7 @@ backend.add(
 
 Note that requests towards `/api/*` will never be handled by the `routes` handler unless a matching plugin exists, and will instead typically falling through to the `middleware.notFound()` handler. That is the case regardless of whether there is a configured `indexPath` or not.
 
-The root HTTP Router service also allows for configuration of the underlying Node.js HTTP server object. This is useful for modifying settings on the HTTP server itself, such as server [timeout](https://nodejs.org/api/http.html#servertimeout), [keepAliveTimeout](https://nodejs.org/api/http.html#serverkeepalivetimeout), and [headersTimeout](https://nodejs.org/api/http.html#serverheaderstimeout).
+The root HTTP Router service also allows for configuration of the underlying Node.js HTTP server object. This is useful for modifying settings on the HTTP server itself, such as server [`timeout`](https://nodejs.org/api/http.html#servertimeout), [`keepAliveTimeout`](https://nodejs.org/api/http.html#serverkeepalivetimeout), and [`headersTimeout`](https://nodejs.org/api/http.html#serverheaderstimeout).
 
 A `applyDefaults` helper is also made available to use the default app/router configuration while still enabling custom server configuration
 

docs/features/search/declarative-integration.md

@@ -161,13 +161,13 @@ The `createSearchResultItemExtension` function returns a Backstage's extension r
 
 In this object, you can see exactly what will happen once the custom extension is installed:
 
-- **[1] $$type**: declares that the object represents an extension;
-- **[2] id**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file;
-- **[3] at**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension;
-- **[4] inputs**: in this case is an empty object because this extension doesn't expect inputs;
-- **[5] output**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference;
-- **[6] configSchema**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file;
-- **[7] disable**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app.
+- **[1] `$$type`**: declares that the object represents an extension;
+- **[2] `id`**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file;
+- **[3] `at`**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension;
+- **[4] `inputs`**: in this case is an empty object because this extension doesn't expect inputs;
+- **[5] `output`**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference;
+- **[6] `configSchema`**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file;
+- **[7] `disable`**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app.
 
 To complete the development cycle for creating a custom search result item extension, we should provide the extension via `TechDocs` plugin:
 

docs/features/software-catalog/external-integrations.md

@@ -775,7 +775,7 @@ sent. Luckily many external systems provide ETag support to check for changes
 which usually doesn't count towards the quota and saves resources both
 internally and externally.
 
-The catalog has built in support for leveraging ETags when refreshing external
+The catalog has built in support for leveraging `ETag`s when refreshing external
 locations in GitHub. This example aims to demonstrate how to add the same
 behavior for `system-x` that we implemented earlier.
 

docs/features/software-catalog/index.md

@@ -126,7 +126,7 @@ _starring_ of components:
 The software catalog is a great way to organize the infrastructure tools you use
 to manage the software. This is how Backstage creates one developer portal for
 all your tools. Rather than asking teams to jump between different
-infrastructure UIs (and incurring additional cognitive overhead each time they
+infrastructure user interfaces (and incurring additional cognitive overhead each time they
 make a context switch), most of these tools can be organized around the entities
 in the catalog.
 

docs/features/software-catalog/life-of-an-entity.md

@@ -133,7 +133,7 @@ the order of registration depends on the order in which the modules are loaded
 by the framework.
 
 It's possible to customize the order of the processors by modifying the
-`catalog.processors.<processorName>.priority` configuration option.
+`catalog.processorOptions.<processorName>.priority` configuration option.
 The default priority is `20`, and lower value means that the processor runs earlier.
 
 :::

docs/integrations/harness/locations.md

@@ -30,4 +30,4 @@ check out https://developer.harness.io/docs/platform/automation/api/add-and-mana
 
 - `host`: The host of the Harness Code instance that you want to match on.
 - `token` (optional): The password or api token to authenticate with.
-- `apiKey` (optional): The apiKey to authenticate with.
+- `apiKey` (optional): The API key to authenticate with.

docs/overview/adopting.md

@@ -85,7 +85,7 @@ Examples of tactics we have used to evangelize Backstage internally:
   as to send out weekly digest emails showing how usage metrics have changed for
   individual plugins.
 
-- Pro-actively identify new plugins. Reach out to teams that own internal UIs or
+- Pro-actively identify new plugins. Reach out to teams that own internal user interfaces or
   platforms that you think would make sense to consolidate into Backstage.
 
 ## KPIs and metrics

docs/plugins/new-backend-system.md

@@ -195,7 +195,7 @@ A `ServiceRef` is a named reference to an interface which are later used to reso
 Services is what provides common utilities that previously resided in the `PluginEnvironment` such as Config, Logging and Database.
 
 On startup the backend will make sure that the services are initialized before being passed to the plugin/module that depend on them.
-ServiceRefs contain a scope which is used to determine if the serviceFactory creating the service will create a new instance scoped per plugin/module or if it will be shared. `plugin` scoped services will be created once per plugin/module and `root` scoped services will be created once per backend instance.
+ServiceRefs contain a scope which is used to determine if the service factory creating the service will create a new instance scoped per plugin/module or if it will be shared. `plugin` scoped services will be created once per plugin/module and `root` scoped services will be created once per backend instance.
 
 #### Defining a Service