Fix some typos in documentation (found by codespell) (#2837)

stweil · web-flow · commit 16b9e46cafc3 · 2025-10-18T16:44:32.000+02:00
Signed-off-by: Stefan Weil &lt;sw@weilnetz.de&gt;
diff --git a/docs/api/supervisor/endpoints.md b/docs/api/supervisor/endpoints.md
@@ -3074,7 +3074,7 @@ Dismiss an issue
 
 <ApiEndpoint path="/resolution/healthcheck" method="post">
 
-Execute a healthcheck and autofix & notifcation.
+Execute a healthcheck and autofix & notification.
 
 </ApiEndpoint>
 
diff --git a/docs/auth_permissions.md b/docs/auth_permissions.md
@@ -130,7 +130,7 @@ if not user.permissions.check_entity(entity_id, POLICY_CONTROL):
 
 All service actions, fired events and states in Home Assistant have a context object. This object allows us to attribute changes to events and actions. These context objects also contain a user id, which is used for checking the permissions.
 
-It's crucial for permission checking that actions taken on behalf of the user are done with a context containing the user ID. If you are in a service action handler, you should re-use the incoming context `call.context`. If you are inside a WebSocket API or Rest API endpoint, you should create a context with the correct user:
+It's crucial for permission checking that actions taken on behalf of the user are done with a context containing the user ID. If you are in a service action handler, you should reuse the incoming context `call.context`. If you are inside a WebSocket API or Rest API endpoint, you should create a context with the correct user:
 
 ```python
 from homeassistant.core import Context
diff --git a/docs/config_entries_config_flow_handler.md b/docs/config_entries_config_flow_handler.md
@@ -238,7 +238,7 @@ When the translations are merged into Home Assistant, they will be automatically
 
 As mentioned above - each Config Entry has a version assigned to it. This is to be able to migrate Config Entry data to new formats when Config Entry schema changes.
 
-Migration can be handled programatically by implementing function `async_migrate_entry` in your integration's `__init__.py` file. The function should return `True` if migration is successful.
+Migration can be handled programmatically by implementing function `async_migrate_entry` in your integration's `__init__.py` file. The function should return `True` if migration is successful.
 
 The version is made of a major and minor version. If minor versions differ but major versions are the same, integration setup will be allowed to continue even if the integration does not implement `async_migrate_entry`. This means a minor version bump is backwards compatible unlike a major version bump which causes the integration to fail setup if the user downgrades Home Assistant Core without restoring their configuration from backup.
 
diff --git a/docs/core/entity/calendar.md b/docs/core/entity/calendar.md
@@ -52,7 +52,7 @@ and are combined using the bitwise or (`|`) operator.
 
 ### Get events
 
-A calendar entity can return events that occur during a particular time range. Some notes for implementors:
+A calendar entity can return events that occur during a particular time range. Some notes for implementers:
 
 - The `start_date` is the lower bound and applied to the event's `end` (exclusive). This has a `tzinfo` of the local Home Assistant timezone.
 - The `end_date` is the upper bound and applied to the event's `start` (exclusive). This has the same `tzinfo` as `start_date`.
diff --git a/docs/core/entity/camera.md b/docs/core/entity/camera.md
@@ -51,7 +51,7 @@ When the width and height are passed, scaling should be done on a best-effort ba
 
 - Return the smallest image that meets the minimum width and minimum height.
 
-- When scaling the image, aspect ratio must be preserved. If the aspect ratio is not the same as the requsted height or width, it is expected that the width and/or height of the returned image will be larger than requested.
+- When scaling the image, aspect ratio must be preserved. If the aspect ratio is not the same as the requested height or width, it is expected that the width and/or height of the returned image will be larger than requested.
 
 - Pass on the width and height if the underlying camera is capable of scaling the image.
 
diff --git a/docs/core/entity/fan.md b/docs/core/entity/fan.md
@@ -161,7 +161,7 @@ class FanEntity(ToggleEntity):
 
 :::tip `speed` is deprecated.
 
-For new intergrations, `speed` should not be implemented and only `percentage` and `preset_mode` should be used.
+For new integrations, `speed` should not be implemented and only `percentage` and `preset_mode` should be used.
 
 :::
 
diff --git a/docs/core/entity/number.md b/docs/core/entity/number.md
@@ -90,7 +90,7 @@ If specifying a device class, your number entity will need to also return the co
 
 ## Restoring number states
 
-Numbers which restore the state after restart or reload should not extend `RestoreEntity` because  that does not store the `native_value`, but instead the `state` which may have been modifed by the number base entity. Numbers which restore the state should extend `RestoreNumber` and call `await self.async_get_last_number_data` from `async_added_to_hass` to get access to the stored `native_min_value`,  `native_max_value`,  `native_step`,  `native_unit_of_measurement` and `native_value`.
+Numbers which restore the state after restart or reload should not extend `RestoreEntity` because  that does not store the `native_value`, but instead the `state` which may have been modified by the number base entity. Numbers which restore the state should extend `RestoreNumber` and call `await self.async_get_last_number_data` from `async_added_to_hass` to get access to the stored `native_min_value`,  `native_max_value`,  `native_step`,  `native_unit_of_measurement` and `native_value`.
 
 ## Methods
 
diff --git a/docs/core/platform/repairs.md b/docs/core/platform/repairs.md
@@ -116,4 +116,4 @@ ir.async_delete_issue(hass, DOMAIN, "manual_migration")
 
 ## Fixing an issue
 
-If an issue has the `is_fixable` issue set to `True`, the user will be allowed to fix the issue. An issue which is succesfully fixed will be removed from the issue registry.
+If an issue has the `is_fixable` issue set to `True`, the user will be allowed to fix the issue. An issue which is successfully fixed will be removed from the issue registry.
diff --git a/docs/creating_integration_manifest.md b/docs/creating_integration_manifest.md
@@ -67,7 +67,7 @@ it thus will become mandatory in the future.
 | ---- | -----------
 | `device` | Provides a single device like, for example, ESPHome. |
 | `entity` | Provides a basic entity platform, like sensor or light. This should generally not be used. |
-| `hardware` | Provides a hardware integration, like Raspbery Pi or Hardkernel. This should generally not be used. |
+| `hardware` | Provides a hardware integration, like Raspberry Pi or Hardkernel. This should generally not be used. |
 | `helper` | Provides an entity to help the user with automations like input boolean, derivative or group. |
 | `hub` | Provides a hub integration, with multiple devices or services, like Philips Hue. |
 | `service` | Provides a single service, like DuckDNS or AdGuard. |
@@ -370,10 +370,10 @@ Example with setting `registered_devices` to `true`:
 
 ## USB
 
-If your integration supports discovery via usb, you can add the type to your manifest. If the user has the `usb` integration loaded, it will load the `usb` step of your integration's config flow when it is discovered. We support discovery by VID (Vendor ID), PID (Device ID), Serial Number, Manufacturer, and Description by extracting these values from the USB descriptor. For help identifiying these values see [How To Identify A Device](https://wiki.debian.org/HowToIdentifyADevice/USB). The manifest value is a list of matcher dictionaries. Your integration is discovered if all items of any of the specified matchers are found in the USB data. It's up to your config flow to filter out duplicates.
+If your integration supports discovery via usb, you can add the type to your manifest. If the user has the `usb` integration loaded, it will load the `usb` step of your integration's config flow when it is discovered. We support discovery by VID (Vendor ID), PID (Device ID), Serial Number, Manufacturer, and Description by extracting these values from the USB descriptor. For help identifying these values see [How To Identify A Device](https://wiki.debian.org/HowToIdentifyADevice/USB). The manifest value is a list of matcher dictionaries. Your integration is discovered if all items of any of the specified matchers are found in the USB data. It's up to your config flow to filter out duplicates.
 
 :::warning
-Some VID and PID combinations are used by many unrelated devices. For example VID `10C4` and PID `EA60` matches any Silicon Labs CP2102 USB-Serial bridge chip. When matching these type of devices, it is important to match on `description` or another identifer to avoid an unexpected discovery.
+Some VID and PID combinations are used by many unrelated devices. For example VID `10C4` and PID `EA60` matches any Silicon Labs CP2102 USB-Serial bridge chip. When matching these type of devices, it is important to match on `description` or another identifier to avoid an unexpected discovery.
 :::
 
 The following example has two matchers consisting of two items. All of the items in any of the two matchers must match for discovery to happen by this config.
diff --git a/docs/data_entry_flow_index.md b/docs/data_entry_flow_index.md
@@ -191,7 +191,7 @@ To specify an icon for a section, update `icons.json` according to this example:
 
 #### Labels & descriptions
 
-Translations for the form are added to `strings.json` in a key for the `step_id`. That object may contain the folowing keys:
+Translations for the form are added to `strings.json` in a key for the `step_id`. That object may contain the following keys:
 
 |        Key         |       Value         | Notes                                                                                                                                        |
 | :----------------: | :-----------------: | :------------------------------------------------------------------------------------------------------------------------------------------- |
diff --git a/docs/development_catching_up.md b/docs/development_catching_up.md
@@ -3,7 +3,7 @@ title: "Catching up with reality"
 ---
 
 If it's taking a while to develop your feature, and you want to catch up with what's in the current Home Assistant `dev` branch, you can either use `git merge` or `git rebase`.
-Bellow you can find instructions on how to do it using `git merge`. This will pull the latest Home Assistant changes locally, and merge them into your branch by creating a merge commit.
+Below you can find instructions on how to do it using `git merge`. This will pull the latest Home Assistant changes locally, and merge them into your branch by creating a merge commit.
 
 You should have added an additional `remote` after you clone your fork. If you did not, do it now before proceeding:
 
@@ -21,7 +21,7 @@ If git detects any conflicts do the following to solve them:
 
 1. Use `git status` to see the file with the conflict; edit the file and resolve the lines between `<<<< | >>>>`
 2. Add the modified file: `git add <file>` or `git add .`
-3. Finish the merge by commiting it (you can leave the default merge commit message unchanged): `git commit`
+3. Finish the merge by committing it (you can leave the default merge commit message unchanged): `git commit`
 
 Finally, just push your changes as normal:
 
diff --git a/docs/development_guidelines.md b/docs/development_guidelines.md
@@ -39,7 +39,7 @@ _LOGGER.error("No route to device: %s", self._resource)
 ```
 
 Do not print out API keys, tokens, usernames or passwords (even if they are wrong).
-Be restrictive with `_LOGGER.info`, use `_LOGGER.debug` for anything which is not targetting the user.
+Be restrictive with `_LOGGER.info`, use `_LOGGER.debug` for anything which is not targeting the user.
 
 ### Use new style string formatting
 
diff --git a/docs/development_testing.md b/docs/development_testing.md
@@ -40,7 +40,7 @@ It might be required that you install additional packages depending on your dist
 
 :::info Important
 Run `pytest` & `pre-commit` before you create your pull request to avoid annoying fixes.
-`pre-commit` will be invoked automatically by git when commiting changes.
+`pre-commit` will be invoked automatically by git when committing changes.
 :::
 
 :::note
diff --git a/docs/frontend/design.md b/docs/frontend/design.md
@@ -13,4 +13,4 @@ We maintain a design portal at [https://design.home-assistant.io](https://design
 When new components or features are added to the frontend, those need to be added to the design portal. This portal page explains the details on how to do so: [https://design.home-assistant.io/#design.home-assistant.io/editing](https://design.home-assistant.io/#design.home-assistant.io/editing)
 
 :::note
-While the portal is publically named "design", it is referred to as "gallery" in the frontend repository. That is why the script to run the gallery locally in your development environment can be found at `gallery/script/develop_gallery` and the source code in `gallery/src`.
+While the portal is publicly named "design", it is referred to as "gallery" in the frontend repository. That is why the script to run the gallery locally in your development environment can be found at `gallery/script/develop_gallery` and the source code in `gallery/src`.
diff --git a/docs/frontend/external-bus.md b/docs/frontend/external-bus.md
@@ -36,7 +36,7 @@ The message describes an action or a piece of information that the sender wants
 
 The format of a message that contains or provides information is the same. It contains an identifier, a type and an optional payload (depending on the type).
 
-A result message will re-use the identifier in the response, to indicate to which action the response is related.
+A result message will reuse the identifier in the response, to indicate to which action the response is related.
 
 The basic format of a message is the following:
 
diff --git a/docs/intent_conversation_api.md b/docs/intent_conversation_api.md
@@ -143,7 +143,7 @@ An intent can have multiple targets which are applied on top of each other. The
 * `custom`
   * A custom target
 
-Most intents end up with 0, 1 or 2 targets. 3 targets currenly only happens when device classes are involved. Examples of target combinations:
+Most intents end up with 0, 1 or 2 targets. 3 targets currently only happens when device classes are involved. Examples of target combinations:
 
  * "Turn off all lights"
      * 1 target: `domain:light`
diff --git a/docs/operating-system/boards/asus.md b/docs/operating-system/boards/asus.md
@@ -21,7 +21,7 @@ however manual intervention is necessary:
 
  1. Set the jumper between Micro-USB and HDMI the maskrom mode
  2. Insert SD card and connect the board via Micro-USB to your PC
- 3. Continusly press Ctrl+C to interrupt boot
+ 3. Continuously press Ctrl+C to interrupt boot
  4. Set the jumper back to the park position
  5. Start UMS using:
 ```
diff --git a/docs/review-process.md b/docs/review-process.md
@@ -268,7 +268,7 @@ each time you go through the process.
 
 ## Repository specific information
 
-Some of our respositories have specific requirements or guidelines that are
+Some of our repositories have specific requirements or guidelines that are
 applied on top of this general guide.
 
 ### Home Assistant Core

Original file line number	Diff line number	Diff line change
`@@ -116,4 +116,4 @@ ir.async_delete_issue(hass, DOMAIN, "manual_migration")`
`116`	`116`
`117`	`117`	`## Fixing an issue`
`118`	`118`
`119`		-If an issue has the `is_fixable` issue set to `True`, the user will be allowed to fix the issue. An issue which is succesfully fixed will be removed from the issue registry.
	`119`	+If an issue has the `is_fixable` issue set to `True`, the user will be allowed to fix the issue. An issue which is successfully fixed will be removed from the issue registry.