Replace authorization with authorisation throughout the spec

The style guide requires en_GB, which spells authorisation with an s.

Author: richvdh

content/application-service-api.md

@@ -100,7 +100,7 @@ this.
 
 ### Homeserver -> Application Service API
 
-#### Authorization
+#### Authorisation
 
 {{% changed-in v="1.4" %}}
 

content/changelog/v1.14.md

@@ -63,7 +63,7 @@ No significant changes.
 
 **Spec Clarifications**
 
-- For room versions 6 and 7, clarify in the authorization rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. ([#2065](https://github.com/matrix-org/matrix-spec/issues/2065))
+- For room versions 6 and 7, clarify in the authorisation rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. ([#2065](https://github.com/matrix-org/matrix-spec/issues/2065))
 - Fix various typos throughout the specification. ([#2066](https://github.com/matrix-org/matrix-spec/issues/2066))
 - Refactor PDU definitions to reduce duplication. ([#2070](https://github.com/matrix-org/matrix-spec/issues/2070))
 - Clarify the maximum `depth` value for room versions 6, 7, 8, 9, 10, and 11. ([#2114](https://github.com/matrix-org/matrix-spec/issues/2114))

content/changelog/v1.3.md

@@ -108,12 +108,12 @@ No significant changes.
 
 
 - Improve readability and understanding of the state resolution algorithms. ([#1037](https://github.com/matrix-org/matrix-spec/issues/1037), [#1042](https://github.com/matrix-org/matrix-spec/issues/1042), [#1043](https://github.com/matrix-org/matrix-spec/issues/1043), [#1120](https://github.com/matrix-org/matrix-spec/issues/1120))
-- Improve readability of the authorization rules. ([#1050](https://github.com/matrix-org/matrix-spec/issues/1050))
+- Improve readability of the authorisation rules. ([#1050](https://github.com/matrix-org/matrix-spec/issues/1050))
 - For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. ([#1093](https://github.com/matrix-org/matrix-spec/issues/1093))
 - Clarify that room versions 1 through 9 accept stringy power levels, as noted by [MSC3667](https://github.com/matrix-org/matrix-spec-proposals/pull/3667). ([#1099](https://github.com/matrix-org/matrix-spec/issues/1099))
-- For all room versions: Add `m.federate` to the authorization rules, as originally intended. ([#1103](https://github.com/matrix-org/matrix-spec/issues/1103))
+- For all room versions: Add `m.federate` to the authorisation rules, as originally intended. ([#1103](https://github.com/matrix-org/matrix-spec/issues/1103))
 - For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. ([#1107](https://github.com/matrix-org/matrix-spec/issues/1107))
-- For room versions 7, 8, 9, and 10: fix join membership authorization rules when `join_rule` is `knock`. ([#3737](https://github.com/matrix-org/matrix-spec-proposals/issues/3737))
+- For room versions 7, 8, 9, and 10: fix join membership authorisation rules when `join_rule` is `knock`. ([#3737](https://github.com/matrix-org/matrix-spec-proposals/issues/3737))
 
 
 ## Appendices

content/changelog/v1.4.md

@@ -73,7 +73,7 @@ date: 2022-09-29
 <strong>Breaking Changes</strong>
 
 
-- Replace homeserver authorization approach with an `Authorization` header instead of `access_token` when talking to the application service, as per [MSC2832](https://github.com/matrix-org/matrix-spec-proposals/pull/2832). ([#1200](https://github.com/matrix-org/matrix-spec/issues/1200))
+- Replace homeserver authorisation approach with an `Authorization` header instead of `access_token` when talking to the application service, as per [MSC2832](https://github.com/matrix-org/matrix-spec-proposals/pull/2832). ([#1200](https://github.com/matrix-org/matrix-spec/issues/1200))
 
 
 <strong>Spec Clarifications</strong>

content/client-server-api/_index.md

@@ -68,7 +68,7 @@ The available room versions are:
 -   [Version 5](/rooms/v5) - **Stable**. Introduces enforcement of
     signing key validity periods.
 -   [Version 6](/rooms/v6) - **Stable**. Alters several
-    authorization rules for events.
+    authorisation rules for events.
 -   [Version 7](/rooms/v7) - **Stable**. Introduces knocking.
 -   [Version 8](/rooms/v8) - **Stable**. Adds a join rule to allow members
     of another room to join without invite.
@@ -85,7 +85,7 @@ The available room versions are:
 
 Room versions are used to change properties of rooms that may not be
 compatible with other servers. For example, changing the rules for event
-authorization would cause older servers to potentially end up in a
+authorisation would cause older servers to potentially end up in a
 split-brain situation due to not understanding the new rules.
 
 A room version is defined as a string of characters which MUST NOT

content/rooms/_index.md

@@ -1,5 +1,5 @@
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/fragments/v1-auth-rules.md

@@ -123,11 +123,11 @@ events: for events *x* and *y*, *x* < *y* if
 The *iterative auth checks algorithm* takes as input an initial room
 state and a sorted list of state events, and constructs a new room state
 by iterating through the event list and applying the state event to the
-room state if the state event is allowed by the [authorization
-rules](/server-server-api#authorization-rules).
-If the state event is not allowed by the authorization rules, then the
+room state if the state event is allowed by the [authorisation
+rules](/server-server-api#authorisation-rules).
+If the state event is not allowed by the authorisation rules, then the
 event is ignored. If a `(event_type, state_key)` key that is required
-for checking the authorization rules is not present in the state, then
+for checking the authorisation rules is not present in the state, then
 the appropriate state event from the event's `auth_events` is used if
 the auth event is not rejected.
 

content/rooms/fragments/v2-state-res.md

@@ -7,7 +7,7 @@ in the same respect, so does not need a signature from that server.
 The event must still be signed by the server denoted by the `sender` property,
 however.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/fragments/v3-auth-rules.md

@@ -1,11 +1,11 @@
 ---
 ---
 {{% added-in v=3 %}} In room versions 1 and 2, redactions were
-explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
+explicitly part of the [authorisation rules](/rooms/v1/#authorisation-rules)
 under Rule 11. As of room version 3, these conditions no longer exist as
-represented by [this version's authorization rules](#authorization-rules).
+represented by [this version's authorisation rules](#authorisation-rules).
 
-While redactions are always accepted by the authorization rules for
+While redactions are always accepted by the authorisation rules for
 events, they should not be sent to clients until both the redaction
 event and the event the redaction affects have been received, and can
 be validated. If both events are valid and have been seen by the server,