Docs - Page names & reference section - Update British spelling to Am…

…erican

- Changed all British spellings to American spellings, in the Customizing admin templates section of the docs
- Transferred all British spellings in the usage guide and advanced topics section to American spellings
- Update a series of other pages to use the spelling cutomize in the file name
Implemented all feedbacks on the usage guide and advanced topics section

CHANGELOG.txt

@@ -14,6 +14,7 @@ Changelog
  * Fix: Correctly handle `date` objects on `human_readable_date` template tag (Jhonatan Lopes)
  * Docs: Add contributing development documentation on how to work with a fork of Wagtail (Nix Asteri, Dan Braghis)
  * Docs: Make sure the settings panel is listed in tabbed interface examples (Tibor Leupold)
+ * Docs: Update multiple pages in the reference sections and multiple page names to their US spelling instead of UK spelling (Victoria Poromon)
  * Maintenance: Move RichText HTML whitelist parser to use the faster, built in `html.parser` (Jake Howard)
  * Maintenance: Remove duplicate 'path' in default_exclude_fields_in_copy (Ramchandra Shahi Thakuri)
  * Maintenance: Update unit tests to always use the faster, built in `html.parser` & remove `html5lib` dependency (Jake Howard)

docs/advanced_topics/deploying.md

@@ -60,7 +60,7 @@ The django-storages Amazon S3 backends (`storages.backends.s3boto.S3BotoStorage`
 
 ### Cache
 
-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 is designed to take adavantage 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 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`).
 

docs/contributing/ui_guidelines.md

@@ -166,7 +166,7 @@ When adding or updating an icon,
 1. Run it through [SVGO](https://jakearchibald.github.io/svgomg/) with appropriate compression settings.
 2. Manually remove any unnecessary attributes. Set the `viewBox` attribute, and remove `width` and `height` attributes.
 3. Manually add its `id` attribute with a prefix of `icon-` and the icon name matching the file name. Keep the icon as named from its source if possible.
-4. Add or preserve licensing information as a HTML comment starting with an exclamation mark: `<!--! Icon license -->`. For Font Awesome, we want: `<!--! [icon name] ([icon style]): Font Awesome [version] -->`. For example, `<!--! triangle-exclamation (solid): Font Awesome Pro 6.4.0 -->`.
+4. Add or preserve licensing information as an HTML comment starting with an exclamation mark: `<!--! Icon license -->`. For Font Awesome, we want: `<!--! [icon name] ([icon style]): Font Awesome [version] -->`. For example, `<!--! triangle-exclamation (solid): Font Awesome Pro 6.4.0 -->`.
 5. Add the icon to Wagtail’s own implementation of the `register_icons` hook, in alphabetical order.
 6. Go to the styleguide and copy the Wagtail icons table according to instructions in the template, pasting the result in `wagtail_icons_table.txt`.
 7. If the icon requires [right-to-left mirroring](https://rtlstyling.com/posts/rtl-styling#bidirectional-icons), add the `class="icon--directional"` attribute.

docs/extending/adding_reports.md

@@ -19,7 +19,7 @@ class UnpublishedChangesReportView(PageReportView):
 
 ## Defining your report
 
-The most important attributes and methods to customise to define your report are:
+The most important attributes and methods to customize to define your report are:
 
 ```{eval-rst}
 .. method:: get_queryset(self)
@@ -88,7 +88,7 @@ and specific type of any pages. For our example, we might want to know when the
 (dictionary)
 
 A dictionary of any fields/attributes in ``list_export`` for which you wish to manually specify a heading for the spreadsheet
-column, and their headings. If unspecified, the heading will be taken from the field ``verbose_name`` if applicable, and the
+column and their headings. If unspecified, the heading will be taken from the field ``verbose_name`` if applicable, and the
 attribute string otherwise. For our example, ``last_published_at`` will automatically get a heading of ``"Last Published At"``,
 but a simple "Last Published" looks neater. We'll add that by setting ``export_headings``:
 

docs/extending/admin_views.md

@@ -102,7 +102,7 @@ Now create a `templates/wagtailcalendar/` folder within the `wagtailcalendar` ap
 {% endblock %}
 ```
 
-Here we are overriding three of the blocks defined in the base template: `titletag` (which sets the content of the HTML `<title>` tag), `extra_css` (which allows us to provide additional CSS styles specific to this page), and `content` (for the main content area of the page). We're also including the standard header bar component, and setting a title and icon. For a list of the recognised icon identifiers, see the [style guide](styleguide).
+Here we are overriding three of the blocks defined in the base template: `titletag` (which sets the content of the HTML `<title>` tag), `extra_css` (which allows us to provide additional CSS styles specific to this page), and `content` (for the main content area of the page). We're also including the standard header bar component, and setting a title and icon. For a list of the recognized icon identifiers, see the [style guide](styleguide).
 
 Revisiting `/admin/calendar/` will now show the calendar within the Wagtail admin page furniture.
 
@@ -192,7 +192,7 @@ The calendar will now be visible at the URL `/admin/calendar/month/`.
 
 ![A single calender month](../_static/images/adminviews_calendarmonth.png)
 
-Finally we can alter our `wagtail_hooks.py` to include a group of custom menu items. This is similar to adding a single item but involves importing two more classes, `Menu` and `SubmenuMenuItem`.
+Finally, we can alter our `wagtail_hooks.py` to include a group of custom menu items. This is similar to adding a single item but involves importing two more classes, `Menu` and `SubmenuMenuItem`.
 
 ```{code-block} python
 :emphasize-lines: 3,20-25
@@ -254,7 +254,7 @@ class CalendarViewSet(ViewSet):
             # This can be accessed at `/admin/calendar/`
             # and reverse-resolved with the name `calendar:index`.
             # This first URL will be used for the menu item, but it can be
-            # customised by overriding the `menu_url` property.
+            # customized by overriding the `menu_url` property.
             path('', index, name='index'),
 
             # This can be accessed at `/admin/calendar/month/`
@@ -275,7 +275,7 @@ def register_viewset():
 
 Compared to the previous example with the two separate hooks, this will result in a single menu item "Calendar" that takes you to the `/admin/calendar/` URL. The second URL will not have its own menu item, but it will still be accessible at `/admin/calendar/month/`. This is useful for grouping related views together, that may not necessarily need their own menu items.
 
-For further customisations, refer to the {class}`~wagtail.admin.viewsets.base.ViewSet` documentation.
+For further customizations, refer to the {class}`~wagtail.admin.viewsets.base.ViewSet` documentation.
 
 (using_base_viewsetgroup)=
 
@@ -307,4 +307,4 @@ def register_viewset():
 
 This will result in a top-level menu item "Agenda" with the two viewsets' menu items as sub-items, e.g. "Calendar" and "Events".
 
-For further customisations, refer to the {class}`~wagtail.admin.viewsets.base.ViewSetGroup` documentation.
+For further customizations, refer to the {class}`~wagtail.admin.viewsets.base.ViewSetGroup` documentation.

docs/extending/audit_log.md

@@ -7,7 +7,7 @@ Wagtail provides a mechanism to log actions performed on its objects. Common act
 The Wagtail admin uses the action log entries to provide a site-wide and page-specific history of changes. It uses a
 registry of 'actions' that provide additional context for the logged action.
 
-The audit log-driven Page history replaces the revisions list page, but provides a filter for revision-specific entries.
+The audit log-driven Page history replaces the revisions list page but provides a filter for revision-specific entries.
 
 ```{note}
 The audit log does not replace revisions.
@@ -21,7 +21,7 @@ The `wagtail.log_actions.log` function can be used to add logging to your own co
    Adds an entry to the audit log.
 
    :param instance: The model instance that the action is performed on
-   :param action: The code name for the action being performed. This can be one of the names listed below, or a custom action defined through the :ref:`register_log_actions` hook.
+   :param action: The code name for the action being performed. This can be one of the names listed below or a custom action defined through the :ref:`register_log_actions` hook.
    :param user: Optional - the user initiating the action. For actions logged within an admin view, this defaults to the logged-in user.
    :param uuid: Optional - log entries given the same UUID indicates that they occurred as part of the same user action (for example a page being immediately published on creation).
    :param title: The string representation, of the instance being logged. By default, Wagtail will attempt to use the instance's ``str`` representation or ``get_admin_display_title`` for page objects.
@@ -62,7 +62,7 @@ When adding logging, you need to log the action or actions that happen to the ob
 | `wagtail.publish`                 | The page was published                                                           |
 | `wagtail.publish.schedule`        | The draft is scheduled for publishing                                            |
 | `wagtail.publish.scheduled`       | Draft published via `publish_scheduled` management command                       |
-| `wagtail.schedule.cancel`         | Draft scheduled for publishing cancelled via "Cancel scheduled publish"          |
+| `wagtail.schedule.cancel`         | Draft scheduled for publishing canceled via "Cancel scheduled publish"           |
 | `wagtail.unpublish`               | The page was unpublished                                                         |
 | `wagtail.unpublish.scheduled`     | Page unpublished via `publish_scheduled` management command                      |
 | `wagtail.lock`                    | Page was locked                                                                  |
@@ -80,7 +80,7 @@ When adding logging, you need to log the action or actions that happen to the ob
 | `wagtail.workflow.approve`        | The draft was approved at a Workflow Task                                        |
 | `wagtail.workflow.reject`         | The draft was rejected, and changes were requested at a Workflow Task            |
 | `wagtail.workflow.resume`         | The draft was resubmitted to the workflow                                        |
-| `wagtail.workflow.cancel`         | The workflow was cancelled                                                       |
+| `wagtail.workflow.cancel`         | The workflow was canceled                                                        |
 
 ## Log context
 

docs/extending/custom_account_settings.md

@@ -1,13 +1,13 @@
 (custom_account_settings)=
 
-# Customising the user account settings form
+# Customizing the user account settings form
 
-This document describes how to customise the user account settings form that can be found by clicking "Account settings"
+This document describes how to customize the user account settings form which can be found by clicking "Account settings"
 at the bottom of the main menu.
 
 ## Adding new panels
 
-Each panel on this form is a separate model form which can operate on an instance of either the user model, or the {class}`wagtail.users.models.UserProfile`.
+Each panel on this form is a separate model form that can operate on an instance of either the user model, or the {class}`wagtail.users.models.UserProfile`.
 
 ### Basic example
 
@@ -113,7 +113,7 @@ class CustomSettingsPanel(BaseSettingsPanel):
 -   `title` - The display name of the title
 -   `order` - The order of the tab. The builtin Wagtail tabs start at `100` and increase by `100` for each tab
 
-## Customising the template
+## Customizing the template
 
 You can provide a custom template for the panel by specifying a template name:
 

docs/extending/custom_bulk_actions.md

@@ -136,7 +136,7 @@ def check_perm(self, obj):
     return obj.has_perm('some_perm')  # returns True or False
 ```
 
-The success message shown on the admin can be customised by overriding the `get_success_message` method.
+The success message shown on the admin can be customized by overriding the `get_success_message` method.
 
 ```python
 def get_success_message(self, num_parent_objects, num_child_objects):

docs/extending/custom_tasks.md

@@ -122,7 +122,7 @@ class UserApprovalTask(Task):
 
 ## Customising behaviour
 
-Both `Task` and `TaskState` have a number of methods that can be overridden to implement custom behaviour. Here are some of the most useful:
+Both `Task` and `TaskState` have a number of methods that can be overridden to implement custom behavior. Here are some of the most useful:
 
 `Task.user_can_access_editor(obj, user)`, `Task.user_can_lock(obj, user)`, `Task.user_can_unlock(obj, user)`:
 
@@ -174,7 +174,7 @@ Returns the name of a custom template to be used in rendering the data entry mod
 
 This performs the actions specified in `Task.get_actions(obj, user)`: it is passed an action name, for example, `approve`, and the relevant task state. By default, it calls `approve` and `reject` methods on the task state when the corresponding action names are passed through. Any additional data entered in a modal (see `get_form_for_action` and `get_actions`) is supplied as kwargs.
 
-For example, let's say we wanted to add an additional option: cancelling the entire workflow:
+For example, let's say we wanted to add an additional option: canceling the entire workflow:
 
 ```python
 def on_action(self, task_state, user, action_name):
@@ -186,7 +186,7 @@ def on_action(self, task_state, user, action_name):
 
 `Task.get_task_states_user_can_moderate(user, **kwargs)`:
 
-This returns a QuerySet of `TaskStates` (or subclasses) the given user can moderate - this is currently used to select objects to display on the user's dashboard.
+This returns a QuerySet of `TaskStates` (or subclasses) that the given user can moderate - this is currently used to select objects to display on the user's dashboard.
 
 For example:
 
@@ -215,7 +215,7 @@ def get_description(cls):
 
 Wagtail's notifications are sent by `wagtail.admin.mail.Notifier` subclasses: callables intended to be connected to a signal.
 
-By default, email notifications are sent upon workflow submission, approval and rejection, and upon submission to a group approval task.
+By default, email notifications are sent upon workflow submission, approval, and rejection, and upon submission to a group approval task.
 
 As an example, we'll add email notifications for when our new task is started.
 
@@ -237,7 +237,7 @@ class BaseUserApprovalTaskStateEmailNotifier(EmailNotificationMixin, Notifier):
 
     def can_handle(self, instance, **kwargs):
         if super().can_handle(instance, **kwargs) and isinstance(instance.task.specific, UserApprovalTask):
-            # Don't send notifications if a Task has been cancelled and then resumed - when object was updated to a new revision
+            # Don't send notifications if a Task has been canceled and then resumed - when object was updated to a new revision
             return not TaskState.objects.filter(workflow_state=instance.workflow_state, task=instance.task, status=TaskState.STATUS_CANCELLED).exists()
         return False
 

docs/extending/customising_group_views.md → docs/extending/customizing_group_views.md

@@ -1,12 +1,12 @@
-(customising_group_views)=
+(customizing_group_views)=
 
-# Customising group edit/create views
+# Customizing group edit/create views
 
-The views for managing groups within the app are collected into a 'viewset' class, which acts as a single point of reference for all shared components of those views, such as forms. By subclassing the viewset, it is possible to override those components and customise the behaviour of the group management interface.
+The views for managing groups within the app are collected into a 'viewset' class, which acts as a single point of reference for all shared components of those views, such as forms. By subclassing the viewset, it is possible to override those components and customize the behavior of the group management interface.
 
 ## Custom edit/create forms
 
-This example shows how to customise forms on the 'edit group' and 'create group' views in the Wagtail admin.
+This example shows how to customize forms on the 'edit group' and 'create group' views in the Wagtail admin.
 
 Let's say you need to connect Active Directory groups with Django groups.
 We create a model for Active Directory groups as follows:
@@ -107,11 +107,11 @@ INSTALLED_APPS = [
 ]
 ```
 
-(customising_group_views_permissions_order)=
+(customizing_group_views_permissions_order)=
 
-## Customising the group editor permissions ordering
+## Customizing the group editor permissions ordering
 
-The order that object types appear in the group editor's "Object permissions" and "Other permissions" sections can be configured by registering that order in one or more `AppConfig` definitions. The order value is typically an integer between 0 and 999, although this is not enforced.
+The order in which object types appear in the group editor's "Object permissions" and "Other permissions" sections can be configured by registering that order in one or more `AppConfig` definitions. The order value is typically an integer between 0 and 999, although this is not enforced.
 
 ```python
 from django.apps import AppConfig