Fix spelling mistakes in documentation

docs/advanced_topics/api/v2/usage.rst

@@ -233,7 +233,7 @@ different order.
 .. note::
 
     It's not possible to use ``?offset`` while ordering randomly because
-    consistent random ordering cannot be guarenteed over multiple requests
+    consistent random ordering cannot be guaranteed over multiple requests
     (so requests for subsequent pages may return results that also appeared in
     previous pages).
 

docs/advanced_topics/embeds.rst

@@ -160,7 +160,7 @@ Multiple finders can be chained together. This can be used for customising the
 configuration for one provider without affecting the others.
 
 For example, this is how you can instruct Youtube to return videos in HTTPS
-(which must be done explictly for YouTube):
+(which must be done explicitly for YouTube):
 
 .. code-block:: python
 

docs/advanced_topics/images/feature_detection.rst

@@ -29,7 +29,7 @@ This will install PyOpenCV into your site packages. If you are using a virtual e
 Enabling site packages in the virtual environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If you are not using a virtual envionment, you can skip this step.
+If you are not using a virtual environment, you can skip this step.
 
 Enabling site packages is different depending on whether you are using pyvenv (Python 3.3+ only) or virtualenv to manage your virtual environment.
 

docs/editor_manual/documents_images_snippets/snippets.rst

@@ -1,14 +1,14 @@
 Snippets
 ~~~~~~~~
 
-Snippets allow you to create elements on a website once and reuse them in multiple places. Then, if you want to change something on the snippet, you only need to change it once, and it will change across all the occurances of the snippet.
+Snippets allow you to create elements on a website once and reuse them in multiple places. Then, if you want to change something on the snippet, you only need to change it once, and it will change across all the occurrences of the snippet.
 
 How snippets are used can vary widely between websites. Here are a few examples of things Torchbox have used snippets for on our clients' websites:
 
 * For staff contact details, so that they can be added to many pages but managed in one place
 * For Adverts, either to be applied sitewide or on individual pages
 * To manage links in a global area of the site, for example in the footer
-* For Calls to Action, such as Newsletter signup blocks, that may be consistent across many different pages
+* For Calls to Action, such as Newsletter sign up blocks, that may be consistent across many different pages
 
 The Snippets menu
 -----------------

docs/getting_started/index.rst

@@ -41,7 +41,7 @@ Inside your ``mysite`` folder, we now just run the setup steps necessary for any
 
 Your site is now accessible at ``http://localhost:8000``, with the admin backend available at ``http://localhost:8000/admin/``.
 
-This will set you up with a new standalone Wagtail project. If you'd like to add Wagtail to an existing Django project instead, see :doc:`integrating_into_django`.
+This will set you up with a new stand-alone Wagtail project. If you'd like to add Wagtail to an existing Django project instead, see :doc:`integrating_into_django`.
 
 There are a few optional packages which are not installed by default but are recommended to improve performance or add features to Wagtail, including:
 

docs/reference/contrib/modeladmin/primer.rst

@@ -89,7 +89,7 @@ configure your ``ModelAdmin`` class to use them instead of the defaults.
 Changing what appears in the listing
 ------------------------------------
 
-You should familarise yourself with the attributes and methods supported by
+You should familiarise yourself with the attributes and methods supported by
 the ``ModelAdmin`` class, that allow you to change what is displayed in the
 ``IndexView``. The following page should give you everything you need to get
 going: :doc:`indexview`
@@ -209,7 +209,7 @@ For example, if you'd like to create your own view class and use it for the
         index_view_class = MyModelIndexView
 
 
-Or, if you have no need for any of ``IndexView``'s exisiting functionality in
+Or, if you have no need for any of ``IndexView``'s existing functionality in
 your view, and would rather create your own view from scratch, ``modeladmin``
 will support that, too. However, it's highly recommended that you use
 ``modeladmin.views.WMABaseView`` as a base for your view. It'll make
@@ -250,14 +250,14 @@ by setting values on the following attributes:
 ``ModelAdmin.url_helper_class``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-By default, the ``modeladmin.helpers.url.PageAdminURLHelper`` class is used 
+By default, the ``modeladmin.helpers.url.PageAdminURLHelper`` class is used
 when your model extends ``wagtailcore.models.Page``, otherwise
 ``modeladmin.helpers.url.AdminURLHelper`` is used.
 
 If you find that the above helper classes don't cater for your needs, you can
 easily create your own helper class, by sub-classing ``AdminURLHelper`` or
 ``PageAdminURLHelper`` (if your  model extend's Wagtail's ``Page`` model), and
-making any neccessary additions/overrides.
+making any necessary additions/overrides.
 
 Once your class is defined, set the ``url_helper_class`` attribute on
 your ``ModelAdmin`` class to use your custom URLHelper, like so:
