Fixed minor documentation errors and mistakes (#151)

doc/development/api/exporter.rst

@@ -4,7 +4,7 @@
 Writing an exporter plugin
 ==========================
 
-An is a method to export the product and order data in pretix for later use in another
+An Exporter is a method to export the product and order data in pretix for later use in another
 context.
 
 In this document, we will walk through the creation of an exporter output plugin. This
@@ -18,7 +18,7 @@ Exporter registration
 The exporter API does not make a lot of usage from signals, however, it does use a signal to get a list of
 all available exporters. Your plugin should listen for this signal and return the subclass of
 ``pretix.base.exporter.BaseExporter``
-that we'll soon create::
+that we'll provide in this plugin::
 
     from django.dispatch import receiver
 
@@ -36,8 +36,7 @@ The exporter class
 
 .. class:: pretix.base.exporter.BaseExporter
 
-   The central object of each exporter is the subclass of ``BaseExporter`` we already mentioned above.
-   In this section, we will discuss it's interface in detail.
+   The central object of each exporter is the subclass of ``BaseExporter``.
 
    .. py:attribute:: BaseExporter.event
 

doc/development/api/general.rst

@@ -60,8 +60,8 @@ Dashboards
    :members: event_dashboard_widgets, user_dashboard_widgets
 
 
-Displaying of log entries
--------------------------
+Display of log entries
+----------------------
 
 .. automodule:: pretix.base.signals
    :members: logentry_display

doc/development/api/payment.rst

@@ -14,7 +14,7 @@ Provider registration
 The payment provider API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available payment providers. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.payment.BasePaymentProvider``
-that we'll soon create::
+that the plugin will provide::
 
     from django.dispatch import receiver
 
@@ -32,8 +32,7 @@ The provider class
 
 .. class:: pretix.base.payment.BasePaymentProvider
 
-   The central object of each payment provider is the subclass of ``BasePaymentProvider``
-   we already mentioned above. In this section, we will discuss it's interface in detail.
+   The central object of each payment provider is the subclass of ``BasePaymentProvider``.
 
    .. py:attribute:: BasePaymentProvider.event
 
@@ -105,9 +104,9 @@ Additional views
 For most simple payment providers it is more than sufficient to implement
 some of the :py:class:`BasePaymentProvider` methods. However, in some cases
 it is necessary to introduce additional views. One example is the PayPal
-provider. It redirects the user to a paypal website in the
-:py:meth:`BasePaymentProvider.checkout_prepare`` step of the checkout process
-and provides PayPal with an URL to redirect back to. This URL points to a
+provider. It redirects the user to a PayPal website in the
+:py:meth:`BasePaymentProvider.checkout_prepare` step of the checkout process
+and provides PayPal with a URL to redirect back to. This URL points to a
 view which looks roughly like this::
 
     @login_required
@@ -123,7 +122,7 @@ view which looks roughly like this::
             try:
                 # Redirect back to the confirm page. We chose to save the
                 # event ID in the user's session. We could also put this
-                # information into an URL parameter.
+                # information into a URL parameter.
                 event = Event.objects.current.get(identity=request.session['payment_paypal_event'])
                 return redirect(reverse('presale:event.checkout.confirm', kwargs={
                     'event': event.slug,
@@ -136,6 +135,6 @@ view which looks roughly like this::
 
 If you do not want to provide a view of your own, you could even let PayPal
 redirect directly back to the confirm page and handle the query parameters
-inside :py:meth:`BasePaymentProvider.checkout_is_valid_session``. However,
+inside :py:meth:`BasePaymentProvider.checkout_is_valid_session`. However,
 because some external providers (not PayPal) force you to have a *constant*
 redirect URL, it might be necessary to define custom views.

doc/development/api/plugins.rst

@@ -6,7 +6,7 @@ Plugin basics
 
 It is possible to extend pretix with custom Python code using the official plugin
 API. Every plugin has to be implemented as an independent Django 'app' living
-in an own python package nstalled like any other python module. There are also some
+in its own python package installed like any other python module. There are also some
 official plugins inside the ``pretix/plugins/`` directory of your pretix installation.
 
 The communication between pretix and the plugins happens mostly using Django's
@@ -16,13 +16,13 @@ on the next pages.
 
 .. _`pluginsetup`:
 
-To create a new plugin, create a new python package which must be a vaild `Django app`_
+To create a new plugin, create a new python package which must be a valid `Django app`_
 and must contain plugin metadata, as described below.
 
 The following pages go into detail about the several types of plugins currently
 supported. While these instructions don't assume that you know a lot about pretix,
-they do assume that you have prior knowledge about Django (e.g. it's view layer,
-how it's ORM works, etc.).
+they do assume that you have prior knowledge about Django (e.g. its view layer,
+how its ORM works, etc.).
 
 Plugin metadata
 ---------------
@@ -83,7 +83,7 @@ Plugin registration
 
 Somehow, pretix needs to know that your plugin exists at all. For this purpose, we
 make use of the `entry point`_ feature of setuptools. To register a plugin that lives
-in a seperate python package, your ``setup.py`` sould contain something like this::
+in a separate python package, your ``setup.py`` should contain something like this::
 
     setup(
         …
@@ -129,4 +129,4 @@ your Django app label.
 .. _Django app: https://docs.djangoproject.com/en/1.7/ref/applications/
 .. _signal dispatcher: https://docs.djangoproject.com/en/1.7/topics/signals/
 .. _namespace packages: http://legacy.python.org/dev/peps/pep-0420/
-.. _entry point: https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins
+.. _entry point: https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins

doc/development/api/ticketoutput.rst

@@ -17,7 +17,7 @@ Output registration
 The ticket output API does not make a lot of usage from signals, however, it
 does use a signal to get a list of all available ticket outputs. Your plugin
 should listen for this signal and return the subclass of ``pretix.base.ticketoutput.BaseTicketOutput``
-that we'll soon create::
+that we'll provide in this plugin::
 
     from django.dispatch import receiver
 
@@ -35,8 +35,7 @@ The output class
 
 .. class:: pretix.base.ticketoutput.BaseTicketOutput
 
-   The central object of each ticket output is the subclass of ``BaseTicketOutput``
-   we already mentioned above. In this section, we will discuss it's interface in detail.
+   The central object of each ticket output is the subclass of ``BaseTicketOutput``.
 
    .. py:attribute:: BaseTicketOutput.event