Fix vale issues (#12532)

ericholscher · web-flow · commit afac3f129f3c · 2025-11-03T10:21:34.000-08:00
diff --git a/common b/common
@@ -1 +1 @@
-Subproject commit 6f242c03c49c7bcb4680a3e0181f23425c4ac036
+Subproject commit 6da49a92d8b29a1c5ca804a66baa0615daf7df63
diff --git a/docs/dev/aws-temporary-credentials.rst b/docs/dev/aws-temporary-credentials.rst
@@ -2,7 +2,7 @@ AWS temporary credentials
 =========================
 
 Builders run arbitrary commands provided by the user, while we run the commands in a sandboxed environment (docker),
-that shouln't be the only line of defense, as we still interact with the files generated by the user outside docker for some operations.
+that shouldn't be the only line of defense, as we still interact with the files generated by the user outside docker for some operations.
 
 This is why instead of using credentials that have access to all the resources in AWS,
 we are using credentials that are generated by the `AWS STS service <https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html>`__,
diff --git a/docs/dev/contribute.rst b/docs/dev/contribute.rst
@@ -174,7 +174,7 @@ label. The reported issue …
 
     Examples:
 
-    - *Refactor namedtuples to dataclasess*
+    - *Refactor namedtuples to dataclasses*
     - *Change font size for the project's title*
 
 … is a valid problem within the code base:
diff --git a/docs/dev/design/build-images.rst b/docs/dev/design/build-images.rst
@@ -39,7 +39,7 @@ on each image without asking the users to change the image selected in their con
 Then, when a completely different image appeared and after testing ``testing`` image enough,
 we discarded ``stable``, old ``latest`` became the new ``stable`` and old ``testing`` became the new ``latest``.
 This produced issues to people pinning their images to any of these names because after this change,
-*we changed all the images for all the users* and many build issues arrised!
+*we changed all the images for all the users* and many build issues arose!
 
 
 Goals
@@ -222,7 +222,7 @@ Python versions can be pre-compiled once and expose the output on the S3 for the
 .. tip::
 
    Since we are building a special cache for pre-compiled Python versions,
-   we could use the same method for all the other languages instead of creating a full mirror (many Gigabyes)
+   we could use the same method for all the other languages instead of creating a full mirror (many Gigabytes)
    This simple `bash script`_ download the language sources, compiles it and upload it to S3 without requiring a mirror.
    Note that it works in the same way for all the languages, not just for Python.
 
diff --git a/docs/dev/design/future-builder.rst b/docs/dev/design/future-builder.rst
@@ -16,7 +16,7 @@ proposing a clear direction to move forward with intermediate steps keeping back
    A lot of things have changed since this document was written.
    We have had multiple discussions where we already took some decisions and discarded some of the ideas/details proposed here.
    The document was merged as-is without a cleaned up and there could be some inconsistencies.
-   Note that ``build.jobs`` and ``build.commands`` are already implemented *without definig a contract* yet,
+   Note that ``build.jobs`` and ``build.commands`` are already implemented *without defining a contract* yet,
    and with small differences from the idea described here.
 
    Please, refer to the following links to read more about all the discussions we already had:
diff --git a/docs/dev/design/new-notifications-system.rst b/docs/dev/design/new-notifications-system.rst
@@ -63,7 +63,7 @@ Small notes and other considerations
 * How do we handle translations?
   We should use ``_("This is the message shown to the user")`` in Python code and return the proper translation when they are read.
 * Reduce complexity on ``Build`` object (remove ``Build.status`` and ``Build.error`` fields among others).
-* Since the ``Build`` object could have more than 1 notification, when showing them, we will sort them by importane: errors, warnings, note, tip.
+* Since the ``Build`` object could have more than 1 notification, when showing them, we will sort them by importance: errors, warnings, note, tip.
 * In case we need a pretty specific order, we can add an extra field for that, but it adds unnecessary complexity at this point.
 * For those notifications that are attached to the ``Project`` or ``Organization``, should it be shown to all the members even if they don't have admin permissions?
   If yes, this is good because all of them will be notified but only some of them will be able to take an action.
@@ -452,7 +452,7 @@ Notification update
 Backward compatibility
 ----------------------
 
-It's not strickly required, but if we want, we could extract the current notification logic from:
+It's not strictly required, but if we want, we could extract the current notification logic from:
 
 * Django templates
 
diff --git a/docs/dev/design/secure-api-access-from-builders.rst b/docs/dev/design/secure-api-access-from-builders.rst
@@ -161,7 +161,7 @@ since it also handles authentication).
 Decision
 --------
 
-Due to the fact that the required features from knox are not released yet,
+Because the required features from knox are not released yet,
 we have decided to use DRF API key instead.
 
 Future work
