From e81bdbfd92001a3e0561efaa313a73ea2f947726 Mon Sep 17 00:00:00 2001 From: Alexander Brock Date: Sat, 18 Jul 2015 00:47:18 +0200 Subject: [PATCH] Spelling corrections --- doc/development/api/general.rst | 2 +- doc/development/api/plugins.rst | 2 +- doc/development/api/restriction.rst | 4 ++-- doc/development/concepts.rst | 21 +++++++++++---------- doc/development/goals.rst | 8 ++++---- doc/development/setup.rst | 8 +++++--- doc/development/structure.rst | 4 ++-- 7 files changed, 26 insertions(+), 23 deletions(-) diff --git a/doc/development/api/general.rst b/doc/development/api/general.rst index 56aec1e2b9..27f7615fec 100644 --- a/doc/development/api/general.rst +++ b/doc/development/api/general.rst @@ -11,7 +11,7 @@ HTML head injection ------------------- These two signals allow you to put code inside the HTML ```` tag -of every page. One signal is for the frontend, one for the backend. You +of every page. One signal is for the front end, one for the back end. You will get the request as a keyword argument ``request`` and can return plain HTML. The ``request`` object will have an attribute ``event``. diff --git a/doc/development/api/plugins.rst b/doc/development/api/plugins.rst index 917dbd00ad..ce0fe9dcbe 100644 --- a/doc/development/api/plugins.rst +++ b/doc/development/api/plugins.rst @@ -77,7 +77,7 @@ A working example would be:: The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks whether the pretix installation meets all requirements of the plugin. If so, -it should contian ``None`` or an empty list, otherwise a list of strings containing +it should contain ``None`` or an empty list, otherwise a list of strings containing human-readable error messages. We recommend using the ``django.utils.functional.cached_property`` decorator, as it might get called a lot. You can also implement ``compatibility_warnings``, those will be displayed but not block the plugin execution. diff --git a/doc/development/api/restriction.rst b/doc/development/api/restriction.rst index 64bfd18501..0fceeaffd1 100644 --- a/doc/development/api/restriction.rst +++ b/doc/development/api/restriction.rst @@ -67,7 +67,7 @@ It is sent out with several keyword arguments: exists, it is available in the dictionary via the special key ``'variation'``. If the item does not have any properties, the list will contain exactly one empty dictionary. Please note: this is *not* the list of all possible variations, this is - only the list of all variations the frontend likes to determine the status for. + only the list of all variations the front end likes to determine the status for. Technically, you won't get ``dict`` objects but ``pretix.base.types.VariationDict`` objects, which behave exactly the same but add some extra methods. ``context`` @@ -217,7 +217,7 @@ Control interface formsets To make it possible for the event organizer to configure your restriction, there is a 'Restrictions' page in the item configuration. This page is able to show a formset for each restriction plugin, but *you* are required to create this formset. This is why you -should listen to the the ``pretix.control.signals.restriction_formset`` signal. +should listen to the ``pretix.control.signals.restriction_formset`` signal. Currently, the signal comes with only one keyword argument: diff --git a/doc/development/concepts.rst b/doc/development/concepts.rst index 7fd76046d9..403881567d 100644 --- a/doc/development/concepts.rst +++ b/doc/development/concepts.rst @@ -26,7 +26,7 @@ Users and events ^^^^^^^^^^^^^^^^ Pretix is all about **events**, which are defined as something happening somewhere. -Every Event is managed by the **organizer**, an abstract entity running the event. +Every event is managed by the **organizer**, an abstract entity running the event. Pretix is used by **users**. We want to enable global users who can just login into pretix and buy tickets for as many events as they like but at the same time it @@ -59,7 +59,7 @@ Items and variations The purpose of pretix is to sell **items** (which belong to **events**) to **users**. An **item** is a abstract thing, popular examples being event tickets or a piece of -merchandise, like 'T-Shirt'. An **item** can have multiple **properties** with multiple +merchandise, like 'T-shirt'. An **item** can have multiple **properties** with multiple **values** each. For example, the **item** 'T-Shirt' could have the **property** 'Size' with **values** 'S', 'M' and 'L' and the **property** 'Color' with **values** 'black' and 'blue'. @@ -79,12 +79,12 @@ include 'Name' or 'age'. Restrictions ^^^^^^^^^^^^ -The probably most powerful concepts of pretix is the very abstract concept of **restricitons**. +The probably most powerful concepts of pretix is the very abstract concept of **restrictions**. We already know that **items** can come in very different **variations**, but a **restriction** decides whether an variation is available for sale and assign **prices** to **variations**. There are **restriction types** (pieces of code implementing the restriction logic) and **restriction instances** (the specific configurations made by the -organzier). Although **restrictions** are a very abstract concept which can be used +organizer). Although **restrictions** are a very abstract concept which can be used to do nearly anything, there are a few obvious examples: * One easy example is a restriction by time, which allows the sale of certain item variations @@ -106,7 +106,7 @@ Any number of **restrictions** can be applied to the whole of a **item** or even * The restrictions are being processed in random order (there may not be any assumptions about the evaluation order). * Multiple restriction instances of **different restriction types** are linked with *and*, so - if both a time frame and a restriction by number are applied to an item, the item is only avaliable + if both a time frame and a restriction by number are applied to an item, the item is only available for sale during the given time frame *and* only as long as items are available. * Multiple restriction instances of the **same restriction type** are typically linked with *or*, although this is the decision of the restriction logic itself and not mandatory. So for example @@ -127,7 +127,7 @@ special care in the implementation to never sell more tickets than allowed, even about how many of them are still available. * Every time a user places a item in the cart, a **cart lock** is created, reducing the number of available items in the pool by one. The lock is valid for a fixed time (e.g. 30 minutes), but not - instantly deleted afther those 30 minutes (we'll get to that). + instantly deleted after those 30 minutes (we'll get to that). * Every time a user places a binding order, the lock object is replaced by an **order** which behaves much the same as the lock. It reduces the number of available item and is valid for a fixed time, this time for the configured payment term (e.g. 14 days). @@ -137,9 +137,10 @@ special care in the implementation to never sell more tickets than allowed, even are more cart locks than available tickets and therefore have to remove one of the expired cart locks. However, we do not choose one by random, but keep the surplus in a way that leads to the deletion of the cart lock of the user who tries *last* to use his lock. -* The same goes for orders which are not paid within the specified timeframe. This policy allows to - sell as much items as possible, guarantees you to get your item if you checkout within the validity - period of your lock or pay within the validity period of your order. It does not guarantee you anything +* The same goes for orders which are not paid within the specified timeframe. This policy allows the organizer to + sell as much items as possible. Moreover, it guarantees the users to get their items if they check out within the validity + period of their locks and pay within the validity period of their orders. It does not guarantee them anything any longer, but it tries to be *as tolerant as possible* to users who are paying after their payment period or click checkout after the expiry of their lock. -* The same quota can apply to multiple items and one item can be affected by multiple quotas +* The same quota can apply to multiple items and one item can be affected by multiple quotas. + diff --git a/doc/development/goals.rst b/doc/development/goals.rst index 35d8bd3f83..f0e561379c 100644 --- a/doc/development/goals.rst +++ b/doc/development/goals.rst @@ -8,7 +8,7 @@ Technical goals * Python 3.4 * Use Django 1.8+ -* Be PEP-8 compliant +* Be [PEP-8](https://www.python.org/dev/peps/pep-0008/) compliant * Be fully internationalized, unicode and timezone aware * Use a fully documented and reproducible setup * Be fully tested by unit tests @@ -23,7 +23,7 @@ Next goals * There is the possibility to send out payment reminders * The user can download the ticket in PDF form, for which the organizer can upload and customize a template without ever touching a line of code * The system provides a variety of statistics -* The system provices export methods for multiple cashdesk/ticket validation systems +* The system provides export methods for multiple cashdesk/ticket validation systems Achieved goals ^^^^^^^^^^^^^^ @@ -33,10 +33,10 @@ Achieved goals * Tickets are only an instance of an abstract model called items, such that the system can also sell e.g. merchandise * An abstract concept of restriction is used to restrict the selling of tickets, for example by date, by number or by user permissions. - * Items can come in multiple flavors (like t-shirt sizes or colors) + * Items can come in multiple flavors (like T-shirt sizes or colors) * Items can require additional user input (like attendee names) -* The software is not only user, but also organizer- and admin-friendly and provides a beautiful and time-saving interface for all admin jobs +* The software is not only user-, but also organizer- and admin-friendly and provides a beautiful and time-saving interface for all admin jobs * The software is able to import bank data, at least using CSV files with support for MT940 * There is the possibility to add more payment methods later, such as credit card payment, PayPal or even cash * There is a flexible concept of payment goals which works well together with the restriction framework mentioned above diff --git a/doc/development/setup.rst b/doc/development/setup.rst index f9db3dc905..b7defa8693 100644 --- a/doc/development/setup.rst +++ b/doc/development/setup.rst @@ -11,7 +11,9 @@ Just clone our git repository including its submodules:: External Dependencies --------------------- * Python 3.4 or newer -* ``pip`` for Python 3 +* ``pip`` for Python 3 (Debian package: ``python3-pip``) +* ``pyvenv`` for Python 3 (Debian package: ``python3-venv``) +* ``libffi`` (Debian package: ``libffi-dev``) * ``git`` * ``lessc`` (Debian package: ``node-less``) @@ -42,7 +44,7 @@ Then, create the local database:: python manage.py migrate A first user with username ``admin@localhost`` and password ``admin`` will be automatically -created. If you want to genreate more test data, run:: +created. If you want to generate more test data, run:: python make_testdata.py @@ -92,7 +94,7 @@ for example:: Working with the documentation ------------------------------ First, you should install the requirements necessary for building the documentation. -Make sure you have your virtual python enviroment activated (see above). Then, install the +Make sure you have your virtual python environment activated (see above). Then, install the packages by executing:: cd doc/ diff --git a/doc/development/structure.rst b/doc/development/structure.rst index 2731eb59cc..09b24ca5ad 100644 --- a/doc/development/structure.rst +++ b/doc/development/structure.rst @@ -14,10 +14,10 @@ pretix/ essential to all of pretix's features. control/ - This is the django app containing the frontend for organizers. + This is the django app containing the front end for organizers. presale/ - This is the django app containing the frontend for users buying tickets. + This is the django app containing the front end for users buying tickets. helpers/ Helpers contain a very few modules providing workarounds for low-level flaws in