Merge pull request #1210 from kaedroho/spellcheck

Add spellchecker to the docs

docs/Makefile

@@ -54,6 +54,11 @@ html:
 	@echo
 	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
 
+spelling:
+	$(SPHINXBUILD) -b spelling $(ALLSPHINXOPTS) $(BUILDDIR)/spelling
+	@echo
+	@echo "Spellcheck complete."
+
 dirhtml:
 	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
 	@echo

docs/conf.py

@@ -50,6 +50,7 @@ os.environ['DATABASE_ENGINE'] = 'django.db.backends.sqlite3'
 # ones.
 extensions = [
     'sphinx.ext.autodoc',
+    'sphinxcontrib.spelling',
 ]
 
 # Add any paths that contain templates here, relative to this directory.
@@ -116,6 +117,12 @@ pygments_style = 'sphinx'
 #keep_warnings = False
 
 
+# splhinxcontrib.spelling settings
+
+spelling_lang = 'en_GB'
+spelling_word_list_filename='spelling_wordlist.txt'
+
+
 # -- Options for HTML output ----------------------------------------------
 
 

docs/contrib/api/configuration.rst

@@ -26,7 +26,7 @@ Adding more fields to the pages endpoint
 
 By default, the pages endpoint only includes the ``id``, ``title`` and ``type`` fields in both the listing and detail views.
 
-You can add more fields to the pages endpoint by setting an attribute called ``api_fields`` to a list/tuple of field names:
+You can add more fields to the pages endpoint by setting an attribute called ``api_fields`` to a ``list`` or ``tuple`` of field names:
 
 .. code-block:: python
 
@@ -63,6 +63,6 @@ If you have a Varnish, Squid or Cloudflare instance in front of your API, the ``
 
 To enable it, firstly configure the ``wagtail.contrib.wagtailfrontendcache`` module within your project (see [Wagtail frontend cache docs](http://docs.wagtail.io/en/latest/contrib_components/frontendcache.html) for more information).
 
-Then make sure that the ``WAGTAILAPI_BASE_URL`` setting is set correctly (eg. ``WAGTAILAPI_BASE_URL = 'http://api.mysite.com'``).
+Then make sure that the ``WAGTAILAPI_BASE_URL`` setting is set correctly (Example: ``WAGTAILAPI_BASE_URL = 'http://api.mysite.com'``).
 
 Then finally, switch it on by setting ``WAGTAILAPI_USE_FRONTENDCACHE`` to ``True``.

docs/contrib/api/index.rst

@@ -1,7 +1,7 @@
 Wagtail API
 ===========
 
-The wagtailapi module can be used to create a read-only, JSON-based API for public Wagtail content.
+The ``wagtailapi`` module can be used to create a read-only, JSON-based API for public Wagtail content.
 
 There are three endpoints to the API:
 

docs/contrib/sitemaps.rst

@@ -20,7 +20,7 @@ You firstly need to add ``"wagtail.contrib.wagtailsitemaps"`` to INSTALLED_APPS
     ]
 
 
-Then, in urls.py, you need to add a link to the ``wagtail.contrib.wagtailsitemaps.views.sitemap`` view which generates the sitemap:
+Then, in ``urls.py``, you need to add a link to the ``wagtail.contrib.wagtailsitemaps.views.sitemap`` view which generates the sitemap:
 
 .. code-block:: python
 
@@ -33,7 +33,7 @@ Then, in urls.py, you need to add a link to the ``wagtail.contrib.wagtailsitemap
     ]
 
 
-You should now be able to browse to "/sitemap.xml" and see the sitemap working. By default, all published pages in your website will be added to the site map.
+You should now be able to browse to ``/sitemap.xml`` and see the sitemap working. By default, all published pages in your website will be added to the site map.
 
 
 Customising
@@ -42,7 +42,7 @@ Customising
 URLs
 ----
 
-The Page class defines a ``get_sitemap_urls`` method which you can override to customise sitemaps per page instance. This method must return a list of dictionaries, one dictionary per URL entry in the sitemap. You can exclude pages from the sitemap by returning an empty list.
+The ``Page`` class defines a ``get_sitemap_urls`` method which you can override to customise sitemaps per ``Page`` instance. This method must return a list of dictionaries, one dictionary per URL entry in the sitemap. You can exclude pages from the sitemap by returning an empty list.
 
 Each dictionary can contain the following:
 

docs/contrib/staticsitegen.rst

@@ -1,7 +1,7 @@
 Generating a static site
 ========================
 
