acknowledgment (US) not acknowledgEment

celery/result.py

@@ -654,7 +654,7 @@ class ResultSet(ResultBase):
                            ``result = app.AsyncResult(task_id)`` (both will
                            take advantage of the backend cache anyway).
 
-        :keyword no_ack: Automatic message acknowledgement (Note that if this
+        :keyword no_ack: Automatic message acknowledgment (Note that if this
             is set to :const:`False` then the messages *will not be
             acknowledged*).
 

docs/faq.rst

@@ -807,7 +807,7 @@ scenario of course, but you can probably imagine something far more
 sinister. So for ease of programming we have less reliability;
 It's a good default, users who require it and know what they
 are doing can still enable acks_late (and in the future hopefully
-use manual acknowledgement).
+use manual acknowledgment).
 
 In addition `Task.retry` has features not available in AMQP
 transactions: delay between retries, max retries, etc.

docs/history/changelog-1.0.rst

@@ -1300,7 +1300,7 @@ News
     the task has an ETA (estimated time of arrival). Also the log message now
     includes the ETA for the task (if any).
 
-* Acknowledgement now happens in the pool callback. Can't do ack in the job
+* Acknowledgment now happens in the pool callback. Can't do ack in the job
     target, as it's not pickleable (can't share AMQP connection, etc.)).
 
 * Added note about .delay hanging in README

docs/sec/CELERYSA-0002.txt

@@ -34,8 +34,8 @@ Patches are now available for all maintained versions (see below),
 and users are urged to upgrade, even if not directly
 affected.
 
-Acknowledgements
-================
+Acknowledgments
+===============
 
 Special thanks to Red Hat for originally discovering and reporting the issue.
 

docs/userguide/optimizing.rst

@@ -180,7 +180,7 @@ The task message is only deleted from the queue after the task is
 :term:`acknowledged`, so if the worker crashes before acknowleding the task,
 it can be redelivered to another worker (or the same after recovery).
 
-When using the default of early acknowledgement, having a prefetch multiplier setting
+When using the default of early acknowledgment, having a prefetch multiplier setting
 of 1, means the worker will reserve at most one extra task for every
 worker process: or in other words, if the worker is started with `-c 10`,
 the worker may reserve at most 20 tasks (10 unacknowledged tasks executing, and 10