Started fixing spellings. Added wordlist

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

@@ -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

@@ -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/howto/settings.rst

@@ -1,4 +1,3 @@
-
 ==============================
 Configuring Django for Wagtail
 ==============================
@@ -173,7 +172,7 @@ The search settings customize the search results templates as well as choosing a
 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
 

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/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/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 log in view (making it easier to have frontend log in 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 log in 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,24 @@
+backend
+backends
+callable
+callables
+Cloudflare
+Django
+Elasticsearch
+Embedly
+frontend
+Heroku
+jQuery
+metadata
+Nginx
+oEmbed
+PostgreSQL
+QuerySet
+Redis
+searchable
+Searchly
+Torchbox
+Vagrantfile
+Vimeo
+Wagtail
+Youtube