Update typos action and fix typos (#1661)

Signed-off-by: Kévin Commaille <[email protected]>

.github/workflows/spell-check.yaml

@@ -14,6 +14,6 @@ jobs:
       uses: actions/checkout@v4
 
     - name: Check spelling of proposals
-      uses: crate-ci/typos@9be36f97fdbe645ee9a12449fb13aca856c2516a
+      uses: crate-ci/typos@ff3f309513469397e1094520fb7a054e057589e1
       with:
         config: ${{github.workspace}}/.github/_typos.toml

changelogs/client_server/newsfragments/1661.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

changelogs/server_server/newsfragments/1661.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

data/api/client-server/create_room.yaml

@@ -209,7 +209,7 @@ paths:
                     based on a preset.
 
                     If unspecified, the server should use the `visibility` to determine
-                    which preset to use. A visbility of `public` equates to a preset of
+                    which preset to use. A visibility of `public` equates to a preset of
                     `public_chat` and `private` visibility equates to a preset of
                     `private_chat`.
                 is_direct:

data/api/client-server/login_token.yaml

@@ -39,7 +39,7 @@ paths:
 
         In v1.7 of the specification, transmission of the generated token to an unauthenticated client is
         left as an implementation detail. Future MSCs such as [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906)
-        might standarise a way to transmit the token between clients.
+        might standardise a way to transmit the token between clients.
 
         The generated token MUST only be valid for a single login, enforced by the server. Clients which
         intend to log in multiple devices must generate a token for each.

data/api/server-server/joins-v2.yaml

@@ -27,7 +27,7 @@ paths:
         exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
+        a more standardised response format. Senders which receive
         a 400, 404, or other status code which indicates this endpoint
         is not available should retry using the v1 API instead.
 

data/api/server-server/leaving-v2.yaml

@@ -27,7 +27,7 @@ paths:
         exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
+        a more standardised response format. Senders which receive
         a 400, 404, or other status code which indicates this endpoint
         is not available should retry using the v1 API instead.
 

meta/documentation_style.rst

@@ -191,4 +191,4 @@ Describing grammar
 
 Use  `RFC5234-style ABNF <https://datatracker.ietf.org/doc/html/rfc5234>`_ when describing
 the grammar for something in the spec, such as user IDs or server names. Use lowercase
-and underscore-deliminated element names (`user_id`, not `UserID` or `user-id`).
+and underscore-delimited element names (`user_id`, not `UserID` or `user-id`).

meta/releasing.md

@@ -31,7 +31,7 @@ day until the release has actually happened & blog post published.
 
 Once a release is scheduled, the SCT will begin planning what the next release is
 expected to look like. The plan should be included in the spec release blog post,
-and be ready for exeuction on spec release day. Plans are guides and not promises.
+and be ready for execution on spec release day. Plans are guides and not promises.
 
 A blog post for the SCT members to review should be ready at minimum 1 week before
 the target release date. 1-2 days before the release itself, the prerequisite steps