Fixed minor documentation errors and mistakes (#151)

doc/development/implementation/background.rst

@@ -2,7 +2,7 @@ Background tasks
 ================
 
 pretix provides the ability to run all longer-running tasks like generating ticket files or sending emails
-in a background thread instead of the webserver process. We use the well-established `Celery`_ project to
+in a background thread instead of the web server process. We use the well-established `Celery`_ project to
 implement this. However, as celery requires running a task queue like RabbitMQ and a result storage such as
 Redis to work efficiently, we don't like to *depend* on celery being available to make small-scale installations
 of pretix more straightforward. For this reason, the "background" in "background task" is always optional.
@@ -13,8 +13,8 @@ in the current installation.
 Implementing a task
 -------------------
 
-A common pattern for implementing "optionally-asynchronous" tasks that can be seen a lot in ``pretix.base.services``
-looks like this::
+A common pattern for implementing "optionally-asynchronous" tasks can be seen a lot in ``pretix.base.services``
+and looks like this::
 
     def my_task(argument1, argument2):
         # Important: All arguments and return values need to be serializable into JSON.
@@ -45,7 +45,7 @@ A usage example taken directly from the code is::
     class OrderCancelDo(EventViewMixin, OrderDetailMixin, AsyncAction, View):
         """
         A view that executes a task asynchronously. A POST request will kick of the
-        task into the background or run it in the foreground, if celery is not installed.
+        task into the background or run it in the foreground if celery is not installed.
         In the former case, subsequent GET calls can be used to determinine the current
         status of the task.
         """
@@ -93,4 +93,4 @@ AJAX sending of the form and display a loading indicator::
         ...
     </form>
 
-.. _Celery: http://www.celeryproject.org/
+.. _Celery: http://www.celeryproject.org/

doc/development/implementation/email.rst

@@ -1,7 +1,7 @@
 Sending Email
 =============
 
-As pretix allows event organizers to configure how they want to sent emails to their users in multiple ways.
-Therefore, all emails should be sent throught the following function:
+pretix allows event organizers to configure how they want to send emails to their users in multiple ways.
+Therefore, all emails should be sent through the following function:
 
-.. autofunction:: pretix.base.services.mail.mail
+.. autofunction:: pretix.base.services.mail.mail

doc/development/implementation/i18n.rst

@@ -1,11 +1,10 @@
 Internationalization
 ====================
 
-One of pretix' major selling points is it's multi-language capability. We make heavy use of Django's
+One of pretix's major selling points is its multi-language capability. We make heavy use of Django's
 `translation features`_ that are built upon `GNU gettext`_. However, Django does not provide a standard
 way to translate *user-generated content*. In our case, we need to translate strings like product names
-or event descriptions, so we need event organizers to be able to fill in all fields in multiple languages
-at the same time.
+or event descriptions, so we need event organizers to be able to fill in all fields in multiple languages.
 
 .. note:: Implementing object-level translation in a relational database is a task that requires some difficult
           trade-off. We decided for a design that is not elegant on the database level (as it violates the `1NF`_) and
@@ -21,8 +20,8 @@ pretix provides two custom model field types that allow you to work with localiz
 ``I18nTextField``. Both of them are stored in the database as a ``TextField`` internally, they only differ in the
 default form widget that is used by ``ModelForm``.
 
-Yes, we know that this has negative impact on performance when indexing or searching them, but as mentioned above,
-within pretix this is not used in places that need to be searched. Lookups are currently not even implemented on these
+As pretix does not use these fields in places that need to be searched, the negative performance impact when searching
+and indexing these fields in negligible, as mentioned above. Lookups are currently not even implemented on these
 fields. In the database, the strings will be stored as a JSON-encoded mapping of language codes to strings.
 
 Whenever you interact with those fields, you will either provide or receive an instance of the following class:
@@ -58,8 +57,8 @@ The ``i18n`` module contains a few more useful utilities, starting with simple l
 numbers and dates, ``LazyDate`` and ``LazyNumber``. There also is a ``LazyLocaleException`` base class that provides
 exceptions with gettext-localized exception messages.
 
-Last, but definitely not least, we have the ``language`` context manager that allows you to execute a piece of code with
-a different locale::
+Last, but definitely not least, we have the ``language`` context manager (``pretix.base.i18n.language``) that allows
+you to execute a piece of code with a different locale::
 
     with language('de'):
         render_mail_template()
@@ -69,4 +68,4 @@ action that causes the mail to be sent.
 
 .. _translation features: https://docs.djangoproject.com/en/1.9/topics/i18n/translation/
 .. _GNU gettext: https://www.gnu.org/software/gettext/
-.. _1NF: https://en.wikipedia.org/wiki/First_normal_form
+.. _1NF: https://en.wikipedia.org/wiki/First_normal_form

doc/development/implementation/index.rst

@@ -2,7 +2,7 @@ Implementation and Utilities
 ============================
 
 This chapter describes the various inner workings that power pretix, most of them living in ``pretix.base``.
-If you want to develop around pretix' core or advanced plugins, this aims to describe everything you absolutely
+If you want to develop around pretix's core or advanced plugins, this aims to describe everything you absolutely
 need to know.
 
 Contents:

doc/development/implementation/settings.rst

@@ -3,7 +3,8 @@ Settings storage
 
 pretix is highly configurable and therefore needs to store a lot of per-event and per-organizer settings.
 Those settings are stored in the database and accessed through a ``SettingsProxy`` instance. You can obtain
-such an instance from any event or organizer model instance by just accessing ``event.settings``.
+such an instance from any event or organizer model instance by just accessing ``event.settings`` or
+``organizer.settings``, respectively.
 
 Any setting consists of a key and a value. By default, all settings are strings, but the settings system
 includes serializers for serializing the following types:

doc/development/implementation/urlconfig.rst

@@ -4,8 +4,8 @@ Working with URLs
 =================
 
 As soon as you write a plugin that provides a new view to the user (or if you want to
-contribute to pretix itself), you need to understand how URLs work in pretix as it slightly
-differs from the standard Django system.
+contribute to pretix itself), you need to understand how URLs work in pretix as it differs
+slightly from the standard Django system.
 
 The reason for the complicated URL handling is that pretix supports custom subdomains for
 single organizers. In this example we will use an event organizer with the slug ``bigorg``