-This document describes how to render your Wagtail site into static HTML files on your local filesystem, Amazon S3 or Google App Engine, using `django medusa`_ and the ``wagtail.contrib.wagtailmedusa`` module.
+This document describes how to render your Wagtail site into static HTML files on your local file system, Amazon S3 or Google App Engine, using `django medusa`_ and the ``wagtail.contrib.wagtailmedusa`` module.
 
 .. note::
 
@@ -38,9 +38,9 @@ Define ``MEDUSA_RENDERER_CLASS`` and ``MEDUSA_DEPLOY_DIR`` in settings:
 Rendering
 ~~~~~~~~~
 
-To render a site, run ``./manage.py staticsitegen``. This will render the entire website and place the HTML in a folder called 'medusa_output'. The static and media folders need to be copied into this folder manually after the rendering is complete. This feature inherits ``django-medusa``'s ability to render your static site to Amazon S3 or Google App Engine; see the `medusa docs <https://github.com/mtigas/django-medusa/blob/master/README.markdown>`_ for configuration details.
+To render a site, run ``./manage.py staticsitegen``. This will render the entire website and place the HTML in a folder called ``medusa_output``. The static and media folders need to be copied into this folder manually after the rendering is complete. This feature inherits ``django-medusa``'s ability to render your static site to Amazon S3 or Google App Engine; see the `medusa docs <https://github.com/mtigas/django-medusa/blob/master/README.markdown>`_ for configuration details.
 
-To test, open the 'medusa_output' folder in a terminal and run ``python -m SimpleHTTPServer``.
+To test, open the ``medusa_output`` folder in a terminal and run ``python -m SimpleHTTPServer``.
 
 
 Advanced topics
@@ -51,7 +51,7 @@ GET parameters
 
 Pages which require GET parameters (e.g. for pagination) don't generate suitable filenames for generated HTML files.
 
-Wagtail provides a mixin (``wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin``) which allows you to embed a Django url configuration into a page. This allows you to give the subpages a URL like ``/page/1/`` which work well with static site generation.
+Wagtail provides a mixin (``wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin``) which allows you to embed a Django URL configuration into a page. This allows you to give the subpages a URL like ``/page/1/`` which work well with static site generation.
 
 
 Example:
@@ -94,7 +94,7 @@ Next, you have to tell the ``wagtailmedusa`` module about your custom routing...
 Rendering pages which use custom routing
 ----------------------------------------
 
-For page types that override the ``route`` method, we need to let django medusa know which URLs it responds on. This is done by overriding the ``get_static_site_paths`` method to make it yield one string per URL path.
+For page types that override the ``route`` method, we need to let ``django-medusa`` know which URLs it responds on. This is done by overriding the ``get_static_site_paths`` method to make it yield one string per URL path.
 
 For example, the BlogIndex above would need to yield one URL for each page of results:
 

docs/editor_manual/getting_started.rst

@@ -12,7 +12,7 @@ Logging in
 __________
 
 * The first port of call for an editor is the login page for the administrator interface.
-* Access this by adding **/admin** onto the end of your root URL (e.g. www.example.com/admin).
+* Access this by adding **/admin** onto the end of your root URL (e.g. ``www.example.com/admin``).
 * Enter your username and password and click **Sign in**.
 
-.. image:: ../_static/images/screen01_login.png
+.. image:: ../_static/images/screen01_login.png

docs/form_builder.rst

@@ -19,7 +19,7 @@ Add 'wagtail.wagtailforms' to your INSTALLED_APPS:
        'wagtail.wagtailforms',
     ]
 
-Within the models.py of one of your apps, create a model that extends wagtailforms.models.AbstractEmailForm:
+Within the ``models.py`` of one of your apps, create a model that extends ``wagtailforms.models.AbstractEmailForm``:
 
 
 .. code:: python

docs/getting_started/installation.rst

@@ -78,11 +78,11 @@ For the best possible performance and feature set, we recommend setting up the f
 
 PostgreSQL
 ----------
-PostgreSQL is a mature database engine suitable for production use, and is recommended by the Django development team. Non-Vagrant users will need to install the PostgreSQL development headers in addition to Postgres itself; on Debian or Ubuntu, this can be done with the following command::
+PostgreSQL is a mature database engine suitable for production use, and is recommended by the Django development team. Non-Vagrant users will need to install the PostgreSQL development headers in addition to PostgreSQL itself; on Debian or Ubuntu, this can be done with the following command::
 
     sudo apt-get install postgresql postgresql-server-dev-all
 