@@ -308,7 +308,7 @@ otherwise ``modeladmin.helpers.permission.PermissionHelper`` is used.
 If you find that the above helper classes don't cater for your needs, you can
 easily create your own helper class, by sub-classing
 ``PermissionHelper`` or (if your  model extend's Wagtail's ``Page`` model)
-``PagePermissionHelper``, and making any neccessary additions/overrides. Once
+``PagePermissionHelper``, and making any necessary additions/overrides. Once
 defined, you set the ``permission_helper_class`` attribute on your
 ``ModelAdmin`` class to use your custom class instead of the default, like so:
 
@@ -350,14 +350,14 @@ isn't possible or doesn't meet your needs, you can override the
 ``ModelAdmin.button_helper_class``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-By default, the ``modeladmin.helpers.button.PageButtonHelper`` class is used 
+By default, the ``modeladmin.helpers.button.PageButtonHelper`` class is used
 when your model extends ``wagtailcore.models.Page``, otherwise
 ``modeladmin.helpers.button.ButtonHelper`` is used.
 
 If you wish to add or change buttons for your model's IndexView, you'll need to
 create  your own button helper class, by sub-classing ``ButtonHelper`` or (if
 your  model extend's Wagtail's ``Page`` model) ``PageButtonHelper``, and
-make any neccessary additions/overrides. Once defined, you set the
+make any necessary additions/overrides. Once defined, you set the
 ``button_helper_class`` attribute on your ``ModelAdmin`` class to use your
 custom class instead of the default, like so:
 

docs/reference/contrib/settings.rst

@@ -145,7 +145,7 @@ Then access the settings through ``{{ settings }}``:
 
 .. note:: Replace ``app_label`` with the label of the app containing your settings model.
 
-If you are not in a ``RequestContext``, then context processors will not have run, and the ``settings`` variable will not be availble. To get the ``settings``, use the provided ``{% get_settings %}`` template tag. If a ``request`` is in the template context, but for some reason it is not a ``RequestContext``, just use ``{% get_settings %}``:
+If you are not in a ``RequestContext``, then context processors will not have run, and the ``settings`` variable will not be available. To get the ``settings``, use the provided ``{% get_settings %}`` template tag. If a ``request`` is in the template context, but for some reason it is not a ``RequestContext``, just use ``{% get_settings %}``:
 
 .. code-block:: html+django
 

docs/reference/contrib/table_block.rst

@@ -74,7 +74,7 @@ Every key in the ``table_options`` dictionary maps to a `handsontable <https://h
 * `contextMenu <https://docs.handsontable.com/0.24.3/Options.html#contextMenu>`_ - Enables or disables the handsontable right-click menu. By default this is set to ``True``.
 * `editor <https://docs.handsontable.com/0.24.3/Options.html#editor>`_ - Defines the editor used for table cells. The default setting is text.
 * `stretchH <https://docs.handsontable.com/0.24.3/Options.html#stretchH>`_ - Sets the default horizontal resizing of tables. Options include, 'none', 'last', and 'all'. By default TableBlock uses 'all' for the even resizing of columns.
-* `height <https://docs.handsontable.com/0.24.3/Options.html#height>`_ - The default height of the grid. By default TableBlock sets the height to ``108`` for the optimal appearance of new tables in the editor. This is optimized for tables with ``startRows`` set to ``3``. If you change the number of startRows in the configuration you might need to change the ``height`` setting to improve the default appearence in the editor.
+* `height <https://docs.handsontable.com/0.24.3/Options.html#height>`_ - The default height of the grid. By default TableBlock sets the height to ``108`` for the optimal appearance of new tables in the editor. This is optimized for tables with ``startRows`` set to ``3``. If you change the number of startRows in the configuration you might need to change the ``height`` setting to improve the default appearance in the editor.
 * `language <https://docs.handsontable.com/0.24.3/Options.html#language>`_ - The default language setting. By default TableBlock tries to get the language from ``django.utils.translation.get_language``. If needed, this setting can be overridden here.
 * `renderer <https://docs.handsontable.com/0.24.3/Options.html#renderer>`_ - The default setting handsontable uses to render the content of table cells.
 * `autoColumnSize <https://docs.handsontable.com/0.24.3/Options.html#autoColumnSize>`_ - Enables or disables the autoColumnSize plugin. The TableBlock default setting is ``False``.

docs/reference/hooks.rst

@@ -472,7 +472,7 @@ Hooks for customising the way users are directed through the process of creating
 ``after_delete_page``
 ~~~~~~~~~~~~~~~~~~~~~
 
-  Do something after a ``Page`` object is deleted. Uses the same behavior as ``after_create_page``.
+  Do something after a ``Page`` object is deleted. Uses the same behaviour as ``after_create_page``.
 
 
 .. _before_delete_page:
@@ -482,7 +482,7 @@ Hooks for customising the way users are directed through the process of creating
 
   Called at the beginning of the "delete page" view passing in the request and the page object.
 
-  Uses the same behavior as ``before_create_page``.
+  Uses the same behaviour as ``before_create_page``.
 
 
 .. _after_edit_page:
@@ -490,7 +490,7 @@ Hooks for customising the way users are directed through the process of creating
 ``after_edit_page``
 ~~~~~~~~~~~~~~~~~~~
 
-  Do something with a ``Page`` object after it has been updated. Uses the same behavior as ``after_create_page``.
+  Do something with a ``Page`` object after it has been updated. Uses the same behaviour as ``after_create_page``.
 
 
 .. _before_edit_page:
@@ -500,7 +500,7 @@ Hooks for customising the way users are directed through the process of creating
 
   Called at the beginning of the "edit page" view passing in the request and the page object.
 
-  Uses the same behavior as ``before_create_page``.
+  Uses the same behaviour as ``before_create_page``.
 
 
 .. _after_copy_page:
@@ -508,7 +508,7 @@ Hooks for customising the way users are directed through the process of creating
 ``after_copy_page``
 ~~~~~~~~~~~~~~~~~~~
 
-  Do something with a ``Page`` object after it has been copied pasing in the request, page object and the new copied page. Uses the same behavior as ``after_create_page``.
+  Do something with a ``Page`` object after it has been copied passing in the request, page object and the new copied page. Uses the same behaviour as ``after_create_page``.
 
 
 .. _before_copy_page:
@@ -518,7 +518,7 @@ Hooks for customising the way users are directed through the process of creating
 
   Called at the beginning of the "copy page" view passing in the request and the page object.
 
-  Uses the same behavior as ``before_create_page``.
+  Uses the same behaviour as ``before_create_page``.
 
 
 .. _construct_wagtail_userbar:
@@ -600,7 +600,7 @@ Hooks for customising the way admins are directed through the process of editing
 ``after_delete_user``
 ~~~~~~~~~~~~~~~~~~~~~
 
-  Do something after a ``User`` object is deleted. Uses the same behavior as ``after_create_user``.
+  Do something after a ``User`` object is deleted. Uses the same behaviour as ``after_create_user``.
 
 
 .. _before_delete_user:
@@ -610,7 +610,7 @@ Hooks for customising the way admins are directed through the process of editing
 
   Called at the beginning of the "delete user" view passing in the request and the user object.
 
-  Uses the same behavior as ``before_create_user``.
+  Uses the same behaviour as ``before_create_user``.
 
 
 .. _after_edit_user:
@@ -618,7 +618,7 @@ Hooks for customising the way admins are directed through the process of editing
 ``after_edit_user``
 ~~~~~~~~~~~~~~~~~~~
 
-  Do something with a ``User`` object after it has been updated. Uses the same behavior as ``after_create_user``.
+  Do something with a ``User`` object after it has been updated. Uses the same behaviour as ``after_create_user``.
 
 
 .. _before_edit_user:
@@ -628,7 +628,7 @@ Hooks for customising the way admins are directed through the process of editing
 
   Called at the beginning of the "edit user" view passing in the request and the user object.
 
-  Uses the same behavior as ``before_create_user``.
+  Uses the same behaviour as ``before_create_user``.
 
 Choosers
 --------

docs/reference/pages/model_recipes.rst

@@ -195,4 +195,4 @@ Here, ``blogs.filter(tags__name=tag)`` invokes a reverse Django queryset filter
 
 Iterating through ``page.tags.all`` will display each tag associated with ``page``, while the link(s) back to the index make use of the filter option added to the ``BlogIndexPage`` model. A Django query could also use the ``tagged_items`` related name field to get ``BlogPage`` objects associated with a tag.
 
-This is just one possible way of creating a taxonomy for Wagtail objects. With all of the components for a taxonomy available through Wagtail, you should be able to fulfill even the most exotic taxonomic schemes.
+This is just one possible way of creating a taxonomy for Wagtail objects. With all of the components for a taxonomy available through Wagtail, you should be able to fulfil even the most exotic taxonomic schemes.

docs/reference/pages/theory.rst

@@ -94,7 +94,7 @@ For going beyond the basics of model definition and interrelation, it might help
     #.  ``serve()`` finds a template to pass it to using ``get_template()``
     #.  A response object is returned by ``serve()`` and Django responds to the requester.
 
-You can apply custom behavior to this process by overriding ``Page`` class methods such as ``route()`` and ``serve()`` in your own models. For examples, see :ref:`model_recipes`.
+You can apply custom behaviour to this process by overriding ``Page`` class methods such as ``route()`` and ``serve()`` in your own models. For examples, see :ref:`model_recipes`.
 
 
 .. _scheduled_publishing:
@@ -114,6 +114,6 @@ The basic workflow is as follows:
 The *Revisions* view for a given page will show which revision is scheduled and when it is scheduled for. A scheduled revision in the list will also provide an *Unschedule* button to cancel it.
 
 
- 
+
 
 

docs/reference/project_template.rst

@@ -46,7 +46,7 @@ The "home" app
 
 Location: ``/mysite/home/``
 
-This app is here to help get you started quicker by providing a ``HomePage`` model with migrations to create one when you first setup your app.
+This app is here to help get you started quicker by providing a ``HomePage`` model with migrations to create one when you first set up your app.
 
 
 Default templates and static files

docs/releases/0.8.3.rst

@@ -15,7 +15,7 @@ Bug fixes
 ~~~~~~~~~
 
  * Added missing jQuery UI sprite files, causing collectstatic to throw errors (most reported on Heroku)
- * Page system check for on_delete actions of ForeignKeys was throwing false positives when page class decends from an abstract class (Alejandro Giacometti)
+ * Page system check for on_delete actions of ForeignKeys was throwing false positives when page class descends from an abstract class (Alejandro Giacometti)
  * Page system check for on_delete actions of ForeignKeys now only raises warnings, not errors
  * Fixed a regression where form builder submissions containing a number field would fail with a JSON serialisation error
  * Resizing an image with a focal point equal to the image size would result in a divide-by-zero error

docs/topics/images.rst

@@ -26,7 +26,7 @@ For example:
     <!-- Display it again, but this time as a square thumbnail: -->
     {% image page.photo fill-80x80 %}
 
-In the above syntax example ``[image]`` is the Django object refering to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``page.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page. Various resizing methods are supported, to cater to different use cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
+In the above syntax example ``[image]`` is the Django object referring to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``page.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page. Various resizing methods are supported, to cater to different use cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
 
 Note that a space separates ``[image]`` and ``[resize-rule]``, but the resize rule must not contain spaces. The width is always specified before the height. Resized images will maintain their original aspect ratio unless the ``fill`` rule is used, which may result in some pixels being cropped.
 

docs/topics/pages.rst

@@ -204,7 +204,7 @@ Page models also include several low-level methods for overriding or accessing p
 Customising URL patterns for a page model
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``Page.get_url_parts(request)`` method will not typically be called directly, but may be overriden 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.
+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.
 
 When overriding ``get_url_parts()``, you should accept ``*args, **kwargs``:
 

docs/topics/search/searching.rst

@@ -89,7 +89,7 @@ Specifying the fields to search
 
 By default, Wagtail will search all fields that have been indexed using ``index.SearchField``.
 
-This can be limited to a certian set of fields by using the ``fields`` keyword argument:
+This can be limited to a certain set of fields by using the ``fields`` keyword argument:
 
 .. code-block:: python
 
@@ -109,7 +109,7 @@ The search operator specifies how search should behave when the user has typed i
  - "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 relevent. The "and" operator only returns results that contain all search terms, but require 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 require 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).
 

docs/topics/streamfield.rst

@@ -165,7 +165,7 @@ DateBlock
 A date picker. The keyword arguments ``required`` (default: True), ``help_text`` and ``format`` are accepted.
 
 ``format`` (default: None)
-  Date format. This must be one of the recognised formats listed in the `DATE_INPUT_FORMATS <https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-DATE_INPUT_FORMATS>`_ setting. If not specifed Wagtail will use ``WAGTAIL_DATE_FORMAT`` setting with fallback to '%Y-%m-%d'.
+  Date format. This must be one of the recognised formats listed in the `DATE_INPUT_FORMATS <https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-DATE_INPUT_FORMATS>`_ setting. If not specified Wagtail will use ``WAGTAIL_DATE_FORMAT`` setting with fallback to '%Y-%m-%d'.
 
 TimeBlock
 ~~~~~~~~~
@@ -182,7 +182,7 @@ DateTimeBlock
 A combined date / time picker. The keyword arguments ``required`` (default: True), ``help_text`` and ``format`` are accepted.
 
 ``format`` (default: None)
-  Date format. This must be one of the recognised formats listed in the `DATETIME_INPUT_FORMATS <https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-DATETIME_INPUT_FORMATS>`_ setting. If not specifed Wagtail will use ``WAGTAIL_DATETIME_FORMAT`` setting with fallback to '%Y-%m-%d %H:%M'.
+  Date format. This must be one of the recognised formats listed in the `DATETIME_INPUT_FORMATS <https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-DATETIME_INPUT_FORMATS>`_ setting. If not specified Wagtail will use ``WAGTAIL_DATETIME_FORMAT`` setting with fallback to '%Y-%m-%d %H:%M'.
 
 RichTextBlock
 ~~~~~~~~~~~~~