Various documentation typo/spelling fixes

Honza Král

    Honza first discovered Django in 2006 and started using it right away,

    first for school and personal projects and later in his full time job. He

    first for school and personal projects and later in his full-time job. He

    contributed various patches and fixes mostly to the newforms library,

    newforms admin and, through participation in the Google Summer of Code

    project, assisted in creating the :ref:`model validation

    documentation at DjangoCon EU 2012, and also helped to develop `CCBV`_, an

    additional class based view reference tool.

    Marc is currently a full time parent, part time developer, and lives in

    Marc is currently a full-time parent, part-time developer, and lives in

    Oxford, UK.

    .. _CCBV: http://ccbv.co.uk/

* Remove ``import`` statements that are no longer used when you change code.

  `flake8`_ will identify these imports for you. If an unused import needs to

  remain for backwards-compatibility, mark the end of of with ``# NOQA`` to

  remain for backwards-compatibility, mark the end of with ``# NOQA`` to

  silence the flake8 warning.

* Systematically remove all trailing whitespaces from your code as those

    release, not the development version.

Our preferred way for marking new features is by prefacing the features'

documentation with: "``.. versionadded:: X.Y``", followed by a a mandatory

documentation with: "``.. versionadded:: X.Y``", followed by a mandatory

blank line and an optional content (indented).

General improvements, or other changes to the APIs that should be emphasized

If there are foreseeable error conditions that may occur while running your

action, you should gracefully inform the user of the problem. This means

handling exceptions and and using

handling exceptions and using

:meth:`django.contrib.admin.ModelAdmin.message_user` to display a user friendly

description of the problem in the response.

    in the :doc:`sessions documentation </topics/http/sessions>` on

    how to enable sessions.

We will use the :class:`SessionWizardView` in all examples but is is completely

We will use the :class:`SessionWizardView` in all examples but is completely

fine to use the :class:`CookieWizardView` instead. As with your

:class:`~django.forms.Form` classes, this :class:`WizardView` class can live

anywhere in your codebase, but convention is to put it in :file:`views.py`.