-To enable Postgres for your project, uncomment the ``psycopg2`` line from your project's requirements.txt, and in ``myprojectname/settings/base.py``, uncomment the DATABASES section for PostgreSQL, commenting out the SQLite one instead. Then run::
+To enable PostgreSQL for your project, uncomment the ``psycopg2`` line from your project's requirements.txt, and in ``myprojectname/settings/base.py``, uncomment the DATABASES section for PostgreSQL, commenting out the SQLite one instead. Then run::
 
     pip install -r requirements.txt
     createdb -Upostgres myprojectname

docs/getting_started/trying_wagtail.rst

@@ -41,7 +41,7 @@ types, in one step. As the root user::
   curl -O https://raw.githubusercontent.com/torchbox/wagtail/master/scripts/install/ubuntu.sh; bash ubuntu.sh
 
 This script installs all the dependencies for a production-ready Wagtail site,
-including PostgreSQL, Redis, Elasticsearch, Nginx and uwsgi. We
+including PostgreSQL, Redis, Elasticsearch, Nginx and uWSGI. We
 recommend you check through the script before running it, and adapt it according
 to your deployment preferences. The canonical version is at
 `github.com/torchbox/wagtail/blob/master/scripts/install/ubuntu.sh
@@ -58,7 +58,7 @@ step. As the root user::
   curl -O https://raw.githubusercontent.com/torchbox/wagtail/master/scripts/install/debian.sh; bash debian.sh
 
 This script installs all the dependencies for a production-ready Wagtail site,
-including PostgreSQL, Redis, Elasticsearch, Nginx and uwsgi. We
+including PostgreSQL, Redis, Elasticsearch, Nginx and uWSGI. We
 recommend you check through the script before running it, and adapt it according
 to your deployment preferences. The canonical version is at
 `github.com/torchbox/wagtail/blob/master/scripts/install/debian.sh

docs/howto/settings.rst

@@ -1,4 +1,3 @@
-
 ==============================
 Configuring Django for Wagtail
 ==============================
@@ -24,8 +23,8 @@ From your app directory, you can safely remove ``admin.py`` and ``views.py``, si
 What follows is a settings reference which skips many boilerplate Django settings. If you just want to get your Wagtail install up quickly without fussing with settings at the moment, see :ref:`complete_example_config`.
 
 
-Middleware (settings.py)
-~~~~~~~~~~~~~~~~~~~~~~~~
+Middleware (``settings.py``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: python
 
@@ -137,8 +136,8 @@ Wagtail Apps
   Models for creating forms on your pages and viewing submissions. See :ref:`form_builder`.
 
 
-Settings Variables (settings.py)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Settings Variables (``settings.py``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Site Name
 ---------
@@ -167,13 +166,13 @@ Search
     }
   }
 
-The search settings customize the search results templates as well as choosing a custom backend for search. For a full explanation, see :ref:`search`.
+The search settings customise the search results templates as well as choosing a custom backend for search. For a full explanation, see :ref:`search`.
 
 
 Embeds
 ------
 
-Wagtail uses the oEmbed standard with a large but not comprehensive number of "providers" (youtube, vimeo, etc.). You can also use a different embed backend by providing an Embedly key or replacing the embed backend by writing your own embed finder function. 
+Wagtail uses the oEmbed standard with a large but not comprehensive number of "providers" (Youtube, Vimeo, etc.). You can also use a different embed backend by providing an Embedly key or replacing the embed backend by writing your own embed finder function. 
 
 .. code-block:: python
 
@@ -289,14 +288,14 @@ That's not everything you might want to include in your project's urlconf, but i
 
 .. _complete_example_config:
 
-Ready to Use Example Config Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ready to Use Example Configuration Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 These two files should reside in your project directory (``myproject/myproject/``).
 
 
-settings.py
------------
+``settings.py``
+---------------
 
 .. code-block:: python
 
@@ -511,8 +510,8 @@ settings.py
   # EMBEDLY_KEY = '253e433d59dc4d2xa266e9e0de0cb830'
 
 
-urls.py
--------
+``urls.py``
+-----------
 
 .. code-block:: python
 

docs/pages/advanced_topics/queryset_methods.rst

@@ -1,8 +1,8 @@
 =====================
-Page Queryset Methods
+Page QuerySet Methods
 =====================
 
-All models that inherit from ``Page`` are given some extra Queryset methods accessible from their ``.objects`` attribute.
+All models that inherit from ``Page`` are given some extra QuerySet methods accessible from their ``.objects`` attribute.
 
 
 Examples
