Update spelling of Customizing Admin Templates and Page Models sectio…

…ns in the docs (wagtail#11544)

* Change all British spelling to American, in the page model section of the docs

* Change all British spelling to American spelling in the Customizing admin templates section of the docs

---------

Co-authored-by: Storm B. Heg <storm@stormbase.digital>

CHANGELOG.txt

@@ -105,6 +105,7 @@ Changelog
  * Docs: Add documentation writing guidelines for intersphinx / external links (LB (Ben) Johnston)
  * Docs: Add `Page` model reference `get_children` documentation (Salvo Polizzi)
  * Docs: Enforce CI build checks for documentation so that malformed links or missing images will not be allowed (Neeraj Yetheendran)
+ * Docs: Update spelling on customizing admin template and page model section from British to American English (Victoria Poromon)
  * Maintenance: Update BeautifulSoup upper bound to 4.12.x (scott-8)
  * Maintenance: Migrate initialization of classes (such as `body.ready`) from multiple JavaScript implementations to one Stimulus controller `w-init` (Chiemezuo Akujobi)
  * Maintenance: Adopt the usage of translate string literals using `arg=_('...')` in all `wagtailadmin` module templates (Chiemezuo Akujobi)

docs/advanced_topics/customisation/admin_templates.md

@@ -1,8 +1,8 @@
-# Customising admin templates
+# Customizing admin templates
 
 In your projects with Wagtail, you may wish to replace elements such as the Wagtail logo within the admin interface with your own branding. This can be done through Django's template inheritance mechanism.
 
-You need to create a `templates/wagtailadmin/` folder within one of your apps - this may be an existing one, or a new one created for this purpose, for example, `dashboard`. This app must be registered in `INSTALLED_APPS` before `wagtail.admin`:
+You need to create a `templates/wagtailadmin/` folder within one of your apps - this may be an existing one or a new one created for this purpose, for example, `dashboard`. This app must be registered in `INSTALLED_APPS` before `wagtail.admin`:
 
 ```python
 INSTALLED_APPS = (
@@ -21,7 +21,7 @@ INSTALLED_APPS = (
 
 ## Custom branding
 
-The template blocks that are available to customise the branding in the admin interface are as follows:
+The template blocks that are available to customize the branding in the admin interface are as follows:
 
 ### `branding_logo`
 
@@ -36,7 +36,7 @@ To replace the default logo, create a template file `dashboard/templates/wagtail
 {% endblock %}
 ```
 
-The logo also appears in the following pages and can be replaced with its template file:
+The logo also appears on the following pages and can be replaced with its template file:
 
 -   **login page** - create a template file `dashboard/templates/wagtailadmin/login.html` that overwrites the `branding_logo` block.
 -   **404 error page** - create a template file `dashboard/templates/wagtailadmin/404.html` that overrides the `branding_logo` block.
@@ -89,7 +89,7 @@ To replace the welcome message on the dashboard, create a template file `dashboa
 
 ## Custom user interface fonts
 
-To customise the font families used in the admin user interface, inject a CSS file using the hook [](insert_global_admin_css) and override the variables within the `:root` selector:
+To customize the font families used in the admin user interface, inject a CSS file using the hook [](insert_global_admin_css) and override the variables within the `:root` selector:
 
 ```css
 :root {
@@ -100,37 +100,37 @@ To customise the font families used in the admin user interface, inject a CSS fi
 
 (custom_user_interface_colours)=
 
-## Custom user interface colours
+## Custom user interface colors
 
 ```{warning}
-The default Wagtail colours conform to the WCAG2.1 AA level colour contrast requirements. When customising the admin colours you should test the contrast using tools like [Axe](https://www.deque.com/axe/browser-extensions/).
+The default Wagtail colors conform to the WCAG2.1 AA level color contrast requirements. When customizing the admin colors you should test the contrast using tools like [Axe](https://www.deque.com/axe/browser-extensions/).
 ```
 
-To customise the colours used in the admin user interface, inject a CSS file using the hook [](insert_global_admin_css) and set the desired variables within the `:root` selector. Colour variables are reused across both the light and dark themes of the admin interface. To change the colours of a specific theme, use:
+To customize the colors used in the admin user interface, inject a CSS file using the hook [](insert_global_admin_css) and set the desired variables within the `:root` selector. Color variables are reused across both the light and dark themes of the admin interface. To change the colors of a specific theme, use:
 
 -   `:root, .w-theme-light` for the light theme.
 -   `.w-theme-dark` for the dark theme.
 -   `@media (prefers-color-scheme: light) { .w-theme-system { […] }}` for the light theme via system settings.
 -   `@media (prefers-color-scheme: dark) { .w-theme-system { […] }}` for the dark theme via system settings.
 
-There are two ways to customise Wagtail’s colour scheme:
+There are two ways to customize Wagtail’s color scheme:
 
--   Set static colour variables, which are then reused in both light and dark themes across a wide number of UI components.
--   Set semantic colours, which are more numerous but allow customising specific UI components.
+-   Set static color variables, which are then reused in both light and dark themes across a wide number of UI components.
+-   Set semantic colors, which are more numerous but allow customizing specific UI components.
 
-For static colours, either set each colour separately (for example `--w-color-primary: #2E1F5E;`); or separately set [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) (`--w-color-primary-hue`, `--w-color-primary-saturation`, `--w-color-primary-lightness`) variables so all shades are customised at once. For example, setting `--w-color-secondary-hue: 180;` will customise all of the secondary shades at once.
+For static colors, either set each color separately (for example `--w-color-primary: #2E1F5E;`); or separately set [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) (`--w-color-primary-hue`, `--w-color-primary-saturation`, `--w-color-primary-lightness`) variables so all shades are customized at once. For example, setting `--w-color-secondary-hue: 180;` will customize all of the secondary shades at once.
 
 ```{include} ../../_static/wagtail_colors_tables.txt
 
 ```
 
 ## 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 customise the branding in the admin page. These can be useful for customising the dashboard on a multitenanted Wagtail installation:
+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:
 
 ### `root_page`
 
-Returns the highest explorable page object for the currently logged in user. If the user has no explore rights, this will default to `None`.
+Returns the highest explorable page object for the currently logged-in user. If the user has no explore rights, this will default to `None`.
 
 ### `root_site`
 
@@ -182,7 +182,7 @@ To add extra fields to the login form, override the `fields` block. You will nee
 
 ### `submit_buttons`
 
-To add extra buttons to the login form, override the `submit_buttons` block. You will need to add `{{ block.super }}` somewhere in your block to include the sign in button:
+To add extra buttons to the login form, override the `submit_buttons` block. You will need to add `{{ block.super }}` somewhere in your block to include the sign-in button:
 
 ```html+django
 {% extends "wagtailadmin/login.html" %}
@@ -195,7 +195,7 @@ To add extra buttons to the login form, override the `submit_buttons` block. You
 
 ### `login_form`
 
-To completely customise the login form, override the `login_form` block. This block wraps the whole contents of the `<form>` element:
+To completely customize the login form, override the `login_form` block. This block wraps the whole contents of the `<form>` element:
 
 ```html+django
 {% extends "wagtailadmin/login.html" %}
@@ -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/releases/6.0.md

@@ -145,6 +145,7 @@ This feature was implemented by Nick Lee, Thibaud Colas, and Sage Abdullah.
  * Add documentation writing guidelines for intersphinx / external links (LB (Ben) Johnston)
  * Add `Page` model reference `get_children` documentation (Salvo Polizzi)
  * Enforce CI build checks for documentation so that malformed links or missing images will not be allowed (Neeraj Yetheendran)
+ * Update spelling on customizing admin template and page model section from British to American English (Victoria Poromon)
 
 ### Maintenance
 

docs/topics/pages.md

@@ -140,9 +140,9 @@ These are used for structuring fields in the interface.
 -   {class}`~wagtail.admin.panels.InlinePanel`
 -   {class}`~wagtail.admin.panels.FieldRowPanel`
 
-#### Customising the page editor interface
+#### Customizing the page editor interface
 
-The page editor can be customised further. See [Customising the editing interface](/advanced_topics/customisation/page_editing_interface).
+The page editor can be customized further. See [Customizing the editing interface](/advanced_topics/customisation/page_editing_interface).
 
 (page_type_business_rules)=
 
@@ -155,7 +155,7 @@ Both parent and subpage types take a list of model classes or model names. Model
 -   `parent_page_types` limits which page types this type can be created under
 -   `subpage_types` limits which page types can be created under this type
 
-By default, any page type can be created under any page type and it is not necessary to set these attributes if that's the desired behaviour.
+By default, any page type can be created under any page type and it is not necessary to set these attributes if that's the desired behavior.
 
 Setting `parent_page_types` to an empty list is a good way of preventing a particular page type from being created in the editor interface.
 
@@ -179,7 +179,7 @@ The most common method of retrieving page URLs is by using the [`{% pageurl %}`]
 
 Page models also include several low-level methods for overriding or accessing page URLs.
 
-#### Customising URL patterns for a page model
+#### Customizing URL patterns for a page model
 
 The `Page.get_url_parts(request)` method will not typically be called directly, but may be overridden to define custom URL routing for a given page model. It should return a tuple of `(site_id, root_url, page_path)`, which are used by `get_url` and `get_full_url` (see below) to construct the given type of page URL.
 
@@ -231,7 +231,7 @@ You just need to create a template in a location where it can be accessed with t
 
 Wagtail renders templates with the `page` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, use `{{ page.title }}`. All variables provided by [context processors](inv:django#subclassing-context-requestcontext) are also available.
 
-#### Customising template context
+#### Customizing template context
 
 All pages have a `get_context` method that is called whenever the template is rendered and returns a dictionary of variables to bind into the template.