fix: typos (#23435)

JPBotelho · web-flow · commit 2c0d6fd79224 · 2025-09-19T16:05:53.000-07:00
## Description Fixed typos ## Related issues or tickets  ## Reviews   - [ ] Technical review - [ ] Editorial review - [ ] Product review
diff --git a/content/get-started/workshop/04_sharing_app.md b/content/get-started/workshop/04_sharing_app.md
@@ -40,7 +40,7 @@ In the following image, you can see an example Docker command from Docker Hub. T
 
 Let's try to push the image to Docker Hub.
 
-1. In the command line, run the following commmand:
+1. In the command line, run the following command:
 
    ```console
    docker push docker/getting-started
diff --git a/content/guides/testcontainers-cloud/common-questions.md b/content/guides/testcontainers-cloud/common-questions.md
@@ -36,7 +36,7 @@ Testcontainers Cloud supports any language that works with the open-source Testc
 
 ### How is container cleanup handled in Testcontainers Cloud?
 
-While Testcontainers library automatically handles container lifecycle management, Testcontainers Cloud manages the allocated cloud worker lifetime. This means that containers are spun up, monitored, and cleaned up after tests are completed by Testcontainers library, and the worker where these containers have being running will be removed automatically after the ~35 min idle period by Testcontainers Cloud. This approach frees developers from manually managing containers and assosiated cloud resources. 
+While Testcontainers library automatically handles container lifecycle management, Testcontainers Cloud manages the allocated cloud worker lifetime. This means that containers are spun up, monitored, and cleaned up after tests are completed by Testcontainers library, and the worker where these containers have being running will be removed automatically after the ~35 min idle period by Testcontainers Cloud. This approach frees developers from manually managing containers and associated cloud resources. 
 
 ### Is there a free tier or pricing model for Testcontainers Cloud?
 
diff --git a/content/manuals/admin/company/users.md b/content/manuals/admin/company/users.md
@@ -1,7 +1,7 @@
 ---
 title: Manage company members
 description: Learn how to manage company users in the Docker Admin Console.
-keywords: company, company users, users, admin, Admin Console, memeber management, organization management, company management, bulk invite, resend invites
+keywords: company, company users, users, admin, Admin Console, member management, organization management, company management, bulk invite, resend invites
 ---
 
 {{< summary-bar feature_name="Company" >}}
diff --git a/content/manuals/admin/organization/onboard.md b/content/manuals/admin/organization/onboard.md
@@ -23,7 +23,7 @@ Onboarding your organization includes:
 - Enforce sign-in for Docker Desktop to ensure security best practices
 
 These actions help administrators gain visibility into user activity and
-enforce security settings. Organization memebers also receive increased pull
+enforce security settings. Organization members also receive increased pull
 limits and other benefits when they are signed in.
 
 ## Prerequisites
diff --git a/content/manuals/build/building/variables.md b/content/manuals/build/building/variables.md
@@ -323,7 +323,7 @@ They're used to configure the Buildx client, or the BuildKit daemon.
 | [BUILDX_GIT_INFO](#buildx_git_info)                                         | Boolean           | Remove Git information in provenance attestations.               |
 | [BUILDX_GIT_LABELS](#buildx_git_labels)                                     | String \| Boolean | Add Git provenance labels to images.                             |
 | [BUILDX_MEM_PROFILE](#buildx_mem_profile)                                   | String            | Generate a `pprof` memory profile at the specified location.     |
-| [BUILDX_METADATA_PROVENANCE](#buildx_metadata_provenance)                   | String \| Boolean | Customize provenance informations included in the metadata file. |
+| [BUILDX_METADATA_PROVENANCE](#buildx_metadata_provenance)                   | String \| Boolean | Customize provenance information included in the metadata file.  |
 | [BUILDX_METADATA_WARNINGS](#buildx_metadata_warnings)                       | String            | Include build warnings in the metadata file.                     |
 | [BUILDX_NO_DEFAULT_ATTESTATIONS](#buildx_no_default_attestations)           | Boolean           | Turn off default provenance attestations.                        |
 | [BUILDX_NO_DEFAULT_LOAD](#buildx_no_default_load)                           | Boolean           | Turn off loading images to image store by default.               |
diff --git a/content/manuals/desktop/setup/vm-vdi.md b/content/manuals/desktop/setup/vm-vdi.md
@@ -93,6 +93,6 @@ Docker Desktop follows the VDI support definitions outlined [previously](#virtua
 
 For WSL 2-related issues, contact Nutanix support. For Docker Desktop-specific issues, contact Docker support.
 
-## Aditional resources
+## Additional resources
 
 - [Docker Desktop on Microsoft Dev Box](/manuals/enterprise/enterprise-deployment/dev-box.md)
diff --git a/content/manuals/dhi/core-concepts/attestations.md b/content/manuals/dhi/core-concepts/attestations.md
@@ -69,7 +69,7 @@ details](../how-to/explore.md#view-image-variant-details) in Docker Hub.
 |----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|
 | CycloneDX SBOM             | A software bill of materials in [CycloneDX](https://cyclonedx.org/) format, listing components, libraries, and versions.                                                                                                      | `https://cyclonedx.org/bom/v1.5`                  |
 | STIG scan                  | Results of a STIG scan, with output in HTML and XCCDF formats.                                                                                                                           | `https://docker.com/dhi/stig/v0.1`                |
-| CVEs (In-Toto format)      | A list of known vulnerabilities (CVEs) affecting the image's components, based on package and distrobution scanning.                                                                           | `https://in-toto.io/attestation/vulns/v0.1`       |
+| CVEs (In-Toto format)      | A list of known vulnerabilities (CVEs) affecting the image's components, based on package and distribution scanning.                                                                           | `https://in-toto.io/attestation/vulns/v0.1`       |
 | VEX                        | A [Vulnerability Exploitability eXchange (VEX)](https://openvex.dev/) document that identifies vulnerabilities that do not apply to the image and explains why (e.g., not reachable or not present).                         | `https://openvex.dev/ns/v0.2.0`                   |
 | Scout health score         | A signed attestation from Docker Scout that summarizes the overall security and quality posture of the image.                                                                           | `https://scout.docker.com/health/v0.1`            |
 | Scout provenance           | Provenance metadata generated by Docker Scout, including the source Git commit, build parameters, and environment details.                                                               | `https://scout.docker.com/provenance/v0.1`        |
diff --git a/content/manuals/dhi/how-to/migrate.md b/content/manuals/dhi/how-to/migrate.md
@@ -34,7 +34,7 @@ Dockerfile:
 | Non-root user      | By default, images intended for runtime, run as the nonroot user. Ensure that necessary files and directories are accessible to the nonroot user.                                                                                                                                                                              |
 | Multi-stage build  | Utilize images with a `dev` or `sdk` tags for build stages and non-dev images for runtime.                                                                                                                                                                                                                                     |
 | TLS certificates   | DHIs contain standard TLS certificates by default. There is no need to install TLS certificates.                                                                                                                                                                                                                               |
-| Ports              | DHIs intented for runtime run as a nonroot user by default. As a result, applications in these images can't bind to privileged ports (below 1024) when running in Kubernetes or in Docker Engine versions older than 20.10. To avoid issues, configure your application to listen on port 1025 or higher inside the container. |
+| Ports              | DHIs intended for runtime run as a nonroot user by default. As a result, applications in these images can't bind to privileged ports (below 1024) when running in Kubernetes or in Docker Engine versions older than 20.10. To avoid issues, configure your application to listen on port 1025 or higher inside the container. |
 | Entry point        | DHIs may have different entry points than images such as Docker Official Images. Inspect entry points for DHIs and update your Dockerfile if necessary.                                                                                                                                                                        |
 | No shell           | DHIs intended for runtime don't contain a shell. Use dev images in build stages to run shell commands and then copy artifacts to the runtime stage.                                                                                                                                                                            |
 
diff --git a/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md b/content/manuals/enterprise/security/hardened-desktop/enhanced-container-isolation/enable-eci.md
@@ -159,7 +159,7 @@ Settings Management:
 - The **Use Enhanced Container Isolation** setting appears turned on in
 Docker Desktop settings.
 - If set to `"locked": true`, the setting is locked and greyed out.
-- All new containers automatically use Linux user namepsaces.
+- All new containers automatically use Linux user namespaces.
 - Existing development workflows continue to work without modification.
 - Users see `sysbox-runc` as the container runtime in `docker inspect` output.
 
diff --git a/content/manuals/enterprise/security/hardened-desktop/registry-access-management.md b/content/manuals/enterprise/security/hardened-desktop/registry-access-management.md
@@ -45,7 +45,7 @@ Before configuring Registry Access Management, you must:
 To configure registry permissions:
 
 1. Sign in to [Docker Home](https://app.docker.com) and select your organization.
-1. Select **Admin Console**, then **Regsitry access**.
+1. Select **Admin Console**, then **Registry access**.
 1. Use the **toggle** to enable registry access. By default, Docker Hub is enabled
 in the registry list.
 1. To add additional registries, select **Add registry** and provide
diff --git a/content/manuals/enterprise/security/hardened-desktop/settings-management/compliance-reporting.md b/content/manuals/enterprise/security/hardened-desktop/settings-management/compliance-reporting.md
@@ -74,7 +74,7 @@ Indicates the user's policy assignment:
 
 | Settings status | What it means |
 |-----------------|---------------|
-| Global policy | The user is assigned your organzation's default policy. |
+| Global policy | The user is assigned your organization's default policy. |
 | User policy | The user is assigned a specific custom policy. |
 | No policy assigned | The user is not assigned to any policy. |
 
diff --git a/content/manuals/enterprise/security/single-sign-on/_index.md b/content/manuals/enterprise/security/single-sign-on/_index.md
@@ -2,7 +2,7 @@
 title: Single sign-on overview
 linkTitle: Single sign-on
 description: Learn how single sign-on works, how to set it up, and the required SSO attributes.
-keywords: Single Sign-On, SSO, sign-in, admin, docker hub, admin console, security, indentity provider, SSO configuration, enterprise login, Docker Business, user authentication
+keywords: Single Sign-On, SSO, sign-in, admin, docker hub, admin console, security, identity provider, SSO configuration, enterprise login, Docker Business, user authentication
 aliases:
 - /single-sign-on/
 - /admin/company/settings/sso/
diff --git a/content/manuals/enterprise/troubleshoot/troubleshoot-provisioning.md b/content/manuals/enterprise/troubleshoot/troubleshoot-provisioning.md
@@ -16,7 +16,7 @@ This page helps troubleshoot common user provisioning issues including user role
 ### Error message
 
 Typically, this scenario does not produce an error message in Docker or your
-IdP. This issue ususally surfaces as incorrect role or team assignment.
+IdP. This issue usually surfaces as incorrect role or team assignment.
 
 ### Causes
 
diff --git a/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md b/content/manuals/extensions/extensions-sdk/design/mui-best-practices.md
@@ -38,11 +38,11 @@ The best way to build your UI, so that it’s robust against future theming chan
 
 Sometimes you’ll need a piece of UI that doesn’t exist in our design system. If so, we recommend that you first reach out to us. We may already have something in our internal design system, or we may be able to expand our design system to accommodate your use case.
 
-If you still decide to build it yourself after contacting us, try and define the new UI in a reuseable fashion. If you define your custom UI in just one place, it’ll make it easier to change in the future if our core theme changes. You could use:
+If you still decide to build it yourself after contacting us, try and define the new UI in a reusable fashion. If you define your custom UI in just one place, it’ll make it easier to change in the future if our core theme changes. You could use:
 
 -  A new `variant` of an existing component - see [MUI docs](https://mui.com/material-ui/customization/theme-components/#creating-new-component-variants)
--  A MUI mixin (a freeform bundle of reuseable styling rules defined inside a theme)
--  A new [reuseable component](https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component)
+-  A MUI mixin (a freeform bundle of reusable styling rules defined inside a theme)
+-  A new [reusable component](https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component)
 
 Some of the above options require you to extend our MUI theme. See the MUI documentation on [theme composition](https://mui.com/material-ui/customization/theming/#nesting-the-theme).
 
diff --git a/content/reference/api/hub/latest.yaml b/content/reference/api/hub/latest.yaml
@@ -3243,7 +3243,7 @@ components:
           example: moby
         invitee:
           type: string
-          description: can either be a dockerID for registred users or an email for non-registred users
+          description: can either be a dockerID for registered users or an email for non-registered users
           example: invitee@docker.com
         org:
           type: string
@@ -3373,7 +3373,7 @@ components:
             - owners
         is_guest:
           type: boolean
-          description: If the organization has verfied domains, members that have email addresses outside of those domains will be flagged as guests.
+          description: If the organization has verified domains, members that have email addresses outside of those domains will be flagged as guests.
           example: false
         primary_email:
           type: string