@@ -24,7 +24,7 @@ Examples
 
     .. code-block:: python
 
-        # This gets a queryset of live children of the homepage with ``show_in_menus`` set
+        # This gets a QuerySet of live children of the homepage with ``show_in_menus`` set
         menu_items = homepage.get_children().live().in_menu()
 
 
@@ -75,7 +75,7 @@ Reference
 
         .. code-block:: python
 
-            # Append an extra page to a queryset
+            # Append an extra page to a QuerySet
             new_queryset = old_queryset | Page.objects.page(page_to_add)
 
     .. automethod:: not_page
@@ -84,7 +84,7 @@ Reference
 
         .. code-block:: python
 
-            # Remove a page from a queryset
+            # Remove a page from a QuerySet
             new_queryset = old_queryset & Page.objects.not_page(page_to_remove)
 
     .. automethod:: descendant_of

docs/pages/editing_api.rst

@@ -9,7 +9,7 @@ Wagtail provides a highly-customizable editing interface consisting of several c
   * **Panels** — the basic editing blocks for fields, groups of fields, and related object clusters
   * **Choosers** — interfaces for finding related objects in a ForeignKey relationship
 
-Configuring your models to use these components will shape the Wagtail editor to your needs. Wagtail also provides an API for injecting custom CSS and JavaScript for further customization, including extending the hallo.js rich text editor.
+Configuring your models to use these components will shape the Wagtail editor to your needs. Wagtail also provides an API for injecting custom CSS and JavaScript for further customization, including extending the ``hallo.js`` rich text editor.
 
 There is also an Edit Handler API for creating your own Wagtail editor components.
 
@@ -412,7 +412,7 @@ As standard, Wagtail organises panels into three tabs: 'Content', 'Promote' and
 Extending the WYSIWYG Editor (hallo.js)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To inject javascript into the Wagtail page editor, see the :ref:`insert_editor_js <insert_editor_js>` hook. Once you have the hook in place and your hallo.js plugin loads into the Wagtail page editor, use the following Javascript to register the plugin with hallo.js.
+To inject JavaScript into the Wagtail page editor, see the :ref:`insert_editor_js <insert_editor_js>` hook. Once you have the hook in place and your hallo.js plugin loads into the Wagtail page editor, use the following Javascript to register the plugin with hallo.js.
 
 .. code-block:: javascript
 

docs/pages/model_recipes.rst