diff --git a/docs/dev/github-app.rst b/docs/dev/github-app.rst
@@ -4,7 +4,7 @@ GitHub App
 Our GitHub App integration consists of a GitHub App (one for each platform, readthedocs.org and readthedocs.com),
 which can be installed on a user's account or organization.
 
-After installing the GitHub App, users can grant acccess to all repositories or select specific repositories,
+After installing the GitHub App, users can grant access to all repositories or select specific repositories,
 this allows Read the Docs to access the repositories and perform actions on them, such as reporting build statuses,
 and subscribe to events like push and pull request events.
 
@@ -42,5 +42,5 @@ Security
 - Since we make use of the installation to perform actions on the repositories instead of the user's OAuth2 token,
   we make sure that only users with admin permissions on the repository can link the repository to a Read the Docs project.
 - Once we lose access to a repository (e.g. the installation is uninstalled or revoked, or the project was deselected from the installation),
-  we remove the remote repository from the database, as we don't want to keep the relation bettween the project and the repository.
+  we remove the remote repository from the database, as we don't want to keep the relation between the project and the repository.
   This is to prevent connecting the repository to the project again without the user's consent if they grant access to the repository again.
diff --git a/docs/user/commercial/sharing.rst b/docs/user/commercial/sharing.rst
@@ -119,7 +119,7 @@ you need to authenticate those users against your own system first.
 The simplest way to do this is to create an authenticated redirect on your site,
 which then redirects to the Read the Docs :ref:`commercial/sharing:secret link`.
 
-This should require very little customization,
+This should require minimal customization,
 and will ensure that only authenticated users can access the documentation.
 The downside is that users won't be able to access the documentation directly from a bookmark,
 and will have to go through your site first.
diff --git a/docs/user/guides/best-practice/links.rst b/docs/user/guides/best-practice/links.rst
@@ -61,7 +61,7 @@ Good practice ✅
   keep original file names rather than going for low-impact URL renaming.
   Renaming an article's title is great for the reader and great for SEO,
   but this does not have to involve the URL.
-* Establish your understanding of the *latest* and :term:`default version` of your documentation at the beginning. Changing their meaning is very disruptive to incoming links.
+* Establish your understanding of the *latest* and :term:`default version` of your documentation at the beginning. Changing their meaning is disruptive to incoming links.
 * Keep development versions :ref:`hidden <versions:Version states>` so people do not find them on search engines by mistake.
   This is the best way to ensure that nobody links to URLs that are intended for development purposes.
 * Use a :ref:`version warning notifications <versions:Version warning notifications>` to ensure the reader is aware in case they are reading an old (archived) version.
diff --git a/docs/user/guides/build-troubleshooting.rst b/docs/user/guides/build-troubleshooting.rst
@@ -18,7 +18,7 @@ terminal prompts disabled
 
    fatal: could not read Username for 'https://github.com': terminal prompts disabled
 
-**Resolution:** This error can be quite misleading. It usually occurs when a repository could not be found because of a typo in the reposistory name or because the repository has been deleted. Verify your repository URL in :guilabel:`Admin > Settings`.
+**Resolution:** This error can be quite misleading. It usually occurs when a repository could not be found because of a typo in the repository name or because the repository has been deleted. Verify your repository URL in :guilabel:`Admin > Settings`.
 
 This error also occurs if you have changed a ``public`` repository to ``private`` and you are using ``https://`` in your git repository URL.
 
diff --git a/docs/user/guides/connecting-git-account.rst b/docs/user/guides/connecting-git-account.rst
@@ -59,7 +59,7 @@ but you should also disable our OAuth Application from your Git provider.
 
 * On GitHub, navigate to `Authorized OAuth Apps`_.
 * On Bitbucket, navigate to `Application Authorizations`_.
-* On GitLab, navigat to `Applications`_
+* On GitLab, navigate to `Applications`_
 
 .. _Authorized OAuth Apps: https://github.com/settings/applications
 .. _Application Authorizations: https://bitbucket.org/account/settings/app-authorizations/
diff --git a/docs/user/guides/creating-project-private-repository.rst b/docs/user/guides/creating-project-private-repository.rst
@@ -147,7 +147,7 @@ Configuring repository webhooks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Your repository will also need to be configured to push updates via webhooks to Read the Docs on repository events.
-Webhook updates are used to automatically trigger new builds for your project and syncronize your repository's branches and tags.
+Webhook updates are used to automatically trigger new builds for your project and synchronize your repository's branches and tags.
 
 This step is the same for public repositories,
 follow the directions for :doc:`manually configuring a Git repository integration </guides/setup/git-repo-manual>`.
