Fixes typos. Thanks to John Chandler

Changelog

@@ -34,7 +34,7 @@ Important Notes
 
     The default backend is now a dummy backend
     (:class:`celery.backends.base.DisabledBackend`).  Saving state is simply an
-    noop operation, and AsyncResult.wait(), .result, .state, etc will raise
+    noop operation, and AsyncResult.wait(), .result, .state, etc. will raise
     a :exc:`NotImplementedError` telling the user to configure the result backend.
 
     For help choosing a backend please see :ref:`task-result-backends`.
@@ -49,7 +49,7 @@ Important Notes
         For django-celery users the default backend is still ``database``,
         and results are not disabled by default.
 
-* The debian init scripts have been deprecated in favor of the generic-init.d
+* The Debian init scripts have been deprecated in favor of the generic-init.d
   init scripts.
 
     In addition generic init scripts for celerybeat and celeryev has been
@@ -147,7 +147,7 @@ News
     The old names are still supported but pending deprecation.
 
 * PyPy: The default pool implementation used is now multiprocessing
-  if running on pypy 1.5.
+  if running on PyPy 1.5.
 
 * celeryd-multi: now supports "pass through" options.
 
@@ -193,7 +193,7 @@ News
   has been renamed to ``callback`` and ``errback`` and take a single scalar
   value instead of a list.
 
-* No longer propagates errors occuring during process cleanup (Issue #365)
+* No longer propagates errors occurring during process cleanup (Issue #365)
 
 * Added ``TaskSetResult.delete()``, which will delete a previously
   saved taskset result.
@@ -231,7 +231,7 @@ Fixes
 * ``CELERY_TASK_ERROR_WHITE_LIST`` is now properly initialized
   in all loaders.
 
-* celeryd_detach now passes thorugh commandline configuration.
+* celeryd_detach now passes through command-line configuration.
 
 * Remote control command ``add_consumer`` now does nothing if the
   queue is already being consumed from.

docs/userguide/tasks.rst

@@ -143,7 +143,7 @@ Using a custom retry delay
 
 When a task is to be retried, it will wait for a given amount of time
 before doing so. The default delay is in the
-:attr:`~celery.task.base.BaseTask.default_retry_delay` 
+:attr:`~celery.task.base.BaseTask.default_retry_delay`
 attribute on the task. By default this is set to 3 minutes. Note that the
 unit for setting the delay is in seconds (int or float).
 
@@ -209,7 +209,7 @@ General
     a given period of time is the task allowed to run.
 
     If this is :const:`None` no rate limit is in effect.
-    If it is an integer, it is interpreted as "tasks per second". 
+    If it is an integer, it is interpreted as "tasks per second".
 
     The rate limits can be specified in seconds, minutes or hours
     by appending `"/s"`, `"/m"` or `"/h"` to the value.
@@ -411,7 +411,7 @@ This is also the case if using Django and using `project.myapp`::
 
     INSTALLED_APPS = ("project.myapp", )
 
-The worker will have the tasks registered as "project.myapp.tasks.*", 
+The worker will have the tasks registered as "project.myapp.tasks.*",
 while this is what happens in the client if the module is imported as
 "myapp.tasks":
 
@@ -461,7 +461,7 @@ result of a successful task, or the exception and traceback information of a
 failed task.
 
 There are several *result backends* to choose from, and they all have
-different strenghts and weaknesses (see :ref:`task-result-backends`).
+different strengths and weaknesses (see :ref:`task-result-backends`).
 
 During its lifetime a task will transition through several possible states,
 and each state may have arbitrary metadata attached to it.  When a task
@@ -490,7 +490,7 @@ built-in backends to choose from: SQLAlchemy/Django ORM, Memcached, Redis,
 AMQP, MongoDB, Tokyo Tyrant and Redis -- or you can define your own.
 
 No backend works well for every use case.
-You should read about the strenghts and weaknesses of each backend, and choose
+You should read about the strengths and weaknesses of each backend, and choose
 the most appropriate for your needs.
 
 
@@ -549,7 +549,7 @@ limitations.
 
   In MySQL the default transaction isolation level is `REPEATABLE-READ`, which
   means the transaction will not see changes by other transactions until the
-  transaction is commited.  It is recommended that you change to the
+  transaction is committed.  It is recommended that you change to the
   `READ-COMMITTED` isolation level.