@@ -78,7 +78,7 @@ Wagtail routes requests by iterating over the path components (separated with a
 
 ``route()`` takes the current object (``self``), the ``request`` object, and a list of the remaining ``path_components`` from the request URL. It either continues delegating routing by calling ``route()`` again on one of its children in the Wagtail tree, or ends the routing process by returning a ``RouteResult`` object or raising a 404 error.
 
-The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's ``serve()`` method and return a final response: this information consists of the page object, and any additional args / kwargs to be passed to ``serve()``.
+The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's ``serve()`` method and return a final response: this information consists of the page object, and any additional ``args``/``kwargs`` to be passed to ``serve()``.
 
 By overriding the ``route()`` method, we could create custom endpoints for each object in the Wagtail tree. One use case might be using an alternate template when encountering the ``print/`` endpoint in the path. Another might be a REST API which interacts with the current object. Just to see what's involved, lets make a simple model which prints out all of its child path components.
 

docs/pages/theory.rst

@@ -89,7 +89,7 @@ For going beyond the basics of model definition and interrelation, it might help
     #.  Django gets a request and routes through Wagtail's URL dispatcher definitions
     #.  Wagtail checks the hostname of the request to determine which ``Site`` record will handle this request.
     #.  Starting from the root page of that site, Wagtail traverses the page tree, calling the ``route()`` method and letting each page model decide whether it will handle the request itself or pass it on to a child page.
-    #.  The page responsible for handling the request returns a ``RouteResult`` object from ``route()``, which identifies the page along with any additional args/kwargs to be passed to ``serve()``.
+    #.  The page responsible for handling the request returns a ``RouteResult`` object from ``route()``, which identifies the page along with any additional ``args``/``kwargs`` to be passed to ``serve()``.
     #.  Wagtail calls ``serve()``, which constructs a context using ``get_context()``
     #.  ``serve()`` finds a template to pass it to using ``get_template()``
     #.  A response object is returned by ``serve()`` and Django responds to the requester.

docs/pages/writing_templates.rst

@@ -159,8 +159,8 @@ Wagtail embeds and images are included at their full width, which may overflow t
 Internal links (tag)
 ~~~~~~~~~~~~~~~~~~~~
 
-pageurl
---------
+``pageurl``
+-----------
 
 Takes a Page object and returns a relative URL (``/foo/bar/``) if within the same site as the current page, or absolute (``http://example.com/foo/bar/``) if not.
 

docs/reference/hooks.rst

@@ -30,7 +30,7 @@ The available hooks are:
 
 ``before_serve_page``
 
-  Called when Wagtail is about to serve a page. The callable passed into the hook will receive the page object, the request object, and the args and kwargs that will be passed to the page's ``serve()`` method. If the callable returns an ``HttpResponse``, that response will be returned immediately to the user, and Wagtail will not proceed to call ``serve()`` on the page.
+  Called when Wagtail is about to serve a page. The callable passed into the hook will receive the page object, the request object, and the ``args`` and ``kwargs`` that will be passed to the page's ``serve()`` method. If the callable returns an ``HttpResponse``, that response will be returned immediately to the user, and Wagtail will not proceed to call ``serve()`` on the page.
 
   .. code-block:: python
 

docs/reference/project_template.rst

@@ -38,7 +38,7 @@ Location: ``/mysite/core/templates/`` and ``/mysite/core/static/``
 
 The templates directory contains ``base.html``, ``404.html`` and ``500.html``. These files are very commonly needed on Wagtail sites to they have been added into the template.
 
-The static directory contains an empty javascript and sass file. Wagtail uses ``django-compressor`` for compiling and compressing static files. For more information, see: `Django Compressor Documentation <http://django-compressor.readthedocs.org/en/latest/>`_
+The static directory contains an empty JavaScript and SASS file. Wagtail uses ``django-compressor`` for compiling and compressing static files. For more information, see: `Django Compressor Documentation <http://django-compressor.readthedocs.org/en/latest/>`_
 
 
 Vagrant configuration
@@ -80,4 +80,4 @@ The Django settings files are split up into ``base.py``, ``dev.py``, ``productio
 
         .. tip::
 
-            On production servers, we recommend that you only store secrets in local.py (such as API keys and passwords). This can save you headaches in the future if you are ever trying to debug why a server is behaving badly. If you are using multiple servers which need different settings then we recommend that you create a different ``production.py`` file for each one.
+            On production servers, we recommend that you only store secrets in ``local.py`` (such as API keys and passwords). This can save you headaches in the future if you are ever trying to debug why a server is behaving badly. If you are using multiple servers which need different settings then we recommend that you create a different ``production.py`` file for each one.

docs/releases/0.4.rst

@@ -88,7 +88,7 @@ Admin
  * Removed the "More" section from the menu
  * Added pagination to page listings
  * Added a new datetime picker widget
- * Updated hallo.js to version 1.0.4
+ * Updated ``hallo.js`` to version 1.0.4
  * Aesthetic improvements to preview experience
  * Login screen redirects to dashboard if user is already logged in
  * Snippets are now ordered alphabetically
@@ -103,15 +103,15 @@ Search
  * Major refactor of Elasticsearch backend
  * Use ``match`` instead of ``query_string`` queries
  * Fields are now indexed in Elasticsearch with their correct type
- * Filter fields are no longer included in '_all'
- * Fields with partial matching are now indexed together into '_partials'
+ * Filter fields are no longer included in ``_all``
+ * Fields with partial matching are now indexed together into ``_partials``
 
 
 Images
 ------
 
  * Added ``original`` as a resizing rule supported by the ``{% image %}`` tag
- * ``image`` tag now accepts extra keyword arguments to be output as attributes on the img tag
+ * ``image`` tag now accepts extra keyword arguments to be output as attributes on the ``img`` tag
  * Added an ``attrs`` property to image rendition objects to output ``src``, ``width``, ``height`` and ``alt`` attributes all in one go
 
 

docs/releases/0.8.5.rst

@@ -22,6 +22,6 @@ Bug fixes
  * When adding tags where there were none before, it is now possible to save a single tag with multiple words in it
  * ``richtext`` template tag no longer raises ``TypeError`` if ``None`` is passed into it
  * Serving documents now uses a streaming HTTP response and will no longer break Django's cache middleware
- * User admin area no longer fails in the presence of negative user IDs (as used by django-guardian's default settings)
+ * User admin area no longer fails in the presence of negative user IDs (as used by ``django-guardian``'s default settings)
  * Password reset emails now use the ``BASE_URL`` setting for the reset URL
  * ``BASE_URL`` is now included in the project template's default settings file

docs/releases/1.0.rst

@@ -65,7 +65,7 @@ Admin
 
 **Page editor**
 
- * Javascript includes in the admin backend have been moved to the HTML header, to accommodate form widgets that render inline scripts that depend on libraries such as jQuery
+ * JavaScript includes in the admin backend have been moved to the HTML header, to accommodate form widgets that render inline scripts that depend on libraries such as jQuery
  * The external link chooser in rich text areas now accepts URLs of the form '/some/local/path', to allow linking to non-Wagtail-controlled URLs within the local site
  * Bare text entered in rich text areas is now automatically wrapped in a paragraph element
 
@@ -84,9 +84,9 @@ Admin
  * Removed the dependency on ``LOGIN_URL`` and ``LOGIN_REDIRECT_URL`` settings
  * Password reset view names namespaced to wagtailadmin
  * Removed the need to add permission check on admin views (now automated)
- * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails login view (making it easier to have front end views)
+ * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails login view (making it easier to have frontend login views)
  * Added cache-control headers to all admin views. This allows Varnish/Squid/CDN to run on vanilla settings in front of a Wagtail site
- * Date / time pickers now consistently use times without seconds, to prevent Javascript behaviour glitches when focusing / unfocusing fields
+ * Date / time pickers now consistently use times without seconds, to prevent JavasSript behaviour glitches when focusing / unfocusing fields
  * Added hook ``construct_homepage_summary_items`` for customising the site summary panel on the admin homepage
  * Renamed the ``construct_wagtail_edit_bird`` hook to ``construct_wagtail_userbar``
 
@@ -219,15 +219,15 @@ should work fine without them.
 Login/Password reset views renamed
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-It was previously possible to reverse the Wagtail login using django.contrib.auth.views.login.
+It was previously possible to reverse the Wagtail login view using ``django.contrib.auth.views.login``.
 This is no longer possible. Update any references to ``wagtailadmin_login``.
 
 Password reset view name has changed from ``password_reset`` to ``wagtailadmin_password_reset``.
 
-Javascript includes in admin backend have been moved
+JavaScript includes in admin backend have been moved
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To improve compatibility with third-party form widgets, pages within the Wagtail admin backend now output their Javascript includes in the HTML header, rather than at the end of the page. If your project extends the admin backend (through the ``register_admin_menu_item`` hook, for example) you will need to ensure that all associated Javascript code runs correctly from the new location. In particular, any code that accesses HTML elements will need to be contained in an 'onload' handler (e.g. jQuery's ``$(document).ready()``).
+To improve compatibility with third-party form widgets, pages within the Wagtail admin backend now output their JavaScript includes in the HTML header, rather than at the end of the page. If your project extends the admin backend (through the ``register_admin_menu_item`` hook, for example) you will need to ensure that all associated JavaScript code runs correctly from the new location. In particular, any code that accesses HTML elements will need to be contained in an 'onload' handler (e.g. jQuery's ``$(document).ready()``).
 
 EditHandler internal API has changed
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/search/indexing.rst

@@ -29,7 +29,7 @@ Signal handlers
 
     Signal handlers are now automatically registered in Django 1.7 and upwards
 
-Wagtailsearch provides some signal handlers which bind to the save/delete signals of all indexed models. This would automatically add and delete them from all backends you have registered in ``WAGTAILSEARCH_BACKENDS``.
+``wagtailsearch`` provides some signal handlers which bind to the save/delete signals of all indexed models. This would automatically add and delete them from all backends you have registered in ``WAGTAILSEARCH_BACKENDS``.
 
 If you are using Django version 1.7 or newer, these signal handlers are automatically registered when the ``wagtail.wagtailsearch`` app is loaded. Otherwise, they must be registered as your application starts up. This can be done by placing the following code in your ``urls.py``:
 
@@ -101,9 +101,9 @@ These are added to the search index and are used for performing full-text search
 Options
 ```````
 
- - **partial_match** (boolean) - Setting this to true allows results to be matched on parts of words. For example, this is set on the title field by default so a page titled "Hello World!" will be found if the user only types "Hel" into the search box.
- - **boost** (number) - This allows you to set fields as being more important than others. Setting this to a high number on a field will make pages with matches in that field to be ranked higher. By default, this is set to 2 on the Page title field and 1 on all other fields.
- - **es_extra** (dict) - This field is to allow the developer to set or override any setting on the field in the ElasticSearch mapping. Use this if you want to make use of any ElasticSearch features that are not yet supported in Wagtail.
+ - **partial_match** (``boolean``) - Setting this to true allows results to be matched on parts of words. For example, this is set on the title field by default so a page titled ``Hello World!`` will be found if the user only types ``Hel`` into the search box.
+ - **boost** (``int/float``) - This allows you to set fields as being more important than others. Setting this to a high number on a field will make pages with matches in that field to be ranked higher. By default, this is set to 2 on the Page title field and 1 on all other fields.
+ - **es_extra** (``dict``) - This field is to allow the developer to set or override any setting on the field in the ElasticSearch mapping. Use this if you want to make use of any ElasticSearch features that are not yet supported in Wagtail.
 
 
 ``index.FilterField``

docs/search/searching.rst

@@ -21,7 +21,7 @@ Wagtail provides a ``search`` method on the QuerySet for all page models:
     >>> EventPage.objects.filter(date__gt=timezone.now()).search("Hello world!")
 
 
-All methods of ``PageQuerySet`` are supported by wagtailsearch:
+All methods of ``PageQuerySet`` are supported by ``wagtailsearch``:
 
 .. code-block:: python
 
@@ -83,7 +83,7 @@ The most basic search functionality just needs a search box which submits a requ
     <input type="submit" value="Search">
   </form>
 
-The form is submitted to the url of the ``wagtailsearch_search`` view, with the search terms variable ``q``. The view will use its own basic search results template.
+The form is submitted to the URL of the ``wagtailsearch_search`` view, with the search terms variable ``q``. The view will use its own basic search results template.
 
 Let's use our own template for the results, though. First, in your project's ``settings.py``, define a path to your template:
 
@@ -156,7 +156,7 @@ Now add a simple interface for the search with a ``<input>`` element to gather s
     <div id="json-results"></div>
   </div>
 
-Finally, we'll use JQuery to make the asynchronous requests and handle the interactivity:
+Finally, we'll use jQuery to make the asynchronous requests and handle the interactivity:
 
 .. code-block:: guess
 

docs/snippets.rst

@@ -35,7 +35,7 @@ Here's an example snippet from the Wagtail demo website:
     def __unicode__(self):
       return self.text
 
-The ``Advert`` model uses the basic Django model class and defines two properties: text and url. The editing interface is very close to that provided for ``Page``-derived models, with fields assigned in the panels property. Snippets do not use multiple tabs of fields, nor do they provide the "save as draft" or "submit for moderation" features.
+The ``Advert`` model uses the basic Django model class and defines two properties: text and URL. The editing interface is very close to that provided for ``Page``-derived models, with fields assigned in the panels property. Snippets do not use multiple tabs of fields, nor do they provide the "save as draft" or "submit for moderation" features.
 
 ``@register_snippet`` tells Wagtail to treat the model as a snippet. The ``panels`` list defines the fields to show on the snippet editing page. It's also important to provide a string representation of the class through ``def __unicode__(self):`` so that the snippet objects make sense when listed in the Wagtail admin.
 

docs/spelling_wordlist.txt

@@ -0,0 +1,35 @@
+backend
+backends
+callable
+callables
+Cloudflare
+Django
+Elasticsearch
+Embedly
+frontend
+Heroku
+hostname
+jQuery
+login
+metadata
+mixin
+Nginx
+oEmbed
+PostgreSQL
+QuerySet
+Redis
+resize
+resized
+resizing
+searchable
+Searchly
+sitemap
+sitemaps
+subpage
+subpages
+Torchbox
+uWSGI
+Vagrantfile
+Vimeo
+Wagtail
+Youtube

requirements-dev.txt

@@ -7,3 +7,7 @@ Pillow>=2.7.0
 # For coverage and PEP8 linting
 coverage>=3.7.0
 flake8>=2.2.0
+
+# For spellchecking the documentation
+sphinxcontrib-spelling==2.1.1
+pyenchant==1.6.6

wagtail/wagtailcore/query.py

@@ -13,13 +13,13 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def live(self):
         """
-        This filters the queryset to only contain published pages.
+        This filters the QuerySet to only contain published pages.
         """
         return self.filter(self.live_q())
 
     def not_live(self):
         """
-        This filters the queryset to only contain unpublished pages.
+        This filters the QuerySet to only contain unpublished pages.
         """
         return self.exclude(self.live_q())
 
@@ -28,7 +28,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def in_menu(self):
         """
-        This filters the queryset to only contain pages that are in the menus.
+        This filters the QuerySet to only contain pages that are in the menus.
         """
         return self.filter(self.in_menu_q())
 
@@ -40,13 +40,13 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def page(self, other):
         """
-        This filters the queryset so it only contains the specified page.
+        This filters the QuerySet so it only contains the specified page.
         """
         return self.filter(self.page_q(other))
 
     def not_page(self, other):
         """
-        This filters the queryset so it doesn't contain the specified page.
+        This filters the QuerySet so it doesn't contain the specified page.
         """
         return self.exclude(self.page_q(other))
 
@@ -60,7 +60,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def descendant_of(self, other, inclusive=False):
         """
-        This filters the queryset to only contain pages that descend from the specified page.
+        This filters the QuerySet to only contain pages that descend from the specified page.
 
         If inclusive is set to True, it will also contain the page itself (instead of just its descendants).
         """
@@ -68,7 +68,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def not_descendant_of(self, other, inclusive=False):
         """
-        This filters the queryset to not contain any pages that descend from the specified page.
+        This filters the QuerySet to not contain any pages that descend from the specified page.
 
         If inclusive is set to True, it will also exclude the specified page.
         """
@@ -79,13 +79,13 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def child_of(self, other):
         """
-        This filters the queryset to only contain pages that are direct children of the specified page.
+        This filters the QuerySet to only contain pages that are direct children of the specified page.
         """
         return self.filter(self.child_of_q(other))
 
     def not_child_of(self, other):
         """
-        This filters the queryset to not contain any pages that are direct children of the specified page.
+        This filters the QuerySet to not contain any pages that are direct children of the specified page.
         """
         return self.exclude(self.child_of_q(other))
 
@@ -103,7 +103,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def ancestor_of(self, other, inclusive=False):
         """
-        This filters the queryset to only contain pages that are ancestors of the specified page.
+        This filters the QuerySet to only contain pages that are ancestors of the specified page.
 
         If inclusive is set to True, it will also include the specified page.
         """
@@ -111,7 +111,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def not_ancestor_of(self, other, inclusive=False):
         """
-        This filters the queryset to not contain any pages that are ancestors of the specified page.
+        This filters the QuerySet to not contain any pages that are ancestors of the specified page.
 
         If inclusive is set to True, it will also exclude the specified page.
         """
@@ -136,7 +136,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def sibling_of(self, other, inclusive=True):
         """
-        This filters the queryset to only contain pages that are siblings of the specified page.
+        This filters the QuerySet to only contain pages that are siblings of the specified page.
 
         By default, inclusive is set to True so it will include the specified page in the results.
 
@@ -146,7 +146,7 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def not_sibling_of(self, other, inclusive=True):
         """
-        This filters the queryset to not contain any pages that are siblings of the specified page.
+        This filters the QuerySet to not contain any pages that are siblings of the specified page.
 
         By default, inclusive is set to True so it will exclude the specified page from the results.
 
@@ -164,13 +164,13 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def type(self, model):
         """
-        This filters the queryset to only contain pages that are an instance of the specified model (including subclasses).
+        This filters the QuerySet to only contain pages that are an instance of the specified model (including subclasses).
         """
         return self.filter(self.type_q(model))
 
     def not_type(self, model):
         """
-        This filters the queryset to not contain any pages which are an instance of the specified model.
+        This filters the QuerySet to not contain any pages which are an instance of the specified model.
         """
         return self.exclude(self.type_q(model))
 
@@ -184,25 +184,25 @@ class PageQuerySet(MP_NodeQuerySet):
 
     def public(self):
         """
-        This filters the queryset to only contain pages that are not in a private section
+        This filters the QuerySet to only contain pages that are not in a private section
         """
         return self.filter(self.public_q())
 
     def not_public(self):
         """
-        This filters the queryset to only contain pages that are in a private section
+        This filters the QuerySet to only contain pages that are in a private section
         """
         return self.exclude(self.public_q())
 
     def search(self, query_string, fields=None, backend='default'):
         """
-        This runs a search query on all the pages in the queryset
+        This runs a search query on all the pages in the QuerySet
         """
         search_backend = get_search_backend(backend)
         return search_backend.search(query_string, self, fields=None)
 
     def unpublish(self):
         """
-        This unpublishes all pages in the queryset
+        This unpublishes all pages in the QuerySet
         """
         self.update(live=False, has_unpublished_changes=True)