Update documentation globally to use US spelling (not UK) + grammar fixes

- Transferred all British spellings in the usage guide and advanced topics section to American spellings

docs/advanced_topics/accessibility_considerations.md

@@ -20,14 +20,14 @@ As part of defining your site’s models, here are areas to pay special attentio
 
 ### Alt text for images
 
-The default behaviour for Wagtail images is to use the `title` field as the alt text ([#4945](https://github.com/wagtail/wagtail/issues/4945)).
+The default behavior for Wagtail images is to use the `title` field as the alt text ([#4945](https://github.com/wagtail/wagtail/issues/4945)).
 This is inappropriate, as it’s not communicated in the CMS interface, and the image upload form uses the image’s filename as the title by default.
 
 Ideally, always add an optional “alt text” field wherever an image is used, alongside the image field:
 
 -   For normal fields, add an alt text field to your image’s panel.
 -   For StreamField, add an extra field to your image block.
--   For rich text – Wagtail already makes it possible to customise alt text for rich text images.
+-   For rich text – Wagtail already makes it possible to customize alt text for rich text images.
 
 When defining the alt text fields, make sure they are optional so editors can choose to not write any alt text for decorative images. Take the time to provide `help_text` with appropriate guidance.
 For example, linking to [established resources on alt text](https://axesslab.com/alt-texts/).
@@ -143,7 +143,7 @@ By default, the checker includes the following rules to find common accessibilit
 -   `link-name`: `<a>` link elements must always have a text label.
 -   `p-as-heading`: This rule checks for paragraphs that are styled as headings. Paragraphs should not be styled as headings, as they don’t help users who rely on headings to navigate content.
 
-To customise how the checker is run (such as what rules to test), you can define a custom subclass of {class}`~wagtail.admin.userbar.AccessibilityItem` and override the attributes to your liking. Then, swap the instance of the default `AccessibilityItem` with an instance of your custom class via the [`construct_wagtail_userbar`](construct_wagtail_userbar) hook.
+To customize how the checker is run (such as what rules to test), you can define a custom subclass of {class}`~wagtail.admin.userbar.AccessibilityItem` and override the attributes to your liking. Then, swap the instance of the default `AccessibilityItem` with an instance of your custom class via the [`construct_wagtail_userbar`](construct_wagtail_userbar) hook.
 
 The following is the reference documentation for the `AccessibilityItem` class:
 
@@ -158,9 +158,9 @@ The following is the reference documentation for the `AccessibilityItem` class:
     .. autoattribute:: axe_messages
        :no-value:
 
-    The above attributes can also be overridden via the following methods to allow per-request customisation.
+    The above attributes can also be overridden via the following methods to allow per-request customization.
     When overriding these methods, be mindful of the mutability of the class attributes above.
-    To avoid unexpected behaviour, you should always return a new object instead of modifying the attributes
+    To avoid unexpected behavior, you should always return a new object instead of modifying the attributes
     directly in the methods.
 
     .. method:: get_axe_include(request)
@@ -169,7 +169,7 @@ The following is the reference documentation for the `AccessibilityItem` class:
     .. method:: get_axe_rules(request)
     .. method:: get_axe_messages(request)
 
-    For more advanced customisation, you can also override the following methods:
+    For more advanced customization, you can also override the following methods:
 
     .. automethod:: get_axe_context
     .. automethod:: get_axe_options

docs/advanced_topics/add_to_django_project.md

@@ -293,7 +293,7 @@ INTERNAL_IPS = ('127.0.0.1', '10.0.2.2')
 # performed by this configuration is to send an email to
 # the site admins on every HTTP 500 error when DEBUG=False.
 # See https://docs.djangoproject.com/en/stable/topics/logging for
-# more details on how to customise your logging configuration.
+# more details on how to customize your logging configuration.
 LOGGING = {
     'version': 1,
     'disable_existing_loggers': False,

docs/advanced_topics/amp.md

@@ -8,7 +8,7 @@ AMP version of the site.
 
 ## Overview
 
-In the next section, we will add a new URL entry that points at Wagtail's
+In the next section, we will add a new URL entry that points to Wagtail's
 internal `serve()` view which will have the effect of rendering the whole
 site again under the `/amp` prefix.
 
@@ -19,7 +19,7 @@ a request object.
 After that, we will add a template context processor to allow us to check from
 within templates which version of the site is being rendered.
 
-Then, finally, we will modify the behaviour of the `{% image %}` tag to make it
+Then, finally, we will modify the behavior of the `{% image %}` tag to make it
 render `<amp-img>` tags when rendering the AMP version of the site.
 
 ## Creating the second page tree
@@ -132,7 +132,7 @@ def serve(request, path):
         return response
 ```
 
-Then we need to create a `amp_urls.py` file in the same app:
+Then we need to create an `amp_urls.py` file in the same app:
 
 ```python
 # <app>/amp_urls.py
@@ -171,7 +171,7 @@ the site.
 This is optional, but worth doing so we can confirm that everything is working
 so far.
 
-Add a `amp_context_processors.py` file into your app that contains the
+Add an `amp_context_processors.py` file into your app that contains the
 following:
 
 ```python
@@ -275,7 +275,7 @@ class MyPageModel(PageAMPTemplateMixin, Page):
 ## Overriding the `{% image %}` tag to output `<amp-img>` tags
 
 Finally, let's change Wagtail's `{% image %}` tag, so it renders an `<amp-img>`
-tags when rendering pages with AMP enabled. We'll make the change on the
+tags when rendering pages with AMP enabled. We'll make the change to the
 `Rendition` model itself so it applies to both images rendered with the
 `{% image %}` tag and images rendered in rich text fields as well.
 

docs/advanced_topics/api/v2/configuration.md

@@ -47,8 +47,8 @@ Wagtail provides multiple endpoint classes you can use:
 -   Documents {class}`wagtail.documents.api.v2.views.DocumentsAPIViewSet`
 -   Redirects {class}`wagtail.contrib.redirects.api.RedirectsAPIViewSet` see [](redirects_api_endpoint)
 
-You can subclass any of these endpoint classes to customise their functionality.
-For example, in this case if you need to change the `APIViewSet` by setting a desired renderer class:
+You can subclass any of these endpoint classes to customize their functionality.
+For example, in this case, if you need to change the `APIViewSet` by setting a desired renderer class:
 
 ```python
 from rest_framework.renderers import JSONRenderer
@@ -288,7 +288,7 @@ Note: `download_url` is the original uploaded file path, whereas
 When you are using another storage backend, such as S3, `download_url` will return
 a URL to the image if your media files are properly configured.
 
-For cases where the source image set may contain SVGs, the `ImageRenditionField` constructor takes a `preserve_svg` argument. The behaviour of `ImageRenditionField` when `preserve_svg` is `True` is as described for the `image` template tag's `preserve-svg` argument (see the documentation on [](svg_images)).
+For cases where the source image set may contain SVGs, the `ImageRenditionField` constructor takes a `preserve_svg` argument. The behavior of `ImageRenditionField` when `preserve_svg` is `True` is as described for the `image` template tag's `preserve-svg` argument (see the documentation on [](svg_images)).
 
 ## Additional settings
 

docs/advanced_topics/api/v2/usage.md

@@ -2,7 +2,7 @@
 
 # Wagtail API v2 Usage Guide
 
-The Wagtail API module exposes a public, read only, JSON-formatted API which
+The Wagtail API module exposes a public, read-only, JSON-formatted API which
 can be used by external clients (such as a mobile app) or the site's frontend.
 
 This document is intended for developers using the API exposed by Wagtail. For
@@ -129,7 +129,7 @@ model. You can read about configuration [here](apiv2_page_fields_configuration).
 ```
 
 This doesn't apply to images/documents as there is only one model exposed in
-those endpoints. But for projects that have customised image/document models,
+those endpoints. But for projects that have customized image/document models,
 the `api_fields` attribute can be used to export any custom fields into the
 API.
 
@@ -213,7 +213,7 @@ uppercase letters when in ascending order.
 
 #### Multiple ordering
 
-Multiple fields cab be passed into the `?order` for consecutive ordering.
+Multiple fields can be passed into the `?order` for consecutive ordering.
 
 ```
 GET /api/v2/pages/?order=title,-slug
@@ -304,7 +304,7 @@ Content-Type: application/json
 Pages can additionally be filtered by their relation to other pages in the tree.
 
 The `?child_of` filter takes the id of a page and filters the list of results
-to contain only direct children of that page.
+to contain only the direct children of that page.
 
 For example, this can be useful for constructing the main menu, by passing the
 id of the homepage to the filter:
@@ -357,8 +357,8 @@ find the particular `blog.BlogIndexPage` a `blog.BlogPage` belongs
 to. By itself, it can be used to construct a breadcrumb trail from
 the current page back to the site's root page.
 
-The `?descendant_of` filter takes the id of a page and filter the list
-to only include descendants of that page (children, grandchildren etc.).
+The `?descendant_of` filter takes the id of a page and filters the list
+to only include descendants of that page (children, grandchildren, etc.).
 
 (api_filtering_pages_by_site)=
 
@@ -547,7 +547,7 @@ the URL. For example:
 -   Documents `/api/v2/documents/1/`
 
 All exported fields will be returned in the response by default. You can use the
-`?fields` parameter to customise which fields are shown.
+`?fields` parameter to customize which fields are shown.
 
 For example: `/api/v2/pages/1/?fields=_,title,body` will return just the
 `title` and `body` of the page with the id of 1.
@@ -572,7 +572,7 @@ These fields are returned by every endpoint.
 The unique ID of the object
 
 ```{note}
-Except for page types, every other content type has its own id space
+Except for page types, every other content type has its own ID space
 so you must combine this with the ``type`` field in order to get a
 unique identifier for an object.
 ```
@@ -602,7 +602,7 @@ Nests some information about the parent page (only available on detail
 views)
 
 **`meta.alias_of` (dictionary)**
-If the page marked as an alias return original page id and full url
+If the page marked as an alias return the original page ID and full URL
 
 ### Images
 
@@ -636,13 +636,13 @@ A URL to the document file
 
 ### Major features
 
--   The `fields` parameter has been improved to allow removing fields, adding all fields and customising nested fields
+-   The `fields` parameter has been improved to allow removing fields, adding all fields, and customizing nested fields
 
 ### Minor features
 
--   `html_url`, `slug`, `first_published_at`, `expires_at` and `show_in_menus` fields have been added to the pages endpoint
+-   `html_url`, `slug`, `first_published_at`, `expires_at`, and `show_in_menus` fields have been added to the pages endpoint
 -   `download_url` field has been added to the documents endpoint
--   Multiple page types can be specified in `type` parameter on pages endpoint
+-   Multiple page types can be specified in `type` parameter on page endpoint
 -   `true` and `false` may now be used when filtering boolean fields
 -   `order` can now be used in conjunction with `search`
 -   `search_operator` parameter was added

docs/advanced_topics/customisation/admin_templates.md

@@ -126,7 +126,7 @@ For static colors, either set each color separately (for example `--w-color-prim
 
 ## Specifying a site or page in the branding
 
-The admin interface has a number of variables available to the renderer context that can be used to customize the branding on the admin page. These can be useful for customizing the dashboard on a multi-tenanted Wagtail installation:
+The admin interface has a number of variables available to the renderer context that can be used to customize the branding in the admin page. These can be useful for customizing the dashboard on a multi-tenanted Wagtail installation:
 
 ### `root_page`
 
@@ -234,4 +234,4 @@ To add extra buttons to the password reset form, override the `submit_buttons` b
 
 ## Extending client-side JavaScript
 
-Wagtail provides multiple ways to [extend client-side JavaScript](extending_client_side).
+Wagtail provides multiple ways to [extend client-side JavaScript](extending_client_side).

docs/advanced_topics/customisation/custom_user_models.md

@@ -5,7 +5,7 @@
 This example shows how to add a text field and foreign key field to a custom user model
 and configure Wagtail user forms to allow the fields values to be updated.
 
-Create a custom user model. This must at minimum inherit from `AbstractBaseUser` and `PermissionsMixin`. In this case we extend the `AbstractUser` class and add two fields. The foreign key references another model (not shown).
+Create a custom user model. This must at minimum inherit from `AbstractBaseUser` and `PermissionsMixin`. In this case, we extend the `AbstractUser` class and add two fields. The foreign key references another model (not shown).
 
 ```python
 from django.contrib.auth.models import AbstractUser
@@ -70,11 +70,11 @@ Template edit.html:
 ```
 
 The `extra_fields` block allows fields to be inserted below the `last_name` field
-in the default templates. Other block overriding options exist to allow appending
-fields to the end or beginning of the existing fields, or to allow all the fields to
+in the default templates. Other block-overriding options exist to allow appending
+fields to the end or beginning of the existing fields or to allow all the fields to
 be redefined.
 
-Add the wagtail settings to your project to reference the user form additions:
+Add the Wagtail settings to your project to reference the user form additions:
 
 ```python
 WAGTAIL_USER_EDIT_FORM = 'users.forms.CustomUserEditForm'

docs/advanced_topics/customisation/page_editing_interface.md

@@ -1,10 +1,10 @@
-# Customising the editing interface
+# Customizing the editing interface
 
 (customising_the_tabbed_interface)=
 
-## Customising the tabbed interface
+## Customizing the tabbed interface
 
-As standard, Wagtail organises panels for pages into two tabs: 'Content' and 'Promote'. For snippets Wagtail puts all panels into one page. Depending on the requirements of your site, you may wish to customise this for specific page types or snippets - for example, adding an additional tab for sidebar content. This can be done by specifying an `edit_handler` attribute on the page or snippet model. For example:
+As standard, Wagtail organizes panels for pages into two tabs: 'Content' and 'Promote'. For snippets, Wagtail puts all panels into one page. Depending on the requirements of your site, you may wish to customize this for specific page types or snippets - for example, adding an additional tab for sidebar content. This can be done by specifying an `edit_handler` attribute on the page or snippet model. For example:
 
 ```python
 from wagtail.admin.panels import TabbedInterface, TitleFieldPanel, ObjectList
@@ -52,7 +52,7 @@ class FundingPage(Page):
     ])
 ```
 
-For more details on how to work with `Panel`s and `PanelGroup`, see [](forms_panels_overview).
+For more details on how to work with `Panel` and `PanelGroup` classes, see [](forms_panels_overview).
 
 (rich_text_field)=
 
@@ -84,7 +84,7 @@ However, template output from `RichTextField` is special and needs to be filtere
 By default, the rich text editor provides users with a wide variety of options for text formatting and inserting embedded content such as images. However, we may wish to restrict a rich text field to a more limited set of features - for example:
 
 -   The field might be intended for a short text snippet, such as a summary to be pulled out on index pages, where embedded images or videos would be inappropriate;
--   When page content is defined using [StreamField](../../topics/streamfield), elements such as headings, images and videos are usually given their own block types, alongside a rich text block type used for ordinary paragraph text; in this case, allowing headings and images to also exist within the rich text content is redundant (and liable to result in inconsistent designs).
+-   When page content is defined using [StreamField](../../topics/streamfield), elements such as headings, images, and videos are usually given their own block types, alongside a rich text block type used for ordinary paragraph text; in this case, allowing headings and images to also exist within the rich text content is redundant (and liable to result in inconsistent designs).
 
 This can be achieved by passing a `features` keyword argument to `RichTextField`, with a list of identifiers for the features you wish to allow:
 
@@ -121,7 +121,7 @@ You can also provide a setting for naming a group of rich text features. See [WA
 
 ### Image Formats in the Rich Text Editor
 
-On loading, Wagtail will search for any app with the file `image_formats.py` and execute the contents. This provides a way to customise the formatting options shown to the editor when inserting images in the `RichTextField` editor.
+On loading, Wagtail will search for any app with the file `image_formats.py` and execute the contents. This provides a way to customize the formatting options shown to the editor when inserting images in the `RichTextField` editor.
 
 As an example, add a "thumbnail" format:
 
@@ -144,7 +144,7 @@ The label used in the chooser form when inserting the image into the `RichTextFi
 The string to assign to the `class` attribute of the generated `<img>` tag.
 
 ```{note}
-Any class names you provide must have CSS rules matching them written separately, as part of the front end CSS code. Specifying a `classname` value of `left` will only ensure that class is output in the generated markup, it won't cause the image to align itself left.
+Any class names you provide must have CSS rules matching them written separately, as part of the frontend CSS code. Specifying a `classname` value of `left` will only ensure that class is output in the generated markup, it won't cause the image to align itself left.
 ```
 
 **`filter_spec`**
@@ -153,12 +153,12 @@ The string specification to create the image rendition. For more, see [](image_t
 To unregister, call `unregister_image_format` with the string of the `name` of the `Format` as the only argument.
 
 ```{warning}
-Unregistering ``Format`` objects will cause errors viewing or editing pages that reference them.
+Unregistering ``Format`` objects will cause errors when viewing or editing pages that reference them.
 ```
 
 (custom_edit_handler_forms)=
 
-## Customising generated forms
+## Customizing generated forms
 
 ```{eval-rst}
 .. class:: wagtail.admin.forms.WagtailAdminModelForm
@@ -234,7 +234,7 @@ so the form field for a model field can be overridden by adding it to the custom
 
 (custom_page_copy_form)=
 
-## Customising the generated copy page form
+## Customizing the generated copy page form
 
 ```{versionadded} 6.0
 

docs/advanced_topics/customisation/streamfield_blocks.md

@@ -6,7 +6,7 @@
 
 ## Custom editing interfaces for `StructBlock`
 
-To customise the styling of a `StructBlock` as it appears in the page editor, you can specify a `form_classname` attribute (either as a keyword argument to the `StructBlock` constructor, or in a subclass's `Meta`) to override the default value of `struct-block`:
+To customize the styling of a `StructBlock` as it appears in the page editor, you can specify a `form_classname` attribute (either as a keyword argument to the `StructBlock` constructor, or in a subclass's `Meta`) to override the default value of `struct-block`:
 
 ```python
 class PersonBlock(blocks.StructBlock):
@@ -23,10 +23,10 @@ class PersonBlock(blocks.StructBlock):
 You can then provide custom CSS for this block, targeted at the specified classname, by using the [](insert_global_admin_css) hook.
 
 ```{note}
-Wagtail's editor styling has some built in styling for the `struct-block` class and other related elements. If you specify a value for `form_classname`, it will overwrite the classes that are already applied to `StructBlock`, so you must remember to specify the `struct-block` as well.
+Wagtail's editor styling has some built-in styling for the `struct-block` class and other related elements. If you specify a value for `form_classname`, it will overwrite the classes that are already applied to `StructBlock`, so you must remember to specify the `struct-block` as well.
 ```
 
-For more extensive customisations that require changes to the HTML markup as well, you can override the `form_template` attribute in `Meta` to specify your own template path. The following variables are available on this template:
+For more extensive customizations that require changes to the HTML markup as well, you can override the `form_template` attribute in `Meta` to specify your own template path. The following variables are available on this template:
 
 **`children`**  
 An `OrderedDict` of `BoundBlock`s for all of the child blocks making up this `StructBlock`.
@@ -62,7 +62,7 @@ class PersonBlock(blocks.StructBlock):
         form_template = 'myapp/block_forms/person.html'
 ```
 
-A form template for a StructBlock must include the output of `render_form` for each child block in the `children` dict, inside a container element with a `data-contentpath` attribute equal to the block's name. This attribute is used by the commenting framework to attach comments to the correct fields. The StructBlock's form template is also responsible for rendering labels for each field, but this (and all other HTML markup) can be customised as you see fit. The template below replicates the default StructBlock form rendering:
+A form template for a StructBlock must include the output of `render_form` for each child block in the `children` dict, inside a container element with a `data-contentpath` attribute equal to the block's name. This attribute is used by the commenting framework to attach comments to the correct fields. The StructBlock's form template is also responsible for rendering labels for each field, but this (and all other HTML markup) can be customized as you see fit. The template below replicates the default StructBlock form rendering:
 
 ```html+django
 {% load wagtailadmin_tags  %}
@@ -106,7 +106,7 @@ class AddressBlock(StructBlock):
     ])
 ```
 
-we may wish to disable the 'state' field when a country other than United States is selected. Since new blocks can be added dynamically, we need to integrate with StreamField's own front-end logic to ensure that our custom JavaScript code is executed when a new block is initialised.
+we may wish to disable the 'state' field when a country other than United States is selected. Since new blocks can be added dynamically, we need to integrate with StreamField's own front-end logic to ensure that our custom JavaScript code is executed when a new block is initialized.
 
 StreamField uses the [telepath](https://wagtail.github.io/telepath/) library to map Python block classes such as `StructBlock` to a corresponding JavaScript implementation. These JavaScript implementations can be accessed through the `window.wagtailStreamField.blocks` namespace, as the following classes:
 
@@ -138,7 +138,7 @@ class AddressBlockAdapter(StructBlockAdapter):
 register(AddressBlockAdapter(), AddressBlock)
 ```
 
-Here `'myapp.blocks.AddressBlock'` is the identifier for our JavaScript class that will be registered with the telepath client-side code, and `'js/address-block.js'` is the file that defines it (as a path within any static file location recognised by Django). This implementation subclasses StructBlockDefinition and adds our custom code to the `render` method:
+Here `'myapp.blocks.AddressBlock'` is the identifier for our JavaScript class that will be registered with the telepath client-side code, and `'js/address-block.js'` is the file that defines it (as a path within any static file location recognized by Django). This implementation subclasses StructBlockDefinition and adds our custom code to the `render` method:
 
 ```javascript
 class AddressBlockDefinition extends window.wagtailStreamField.blocks
@@ -184,7 +184,7 @@ class LinkBlock(StructBlock):
     external_url = URLBlock(label="external URL", required=False)
 ```
 
-you may want to make a `url` property available, that returns either the page URL or external URL depending which one was filled in. A common mistake is to define this property on the block class itself:
+you may want to make a `url` property available, that returns either the page URL or external URL depending on which one was filled in. A common mistake is to define this property on the block class itself:
 
 ```python
 class LinkBlock(StructBlock):
@@ -197,7 +197,7 @@ class LinkBlock(StructBlock):
         return self.external_url or self.page.url
 ```
 
-This does not work because the value as seen in the template is not an instance of `LinkBlock`. `StructBlock` instances only serve as specifications for the block's behaviour, and do not hold block data in their internal state - in this respect, they are similar to Django's form widget objects (which provide methods for rendering a given value as a form field, but do not hold on to the value itself).
+This does not work because the value as seen in the template is not an instance of `LinkBlock`. `StructBlock` instances only serve as specifications for the block's behavior, and do not hold block data in their internal state - in this respect, they are similar to Django's form widget objects (which provide methods for rendering a given value as a form field, but do not hold on to the value itself).
 
 Instead, you should define a subclass of `StructValue` that implements your custom property or method. Within this method, the block's data can be accessed as `self['page']` or `self.get('page')`, since `StructValue` is a dict-like object.
 
@@ -247,12 +247,12 @@ class IPAddressBlock(FieldBlock):
         super().__init__(**kwargs)
 ```
 
-Since the StreamField editing interface needs to create blocks dynamically, certain complex widget types will need additional JavaScript code to define how to render and populate them on the client-side. If a field uses a widget type that does not inherit from one of the classes inheriting from `django.forms.widgets.Input`, `django.forms.Textarea`, `django.forms.Select` or `django.forms.RadioSelect`, or has customised client-side behaviour to the extent where it is not possible to read or write its data simply by accessing the form element's `value` property, you will need to provide a JavaScript handler object, implementing the methods detailed on [](streamfield_widget_api).
+Since the StreamField editing interface needs to create blocks dynamically, certain complex widget types will need additional JavaScript code to define how to render and populate them on the client-side. If a field uses a widget type that does not inherit from one of the classes inheriting from `django.forms.widgets.Input`, `django.forms.Textarea`, `django.forms.Select` or `django.forms.RadioSelect`, or has customized client-side behavior to the extent where it is not possible to read or write its data simply by accessing the form element's `value` property, you will need to provide a JavaScript handler object, implementing the methods detailed on [](streamfield_widget_api).
 
 ## Handling block definitions within migrations
 
 As with any model field in Django, any changes to a model definition that affect a StreamField will result in a migration file that contains a 'frozen' copy of that field definition. Since a StreamField definition is more complex than a typical model field, there is an increased likelihood of definitions from your project being imported into the migration -- which would cause problems later on if those definitions are moved or deleted.
 
-To mitigate this, StructBlock, StreamBlock and ChoiceBlock implement additional logic to ensure that any subclasses of these blocks are deconstructed to plain instances of StructBlock, StreamBlock and ChoiceBlock -- in this way, the migrations avoid having any references to your custom class definitions. This is possible because these block types provide a standard pattern for inheritance, and know how to reconstruct the block definition for any subclass that follows that pattern.
+To mitigate this, StructBlock, StreamBlock, and ChoiceBlock implement additional logic to ensure that any subclasses of these blocks are deconstructed to plain instances of StructBlock, StreamBlock and ChoiceBlock -- in this way, the migrations avoid having any references to your custom class definitions. This is possible because these block types provide a standard pattern for inheritance, and know how to reconstruct the block definition for any subclass that follows that pattern.
 
-If you subclass any other block class, such as `FieldBlock`, you will need to either keep that class definition in place for the lifetime of your project, or implement a [custom deconstruct method](inv:django#custom-deconstruct-method) that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customise a StructBlock, StreamBlock or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own `deconstruct` method.
+If you subclass any other block class, such as `FieldBlock`, you will need to either keep that class definition in place for the lifetime of your project, or implement a [custom deconstruct method](inv:django#custom-deconstruct-method) that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customize a StructBlock, StreamBlock, or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own `deconstruct` method.

docs/advanced_topics/deploying.md

@@ -60,7 +60,7 @@ The django-storages Amazon S3 backends (`storages.backends.s3boto.S3BotoStorage`
 
 ### Cache
 
-Wagtail is designed to make huge advantage of Django's [cache framework](inv:django#topics/cache) when available to accelerate page loads. The cache is especially useful for the Wagtail admin, which can't take advantage of conventional CDN caching.
+Wagtail is designed to leverage Django's [cache framework](inv:django#topics/cache) when available to accelerate page loads. The cache is especially useful for the Wagtail admin, which can't take advantage of conventional CDN caching.
 
 Wagtail supports any of Django's cache backend, however we recommend against using one tied to the specific process or environment Django is running (eg `FileBasedCache` or `LocMemCache`).
 
@@ -72,7 +72,7 @@ Wagtail, and by extension Django, can be deployed in many different ways on many
 
 Django has a [deployment checklist](inv:django#howto/deployment/checklist) which runs through everything you should have done or should be aware of before deploying a Django application.
 
-### Performance optimisation
+### Performance optimization
 
 Your production site should be as fast and performant as possible. For tips on how to ensure Wagtail performs as well as possible, take a look at our [performance tips](performance_overview).
 
@@ -80,8 +80,8 @@ Your production site should be as fast and performant as possible. For tips on h
 
 ## Deployment examples
 
-Some examples for deployments on a few hosting platforms can be found in [](./third_party_tutorials). This is not a complete list of platforms where Wagtail can run, nor is it necessarily the only way to run Wagtail there.
+Some examples of deployments on a few hosting platforms can be found in [](./third_party_tutorials). This is not a complete list of platforms where Wagtail can run, nor is it necessarily the only way to run Wagtail there.
 
-An example of a production Wagtail site is [guide.wagail.org](https://guide.wagtail.org/), which is [open-source](https://github.com/wagtail/guide) and run on Heroku. More information on its hosting environment can be found in [its documentation](https://github.com/wagtail/guide/blob/main/docs/hosting-environment.md).
+An example of a production Wagtail site is [guide.wagail.org](https://guide.wagtail.org/), which is [open-source](https://github.com/wagtail/guide) and runs on Heroku. More information on its hosting environment can be found in [its documentation](https://github.com/wagtail/guide/blob/main/docs/hosting-environment.md).
 
 If you have successfully installed Wagtail on your platform or infrastructure, please [contribute](../contributing/index) your notes to this documentation!

docs/advanced_topics/documents/custom_document_model.md

@@ -2,7 +2,7 @@
 
 # Custom document model
 
-An alternate `Document` model can be used to add custom behaviour and
+An alternate `Document` model can be used to add custom behavior and
 additional fields.
 
 You need to complete the following steps in your project to do this:

docs/advanced_topics/documents/title_generation_on_upload.md

@@ -2,13 +2,13 @@
 
 # Title generation on upload
 
-When uploading a file (document), Wagtail takes the filename, removes the file extension, and populates the title field. This section is about how to customise this filename to title conversion.
+When uploading a file (document), Wagtail takes the filename, removes the file extension, and populates the title field. This section is about how to customize this filename to title conversion.
 
 The filename to title conversion is used on the single file widget, multiple upload widget, and within chooser modals.
 
-You can also customise this [same behaviour for images](../images/title_generation_on_upload).
+You can also customize this [same behavior for images](../images/title_generation_on_upload).
 
-You can customise the resolved value of this title using a JavaScript [event listener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener) which will listen to the `'wagtail:documents-upload'` event.
+You can customize the resolved value of this title using a JavaScript [event listener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener) which will listen to the `'wagtail:documents-upload'` event.
 
 The simplest way to add JavaScript to the editor is via the [`insert_global_admin_js` hook](insert_global_admin_js). However, any JavaScript that adds an event listener will work.
 
@@ -24,7 +24,7 @@ To modify the generated `Document` title, access and update `event.detail.data.t
 
 For single document uploads, the custom event will only run if the title does not already have a value so that we do not overwrite whatever the user has typed.
 
-You can prevent the default behaviour by calling `event.preventDefault()`. For the single upload page or modals, this will not pre-fill any value into the title. For multiple uploads, this will avoid any title submission and use the filename title only (with file extension) as a title is required to save the document.
+You can prevent the default behavior by calling `event.preventDefault()`. For the single upload page or modals, this will not pre-fill any value into the title. For multiple uploads, this will avoid any title submission and use the filename title only (with file extension) as a title is required to save the document.
 
 The event will 'bubble' up so that you can simply add a global `document` listener to capture all of these events, or you can scope your listener or handler logic as needed to ensure you only adjust titles in some specific scenarios.
 

docs/advanced_topics/embeds.md

@@ -3,7 +3,7 @@
 # Embedded content
 
 Wagtail supports generating embed code from URLs to content on external
-providers such as Youtube or Twitter. By default, Wagtail will fetch the embed
+providers such as YouTube or Twitter. By default, Wagtail will fetch the embed
 code directly from the relevant provider's site using the oEmbed protocol.
 
 Wagtail has a built-in list of the most common providers and this list can be
@@ -114,7 +114,7 @@ following link:
 
 (customising_embed_providers)=
 
-#### Customising the provider list
+#### Customizing the provider list
 
 You can limit which providers may be used by specifying the list of providers
 in the finder configuration.
@@ -145,12 +145,12 @@ WAGTAILEMBEDS_FINDERS = [
 ]
 ```
 
-#### Customising an individual provider
+#### Customizing an individual provider
 
-Multiple finders can be chained together. This can be used for customising the
+Multiple finders can be chained together. This can be used for customizing the
 configuration for one provider without affecting the others.
 
-For example, this is how you can instruct Youtube to return videos in HTTPS
+For example, this is how you can instruct YouTube to return videos in HTTPS
 (which must be done explicitly for YouTube):
 
 ```python
@@ -179,7 +179,7 @@ If multiple providers can handle a URL (for example, a YouTube video was
 requested using the configuration above), the topmost finder is chosen to
 perform the request.
 
-Wagtail will not try to run any other finder, even if the chosen one didn't
+Wagtail will not try to run any other finder, even if the chosen one doesn't
 return an embed.
 
 (facebook_and_instagram_embeds)=
@@ -196,7 +196,7 @@ and [Instagram](https://developers.facebook.com/docs/instagram/oembed) documenta
 
 As of June 2021, the _oEmbed Product_ has been replaced with the _oEmbed Read_
 feature. In order to embed Facebook and Instagram posts your app must activate
-the _oEmbed Read_ feature. Furthermore the app must be reviewed and accepted
+the _oEmbed Read_ feature. Furthermore, the app must be reviewed and accepted
 by Meta. You can find the announcement in the
 [API changelog](https://developers.facebook.com/docs/graph-api/changelog/version11.0/#oembed).
 
@@ -361,7 +361,7 @@ WAGTAILEMBEDS_FINDERS = [
 
         (text)
 
-        The author name of the content that is being embedded.
+        The author's name of the content that is being embedded.
 
     .. attribute:: provider_name
 
@@ -406,4 +406,4 @@ You may want to do this if you've changed from oEmbed to Embedly or vice-versa
 as the embed code they generate may be slightly different and lead to
 inconsistency on your site.
 
-In general whenever you make changes to embed settings you are recommended to clear out Embed objects using [`purge_embeds` command](purge_embeds).
+In general, whenever you make changes to embed settings you are recommended to clear out Embed objects using [`purge_embeds` command](purge_embeds).

docs/advanced_topics/i18n.md

@@ -1,6 +1,6 @@
 (internationalisation)=
 
-# Internationalisation
+# Internationalization
 
 ```{contents}
 ---
@@ -25,14 +25,14 @@ There are two options for managing translations across different languages in th
 [wagtail.contrib.simple_translation](simple_translation) or the more advanced [wagtail-localize](https://github.com/wagtail/wagtail-localize) (third-party package).
 ```
 
-This document only covers the internationalisation of content managed by Wagtail.
+This document only covers the internationalization of content managed by Wagtail.
 For information on how to translate static content in template files, JavaScript
-code, etc, refer to the [Django internationalisation docs](inv:django#topics/i18n/translation).
+code, etc, refer to the [Django internationalization docs](inv:django#topics/i18n/translation).
 Or, if you are building a headless site, refer to the docs of the frontend framework you are using.
 
 ### Wagtail's approach to multi-lingual content
 
-This section provides an explanation of Wagtail's internationalisation approach.
+This section provides an explanation of Wagtail's internationalization approach.
 If you're in a hurry, you can skip to [](Configuration).
 
 In summary:
@@ -75,7 +75,7 @@ one translation in the same locale.
 When you set up a site in Wagtail, you select the site's homepage in the 'root page'
 field and all requests to that site's root URL will be routed to that page.
 
-Multi-lingual sites have a separate homepage for each locale that exist as siblings
+Multi-lingual sites have a separate homepage for each locale that exists as siblings
 in the page tree. Wagtail finds the other homepages by looking for translations of
 the site's 'root page'.
 
@@ -90,9 +90,9 @@ this field to specify the default language of your site.
 
 For detecting the user's language and adding a prefix to the URLs
 (`/en/`, `/fr-fr/`, for example), Wagtail is designed to work with Django's
-built-in internationalisation utilities such as `i18n_patterns` and
+built-in internationalization utilities such as `i18n_patterns` and
 `LocaleMiddleware`. This means that Wagtail should work seamlessly with any
-other internationalised Django applications on your site.
+other internationalized Django applications on your site.
 
 #### Locales
 
@@ -106,15 +106,15 @@ in the shell. The possible values of the `language_code` field are controlled
 by the `WAGTAIL_CONTENT_LANGUAGES` setting.
 
 ```{note}
-Read this if you've changed ``LANGUAGE_CODE`` before enabling internationalisation
+Read this if you've changed ``LANGUAGE_CODE`` before enabling internationalization
 
 On initial migration, Wagtail creates a ``Locale`` record for the language that
 was set in the ``LANGUAGE_CODE`` setting at the time the migration was run. All
-pages will be assigned to this ``Locale`` when Wagtail's internationalisation is disabled.
+pages will be assigned to this ``Locale`` when Wagtail's internationalization is disabled.
 
 If you have changed the ``LANGUAGE_CODE`` setting since updating to Wagtail 2.11,
 you will need to manually update the record in the ``Locale`` model too before
-enabling internationalisation, as your existing content will be assigned to the old code.
+enabling internationalization, as your existing content will be assigned to the old code.
 ```
 
 (configuration)=
@@ -133,9 +133,9 @@ depth: 1
 
 (enabling_internationalisation)=
 
-#### Enabling internationalisation
+#### Enabling internationalization
 
-To enable internationalisation in both Django and Wagtail, set the following
+To enable internationalization in both Django and Wagtail, set the following
 settings to `True`:
 
 ```python
@@ -145,7 +145,7 @@ USE_I18N = True
 WAGTAIL_I18N_ENABLED = True
 ```
 
-In addition, you might also want to enable Django's localisation support. This
+In addition, you might also want to enable Django's localization support. This
 will make dates and numbers display in the user's local format:
 
 ```python
@@ -187,7 +187,7 @@ management UI described in the next section.
 ```
 
 You can also set these to different values. You might want to do this if you
-want to have some programmatic localisation (like date formatting or currency,
+want to have some programmatic localization (like date formatting or currency,
 for example) but use the same Wagtail content in multiple regions:
 
 ```python
@@ -345,11 +345,11 @@ All Wagtail needs is the language to be activated (using Django's
 `django.utils.translation.activate` function) before the
 `wagtail.views.serve` view is called.
 
-### Recipes for internationalised sites
+### Recipes for internationalized sites
 
 #### Language/region selector
 
-Perhaps the most important bit of internationalisation-related UI you can add
+Perhaps the most important bit of internationalization-related UI you can add
 to your site is a selector to allow users to switch between different
 languages.
 
@@ -506,7 +506,7 @@ URL of the page in its default locale.
 
 #### API filters for headless sites
 
-For headless sites, the Wagtail API supports two extra filters for internationalised sites:
+For headless sites, the Wagtail API supports two extra filters for internationalized sites:
 
 -   `?locale=` Filters pages by the given locale
 -   `?translation_of=` Filters pages to only include translations of the given page ID
@@ -541,7 +541,7 @@ make a migration, and run it. This is because the `locale` and `translation_key`
 fields are both required and `translation_key` needs a unique value for each
 instance.
 
-To migrate the existing data properly, we firstly need to use `BootstrapTranslatableMixin`,
+To migrate the existing data properly, we first need to use `BootstrapTranslatableMixin`,
 which excludes these constraints, then add a data migration to set the two fields, then
 switch to `TranslatableMixin`.
 
@@ -659,14 +659,14 @@ Simple Translation is optional. It can be switched out by third-party packages.
 
 #### Wagtail Localize
 
-As part of the initial work on implementing internationalisation for Wagtail core,
+As part of the initial work on implementing internationalization for Wagtail core,
 we also created a translation package called `wagtail-localize`. This supports
 translating pages within Wagtail, using PO files, machine translation, and external
 integration with translation services.
 
 GitHub: [https://github.com/wagtail/wagtail-localize](https://github.com/wagtail/wagtail-localize)
 
-## Alternative internationalisation plugins
+## Alternative internationalization plugins
 
 Before official multi-language support was added into Wagtail, site implementers
 had to use external plugins. These have not been replaced by Wagtail's own

docs/advanced_topics/icons.md

@@ -12,7 +12,7 @@ Elements that use icons are:
 -   [Snippets](wagtailsnippets_icon)
 -   [StreamField blocks](custom_streamfield_blocks)
 
-This document describes how to choose, add and customise icons.
+This document describes how to choose, add and customize icons.
 
 ## Add a custom icon
 

docs/advanced_topics/images/changing_rich_text_representation.md

@@ -2,7 +2,7 @@
 
 # Changing rich text representation
 
-The HTML representation of an image in rich text can be customised - for example, to display captions or custom fields.
+The HTML representation of an image in rich text can be customized - for example, to display captions or custom fields.
 
 To do this requires subclassing `Format` (see [](rich_text_image_formats)), and overriding its `image_to_html` method.
 

docs/advanced_topics/images/custom_image_model.md

@@ -2,7 +2,7 @@
 
 # Custom image models
 
-The `Image` model can be customised, allowing additional fields to be added
+The `Image` model can be customized, allowing additional fields to be added
 to images.
 
 To do this, you need to add two models to your project:

docs/advanced_topics/images/image_serve_view.md

@@ -99,7 +99,7 @@ You can pass an optional view name that will be used to serve the image through.
 
 ### Making the view redirect instead of serve
 
-By default, the view will serve the image file directly. This behaviour can be
+By default, the view will serve the image file directly. This behavior can be
 changed to a 301 redirect instead, which may be useful if you host your images
 externally.
 
@@ -142,7 +142,7 @@ urlpatterns = [
 ]
 ```
 
-You can customise it to override the backend defined in the `SENDFILE_BACKEND`
+You can customize it to override the backend defined in the `SENDFILE_BACKEND`
 setting:
 
 ```python
@@ -153,7 +153,7 @@ class MySendFileView(SendFileView):
     backend = MyCustomBackend
 ```
 
-You can also customise it to serve private files. For example, if the only need
+You can also customize it to serve private files. For example, if the only need
 is to be authenticated (Django >= 1.9):
 
 ```python

docs/advanced_topics/images/renditions.md

@@ -139,7 +139,7 @@ def get_events():
 
 ## Model methods involved in rendition generation
 
-The following `AbstractImage` model methods are involved in finding and generating renditions. If using a custom image model, you can customise the behaviour of either of these methods by overriding them on your model:
+The following `AbstractImage` model methods are involved in finding and generating renditions. If using a custom image model, you can customize the behavior of either of these methods by overriding them on your model:
 
 ```{eval-rst}
 .. automodule:: wagtail.images.models

docs/advanced_topics/images/title_generation_on_upload.md

@@ -2,15 +2,15 @@
 
 # Title generation on upload
 
-When uploading an image, Wagtail takes the filename, removes the file extension, and populates the title field. This section is about how to customise this filename to title conversion.
+When uploading an image, Wagtail takes the filename, removes the file extension, and populates the title field. This section is about how to customize this filename to title conversion.
 
 The filename to title conversion is used on the single file widget, multiple upload widget, and within chooser modals.
 
-You can also customise this [same behaviour for documents](../documents/title_generation_on_upload).
+You can also customize this [same behavior for documents](../documents/title_generation_on_upload).
 
-You can customise the resolved value of this title using a JavaScript [event listener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener) which will listen to the `'wagtail:images-upload'` event.
+You can customize the resolved value of this title using a JavaScript [event listener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener) which will listen to the `'wagtail:images-upload'` event.
 
-The simplest way to add JavaScript to the editor is via the [`insert_global_admin_js` hook](insert_global_admin_js), however any JavaScript that adds the event listener will work.
+The simplest way to add JavaScript to the editor is via the [`insert_global_admin_js` hook](insert_global_admin_js), however, any JavaScript that adds the event listener will work.
 
 ## DOM event
 
@@ -24,7 +24,7 @@ To modify the generated `Image` title, access and update `event.detail.data.titl
 
 For single image uploads, the custom event will only run if the title does not already have a value so that we do not overwrite whatever the user has typed.
 
-You can prevent the default behaviour by calling `event.preventDefault()`. For the single upload page or modals, this will not pre-fill any value into the title. For multiple upload, this will avoid any title submission and use the filename title only (with file extension) as a title is required to save the image.
+You can prevent the default behavior by calling `event.preventDefault()`. For the single upload page or modals, this will not pre-fill any value into the title. For multiple uploads, this will avoid any title submission and use the filename title only (with file extension) as a title is required to save the image.
 
 The event will 'bubble' up so that you can simply add a global `document` listener to capture all of these events, or you can scope your listener or handler logic as needed to ensure you only adjust titles in some specific scenarios.
 

docs/advanced_topics/multi_site_multi_instance_multi_tenancy.md

@@ -14,13 +14,13 @@ Multi-site is a Wagtail project configuration where content creators go into a s
 
 Multi-site configuration is a single code base, on a single server, connecting to a single database. Media is stored in a single media root directory. Content can be shared between sites.
 
-Wagtail supports multi-site out of the box: Wagtail comes with a [site model](wagtail.models.Site). The site model contains a hostname, port, and root page field. When a URL is requested, the request comes in, the domain name and port are taken from the request object to look up the correct site object. The root page is used as starting point to resolve the URL and serve the correct page.
+Wagtail supports multi-site out of the box: Wagtail comes with a [site model](wagtail.models.Site). The site model contains a hostname, port, and root page field. When a URL is requested, the request comes in, the domain name and port are taken from the request object to look up the correct site object. The root page is used as a starting point to resolve the URL and serve the correct page.
 
 Wagtail also comes with [site settings](site_settings). _Site settings_ are 'singletons' that let you store additional information on a site. For example, social media settings, a field to upload a logo, or a choice field to select a theme.
 
 Model objects can be linked to a site by placing a foreign key field on the model pointing to the site object. A request object can be used to look up the current site. This way, content belonging to a specific site can be served.
 
-User, groups, and permissions can be configured in such a way that content creators can only manage the pages, images, and documents of a specific site. Wagtail can have multiple _site objects_ and multiple _page trees_. Permissions can be linked to a specific page tree or a subsection thereof. Collections are used to categorise images and documents. A collection can be restricted to users who are in a specific group.
+User, groups, and permissions can be configured in such a way that content creators can only manage the pages, images, and documents of a specific site. Wagtail can have multiple _site objects_ and multiple _page trees_. Permissions can be linked to a specific page tree or a subsection thereof. Collections are used to categorize images and documents. A collection can be restricted to users who are in a specific group.
 
 Some projects require content editors to have permissions on specific sites and restrict access to other sites. Splitting _all_ content per site and guaranteeing that no content 'leaks' is difficult to realize in a multi-site project. If you require full separation of content, then multi-instance might be a better fit...
 
@@ -48,13 +48,13 @@ Because each site has its own database and media folder, nothing can 'leak' to a
 
 In this configuration, multiple sites share the same, single set of project files. Deployment would update the single set of project files and reload each instance.
 
-This multi-instance configuration isn't that different from deploying the project code several times. However, having a single set of project files, and only differentiate with settings files, is the closest Wagtail can get to true multi-tenancy. Every site is identical, content is separated, including user management. 'Adding a new tenant' is adding a new settings file and running a new instance.
+This multi-instance configuration isn't that different from deploying the project code several times. However, having a single set of project files, and only differentiating with settings files, is the closest Wagtail can get to true multi-tenancy. Every site is identical, content is separated, including user management. 'Adding a new tenant' is adding a new settings file and running a new instance.
 
 In a multi-instance configuration, each instance requires a certain amount of server resources (CPU and memory). That means adding sites will increase server load. This only scales up to a certain point.
 
 ## Multi-tenancy
 
-Multi-tenancy is a project configuration in which a single instance of the software serves multiple tenants. A tenant is a group of users who have access and permission to a single site. Multitenant software is designed to provide every tenant its configuration, data, and user management.
+Multi-tenancy is a project configuration in which a single instance of the software serves multiple tenants. A tenant is a group of users who have access and permission to a single site. Multitenant software is designed to provide every tenant with its configuration, data, and user management.
 
 Wagtail supports _multi-site_, where user management and content are shared. Wagtail can run _multi-instance_ where there is full separation of content at the cost of running multiple instances. Multi-tenancy combines the best of both worlds: a single instance, and the full separation of content per site and user management.
 
@@ -81,7 +81,7 @@ But several features do not currently support multi-tenancy:
 
 Permission configuration for built-in models like Sites, Site settings and Users is not site-specific, so any user with permission to edit a single entry can edit them all. This limitation can be mostly circumvented by only allowing superusers to manage these models.
 
-Python, Django, and Wagtail allow you to override, extend and customise functionality. Here are some ideas that may help you create a multi-tenancy solution for your site:
+Python, Django, and Wagtail allow you to override, extend and customize functionality. Here are some ideas that may help you create a multi-tenancy solution for your site:
 
 -   Django allows to override templates, this also works in the Wagtail admin.
 -   A custom user model can be used to link users to a specific site.

docs/advanced_topics/performance.md

@@ -4,7 +4,7 @@
 
 Wagtail is designed for speed, both in the editor interface and on the front-end, but if you want even better performance or you need to handle very high volumes of traffic, here are some tips on eking out the most from your installation.
 
-We have tried to minimise external dependencies for a working installation of Wagtail, in order to make it as simple as possible to get going. However, a number of default settings can be configured for better performance:
+We have tried to minimize external dependencies for a working installation of Wagtail, in order to make it as simple as possible to get going. However, a number of default settings can be configured for better performance:
 
 ## Cache
 
@@ -74,7 +74,7 @@ To fully resolve the URL of a page, Wagtail requires information from a few diff
 
 The methods used to get the URL of a `Page` such as `Page.get_url` and `Page.get_full_url` optionally accept extra arguments for `request` and `current_site`. Passing these arguments enable much of underlying site-level URL information to be reused for the current request. In situations such as navigation menu generation, plus any links that appear in page content, providing `request` or `current_site` can result in a drastic reduction in the number of cache or database queries your site will generate for a given page load.
 
-When using the [`{% pageurl %}`](pageurl_tag) or [`{% fullpageurl %}`](fullpageurl_tag) template tags, the request is automatically passed in, so no further optimisation is needed.
+When using the [`{% pageurl %}`](pageurl_tag) or [`{% fullpageurl %}`](fullpageurl_tag) template tags, the request is automatically passed in, so no further optimization is needed.
 
 ## Search
 
@@ -100,7 +100,7 @@ Wagtail supports automatic cache invalidation for Varnish/Squid. See [](frontend
 
 For some images, it may be beneficial to lazy load images, so the rest of the page can continue to load. It can be configured site-wide [](adding_default_attributes_to_images) or per-image [](image_tag_alt). For more details you can read about the [`loading='lazy'` attribute](https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading#images_and_iframes) and the [`'decoding='async'` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-decoding) or this [web.dev article on lazy loading images](https://web.dev/lazy-loading-images/).
 
-This optimisation is already handled for you for images in the admin site.
+This optimization is already handled for you for images in the admin site.
 
 ## Template fragment caching
 

docs/advanced_topics/privacy.md

@@ -2,21 +2,21 @@
 
 # Private pages
 
-Users with publish permission on a page can set it to be private by clicking the 'Privacy' control in the top right corner of the page explorer or editing interface. This sets a restriction on who is allowed to view the page and its sub-pages. Several different kinds of restriction are available:
+Users with publish permission on a page can set it to be private by clicking the 'Privacy' control in the top right corner of the page explorer or editing interface. This sets a restriction on who is allowed to view the page and its sub-pages. Several different kinds of restrictions are available:
 
 -   **Accessible to logged-in users:** The user must log in to view the page. All user accounts are granted access, regardless of permission level.
 -   **Accessible with the following password:** The user must enter the given password to view the page. This is appropriate for situations where you want to share a page with a trusted group of people, but giving them individual user accounts would be overkill. The same password is shared between all users, and this works independently of any user accounts that exist on the site.
--   **Accessible to users in specific groups:** The user must be logged in, and a member of one or more of the specified groups, in order to view the page.
+-   **Accessible to users in specific groups:** The user must be logged in, and a member of one or more of the specified groups, to view the page.
 
 Similarly, documents can be made private by placing them in a collection with appropriate privacy settings (see: [](image_document_permissions)).
 
-Private pages and documents work on Wagtail out of the box - the site implementer does not need to do anything to set them up. However, the default "log in" and "password required" forms are only bare-bones HTML pages, and site implementers may wish to replace them with a page customised to their site design.
+Private pages and documents work on Wagtail out of the box - the site implementer does not need to do anything to set them up. However, the default "login" and "password required" forms are only bare-bones HTML pages, and site implementers may wish to replace them with a page customized to their site design.
 
 (login_page)=
 
 ## Setting up a login page
 
-The basic login page can be customised by setting `WAGTAIL_FRONTEND_LOGIN_TEMPLATE` to the path of a template you wish to use:
+The basic login page can be customized by setting `WAGTAIL_FRONTEND_LOGIN_TEMPLATE` to the path of a template you wish to use:
 
 ```python
 WAGTAIL_FRONTEND_LOGIN_TEMPLATE = 'myapp/login.html'
@@ -42,7 +42,7 @@ PASSWORD_REQUIRED_TEMPLATE = 'myapp/password_required.html'
 
 This template will receive the same set of context variables that the blocked page would pass to its own template via `get_context()` - including `page` to refer to the page object itself - plus the following additional variables (which override any of the page's own context variables of the same name):
 
--   **form** - A Django form object for the password prompt; this will contain a field named `password` as its only visible field. A number of hidden fields may also be present, so the page must loop over `form.hidden_fields` if not using one of Django's rendering helpers such as `form.as_p`.
+-   **form** - A Django form object for the password prompt; this will contain a field named `password` as its only visible field. Several hidden fields may also be present, so the page must loop over `form.hidden_fields` if not using one of Django's rendering helpers such as `form.as_p`.
 -   **action_url** - The URL that the password form should be submitted to, as a POST request.
 
 A basic template suitable for use as `PASSWORD_REQUIRED_TEMPLATE` might look like this:
@@ -57,7 +57,7 @@ A basic template suitable for use as `PASSWORD_REQUIRED_TEMPLATE` might look lik
         <h1>Password required</h1>
         <p>
             You need a password to access this page.
-            {% if user.is_authenticated %}To proceed, please login with an account that has access.{% endif %}
+            {% if user.is_authenticated %}To proceed, please log in with an account that has access.{% endif %}
         </p>
         <form action="{{ action_url }}" method="POST">
             {% csrf_token %}
@@ -83,7 +83,7 @@ Password restrictions on documents use a separate template, specified through th
 
 ## Setting a "password required" page for a specific page type
 
-The attribute `password_required_template` can be defined on a page model to use a custom template for the "password required" view, for that page type only. For example, if a site had a page type for displaying embedded videos along with a description, it might choose to use a custom "password required" template that displays the video description as usual, but shows the password form in place of the video embed.
+The attribute `password_required_template` can be defined on a page model to use a custom template for the "password required" view, for that page type only. For example, if a site had a page type for displaying embedded videos along with a description, it might choose to use a custom "password required" template that displays the video description as usual but shows the password form in place of the video embed.
 
 ```python
 class VideoPage(Page):

docs/advanced_topics/streamfield_migrations.md

@@ -6,7 +6,7 @@
 
 ## Migrating RichTextFields to StreamField
 
-If you change an existing RichTextField to a StreamField, the database migration will complete with no errors, since both fields use a text column within the database. However, StreamField uses a JSON representation for its data, so the existing text requires an extra conversion step in order to become accessible again. For this to work, the StreamField needs to include a RichTextBlock as one of the available block types. Create the migration as normal using `./manage.py makemigrations`, then edit it as follows (in this example, the 'body' field of the `demo.BlogPage` model is being converted to a StreamField with a RichTextBlock named `rich_text`):
+If you change an existing RichTextField to a StreamField, the database migration will complete with no errors, since both fields use a text column within the database. However, StreamField uses a JSON representation for its data, so the existing text requires an extra conversion step to become accessible again. For this to work, the StreamField needs to include a RichTextBlock as one of the available block types. Create the migration as normal using `./manage.py makemigrations`, then edit it as follows (in this example, the 'body' field of the `demo.BlogPage` model is being converted to a StreamField with a RichTextBlock named `rich_text`):
 
 ```python
 import json
@@ -317,7 +317,7 @@ class Migration(migrations.Migration):
 
 In a StreamField, accessing just the field is not enough, since we will typically need to operate on specific block types. For this, we define a block path which points to that specific block path within the `StreamField` definition to obtain the specific data we need. Finally, we define an operation to update that data. As such we have an `(IntraFieldOperation(), 'block_path')` tuple. We can have as many as these as we like in our `operations_and_block_paths`, but for now we'll look at a single one for our rename operation.
 
-In this case the block that we are operating on is `stream1`, the parent of the block being renamed (refer to [](rename_stream_children_operation) - for rename and remove operations we always operate on the parent block). In that case our block path will be `stream1`. Next we need a function which will update our data. For this, the `wagtail.blocks.operations` module has a set of commonly used intra-field operations available (and it is possible to write [custom operations](custom_streamfield_migration_operations)). Since this is a rename operation which operates on a StreamField, we will use `wagtail.blocks.operations.RenameStreamChildrenOperation` which accepts two arguments as the old block name and the new block name. As such our operation and block path tuple will look like:
+In this case the block that we are operating on is `stream1`, the parent of the block being renamed (refer to [](rename_stream_children_operation) - for rename and remove operations we always operate on the parent block). In that case our block path will be `stream1`. Next we need a function that will update our data. For this, the `wagtail.blocks.operations` module has a set of commonly used intra-field operations available (and it is possible to write [custom operations](custom_streamfield_migration_operations)). Since this is a rename operation that operates on a StreamField, we will use `wagtail.blocks.operations.RenameStreamChildrenOperation` which accepts two arguments as the old block name and the new block name. As such our operation and block path tuple will look like this:
 
 ```python
 (RenameStreamChildrenOperation(old_name="field1", new_name="block1"), "stream1")
@@ -509,7 +509,7 @@ Block ids are not preserved here since the new blocks are structurally different
 While this package comes with a set of operations for common use cases, there may be many instances where you need to define your own operation for mapping data. Making a custom operation is fairly straightforward. All you need to do is extend the `BaseBlockOperation` class and define the required methods,
 
 -   `apply`  
-    This applies the actual changes on the existing block value and returns the new block value.
+    This applies the actual changes to the existing block value and returns the new block value.
 -   `operation_name_fragment`  
     (`@property`) Returns a name to be used for generating migration names.
 
@@ -543,7 +543,7 @@ class MyBlockOperation(BaseBlockOperation):
 
 Note that depending on the type of block we're dealing with, the `block_value` which is passed to `apply` may take different structures.
 
-For non structural blocks, the value of the block will be passed directly. For example, if we're dealing with a `CharBlock`, it will be a string value.
+For non-structural blocks, the value of the block will be passed directly. For example, if we're dealing with a `CharBlock`, it will be a string value.
 
 The value passed to `apply` when the matched block is a StreamBlock would look like this,
 
@@ -583,7 +583,7 @@ Take a look at the implementation of `RenameStreamChildrenOperation` for an exam
 
 #### Old list format
 
-Prior to Wagtail version 2.16, `ListBlock` children were saved as just a normal python list of values. However for newer versions of Wagtail, list block children are saved as `ListValue`s. When handling raw data, the changes would look like the following:
+Prior to Wagtail version 2.16, `ListBlock` children were saved as just a normal Python list of values. However, for newer versions of Wagtail, list block children are saved as `ListValue`s. When handling raw data, the changes would look like the following:
 
 Old format
 

docs/advanced_topics/sustainability_considerations.md

@@ -4,7 +4,7 @@ Here are guidelines and resources we recommend for projects with sustainability
 
 ## Standards
 
-To account for the emissions of websites and track their reduction, we recommend following:
+To account for the emissions of websites and track their reduction, we recommend the following:
 
 -   ITU [L.1420](https://www.itu.int/rec/T-REC-L.1420) and [L.1430](https://www.itu.int/rec/T-REC-L.1430)
 -   GHG Protocol [Product Life Cycle Accounting and Reporting Standard](https://ghgprotocol.org/product-standard) (Scope 3), and its additional [ICT Sector Guidance](https://ghgprotocol.org/guidance-built-ghg-protocol).
@@ -13,7 +13,7 @@ Those are the same standards used to assess the [sustainability of Wagtail](http
 
 ## Guidelines
 
-Here are guidelines we would recommend applying to Wagtail websites:
+Here are the guidelines we would recommend applying to Wagtail websites:
 
 -   [Sustainable Web Design Strategies](https://sustainablewebdesign.org/strategies/)
 -   [GR491](https://gr491.isit-europe.org/en/)
@@ -26,10 +26,10 @@ The [Sustainable Web Design W3C Community Group](https://www.w3.org/community/su
 
 To quantify the emissions of a Wagtail website, we recommend three different approaches:
 
--   The [Sustainable Web Design](https://sustainablewebdesign.org/calculating-digital-emissions/) model, which uses page weight as a metric of energy efficiency, and page views as a metric of site utilisation. This model has clear [known limitations](https://www.fershad.com/writing/is-data-the-best-proxy-for-website-carbon-emissions/), but is nonetheless ideal to provide high-level figures for a wide range of websites or pages.
+-   The [Sustainable Web Design](https://sustainablewebdesign.org/calculating-digital-emissions/) model, which uses page weight as a metric of energy efficiency, and page views as a metric of site utilization. This model has clear [known limitations](https://www.fershad.com/writing/is-data-the-best-proxy-for-website-carbon-emissions/), but is nonetheless ideal to provide high-level figures for a wide range of websites or pages.
 -   Infrastructure-based calculators such as [Cloud Carbon Footprint](https://www.cloudcarbonfootprint.org/), a measurement and analysis tools.
 -   Measurement orchestration tools such as [Green Metrics](https://github.com/green-coding-berlin/green-metrics-tool), [GreenFrame](https://greenframe.io/), [Scaphandre](https://github.com/hubblo-org/scaphandre).
 
 ---
 
-We are working upon those considerations as part of Wagtail's development process. An example of this is the two [Google Summer of Code internships focusing on sustainability](https://wagtail.org/blog/going-green-with-google-summer-of-code/), in partnership with the [Green Web Foundation and Green Coding Berlin](https://github.com/wagtail/wagtail/discussions/8843).
+We are working on those considerations as part of Wagtail's development process. An example of this is the two [Google Summer of Code internships focusing on sustainability](https://wagtail.org/blog/going-green-with-google-summer-of-code/), in partnership with the [Green Web Foundation and Green Coding Berlin](https://github.com/wagtail/wagtail/discussions/8843).

docs/advanced_topics/testing.md

@@ -299,7 +299,7 @@ Here are a few things to be wary of.
 
 #### Custom Page models
 
-When creating customised Page models in fixtures, you will need to add both a
+When creating customized Page models in fixtures, you will need to add both a
 `wagtailcore.page` entry, and one for your custom Page model.
 
 Let's say you have a `website` module which defines a `Homepage(Page)` class.
@@ -326,7 +326,7 @@ You could create such a homepage in a fixture with:
 
 #### Treebeard fields
 
-Filling in the `path` / `numchild` / `depth` fields is necessary in order for tree operations like `get_parent()` to work correctly.
+Filling in the `path` / `numchild` / `depth` fields is necessary for tree operations like `get_parent()` to work correctly.
 `url_path` is another field that can cause errors in some uncommon cases if it isn't filled in.
 
 The [Treebeard docs](https://django-treebeard.readthedocs.io/en/latest/mp_tree.html) might help in understanding how this works.

docs/topics/images.md

@@ -2,7 +2,7 @@
 
 # How to use images in templates
 
-The `image` tag inserts an XHTML-compatible `img` element into the page, setting its `src`, `width`, `height` and `alt`. See also [](image_tag_alt).
+The `image` tag inserts an XHTML-compatible `img` element into the page, setting its `src`, `width`, `height`, and `alt`. See also [](image_tag_alt).
 
 The syntax for the tag is thus:
 
@@ -49,7 +49,7 @@ Compared to `image`, this will render a `<picture>` element with a fallback `<im
 </picture>
 ```
 
-In this case, if the browser supports the [AVIF](https://en.wikipedia.org/wiki/AVIF) format it will load the AVIF file. Otherwise, if the browser supports the [WebP](https://en.wikipedia.org/wiki/WebP) format, it will try to load the WebP file. If none of those formats are supported, the browser will load the JPEG image. The order of the provided formats isn’t configurable – Wagtail will always output source elements in the following order: AVIF, WebP, JPEG, PNG, GIF. This ensures the most optimized format is provided whenever possible.
+In this case, if the browser supports the [AVIF](https://en.wikipedia.org/wiki/AVIF) format it will load the AVIF file. Otherwise, if the browser supports the [WebP](https://en.wikipedia.org/wiki/WebP) format, it will try to load the WebP file. If none of those formats are supported, the browser will load the JPEG image. The order of the provided formats isn’t configurable – Wagtail will always output source elements in the following order: AVIF, WebP, JPEG, PNG, and GIF. This ensures the most optimized format is provided whenever possible.
 
 The `picture` tag can also be used with multiple image resize rules to generate responsive images.
 
@@ -68,7 +68,7 @@ The syntax for `srcset_image` is the same as `image`, with two exceptions:
 - The resize rule should be provided with multiple sizes in a brace-expansion pattern, like `width-{200,400}`. This will generate the `srcset` attribute, with as many URLs as there are sizes defined in the resize rule, and one width descriptor per URL. The first provided size will always be used as the `src` attribute, and define the image’s width and height attributes, as a fallback.
 - The [`sizes`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#sizes) attribute is essential. This tells the browser how large the image will be displayed on the page, so that it can select the most appropriate image to load.
 
-Here is an example of `srcset_image` in action, generating an `srcset` attribute:
+Here is an example of `srcset_image` in action, generating a `srcset` attribute:
 
 ```html+django
 {% srcset_image page.photo width-{400,800} sizes="(max-width: 600px) 400px, 80vw" %}
@@ -80,7 +80,7 @@ This outputs:
 <img srcset="/media/images/pied-wagtail.width-400.jpg 400w, /media/images/pied-wagtail.width-800.jpg 800w" src="/media/images/pied-wagtail.width-400.jpg" alt="A pied Wagtail" sizes="(max-width: 600px) 400px, 80vw" width="400" height="300">
 ```
 
-And here is an example with the `picture` tag:
+Here is an example with the `picture` tag:
 
 ```html+django
 {% picture page.photo format-{avif,webp,jpeg} width-{400,800} sizes="80vw" %}
@@ -176,7 +176,7 @@ Resize and **crop** to fill the **exact** dimensions specified.
 
 This can be particularly useful for websites requiring square thumbnails of arbitrary images. For example, a landscape image of width 2000 and height 1000 treated with the `fill-200x200` rule would have its height reduced to 200, then its width (ordinarily 400) cropped to 200.
 
-This resize-rule will crop to the image's focal point if it has been set. If not, it will crop to the centre of the image.
+This resize-rule will crop to the image's focal point if it has been set. If not, it will crop to the center of the image.
 
 ![Example of fill filter on an image](../_static/images/image_filter_fill.png)
 
@@ -204,11 +204,11 @@ If you find that `-c100` is too close, you can try `-c75` or `-c50`. Any whole n
 
 ![Example of fill filter on an image with a focal point set](../_static/images/image_filter_fill_focal.png)
 
-Example: The focal point is set off centre so the image is scaled and also cropped like fill, however the center point of the crop is positioned closer the focal point.
+Example: The focal point is set off center so the image is scaled and also cropped like fill, however the center point of the crop is positioned closer to the focal point.
 
 ![Example of fill and closeness filter on an image with a focal point set](../_static/images/image_filter_fill_focal_close.png)
 
-Example: With `-c75` set, the final crop will be closer to the focal point.
+Example: With the `-c75` set, the final crop will be closer to the focal point.
 
 ### `original`
 
@@ -318,7 +318,7 @@ This is useful for images that will be re-used outside of the current site, such
 <meta name="twitter:image" content="{{ tmp_photo.full_url }}">
 ```
 
-If your site defines a custom image model using `AbstractImage`, any additional fields you add to an image (such as a copyright holder) are **not** included in the rendition.
+If your site defines a custom image model using `AbstractImage`, any additional fields you add to an image (such as a copyright holder) is **not** included in the rendition.
 
 Therefore, if you'd added the field `author` to your AbstractImage in the above example, you'd access it using `{{ page.photo.author }}` rather than `{{ tmp_photo.author }}`.
 
@@ -388,7 +388,7 @@ And to use the `<amp-img>` tag (based on the [Mountains example](https://amp.dev
 
 The information above relates to images defined via image-specific fields in your model. However, images can also be embedded arbitrarily in Rich Text fields by the page editor (see [](rich_text_field).
 
-Images embedded in Rich Text fields can't be controlled by the template developer as easily. There are no image objects to work with, so the `{% image %}` template tag can't be used. Instead, editors can choose from one of a number of image "Formats" at the point of inserting images into their text.
+Images embedded in Rich Text fields can't be controlled by the template developer as easily. There are no image objects to work with, so the `{% image %}` template tag can't be used. Instead, editors can choose from one of several image "Formats" at the point of inserting images into their text.
 
 Wagtail comes with three pre-defined image formats, but more can be defined in Python by the developer. These formats are:
 
@@ -444,15 +444,15 @@ You can encode the image into lossless AVIF or WebP format by using `format-avif
 
 (image_background_colour)=
 
-## Background colour
+## Background color
 
 The PNG and GIF image formats both support transparency, but if you want to
-convert images to JPEG format, the transparency will need to be replaced with a solid background colour.
+convert images to JPEG format, the transparency will need to be replaced with a solid background color.
 
-By default, Wagtail will set the background to white. But if a white background doesn't fit your design, you can specify a colour using the `bgcolor` filter.
+By default, Wagtail will set the background to white. But if a white background doesn't fit your design, you can specify a color using the `bgcolor` filter.
 
 This filter takes a single argument, which is a CSS 3 or 6-digit hex code
-representing the colour you would like to use:
+representing the color you would like to use:
 
 ```html+django
 {# Sets the image background to black #}
@@ -469,7 +469,7 @@ This can be changed either globally or on a per-tag basis.
 ### Changing globally
 
 Use the `WAGTAILIMAGES_AVIF_QUALITY`, `WAGTAILIMAGES_JPEG_QUALITY` and `WAGTAILIMAGES_WEBP_QUALITY` settings to change
-the global defaults of AVIF, JPEG and WebP quality:
+the global defaults of AVIF, JPEG, and WebP quality:
 
 ```python
 # settings.py
@@ -498,7 +498,7 @@ You can read more about this command from [](wagtail_update_image_renditions)
 
 ### Changing per-tag
 
-It's also possible to have different AVIF, JPEG and WebP qualities on individual tags by using `avifquality`, `jpegquality` and `webpquality` filters. This will always override the default setting:
+It's also possible to have different AVIF, JPEG, and WebP qualities on individual tags by using `avifquality`, `jpegquality`, and `webpquality` filters. This will always override the default setting:
 
 ```html+django
 {% image page.photo_avif width-400 avifquality-40 %}
@@ -506,7 +506,7 @@ It's also possible to have different AVIF, JPEG and WebP qualities on individual
 {% image page.photo_webp width-400 webpquality-50 %}
 ```
 
-Note that this will have no effect on PNG or GIF files. If you want all images to be low quality, you can use this filter with `format-avif`, `format-jpeg` or `format-webp` (which forces all images to output in AVIF, JPEG or WebP format):
+Note that this will not affect PNG or GIF files. If you want all images to be low quality, you can use this filter with `format-avif`, `format-jpeg`, or `format-webp` (which forces all images to output in AVIF, JPEG, or WebP format):
 
 ```html+Django
 {% image page.photo width-400 format-avif avifquality-40 %}
@@ -529,9 +529,9 @@ Wagtail supports the use of Scalable Vector Graphics alongside raster images. To
 WAGTAILIMAGES_EXTENSIONS = ["gif", "jpg", "jpeg", "png", "webp", "svg"]
 ```
 
-SVG images can be included in templates via the `image` template tag, as with raster images. However, operations that require SVG images to be rasterised are not currently supported. This includes direct format conversion, e.g. `format-webp`, and `bgcolor` directives. Crop and resize operations do not require rasterisation, so may be used freely (see [](available_resizing_methods)).
+SVG images can be included in templates via the `image` template tag, as with raster images. However, operations that require SVG images to be rasterized are not currently supported. This includes direct format conversion, e.g. `format-webp`, and `bgcolor` directives. Crop and resize operations do not require rasterization, so may be used freely (see [](available_resizing_methods)).
 
-The `image` tag's `preserve-svg` positional argument may be used to restrict the operations applied to an SVG image to only those that do not require rasterisation. This may be useful in situations where a single `image` tag declaration is applied to multiple source images, for example:
+The `image` tag's `preserve-svg` positional argument may be used to restrict the operations applied to an SVG image to only those that do not require rasterization. This may be useful in situations where a single `image` tag declaration is applied to multiple source images, for example:
 
 ```html+django
 {% for picture in pictures %}
@@ -539,13 +539,13 @@ The `image` tag's `preserve-svg` positional argument may be used to restrict the
 {% endfor %}
 ```
 
-In this example, any of the image objects that are SVGs will only have the `fill-400x400` operation applied to them, while raster images will have both the `fill-400x400` and `format-webp` operations applied. If the `preserve-svg` argument is not used in this example, an error will be raised when attempting to convert SVG images to webp, as this is not possible without a rasterisation library.
+In this example, any of the image objects that are SVGs will only have the `fill-400x400` operation applied to them, while raster images will have both the `fill-400x400` and `format-webp` operations applied. If the `preserve-svg` argument is not used in this example, an error will be raised when attempting to convert SVG images to webp, as this is not possible without a rasterization library.
 
 ### Security considerations
 
 Wagtail's underlying image library, Willow, is configured to mitigate known XML parser exploits (e.g. billion laughs, quadratic blowup) by rejecting suspicious files.
 
-When including SVG images in templates via the `image` tag, they will be rendered as html `img` elements. In this case, `script` elements in SVGs will not be executed, mitigating XSS attacks.
+When including SVG images in templates via the `image` tag, they will be rendered as HTML `img` elements. In this case, `script` elements in SVGs will not be executed, mitigating XSS attacks.
 
 If a user navigates directly to the URL of the SVG file embedded scripts may be executed, depending on server/storage configuration. This can be mitigated by setting appropriate Content-Security-Policy or Content-Disposition headers for SVG responses:
 

docs/topics/permissions.md

@@ -2,7 +2,7 @@
 
 # Permissions
 
-Wagtail adapts and extends [the Django permission system](https://docs.djangoproject.com/en/stable/topics/auth/default/#topic-authorization) to cater for the needs of website content creation, such as moderation workflows, and multiple teams working on different areas of a site (or multiple sites within the same Wagtail installation). Permissions can be configured through the 'Groups' area of the Wagtail admin interface, under 'Settings'.
+Wagtail adapts and extends [the Django permission system](https://docs.djangoproject.com/en/stable/topics/auth/default/#topic-authorization) to cater to the needs of website content creation, such as moderation workflows, and multiple teams working on different areas of a site (or multiple sites within the same Wagtail installation). Permissions can be configured through the 'Groups' area of the Wagtail admin interface, under 'Settings'.
 
 ```{note}
 Whilst Wagtail supports a number of user roles and permissions, the Wagtail Admin should still be restricted to trusted users.
@@ -21,9 +21,9 @@ MegaCorp/
         Germany
 ```
 
-then a group with 'edit' permissions on the 'Offices' page would automatically receive the ability to edit the 'UK', 'France' and 'Germany' pages. Permissions can be set globally for the entire tree by assigning them on the 'root' page - since all pages must exist underneath the root node, and the root cannot be deleted, this permission will cover all pages that exist now and in future.
+then a group with 'edit' permissions on the 'Offices' page would automatically receive the ability to edit the 'UK', 'France', and 'Germany' pages. Permissions can be set globally for the entire tree by assigning them on the 'root' page - since all pages must exist underneath the root node, and the root cannot be deleted, this permission will cover all pages that exist now and in the future.
 
-Whenever a user creates a page through the Wagtail admin, that user is designated as the owner of that page. Any user with 'add' permission has the ability to edit pages they own, as well as adding new ones. This is in recognition of the fact that creating pages is typically an iterative process involving creating a number of draft versions - giving a user the ability to create a draft but not letting them subsequently edit it would not be very useful. Ability to edit a page also implies the ability to delete it; unlike Django's standard permission model, there is no distinct 'delete' permission.
+Whenever a user creates a page through the Wagtail admin, that user is designated as the owner of that page. Any user with 'add' permission has the ability to edit pages they own, as well as add new ones. This is in recognition of the fact that creating pages is typically an iterative process involving creating a number of draft versions - giving a user the ability to create a draft but not letting them subsequently edit it would not be very useful. The ability to edit a page also implies the ability to delete it; unlike Django's standard permission model, there is no distinct 'delete' permission.
 
 The full set of available permission types is as follows:
 
@@ -41,7 +41,7 @@ Drafts can be viewed only if the user has either Edit or Publish permission.
 
 The permission rules for images and documents work on a similar basis to pages. Images and documents are considered to be 'owned' by the user who uploaded them; a user with 'add' permission also has the ability to edit items they own; and deletion is considered equivalent to editing rather than having a specific permission type.
 
-Access to specific sets of images and documents can be controlled by setting up _collections_. By default all images and documents belong to the 'root' collection, but users with appropriate permissions can create new collections the Settings -> Collections area of the admin interface. Permissions set on 'root' apply to all collections, so a user with 'edit' permission for images in the root collection can edit all images; permissions set on other collections only apply to that collection and any of its sub-collections.
+Access to specific sets of images and documents can be controlled by setting up _collections_. By default, all images and documents belong to the 'root' collection, but users with appropriate permissions can create new collections in the Settings -> Collections area of the admin interface. Permissions set on 'root' apply to all collections, so a user with 'edit' permission for images in the root collection can edit all images; permissions set on other collections only apply to that collection and any of its sub-collections.
 
 The 'choose' permission for images and documents determines which collections are visible within the chooser interface used to select images and document links for insertion into pages (and other models, such as snippets). Typically, all users are granted choose permission for all collections, allowing them to use any uploaded image or document on pages they create, but this permission can be limited to allow creating collections that are only visible to specific groups.
 
@@ -52,8 +52,8 @@ The 'choose' permission for images and documents determines which collections ar
 Permission for managing collections themselves can be attached at any point in the collection tree. The available collection management permissions are as follows:
 
 -   **Add** - grants the ability to create new collections underneath this collection.
--   **Edit** - grants the ability to edit the name of the collection, change its location in the collection tree, and to change the privacy settings for documents within this collection.
--   **Delete** - grants the ability to delete collections that were added below this collection. _Note:_ a collection must have no subcollections under it and the collection itself must be empty before it can be deleted.
+-   **Edit** - grants the ability to edit the name of the collection, change its location in the collection tree, and change the privacy settings for documents within this collection.
+-   **Delete** - grants the ability to delete collections that were added below this collection. _Note:_ A collection must have no subcollections under it and the collection itself must be empty before it can be deleted.
 
 ```{note}
 Users are not allowed to move or delete the collection that is used to assign them permission to manage collections.
@@ -64,15 +64,15 @@ Users are not allowed to move or delete the collection that is used to assign th
 See Django's documentation on [custom permissions](https://docs.djangoproject.com/en/stable/topics/auth/customizing/#custom-permissions) for details on how to set permissions up.
 
 ```{note}
-Custom permissions starting with `add_`, `change_` or `delete_` are not currently supported in Wagtail as these will conflict with standard model permissions.
+Custom permissions starting with `add_`, `change_`, or `delete_` are not currently supported in Wagtail as these will conflict with standard model permissions.
 ```
 
 ## Displaying custom permissions in the admin
 
-Most permissions will automatically show up in the wagtail admin Group edit form, however, you can also add them using the `register_permissions` hook (see [](register_permissions)).
+Most permissions will automatically show up in the Wagtail admin Group edit form, however, you can also add them using the `register_permissions` hook (see [](register_permissions)).
 
 ## `FieldPanel` and `PanelGroup` permissions
 
 Permissions can be used to restrict access to fields within the editor interface. See `permission` on [FieldPanel](field_panel).
 
-Permissions can be used to restrict groups of panels via the `permission` keyword argument on `PanelGroup` classes (`TabbedInterface`, `ObjectList`, `FieldRowPanel`, `MultiFieldPanel`). See how `PanelGroup` usage can be customised [](forms_panels_overview).
+Permissions can be used to restrict groups of panels via the `permission` keyword argument on `PanelGroup` classes (`TabbedInterface`, `ObjectList`, `FieldRowPanel`, `MultiFieldPanel`). See how `PanelGroup` usage can be customized [](forms_panels_overview).

docs/topics/search/searching.md

@@ -6,7 +6,7 @@
 
 ## Searching QuerySets
 
-Wagtail search is built on Django's [QuerySet API](inv:django#ref/models/querysets). You should be able to search any Django QuerySet provided the model and the fields being filtered on have been added to the search index.
+Wagtail search is built on Django's [QuerySet API](inv:django#ref/models/querysets). You should be able to search any Django QuerySet provided the model and the fields being filtered have been added to the search index.
 
 ### Searching Pages
 
@@ -30,7 +30,7 @@ All other methods of `PageQuerySet` can be used with `search()`. For example:
 The `search()` method will convert your `QuerySet` into an instance of one of Wagtail's `SearchResults` classes (depending on backend). This means that you must perform filtering before calling `search()`.
 ```
 
-The standard behaviour of the `search` method is to only return matches for complete words; for example, a search for "hel" will not return results containing the word "hello". The exception to this is the fallback database search backend, used when the database does not have full-text search extensions available, and no alternative backend has been specified. This performs basic substring matching, and will return results containing the search term ignoring all word boundaries.
+The standard behavior of the `search` method is to only return matches for complete words; for example, a search for "hel" will not return results containing the word "hello". The exception to this is the fallback database search backend, used when the database does not have full-text search extensions available, and no alternative backend has been specified. This performs basic substring matching and will return results containing the search term ignoring all word boundaries.
 
 ### Autocomplete searches
 
@@ -117,7 +117,7 @@ OrderedDict([
 ])
 ```
 
-## Changing search behaviour
+## Changing search behavior
 
 ### Search operator
 
@@ -126,7 +126,7 @@ The search operator specifies how the search should behave when the user has typ
 -   "or" - The results must match at least one term (default for Elasticsearch)
 -   "and" - The results must match all terms (default for database search)
 
-Both operators have benefits and drawbacks. The "or" operator will return many more results but will likely contain a lot of results that aren't relevant. The "and" operator only returns results that contain all search terms, but requires the user to be more precise with their query.
+Both operators have benefits and drawbacks. The "or" operator will return many more results but will likely contain a lot of results that aren't relevant. The "and" operator only returns results that contain all search terms but requires the user to be more precise with their query.
 
 We recommend using the "or" operator when ordering by relevance and the "and" operator when ordering by anything else (note: the database backend doesn't currently support ordering by relevance).
 
@@ -155,7 +155,7 @@ Here's an example of using the `operator` keyword argument:
 [<Thing: Hello world>]
 ```
 
-For page, image and document models, the `operator` keyword argument is also supported on the QuerySet's `search` method:
+For page, image, and document models, the `operator` keyword argument is also supported on the QuerySet's `search` method:
 
 ```python
 >>> Page.objects.search("Hello world", operator="or")
@@ -189,7 +189,7 @@ If you are looking to implement phrase queries using the double-quote syntax, se
 
 Fuzzy matching will return documents which contain terms similar to the search term, as measured by a [Levenshtein edit distance](https://en.wikipedia.org/wiki/Levenshtein_distance).
 
-A maximum of one edit (transposition, insertion, or removal of a character) is permitted for three to five letter terms, two edits for longer terms, and shorter terms must match exactly.
+A maximum of one edit (transposition, insertion, or removal of a character) is permitted for three to five-letter terms, two edits for longer terms, and shorter terms must match exactly.
 
 For example:
 
@@ -257,8 +257,8 @@ Note that this isn't supported by the PostgreSQL or database search backends.
 ### Query string parsing
 
 The previous sections show how to construct a phrase search query manually, but a lot of search engines (Wagtail admin included, try it!)
-support writing phrase queries by wrapping the phrase with double-quotes. In addition to phrases, you might also want to allow users to
-add filters into the query using the colon syntax (`hello world published:yes`).
+support writing phrase queries by wrapping the phrase with double quotes. In addition to phrases, you might also want to allow users to
+add filters to the query using the colon syntax (`hello world published:yes`).
 
 These two features can be implemented using the `parse_query_string` utility function. This function takes a query string that a user
 typed and returns a query object and a [QueryDict](inv:django#django.http.QueryDict) of filters:
@@ -275,12 +275,12 @@ For example:
 >>> filters
 <QueryDict: {'this_is_a': ['filter'], 'key': ['value1', 'value2']}>>
 
-# Get a list of values associated to a particular key using getlist method
+# Get a list of values associated with a particular key using the getlist method
 >>> filters.getlist('key')
 ['value1', 'value2']
 
-# Get a dict representation using dict method
-# NOTE: dict method will reduce multiple values for a particular key to the last assigned value
+# Get a dict representation using the dict method
+# NOTE: The dict method will reduce multiple values for a particular key to the last assigned value
 >>> filters.dict()
 {
     'this_is_a': 'filter',

docs/topics/snippets/customising.md

@@ -4,9 +4,9 @@
 
 (wagtailsnippets_custom_admin_views)=
 
-# Customising admin views for snippets
+# Customizing admin views for snippets
 
-Additional customisations to the admin views for each snippet model can be achieved through a custom {class}`~SnippetViewSet` class. The `SnippetViewSet` is a subclass of {class}`.ModelViewSet`, with snippets-specific properties provided by default. Hence, it supports the same customisations provided by `ModelViewSet` such as customising the listing view (e.g. adding custom columns, filters), creating a custom menu item, and more.
+Additional customizations to the admin views for each snippet model can be achieved through a custom {class}`~SnippetViewSet` class. The `SnippetViewSet` is a subclass of {class}`.ModelViewSet`, with snippets-specific properties provided by default. Hence, it supports the same customizations provided by `ModelViewSet` such as customizing the listing view (e.g. adding custom columns, and filters), creating a custom menu item, and more.
 
 Before proceeding, ensure that you register the snippet model using `register_snippet` as a function instead of a decorator, as described in [](wagtailsnippets_registering).
 
@@ -83,15 +83,15 @@ You can define an {attr}`~.ViewSet.icon` attribute on the `SnippetViewSet` to sp
 
 ## URL namespace and base URL path
 
-The {attr}`~.ViewSet.url_namespace` property can be overridden to use a custom URL namespace for the URL patterns of the views. If unset, it defaults to `wagtailsnippets_{app_label}_{model_name}`. Meanwhile, overriding {attr}`~.ViewSet.url_prefix` allows you to customise the base URL path relative to the Wagtail admin URL. If unset, it defaults to `snippets/app_label/model_name`.
+The {attr}`~.ViewSet.url_namespace` property can be overridden to use a custom URL namespace for the URL patterns of the views. If unset, it defaults to `wagtailsnippets_{app_label}_{model_name}`. Meanwhile, overriding {attr}`~.ViewSet.url_prefix` allows you to customize the base URL path relative to the Wagtail admin URL. If unset, it defaults to `snippets/app_label/model_name`.
 
-Similar URL customisations are also possible for the snippet chooser views through {attr}`~SnippetViewSet.chooser_admin_url_namespace`, {attr}`~SnippetViewSet.chooser_base_url_path`, {meth}`~SnippetViewSet.get_chooser_admin_url_namespace`, and {meth}`~SnippetViewSet.get_chooser_admin_base_path`.
+Similar URL customizations are also possible for the snippet chooser views through {attr}`~SnippetViewSet.chooser_admin_url_namespace`, {attr}`~SnippetViewSet.chooser_base_url_path`, {meth}`~SnippetViewSet.get_chooser_admin_url_namespace`, and {meth}`~SnippetViewSet.get_chooser_admin_base_path`.
 
 ## Listing view
 
-You can customise the listing view to add custom columns, filters, pagination, etc. via various attributes available on the `SnippetViewSet`. Refer to [the listing view customisations for `ModelViewSet`](modelviewset_listing) for more details.
+You can customize the listing view to add custom columns, filters, pagination, etc. via various attributes available on the `SnippetViewSet`. Refer to [the listing view customizations for `ModelViewSet`](modelviewset_listing) for more details.
 
-Additionally, you can customise the base queryset for the listing view by overriding the {meth}`~SnippetViewSet.get_queryset` method.
+Additionally, you can customize the base queryset for the listing view by overriding the {meth}`~SnippetViewSet.get_queryset` method.
 
 ## Copy view
 
@@ -99,21 +99,21 @@ Additionally, you can customise the base queryset for the listing view by overri
 
 ```
 
-The copy view is enabled by default and will be accessible by users with the 'add' permission on the model. To disable it, set {attr}`~.ModelViewSet.copy_view_enabled` to `False`. Refer to [the copy view customisations for `ModelViewSet`](modelviewset_copy) for more details.
+The copy view is enabled by default and will be accessible by users with the 'add' permission on the model. To disable it, set {attr}`~.ModelViewSet.copy_view_enabled` to `False`. Refer to [the copy view customizations for `ModelViewSet`](modelviewset_copy) for more details.
 
 ## Inspect view
 
-The inspect view is disabled by default, as it's not often useful for most models. To enable it, set {attr}`~.ModelViewSet.inspect_view_enabled` to `True`. Refer to [the inspect view customisations for `ModelViewSet`](modelviewset_inspect) for more details.
+The inspect view is disabled by default, as it's not often useful for most models. To enable it, set {attr}`~.ModelViewSet.inspect_view_enabled` to `True`. Refer to [the inspect view customizations for `ModelViewSet`](modelviewset_inspect) for more details.
 
 (wagtailsnippets_templates)=
 
 ## Templates
 
-Template customisations work the same way as for `ModelViewSet`, except that the {attr}`~.ModelViewSet.template_prefix` defaults to `wagtailsnippets/snippets/`. Refer to [the template customisations for `ModelViewSet`](modelviewset_templates) for more details.
+Template customizations work the same way as for `ModelViewSet`, except that the {attr}`~.ModelViewSet.template_prefix` defaults to `wagtailsnippets/snippets/`. Refer to [the template customizations for `ModelViewSet`](modelviewset_templates) for more details.
 
 ## Menu item
 
-By default, registering a snippet model will add a "Snippets" menu item to the sidebar menu. However, you can configure a snippet model to have its own top-level menu item in the sidebar menu by setting {attr}`~.ViewSet.add_to_admin_menu` to `True`. Refer to [the menu customisations for `ModelViewSet`](modelviewset_menu) for more details.
+By default, registering a snippet model will add a "Snippets" menu item to the sidebar menu. However, you can configure a snippet model to have its own top-level menu item in the sidebar menu by setting {attr}`~.ViewSet.add_to_admin_menu` to `True`. Refer to [the menu customizations for `ModelViewSet`](modelviewset_menu) for more details.
 
 An example of a custom `SnippetViewSet` subclass with `add_to_admin_menu` set to `True`:
 
@@ -165,4 +165,4 @@ register_snippet(MarketingViewSetGroup)
 
 If all snippet models have their own menu items, the "Snippets" menu item will not be shown.
 
-Various additional attributes are available to customise the viewset - see {class}`~SnippetViewSet`.
+Various additional attributes are available to customize the viewset - see {class}`~SnippetViewSet`.

docs/topics/snippets/features.md

@@ -43,9 +43,9 @@ With the following `demo/previews/advert.html` template:
 </html>
 ```
 
-The variables available in the default context are `request` (a fake {class}`~django.http.HttpRequest` object) and `object` (the snippet instance). To customise the context, you can override the {meth}`~wagtail.models.PreviewableMixin.get_preview_context` method.
+The variables available in the default context are `request` (a fake {class}`~django.http.HttpRequest` object) and `object` (the snippet instance). To customize the context, you can override the {meth}`~wagtail.models.PreviewableMixin.get_preview_context` method.
 
-By default, the `serve_preview` method returns a {class}`~django.template.response.TemplateResponse` that is rendered using the request object, the template returned by `get_preview_template`, and the context object returned by `get_preview_context`. You can override the `serve_preview` method to customise the rendering and/or routing logic.
+By default, the `serve_preview` method returns a {class}`~django.template.response.TemplateResponse` that is rendered using the request object, the template returned by `get_preview_template`, and the context object returned by `get_preview_context`. You can override the `serve_preview` method to customize the rendering and/or routing logic.
 
 Similar to pages, you can define multiple preview modes by overriding the {attr}`~wagtail.models.PreviewableMixin.preview_modes` property. For example, the following `Advert` snippet has two preview modes:
 
@@ -115,7 +115,7 @@ class Advert(index.Indexed, models.Model):
 
 If a snippet model inherits from {class}`~wagtail.models.RevisionMixin`, Wagtail will automatically save revisions when you save any changes in the snippets admin.
 
-In addition to inheriting the mixin, it is highly recommended to define a {class}`~django.contrib.contenttypes.fields.GenericRelation` to the {class}`~wagtail.models.Revision` model as the {attr}`~wagtail.models.RevisionMixin.revisions` attribute so that you can do related queries. Defining the `GenericRelation` is also necessary to ensure that `Revision` instances are automatically deleted when the snippet instance is deleted. If you need to customise how the revisions are fetched (for example, to handle the content type to use for models with multi-table inheritance), you can define the `revisions` as a property.
+In addition to inheriting the mixin, it is highly recommended to define a {class}`~django.contrib.contenttypes.fields.GenericRelation` to the {class}`~wagtail.models.Revision` model as the {attr}`~wagtail.models.RevisionMixin.revisions` attribute so that you can do related queries. Defining the `GenericRelation` is also necessary to ensure that `Revision` instances are automatically deleted when the snippet instance is deleted. If you need to customize how the revisions are fetched (for example, to handle the content type to use for models with multi-table inheritance), you can define the `revisions` as a property.
 
 For example, the `Advert` snippet could be made revisable as follows:
 
@@ -238,7 +238,7 @@ You can publish revisions programmatically by calling {meth}`instance.publish(re
 
 If you use the scheduled publishing feature, make sure that you run the [`publish_scheduled`](publish_scheduled) management command periodically. For more details, see [](scheduled_publishing).
 
-Publishing a snippet instance requires `publish` permission on the snippet model. For models with `DraftStateMixin` applied, Wagtail automatically creates the corresponding `publish` permissions and display them in the 'Groups' area of the Wagtail admin interface. For more details on how to configure the permission, see [](permissions_overview).
+Publishing a snippet instance requires `publish` permission on the snippet model. For models with `DraftStateMixin` applied, Wagtail automatically creates the corresponding `publish` permissions and displays them in the 'Groups' area of the Wagtail admin interface. For more details on how to configure the permission, see [](permissions_overview).
 
 ```{warning}
 Wagtail does not yet have a mechanism to prevent editors from including unpublished ("draft") snippets in pages. When including a `DraftStateMixin`-enabled snippet in pages, make sure that you add necessary checks to handle how a draft snippet should be rendered (for example, by checking its `live` field). We are planning to improve this in the future.
@@ -276,15 +276,15 @@ If you use the other mixins, make sure to apply `LockableMixin` after the other
 
 The `LockableMixin` includes additional fields that need to be added to your database table. Make sure to run the `makemigrations` and `migrate` management commands after making the above changes to apply the changes to your database.
 
-Locking and unlocking a snippet instance requires `lock` and `unlock` permissions on the snippet model, respectively. For models with `LockableMixin` applied, Wagtail automatically creates the corresponding `lock` and `unlock` permissions and display them in the 'Groups' area of the Wagtail admin interface. For more details on how to configure the permission, see [](permissions_overview).
+Locking and unlocking a snippet instance requires `lock` and `unlock` permissions on the snippet model, respectively. For models with `LockableMixin` applied, Wagtail automatically creates the corresponding `lock` and `unlock` permissions and displays them in the 'Groups' area of the Wagtail admin interface. For more details on how to configure the permission, see [](permissions_overview).
 
 (wagtailsnippets_enabling_workflows)=
 
 ## Enabling workflows for snippets
 
-If a snippet model inherits from {class}`~wagtail.models.WorkflowMixin`, Wagtail will automatically add the ability to assign a workflow to the model. With a workflow assigned to the snippet model, a "Submit for moderation" and other workflow action menu items will be shown in the editor. The status side panel will also show the information of the current workflow.
+If a snippet model inherits from {class}`~wagtail.models.WorkflowMixin`, Wagtail will automatically add the ability to assign a workflow to the model. With a workflow assigned to the snippet model, a "Submit for moderation" and other workflow action menu items will be shown in the editor. The status side panel will also show the information on the current workflow.
 
-Since the `WorkflowMixin` utilises revisions and publishing mechanisms in Wagtail, inheriting from this mixin also requires inheriting from `RevisionMixin` and `DraftStateMixin`. It is also recommended to enable locking by inheriting from `LockableMixin`, so that the snippet instance can be locked and only editable by reviewers when it is in a workflow. See the above sections for more details.
+Since the `WorkflowMixin` utilizes revisions and publishing mechanisms in Wagtail, inheriting from this mixin also requires inheriting from `RevisionMixin` and `DraftStateMixin`. It is also recommended to enable locking by inheriting from `LockableMixin`, so that the snippet instance can be locked and only editable by reviewers when it is in a workflow. See the above sections for more details.
 
 In addition to inheriting the mixins, it is highly recommended to define a {class}`~django.contrib.contenttypes.fields.GenericRelation` to the {class}`~wagtail.models.WorkflowState` model so that you can do related queries and that the workflow-related data is properly cleaned up when the snippet instance is deleted.
 

docs/topics/snippets/registering.md

@@ -2,7 +2,7 @@
 
 # Registering snippets
 
-Snippets can be registered using `register_snippet` as a decorator or as a function. The latter is recommended, but the decorator is provided for convenience and backwards compatibility.
+Snippets can be registered using `register_snippet` as a decorator or as a function. The latter is recommended, but the decorator is provided for convenience and backward compatibility.
 
 ## Using `@register_snippet` as a decorator
 
@@ -47,7 +47,7 @@ from myapp.models import Advert
 register_snippet(Advert)
 ```
 
-Registering snippets in this way allows you to add further customisations using a custom {class}`~wagtail.snippets.views.snippets.SnippetViewSet` class later. This also provides better separation between your Django model and Wagtail-specific concerns. For example, instead of defining the `panels` or `edit_handler` on the model class, they can be defined on the `SnippetViewSet` class:
+Registering snippets in this way allows you to add further customizations using a custom {class}`~wagtail.snippets.views.snippets.SnippetViewSet` class later. This also provides a better separation between your Django model and Wagtail-specific concerns. For example, instead of defining the `panels` or `edit_handler` on the model class, they can be defined on the `SnippetViewSet` class:
 
 ```python
 # myapp/wagtail_hooks.py
@@ -71,4 +71,4 @@ class AdvertViewSet(SnippetViewSet):
 register_snippet(AdvertViewSet)
 ```
 
-If you would like to do more customisations of the panels, you can override the {meth}`~wagtail.snippets.views.snippets.SnippetViewSet.get_edit_handler` method. Further customisations will be explained later in [](wagtailsnippets_custom_admin_views).
+If you would like to do more customizations of the panels, you can override the {meth}`~wagtail.snippets.views.snippets.SnippetViewSet.get_edit_handler` method. Further customizations will be explained later in [](wagtailsnippets_custom_admin_views).

docs/topics/streamfield.md

@@ -2,11 +2,11 @@
 
 # How to use StreamField for mixed content
 
-StreamField provides a content editing model suitable for pages that do not follow a fixed structure -- such as blog posts or news stories -- where the text may be interspersed with subheadings, images, pull quotes and video. It's also suitable for more specialised content types, such as maps and charts (or, for a programming blog, code snippets). In this model, these different content types are represented as a sequence of 'blocks', which can be repeated and arranged in any order.
+StreamField provides a content editing model suitable for pages that do not follow a fixed structure -- such as blog posts or news stories -- where the text may be interspersed with subheadings, images, pull quotes and video. It's also suitable for more specialized content types, such as maps and charts (or, for a programming blog, code snippets). In this model, these different content types are represented as a sequence of 'blocks', which can be repeated and arranged in any order.
 
 For further background on StreamField, and why you would use it instead of a rich text field for the article body, see the blog post [Rich text fields and faster horses](https://torchbox.com/blog/rich-text-fields-and-faster-horses/).
 
-StreamField also offers a rich API to define your own block types, ranging from simple collections of sub-blocks (such as a 'person' block consisting of first name, surname and photograph) to completely custom components with their own editing interface. Within the database, the StreamField content is stored as JSON, ensuring that the full informational content of the field is preserved, rather than just an HTML representation of it.
+StreamField also offers a rich API to define your own block types, ranging from simple collections of sub-blocks (such as a 'person' block consisting of first name, surname, and photograph) to completely custom components with their own editing interface. Within the database, the StreamField content is stored as JSON, ensuring that the full informational content of the field is preserved, rather than just an HTML representation of it.
 
 ## Using StreamField
 
@@ -498,7 +498,7 @@ All block types, not just `StructBlock`, support the `template` property. Howeve
 
 ## Customisations
 
-All block types implement a common API for rendering their front-end and form representations, and storing and retrieving values to and from the database. By subclassing the various block classes and overriding these methods, all kinds of customisations are possible, from modifying the layout of StructBlock form fields to implementing completely new ways of combining blocks. For further details, see [](custom_streamfield_blocks).
+All block types implement a common API for rendering their front-end and form representations, and storing and retrieving values to and from the database. By subclassing the various block classes and overriding these methods, all kinds of customizations are possible, from modifying the layout of StructBlock form fields to implementing completely new ways of combining blocks. For further details, see [](custom_streamfield_blocks).
 
 (modifying_streamfield_data)=
 
@@ -521,7 +521,7 @@ my_page.body.append(('paragraph', RichText("<p>And they all lived happily ever a
 my_page.save()
 ```
 
-If a block extending a StructBlock is to be used inside of the StreamField's value, the value of this block can be provided as a python dict (similar in what is accepted by the block's `.to_python` method).
+If a block extending a StructBlock is to be used inside of the StreamField's value, the value of this block can be provided as a Python dict (similar to what is accepted by the block's `.to_python` method).
 
 ```python
 

docs/topics/writing_templates.md

@@ -12,7 +12,7 @@ You should be familiar with Django templating basics before continuing with this
 
 ## Templates
 
-Every type of page or "content type" in Wagtail is defined as a "model" in a file called `models.py`. If your site has a blog, you might have a `BlogPage` model and another called `BlogPageListing`. The names of the models are up to the Django developer.
+Every type of page or "content-type" in Wagtail is defined as a "model" in a file called `models.py`. If your site has a blog, you might have a `BlogPage` model and another called `BlogPageListing`. The names of the models are up to the Django developer.
 
 For each page model in `models.py`, Wagtail assumes an HTML template file exists of (almost) the same name. The Front End developer may need to create these templates themselves by referring to `models.py` to infer template names from the models defined therein.
 
@@ -41,7 +41,7 @@ Additionally, `request.` is available and contains Django's request object.
 
 ## Static assets
 
-Static files (such as CSS, JS and images) are typically stored here:
+Static files (such as CSS, JS, and images) are typically stored here:
 
 ```
 name_of_project/
@@ -76,7 +76,7 @@ In addition to Django's standard tags and filters, Wagtail provides some of its
 
 ## Images (tag)
 
-The `image` tag inserts an XHTML-compatible `img` element into the page, setting its `src`, `width`, `height` and `alt`. See also [](image_tag_alt).
+The `image` tag inserts an XHTML-compatible `img` element into the page, setting its `src`, `width`, `height`, and `alt`. See also [](image_tag_alt).
 
 The syntax for the `image` tag is thus:
 
@@ -138,7 +138,7 @@ See [](responsive_images) for full documentation.
 
 ## Rich text (filter)
 
-This filter takes a chunk of HTML content and renders it as safe HTML in the page. Importantly, it also expands internal shorthand references to embedded images and links made in the Wagtail editor, into fully-baked HTML ready for display.
+This filter takes a chunk of HTML content and renders it as safe HTML on the page. Importantly, it also expands internal shorthand references to embedded images and links made in the Wagtail editor, into fully-baked HTML ready for display.
 
 Only fields using `RichTextField` need this applied in the template.
 
@@ -152,7 +152,7 @@ Only fields using `RichTextField` need this applied in the template.
 
 ### Responsive Embeds
 
-As Wagtail does not impose any styling of its own on templates, images and embedded media will be displayed at a fixed width as determined by the HTML. Images can be made to resize to fit their container using a CSS rule such as the following:
+As Wagtail does not impose any styling of its own on templates, images, and embedded media will be displayed at a fixed width as determined by the HTML. Images can be made to resize to fit their container using a CSS rule such as the following:
 
 ```css
 .body img {
@@ -229,7 +229,7 @@ Much like `pageurl`, a `fallback` keyword argument may be provided.
 
 Takes any `slug` as defined in a page's "Promote" tab and returns the URL for the matching Page. If multiple pages exist with the same slug, the page chosen is undetermined.
 
-Like `pageurl`, this will try to provide a relative link if possible, but will default to an absolute link if the Page is on a different Site. This is most useful when creating shared page furniture, for example, top-level navigation or site-wide links.
+Like `pageurl`, this will try to provide a relative link if possible but will default to an absolute link if the Page is on a different Site. This is most useful when creating shared page furniture, for example, top-level navigation or site-wide links.
 
 ```html+django
 {% load wagtailcore_tags %}
@@ -309,7 +309,7 @@ wagtail-userbar::part(userbar) {
 }
 ```
 
-To customise the items shown in the user bar, you can use the [`construct_wagtail_userbar`](construct_wagtail_userbar) hook.
+To customize the items shown in the user bar, you can use the [`construct_wagtail_userbar`](construct_wagtail_userbar) hook.
 
 ## Varying output between preview and live
 
@@ -337,7 +337,7 @@ Django supports [template fragment caching](https://docs.djangoproject.com/en/st
 
 ### Preview-aware caching
 
-The `{% wagtailcache %}` tag functions similarly to Django's `{% cache %}` tag, but will neither cache or serve cached content when previewing a page (or other model) in Wagtail.
+The `{% wagtailcache %}` tag functions similarly to Django's `{% cache %}` tag, but will neither cache nor serve cached content when previewing a page (or other model) in Wagtail.
 
 ```html+django
 {% load wagtail_cache %}
@@ -353,7 +353,7 @@ Much like `{% cache %}`, you can use [`make_template_fragment_key`](django.core.
 
 ### Page-aware caching
 
-`{% wagtailpagecache %}` is an extension of `{% wagtailcache %}`, but is also aware of the current `page` and `site`, and includes those as part of the cache key. This makes it possible to easily add caching around parts of the page without worrying about the page it's on. `{% wagtailpagecache %}` intentionally makes assumptions - for more customisation it's recommended to use `{% wagtailcache %}`.
+`{% wagtailpagecache %}` is an extension of `{% wagtailcache %}`, but is also aware of the current `page` and `site`, and includes those as part of the cache key. This makes it possible to easily add caching around parts of the page without worrying about the page it's on. `{% wagtailpagecache %}` intentionally makes assumptions - for more customization it's recommended to use `{% wagtailcache %}`.
 
 ```html+django
 {% load wagtail_cache %}