Style / grammar fixes for the configuration chapter

Author: frne

cookbook/configuration/apache_router.rst

@@ -133,7 +133,7 @@ You're now all set to use Apache routes.
 Additional Tweaks
 -----------------
 
-To save a little bit of processing time, change occurrences of ``Request``
+To save some processing time, change occurrences of ``Request``
 to ``ApacheRequest`` in ``web/app.php``::
 
     // web/app.php

cookbook/configuration/environments.rst

@@ -6,7 +6,7 @@ How to Master and Create new Environments
 
 Every application is the combination of code and a set of configuration that
 dictates how that code should function. The configuration may define the
-database being used, whether or not something should be cached, or how verbose
+database being used, whether something should be cached, or how verbose
 logging should be. In Symfony, the idea of "environments" is the idea that
 the same codebase can be run using multiple different configurations. For
 example, the ``dev`` environment should use configuration that makes development
@@ -170,10 +170,10 @@ this code and changing the environment string.
 
     Important, but unrelated to the topic of *environments* is the ``false``
     argument as the second argument to the ``AppKernel`` constructor. This
-    specifies whether or not the application should run in "debug mode". Regardless
+    specifies if the application should run in "debug mode". Regardless
     of the environment, a Symfony application can be run with debug mode
     set to ``true`` or ``false``. This affects many things in the application,
-    such as whether or not errors should be displayed or if cache files are
+    such as if errors should be displayed or if cache files are
     dynamically rebuilt on each request. Though not a requirement, debug mode
     is generally set to ``true`` for the ``dev`` and ``test`` environments
     and ``false`` for the ``prod`` environment.
@@ -322,7 +322,7 @@ The new environment is now accessible via::
 .. note::
 
     Some environments, like the ``dev`` environment, are never meant to be
-    accessed on any deployed server by the general public. This is because
+    accessed on any deployed server by the public. This is because
     certain environments, for debugging purposes, may give too much information
     about the application or underlying infrastructure. To be sure these environments
     aren't accessible, the front controller is usually protected from external

cookbook/configuration/front_controllers_and_kernel.rst

@@ -39,7 +39,7 @@ The main purpose of the front controller is to create an instance of the
 and return the resulting response to the browser.
 
 Because every request is routed through it, the front controller can be
-used to perform global initializations prior to setting up the kernel or
+used to perform global initialization prior to setting up the kernel or
 to `decorate`_ the kernel with additional features. Examples include:
 
 * Configuring the autoloader or adding additional autoloading mechanisms;

cookbook/configuration/pdo_session_storage.rst

@@ -7,7 +7,7 @@ How to Use PdoSessionHandler to Store Sessions in the Database
 The default Symfony session storage writes the session information to files.
 Most medium to large websites use a database to store the session values
 instead of files, because databases are easier to use and scale in a
-multi-webserver environment.
+multi webserver environment.
 
 Symfony has a built-in solution for database session storage called
 :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\PdoSessionHandler`.
@@ -16,7 +16,7 @@ To use it, you just need to change some parameters in the main configuration fil
 .. versionadded:: 2.1
     In Symfony 2.1 the class and namespace are slightly modified. You can now
     find the session storage classes in the ``Session\Storage`` namespace:
-    ``Symfony\Component\HttpFoundation\Session\Storage``. Also
+    ``Symfony\Component\HttpFoundation\Session\Storage``. Also,
     note that in Symfony 2.1 you should configure ``handler_id`` not ``storage_id`` like in Symfony 2.0.
     Below, you'll notice that ``%session.storage.options%`` is not used anymore.
 

cookbook/configuration/using_parameters_in_dic.rst

@@ -9,7 +9,7 @@ You have seen how to use configuration parameters within
 There are special cases such as when you want, for instance, to use the
 ``%kernel.debug%`` parameter to make the services in your bundle enter
 debug mode. For this case there is more work to do in order
-to make the system understand the parameter value. By default
+to make the system understand the parameter value. By default,
 your parameter ``%kernel.debug%`` will be treated as a
 simple string. Consider the following example::