Fix some typos

docs/concepts.rst

@@ -28,7 +28,7 @@ The core of Channels is, unsurprisingly, a datastructure called a *channel*.
 What is a channel? It is an *ordered*, *first-in first-out queue* with
 *message expiry* and *at-most-once delivery* to *only one listener at a time*.
 
-You can think of it as analagous to a task queue - messages are put onto
+You can think of it as analogous to a task queue - messages are put onto
 the channel by *producers*, and then given to just one of the *consumers*
 listening to that channnel.
 

docs/getting-started.rst

@@ -244,7 +244,7 @@ connection, as part of the query string (e.g. ``wss://host/websocket?room=abc``)
 
 The ``reply_channel`` attribute you've seen before is our unique pointer to the
 open WebSocket - because it varies between different clients, it's how we can
-keep track of "who" a message is from. Remember, Channels is network-trasparent
+keep track of "who" a message is from. Remember, Channels is network-transparent
 and can run on multiple workers, so you can't just store things locally in
 global variables or similar.
 
@@ -384,7 +384,7 @@ Django session ID as part of the URL, like this::
 
 You can get the current session key in a template with ``{{ request.session.session_key }}``.
 Note that Channels can't work with signed cookie sessions - since only HTTP
-responses can set cookies, it needs a backend it can write to to separately to
+responses can set cookies, it needs a backend it can write to to separately
 store state.
 
 
@@ -484,7 +484,7 @@ whereas you'd naturally expect ``receive`` to run after ``connect``.
 But, of course, Channels has a solution - the ``linearize`` decorator. Any
 handler decorated with this will use locking to ensure it does not run at the
 same time as any other view with ``linearize`` **on messages with the same reply channel**.
-That means your site will happily mutitask with lots of different people's messages,
+That means your site will happily multitask with lots of different people's messages,
 but if two happen to try to run at the same time for the same client, they'll
 be deconflicted.
 

docs/installation.rst

@@ -21,8 +21,8 @@ That's it! Once enabled, ``channels`` will integrate itself into Django and
 take control of the ``runserver`` command. See :doc:`getting-started` for more.
 
 
-Installing the lastest development version
-------------------------------------------
+Installing the latest development version
+-----------------------------------------
 
 To install the latest version of Channels, clone the repo, change to the repo,
 change to the repo directory, and pip install it into your current virtual

docs/message-standards.rst

@@ -15,7 +15,7 @@ the received data (or something else based on ``reply_channel``).
 
 All messages must be able to be encoded as JSON; channel backends don't
 necessarily have to use JSON, but we consider it the lowest common denominator
-for serialisation format compatability.
+for serialisation format compatibility.
 
 The size limit on messages is 1MB (while channel backends may support larger
 sizes, all message formats should stay under this limit, which might include

docs/releases/0.8.rst

@@ -13,7 +13,7 @@ more efficient and user friendly:
   added to allow moving the user details from the HTTP session to the channel session in the ``connect`` consumer.
 
 * A ``@linearize`` decorator was added to help ensure a ``connect``/``receive`` pair are not executed
-  simultanously on two different workers.
+  simultaneously on two different workers.
 
 * Channel backends gained locking mechanisms to support the ``linearize`` feature.
 

docs/scaling.rst

@@ -1,7 +1,7 @@
 Scaling
 =======
 
-Of course, one of the downsides of introducing a channel layer to Django it
+Of course, one of the downsides of introducing a channel layer to Django is
 that it's something else that must scale. Scaling traditional Django as a
 WSGI application is easy - you just add more servers and a loadbalancer. Your
 database is likely to be the thing that stopped scaling before, and there's