@@ -24,10 +24,10 @@ URL routing
 The hard part about implementing this URL routing in Django is that
 ``https://pretix.eu/bigorg/awesomecon/`` contains two parameters of nearly arbitrary content
 and ``https://tickets.bigorg.com/awesomecon/`` contains only one. The only robust way to do
-this is by having *seperate* URL configuration for those two cases. In pretix, we call the
-former our ``maindomain`` config and the latter our ``subdomain`` config. For pretix' core
+this is by having *separate* URL configuration for those two cases. In pretix, we call the
+former our ``maindomain`` config and the latter our ``subdomain`` config. For pretix's core
 modules we do some magic to avoid duplicate configuration, but for a fairly simple plugin with
-only a handful of routes, we recommend just configuring the two URL sets seperately.
+only a handful of routes, we recommend just configuring the two URL sets separately.
 
 The file ``maindomain_urls.py`` inside your plugin package will be loaded and scanned for
 URL configuration automatically and should be provided by any plugin that provides any view.
@@ -63,12 +63,12 @@ If you only provide URLs in the admin area, you do not need to provide a ``subdo
 URL reversal
 ------------
 
-pretix uses Django's URL namespacing feature. The URLs of pretix' core are available in the ``control``
+pretix uses Django's URL namespacing feature. The URLs of pretix's core are available in the ``control``
 and ``presale`` namespaces, there are only very few URLs in the root namespace. Your plugin's URLs will
 be available in the ``plugins:<applabel>`` namespace, e.g. the form of the email sending plugin is
 available as ``plugins:sendmail:send``.
 
-Generating an URL for the frontend is a complicated task, because you need to know whether the event's
+Generating a URL for the frontend is a complicated task, because you need to know whether the event's
 organizer uses a custom URL or not and then generate the URL with a different domain and different
 arguments based on this information. pretix provides some helpers to make this easier. The first helper
 is a python method that emulates a behaviour similar to ``reverse``:
@@ -87,4 +87,4 @@ Implementation details
 
 There are some other caveats when using a design like this, e.g. you have to care about cookie domains
 and referer verification yourself. If you want to see how we built this, look into the ``pretix/multidomain/``
-sub-tree.
+sub-tree.