wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update typos action and fix typos (#1661)

Browse source 
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2023-10-11 12:42:05 +02:00 • committed by GitHub
parent 560d98ba9b
commit 9fe119370b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
9 changed files with 9 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.github/workflows/spell-check.yaml vendored
View file

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

1
changelogs/client_server/newsfragments/1661.clarification Normal file
View file

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

1
changelogs/server_server/newsfragments/1661.clarification Normal file
View file

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

2
data/api/client-server/create_room.yaml
View file

@ -209,7 +209,7 @@ paths:
based on a preset. based on a preset.
If unspecified, the server should use the `visibility` to determine 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 `public_chat` and `private` visibility equates to a preset of
`private_chat`. `private_chat`.
is_direct: is_direct:

2
data/api/client-server/login_token.yaml
View file

@ -39,7 +39,7 @@ paths:
In v1.7 of the specification, transmission of the generated token to an unauthenticated client is 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) 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 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. intend to log in multiple devices must generate a token for each.

2
data/api/server-server/joins-v2.yaml
View file

@ -27,7 +27,7 @@ paths:
exception of the response format being fixed. exception of the response format being fixed.
This endpoint is preferred over the v1 API as it provides 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 a 400, 404, or other status code which indicates this endpoint
is not available should retry using the v1 API instead. is not available should retry using the v1 API instead.

2
data/api/server-server/leaving-v2.yaml
View file

@ -27,7 +27,7 @@ paths:
exception of the response format being fixed. exception of the response format being fixed.
This endpoint is preferred over the v1 API as it provides 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 a 400, 404, or other status code which indicates this endpoint
is not available should retry using the v1 API instead. is not available should retry using the v1 API instead.

2
meta/documentation_style.rst
View file

@ -191,4 +191,4 @@ Describing grammar
Use `RFC5234-style ABNF <https://datatracker.ietf.org/doc/html/rfc5234>`_ when describing 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 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`).

2
meta/releasing.md
View file

@ -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 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, 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 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 the target release date. 1-2 days before the release itself, the prerequisite steps