infos -> information

Async.rst

@@ -23,13 +23,10 @@ the ``--async <n>`` option
 
 Currently the uWSGI distribution includes the following suspend/resume engines:
 
-``uGreen`` Unbit greenthreads implementation (based on swapcontext() )
-
-``Greenlet`` Python greenlet module
-
-``Stackless`` Stackless python
-
-``Fiber`` Ruby 1.9 fibers
+* ``uGreen`` - Unbit's greenthread implementation (based on `swapcontext()`)
+* ``Greenlet`` - Python greenlet module
+* ``Stackless`` Stackless Åython
+* ``Fiber`` - Ruby 1.9 fibers
 
 Running the uWSGI async mode without a proper suspend/resume engine will raise a warning, so for a minimal non-blocking app
 you will need something like that:
@@ -39,8 +36,8 @@ you will need something like that:
    uwsgi --async 100 --ugreen --socket :3031
 
 An important aspect of suspend/resume engines is that they can easily destroy your process if it is not aware of them.
-Some of the language plugins (most-notably python) has hooks to cooperate flawlessly with coroutine/greenthreads. Other languages
-may fail miserably. Always check the uWSGI mailinglist or irc channel for updated infos.
+Some of the language plugins (most notably Python) has hooks to cooperate flawlessly with coroutine/greenthreads. Other languages
+may fail miserably. Always check the uWSGI mailing list or IRC channel for updated information.
 
 Older uWSGI releases supported an additional system: callbacks.
 

Changelog-1.9.7.rst

@@ -139,7 +139,7 @@ For example you can monitor (and throw an alarm) when your cgroup is running the
 in this example CGROUP_OOM_FD is an environment variable mapping to the number of an eventfd() filedescriptor inherited from some kind
 of startup script. Maybe (in the near future) we could be able to directly define this kind of monitor directly in uWSGI.
 
-More infos on the eventfd() + cgroup integration are here: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
+More information on the eventfd() + cgroup integration are here: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
 
 an example perl startup script:
 

Changelog-1.9.rst

@@ -244,7 +244,7 @@ As well as the request body language-independent management, an exception manage
 
 Currently supported only in the Python and Ruby plugins, allows language-independent handling of exceptions cases (like reloading on a specific exception).
 
-The --catch-exception option has been improved to show lot of useful infos. Just try it (in development !!!)
+The --catch-exception option has been improved to show lot of useful information. Just try it (in development !!!)
 
 Future development will allow automatic sending of exception to system like Sentry or Airbrake.
 

Emperor.rst

@@ -99,7 +99,7 @@ On demand vassals (socket activation)
 -------------------------------------
 
 Inspired by the venerable xinetd/inetd approach, you can spawn your vassals only after the first connection
-to a specific socket. This feature is available since 1.9.1, check its changelog for more infos: 
+to a specific socket. This feature is available since 1.9.1, check its changelog for more information: 
 
 :doc:`Changelog-1.9.1`
 

InternalRouting.rst

@@ -161,7 +161,7 @@ base64, encode the specified var in base64
 
 hex, encode the specified var in hex
 
-uwsgi, return internal uWSGI infos, uwsgi[wid] and uwsgi[pid] are currently supported
+uwsgi, return internal uWSGI information, uwsgi[wid] and uwsgi[pid] are currently supported
 
 
 Is not --route-if enough ? Why --route-uri and friends ?

JVM.rst

@@ -16,7 +16,7 @@ Building the JVM support
 First of all, be sure to have a full JDK distibution installed.
 
 The uWSGI build system will try to detect common JDK setup (debian,ubuntu,centos, OSX...), but if it is not able
-to find a JDK installation it will need infos from the user (see below).
+to find a JDK installation it will need information from the user (see below).
 
 To build the JVM plugin simply run:
 

Legion.rst

@@ -239,7 +239,7 @@ Obviously more api functions will be added in the future, feel free to expose yo
 Stats
 *****
 
-The Legion infos are exported in the :doc:`StatsServer`
+The Legion information are exported in the :doc:`StatsServer`
 
 Be sure to understand the difference between "nodes" and "members". Nodes are the peer you configure with the **legion-node** option
 while members are the effective nodes that joined the cluster.

Ring.rst

@@ -24,7 +24,7 @@ java-1.6.0-openjdk.x86_64-devel or java-1.7.0-openjdk-devel.x86_64 or on debian/
 
 OSX/X-Code default paths are searched too.
 
-For more infos on the JVM plugin check :doc:`JVM`
+For more information on the JVM plugin check :doc:`JVM`
 
 After a successfull build you will have the uwsgi binary and a uwsgi.jar file that you should copy in your CLASSPATH (or just remember
 to set it in the uwsgi configuration everytime).

WSGIquickstart.rst

@@ -106,7 +106,7 @@ The stats subsystem allows you to export uWSGI internal statistics via json
 
    uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
 
-make some request to your app and then telnet to the port 9191. You will get lot of funny infos.
+make some request to your app and then telnet to the port 9191. You will get lot of funny information.
 
 There is a top-like tool for monitoring instances, named 'uwsgitop' (just pip install it)
 

tutorials/heroku_python.rst

@@ -104,7 +104,7 @@ Following push will be much faster.
 Checking your app
 *****************
 
-Running ``heroku logs`` you will be able to access uWSGI logs. You should get all of your familiar infos, and eventually
+Running ``heroku logs`` you will be able to access uWSGI logs. You should get all of your familiar information, and eventually
 some hint in case of problems.
 
 Using another version of python