diff --git a/docs/user/guides/deprecating-content.rst b/docs/user/guides/deprecating-content.rst
@@ -66,7 +66,7 @@ to avoid search engines of showing those results. For example::
 
    Disallow: /en/latest/api/v1.html # Deprecated API
 
-But your users will still see search results from that page if they use the search from your docs.
+However, your users will still see search results from that page if they use the search from your docs.
 With Read the Docs you can set a :ref:`custom rank per pages <config-file/v2:search.ranking>`.
 For example:
 
@@ -96,7 +96,7 @@ Moving and deleting pages
 After you have deprecated a feature for a while,
 you may want to get rid of its documentation,
 that's OK, you don't have to maintain that content forever.
-But be aware that users may have links of that page saved,
+However, be aware that users may have links of that page saved,
 and it will be frustrating and confusing for them to get a 404.
 
 To solve that problem you can create a redirect to a page with a similar feature/content,
diff --git a/docs/user/guides/technical-docs-seo-guide.rst b/docs/user/guides/technical-docs-seo-guide.rst
@@ -56,7 +56,7 @@ as they apply to technical documentation, your site should:
   Sphinx uses the source filename without the file extension as the URL.
 * Make sure the words your readers would search for to find your site
   are actually included on your pages.
-* Avoid low content pages or pages with very little original content.
+* Avoid low content pages or pages with minimal original content.
 * Avoid tactics that attempt to increase your search engine ranking
   without actually improving content.
 * Google specifically `warns about automatically generated content`_
diff --git a/docs/user/science.rst b/docs/user/science.rst
@@ -114,7 +114,7 @@ We want science communities to use Read the Docs and to be part of the documenta
 Getting started: Jupyter Book
 -----------------------------
 
-:external+jupyterbook:doc:`Jupyter Book <intro>` on Read the Docs brings you the rich experience of computated `Jupyter <https://jupyter.org/>`__ documents built together with a modern documentation tool. The results are beautiful and automatically deployed websites, built with Sphinx and :doc:`Executable Book <executablebook:index>` + all the extensions available in this ecosystem.
+:external+jupyterbook:doc:`Jupyter Book <intro>` on Read the Docs brings you the rich experience of computed `Jupyter <https://jupyter.org/>`__ documents built together with a modern documentation tool. The results are beautiful and automatically deployed websites, built with Sphinx and :doc:`Executable Book <executablebook:index>` + all the extensions available in this ecosystem.
 
 Here are some popular activities that are well-supported by Jupyter Book:
 
diff --git a/docs/user/security-implications.rst b/docs/user/security-implications.rst
@@ -60,7 +60,7 @@ but it requires users to be previously authenticated in the embedded domain.
 
 It's important to note that embedding documentation pages in an iframe does not grant the parent page access the iframe's content.
 Documentation pages serve static content only, and the exposed APIs are read-only,
-making the exploitation of a clickjacking vulnerability very unlikely.
+making the exploitation of a clickjacking vulnerability extremely unlikely.
 
 If needed, the ``X-Frame-Options`` and ``Content-Security-Policy`` headers can be set on your documentation pages by :doc:`contacting support </support>`.
 **You are responsible for providing the correct values for these headers, and making sure they don't break your documentation pages.**
diff --git a/docs/user/security.rst b/docs/user/security.rst
@@ -5,7 +5,7 @@
 Security reports
 ================
 
-Security is very important to us at Read the Docs.
+Security is extremely important to us at Read the Docs.
 We follow generally accepted industry standards to protect the personal information
 submitted to us, both during transmission and once we receive it.
 In the spirit of transparency,
diff --git a/docs/user/tutorial/index.rst b/docs/user/tutorial/index.rst
@@ -81,7 +81,7 @@ On the authorization page, click the green :guilabel:`Authorize readthedocs` but
 After that, you will be redirected to Read the Docs to confirm your e-mail and username. Click the :guilabel:`Sign Up »` button to create your account and
 open your :term:`dashboard`.
 
-When you have clicked the link in your emaill from Read the Docs to "verify your email address" and finalize the process, your Read the Docs account will be ready to create your first project.
+When you have clicked the link in your email from Read the Docs to "verify your email address" and finalize the process, your Read the Docs account will be ready to create your first project.
 
 .. figure:: /_static/images/tutorial/rtd-empty-dashboard.png
    :width: 80%
@@ -301,7 +301,7 @@ Making build warnings more visible
 If you navigate to your HTML documentation,
 you will notice that the index page looks correct
 but the API section is empty.
-This is a very common issue with Sphinx,
+This is a common issue with Sphinx,
 and the reason is stated in the build logs.
 On the build page you opened before,
 click on the :guilabel:`View raw` link on the top right,
