codespell the docs directory (#11664)

cclauss · web-flow · commit 05e2852c6582 · 2024-10-12T14:39:29.000+02:00
diff --git a/docs/Makefile b/docs/Makefile
@@ -4,7 +4,7 @@
 # You can set these variables from the command line.
 
 # Options should be aligned with how the documentation is built on RTD
-# (except for '--keep-going', failing fast is prefered on local builds)
+# (except for '--keep-going', failing fast is preferred on local builds)
 # We also remove '-E' to reduce the time of rebuilding reference indexes
 # on each build.
 SPHINXOPTS    = -T -j auto -W
diff --git a/docs/dev/design/better-doc-urls-handling.rst b/docs/dev/design/better-doc-urls-handling.rst
@@ -42,7 +42,7 @@ Instead of trying to map a URL to a view,
 we first analyze the root project (given from the subdomain),
 and based on that we map each part of the URL to the *current* project and version.
 
-This will allow us to re-use this code in our unresolver
+This will allow us to reuse this code in our unresolver
 without the need to override the Django's urlconf at runtime,
 or guessing a project only by the structure of its URL.
 
@@ -61,7 +61,7 @@ Look up process
 ---------------
 
 Proxito will process all documentation requests from a single *docs serve* view,
-exluding ``/_`` URLs.
+excluding ``/_`` URLs.
 
 This view then will process the current URL using the root project as follows:
 
diff --git a/docs/dev/design/build-images.rst b/docs/dev/design/build-images.rst
@@ -265,7 +265,7 @@ and we can roll back if the new pre-compiled version was built with a problem.
 
    Installing always the latest version is harder to maintain.
    It will require building the newest version each time a new patch version is released.
-   Beacause of that, Read the Docs will always be behind official releases.
+   Because of that, Read the Docs will always be behind official releases.
    Besides, it will give projects different versions more often.
 
    Exposing to the user the patch version would require to cache many different versions ourselves,
@@ -287,7 +287,7 @@ How do we remove an old Python version?
 At some point, an old version of Python will be deprecated (eg. 3.4) and will be removed.
 To achieve this, we can just remove the pre-compiled Python version from the cache.
 
-However, unless it's strictly neeed for some specific reason, we shouldn't require to remove support for a Python version
+However, unless it's strictly needed for some specific reason, we shouldn't require to remove support for a Python version
 as long as we support the Ubuntu OS version where this version was compiled for.
 
 In any case, we will know which projects are using these versions because they are pinning these specific versions in the config file.
@@ -424,10 +424,10 @@ that doesn't seem to be useful to have the same OS version with different states
 Allowing users to install extra languages by using the Config File will cover most of the support requests we have had in the past.
 It also will allow us to know more about how our users are using the platform to make future decisions based on this data.
 Exposing users how we want them to use our platform will allow us to be able to maintain it longer,
-than giving the option to select a specific Docker image by name that we can't guarrantee it will be frozen.
+than giving the option to select a specific Docker image by name that we can't guarantee it will be frozen.
 
 Finally, having the ability to deprecate and *remove* pre-built images from our builders over time,
-will reduce the maintainance work required from the the core team.
+will reduce the maintenance work required from the the core team.
 We can always support all the languages versions by installing them at build time.
 The only required pre-built image for this are the OS ``-base`` images.
 In fact, even after decided to deprecate and removed a pre-built image from the builders,
diff --git a/docs/dev/design/file-tree-diff.rst b/docs/dev/design/file-tree-diff.rst
@@ -311,7 +311,7 @@ For the initial implementation, we will:
   not the whole file.
 - MD5 will be the hashing algorithm used.
 - Only expose the files that were added, removed, or modified (HTML files only).
-  The number of lines that changed wont be exposed.
+  The number of lines that changed won't be exposed.
 - Don't store the results in the DB,
   we can store the results in a next iteration.
 - Expose this feature only via the addons feature.
@@ -320,7 +320,7 @@ For the initial implementation, we will:
 
 Other features that are not mentioned here, like exposing the number of lines that changed,
 or a public API, will not be implemented in the initial version,
-and may be considered in the future (and thier implementation is subject to change).
+and may be considered in the future (and their implementation is subject to change).
 
 Possible issues
 ---------------
@@ -350,7 +350,7 @@ Future improvements and ideas
   we would need to re-fetch that metadata from S3.
   Could be a feature request for rclone.
 - Detect changes in sections of HTML files.
-  We could re-use the code we have for search indexing.
+  We could reuse the code we have for search indexing.
 - Expand to other file types
 - Allow doing a diff between versions of different projects
 - Allow to configure how the main content of the file is detected
diff --git a/docs/dev/design/new-notifications-system.rst b/docs/dev/design/new-notifications-system.rst
@@ -34,7 +34,7 @@ Goals
 * Ability to add non-error notifications from the build process
 * Add extra metadata associated to the notification: icon, header, body, etc
 * Support different types of notifications (e.g. error, warning, note, tip)
-* Re-use the new notification system for product updates (e.g. new features, deprecated config keys)
+* Reuse the new notification system for product updates (e.g. new features, deprecated config keys)
 * Message content lives on Python classes that can be translated and formatted with objects (e.g. Build, Project)
 * Message could have richer content (e.g. HTML code) to generate links and emphasis
 * Notifications have trackable state (e.g. unread (default)=never shown, read=shown, dismissed=don't show again, cancelled=auto-removed after user action)
@@ -43,7 +43,7 @@ Goals
 * Notifications can be attached to Project, Organization, Build and User models
 * Specific notifications can be shown under the user's bell icon
 * Easy way to cleanup notification on status changes (e.g. subscription failure notification is auto-deleted after CC updated)
-* Notifications attached to Organization/Project dissappear for all the users once they are dismissed by anyone
+* Notifications attached to Organization/Project disappear for all the users once they are dismissed by anyone
 
 
 Non-goals
@@ -88,7 +88,7 @@ This section shows all the classes and models involved for the notification syst
 .. note:: Accessing the database from the build process
 
     Builders doesn't have access to the database due to security reasons.
-    We had solved this limitation by creating an API endpoint the builder hits once they need to interact with the databse to get a ``Project``, ``Version`` and ``Build`` resources, create a ``BuildCommand`` resource, etc.
+    We had solved this limitation by creating an API endpoint the builder hits once they need to interact with the database to get a ``Project``, ``Version`` and ``Build`` resources, create a ``BuildCommand`` resource, etc.
 
     Besides, the build process is capable to trigger Celery tasks that are useful for managing more complex logic
     that also require accessing from and writing to the database.
@@ -116,7 +116,7 @@ and some helper logic to return in the API response.
             body = str
             icon = str
             icon_style = str(SOLID, DUOTONE)
-            type = str(ERROR, WARINIG, NOTE, TIP)
+            type = str(ERROR, WARNING, NOTE, TIP)
 
         def get_display_icon(self):
             if self.icon:
@@ -201,7 +201,7 @@ It contains an identifier (``message_id``) pointing to one of the messages defin
         message_id = models.CharField(max_length=128)
 
         # UNREAD: the notification was not shown to the user
-        # READ: the notifiation was shown
+        # READ: the notification was shown
         # DISMISSED: the notification was shown and the user dismissed it
         # CANCELLED: removed automatically because the user has done the action required (e.g. paid the subscription)
         state = models.CharField(
@@ -210,7 +210,7 @@ It contains an identifier (``message_id``) pointing to one of the messages defin
             db_index=True,
         )
 
-        # Makes the notification imposible to dismiss (useful for Build notifications)
+        # Makes the notification impossible to dismiss (useful for Build notifications)
         dismissable = models.BooleanField(default=False)
 
         # Show the notification under the bell icon for the user
diff --git a/docs/dev/design/new-search-api.rst b/docs/dev/design/new-search-api.rst
@@ -139,7 +139,7 @@ like the projects, versions, and the query that were used in the final search.
 And the ``version``, ``project``, and ``project_alias`` attributes will
 now be objects.
 
-We could just re-use the old response too,
+We could just reuse the old response too,
 since the only breaking changes would be the attributes now being objects,
 and we aren't adding any new information to those objects (yet).
 But also, re-using the current serializers shouldn't be a problem either.
@@ -230,7 +230,7 @@ the readthedocs.org/readthedocs.com domains.
 We have two types:
 
 Project scoped search:
-   Search files and versions of the curent project only.
+   Search files and versions of the current project only.
 
 Global search:
    Search files and versions of all projects in .org,
diff --git a/docs/dev/design/pr-builder.rst b/docs/dev/design/pr-builder.rst
@@ -43,7 +43,7 @@ We might consider adding a ``VERSION_TYPES`` to the ``Version`` model.
 - If we go with ``VERSION_TYPES`` we can add something like ``pull_request`` alongside Tag and Branch.
 
 We should add ``Version`` and ``Build`` Model Managers for PR and Regular Versions and Builds.
-The proposed names for PR and Regular Version and Build Mangers are ``external`` and ``internal``.
+The proposed names for PR and Regular Version and Build Managers are ``external`` and ``internal``.
 
 We can then use ``Version.internal.all()`` to get all regular versions,
 ``Version.external.all()`` to get all PR versions.
diff --git a/docs/dev/design/redirects.rst b/docs/dev/design/redirects.rst
@@ -386,7 +386,7 @@ We can do this in three ways:
   We could limit the number of redirects that can be created with query arguments,
   or the number of redirects in general.
 
-We hava had only one user requesting this feature,
+We have had only one user requesting this feature,
 so this is not a priority.
 
 Migration
diff --git a/docs/dev/design/secure-api-access-from-builders.rst b/docs/dev/design/secure-api-access-from-builders.rst
@@ -98,7 +98,7 @@ Why attach tokens to users?
 ---------------------------
 
 Attaching tokens to users will ease the implementation,
-since we can re-use the code from knox package.
+since we can reuse the code from knox package.
 
 Attaching tokens to projects only is possible,
 but it will require to manage the authentication manually.
@@ -108,7 +108,7 @@ An alternative is to use the DRF API key package, which doesn't require a user,
 but then if we wanted to extend this functionality to our normal APIs, we will have
 to implement the authentication manually.
 
-Kepping backwards compatibility
+Keeping backwards compatibility
 -------------------------------
 
 Access to write API V2 is restricted to superusers,
@@ -161,7 +161,7 @@ since it also handles authentication).
 Decision
 --------
 
-Due to the fact that the required featues from knox are not released yet,
+Due to the fact that 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/search-integration.rst b/docs/dev/search-integration.rst
@@ -190,7 +190,7 @@ will be indexed as part of the section content:
          <h1 id="3">This is also a valid section title</h1>
       </header>
       <p>
-         Thi is the content of the third section.
+         This is the content of the third section.
       </p>
    </div>
 
diff --git a/docs/dev/subscriptions.rst b/docs/dev/subscriptions.rst
@@ -74,7 +74,7 @@ and it's manually created by the RTD core team.
 To create a custom plan, you need to create a new product in Stripe,
 and add the product id to the ``RTD_PRODUCTS`` setting mapped to the features that the plan will provide.
 After that, you can create a subscription for the organization with the custom product,
-our appliction will automatically relate this new product to the organization.
+our application will automatically relate this new product to the organization.
 
 Extra products
 --------------
@@ -87,4 +87,4 @@ extra product will provide, this product should have the ``extra`` attribute set
 
 To subscribe an organization to an extra product,
 you just need to add the product to its subscription with the desired quantity,
-our appliction will automatically relate this new product to the organization.
+our application will automatically relate this new product to the organization.
diff --git a/docs/user/api/v3.rst b/docs/user/api/v3.rst
@@ -1958,7 +1958,7 @@ Remote repository listing
     The ``results`` in response is an array of remote repositories data.
 
     :query string name: return remote repositories containing the name
-    :query string full_name: return remote repositories containing the full name (it inclues the username/organization the project belongs to)
+    :query string full_name: return remote repositories containing the full name (it includes the username/organization the project belongs to)
     :query string vcs_provider: return remote repositories for specific vcs provider (``github``, ``gitlab`` or ``bitbucket``)
     :query string organization: return remote repositories for specific remote organization (using remote organization ``slug``)
     :query string expand: Add additional fields in the response.
diff --git a/docs/user/builds.rst b/docs/user/builds.rst
@@ -91,7 +91,7 @@ Read the Docs supports three different mechanisms to cancel a running build:
    When Read the Docs detects a push to a version that is already building,
    it cancels the running build and starts a new build using the latest commit.
 
-:Programatically:
+:Programmatically:
 
    You can use user-defined commands on ``build.jobs`` or ``build.commands`` (see :doc:`build-customization`)
    to check for your own cancellation condition and then return exit code ``183`` to cancel a build.
diff --git a/docs/user/faq.rst b/docs/user/faq.rst
@@ -325,7 +325,7 @@ According to `its own documentation <https://jupyterbook.org/>`_,
 
 Even though `Jupyter Book leverages Sphinx "for almost everything that it
 does" <https://jupyterbook.org/explain/sphinx.html#jupyter-book-is-a-distribution-of-sphinx>`_,
-it purposedly hides Sphinx ``conf.py`` files from the user,
+it purposely hides Sphinx ``conf.py`` files from the user,
 and instead generates them on the fly from its declarative ``_config.yml``.
 As a result, you need to follow some extra steps
 to make Jupyter Book work on Read the Docs.
diff --git a/docs/user/glossary.rst b/docs/user/glossary.rst
@@ -95,7 +95,7 @@ so that you have a reference for how we're using them.
       Another name for :term:`project home`.
 
    reproducible
-      A documentation project is said to be *reproducible* when its sources build correctly on Read the Docs over a periode of many years.
+      A documentation project is said to be *reproducible* when its sources build correctly on Read the Docs over a period of many years.
       You can also think of being *reproducible* as being *robust* or *resillient*.
 
       Being "reproducible" is an important positive quality goal of documentation.
diff --git a/docs/user/intro/add-project.rst b/docs/user/intro/add-project.rst
@@ -13,7 +13,7 @@ Automatically add your project
 
 #. Go to your :term:`dashboard`.
 #. Click on :guilabel:`Add project`.
-#. Type the name of the respository you want to add and click on it.
+#. Type the name of the repository you want to add and click on it.
 #. Click on :guilabel:`Continue`.
 #. Edit any of the pre-filled fields with information of the repository.
 #. Click on :guilabel:`Next`.
diff --git a/docs/user/science.rst b/docs/user/science.rst
@@ -130,7 +130,7 @@ Here are some popular activities that are well-supported by Jupyter Book:
 Ready to get started?
 """""""""""""""""""""
 
-.. Note that this is a deliberate repitition of a previous segment. Should it repeat? Maybe not, but for now it's nice to be sure that people see it.
+.. Note that this is a deliberate repetition of a previous segment. Should it repeat? Maybe not, but for now it's nice to be sure that people see it.
 
 * All new to this? Take the official :external+jupyterbook:doc:`Jupyter Book Tutorial » <start/your-first-book>`
 * Curious for practical code? See the list of :doc:`example projects » </examples>`
diff --git a/docs/user/server-side-search/api.rst b/docs/user/server-side-search/api.rst
@@ -153,7 +153,7 @@ with the following changes:
 
 When searching on a parent project,
 results from their subprojects won't be included automatically,
-to include results from subprojects use the ``subprojects`` paramater.
+to include results from subprojects use the ``subprojects`` parameter.
 
 Authentication and authorization
 --------------------------------
diff --git a/docs/user/tutorial/index.rst b/docs/user/tutorial/index.rst
@@ -119,7 +119,7 @@ To import your GitHub project to Read the Docs:
    Default branch
       Name of the default branch of the project, leave it as ``main``.
 
-   Then click the :guilabel:`Next` button to create the poject and open the :term:`project home`.
+   Then click the :guilabel:`Next` button to create the project and open the :term:`project home`.
 
 You just created your first project on Read the Docs! |:tada:|
 
@@ -167,7 +167,7 @@ To see the build logs:
 
    If you don't see the ad, you might be using an ad blocker.
    Our EthicalAds network respects your privacy, doesn't target you,
-   and tries to be as unobstrusive as possible,
+   and tries to be as unobtrusive as possible,
    so we would like to kindly ask you to :doc:`not block us </advertising/ad-blocking>` |:heart:|
 
 Configuring the project
@@ -242,7 +242,7 @@ Build process configuration settings are in ``.readthedocs.yaml`` :doc:`configur
 .. TODO: We are adding a how-to that we need to include in this tutorial.
 .. Maybe by reference or maybe as full-featured content.
 
-.. TODO there is a bit of handwaving about whether you're commiting and merging branches here, we might need to be a bit more explicit. Or at least add a mention at this level that wherever we talk about editing, we mean on main and pushing to GH.
+.. TODO there is a bit of handwaving about whether you're committing and merging branches here, we might need to be a bit more explicit. Or at least add a mention at this level that wherever we talk about editing, we mean on main and pushing to GH.
 
 Using different Python versions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
