Fixes spotted by reviewers

Author: javiereguiluz

configuration.rst

@@ -67,9 +67,9 @@ there's not even any performance difference between them.
 YAML is used by default when installing packages because it's concise and very
 readable. These are the main advantages and disadvantages of each format:
 
-* **YAML**: simple, clean and readable, but requires using a dedicated parser.
-  :doc:`Learn the YAML syntax </components/yaml/yaml_format>`;
-* **XML**: supports IDE autocompletion/validation and is parsed natively by PHP,
+* **YAML**: simple, clean and readable, but not all IDEs support autocompletion
+  and validation for it. :doc:`Learn the YAML syntax </components/yaml/yaml_format>`;
+* **XML**:autocompleted/validated by most IDEs and is parsed natively by PHP,
   but sometimes it generates too verbose configuration. `Learn the XML syntax`_;
 * **PHP**: very powerful and it allows to create dynamic configuration, but the
   resulting configuration is less readable than the other formats.
@@ -603,23 +603,9 @@ will load the parsed file instead of parsing the ``.env`` files again:
 
 .. _configuration-env-var-web-server:
 
-Using ``.env`` files is the recommended way of using env vars in Symfony
-applications. However, you can also define env vars in the web server
-configuration if you prefer that:
-
-.. configuration-block::
-
-    .. code-block:: apache
-
-        <VirtualHost *:80>
-            # ...
-
-            SetEnv DATABASE_URL "mysql://db_user:db_password@127.0.0.1:3306/db_name"
-        </VirtualHost>
-
-    .. code-block:: nginx
-
-        fastcgi_param DATABASE_URL "mysql://db_user:db_password@127.0.0.1:3306/db_name";
+Creating ``.env`` files is the easiest way of using env vars in Symfony
+applications. However, you can also configure real env vars in your servers and
+operating systems.
 
 .. tip::
 
@@ -643,30 +629,33 @@ Managing Multiple .env Files
 The ``.env`` file defines the default values for all env vars. However, it's
 common to override some of those values depending on the environment (e.g. to
 use a different database for tests) or depending on the machine (e.g. to use a
-different OAuth token in your local machine while developing).
+different OAuth token on your local machine while developing).
 
 That's why you can define multiple ``.env`` files to override env vars. The
 following list shows the files loaded in all environments. The ``.env`` file is
-the only mandatory file and each file overrides all the previous ones:
+the only mandatory file and each file content overrides the previous one:
 
 * ``.env``: defines the default values of the env vars needed by the application;
-* ``.env.local``: overrides env vars for all environments but only in your local
-  machine;
-* ``.env.<environment>`` (e.g. ``.env.test``): overrides env vars for some
-  environment and for all machines;
-* ``.env.<environment>.local`` (e.g. ``.env.test.local``): overrides env vars
-  only for some environment and only in your local machine.
+* ``.env.local``: defines machine-specific overrides for env vars on all
+  environments. This file is not committed to the repository, so these overrides
+  only apply to the machine which contains the file (your local computer,
+  production server, etc.);
+* ``.env.<environment>`` (e.g. ``.env.test``): overrides env vars only for some
+  environment but for all machines;
+* ``.env.<environment>.local`` (e.g. ``.env.test.local``): defines machine-specific
+  env vars overrides only for some environment. It's similar to ``.env.local``,
+  but the overrides only apply to some particular environment.
 
 .. note::
 
     The real environment variables defined in the server always win over the
     env vars created by the ``.env`` files.
 
 The ``.env`` and ``.env.<environment>`` files should be committed to the shared
-repository because they are the same for all developers. However, the env files
-ending in ``.local`` (``.env.local`` and ``.env.<environment>.local``) **should
-not be committed** because only you will use them. In fact, the ``.gitignore``
-file that comes with Symfony prevents them from being committed.
+repository because they are the same for all developers and machines. However,
+the env files ending in ``.local`` (``.env.local`` and ``.env.<environment>.local``)
+**should not be committed** because only you will use them. In fact, the
+``.gitignore`` file that comes with Symfony prevents them from being committed.
 
 .. caution::
 
@@ -677,18 +666,18 @@ file that comes with Symfony prevents them from being committed.
 Accessing Configuration Values
 ------------------------------
 
-Controllers and services can access to all the configuration parameters. This
-includes both the :ref:`parameteres defined by yourself <configuration-parameters>`
+Controllers and services can access all the configuration parameters. This
+includes both the :ref:`parameters defined by yourself <configuration-parameters>`
 and the parameters created by packages/bundles. Run the following command to see
 all the parameters that exist in your application:
 
 .. code-block:: terminal
 
     $ php bin/console debug:container --parameters
 
-Parameters are injected in services as arguments of their constructors.
+Parameters are injected in services as arguments to their constructors.
 :doc:`Service autowiring </service_container/autowiring>` doesn't work for
-parameters, so you must inject them explicitly:
+parameters. Instead, inject them explicitly:
 
 .. configuration-block::
 
@@ -737,8 +726,8 @@ parameters, so you must inject them explicitly:
 If you inject the same parameters over and over again, use instead the
 ``services._defaults.bind`` option. The arguments defined in that option are
 injected automatically whenever a service constructor or controller action
-define an argument with that exact name. For example, if you want to inject the
-value of the :ref:`kernel.project_dir parameter <configuration-kernel-project-directory>`
+define an argument with that exact name. For example, to inject the value of the
+:ref:`kernel.project_dir parameter <configuration-kernel-project-directory>`
 whenever a service/controller defines a ``$projectDir`` argument, use this:
 
 .. configuration-block::
@@ -799,28 +788,25 @@ whenever a service/controller defines a ``$projectDir`` argument, use this:
 Finally, if some service needs to access to lots of parameters, instead of
 injecting each of them individually, you can inject all the application
 parameters at once by type-hinting any of its constructor arguments with the
-:class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ParameterBagInterface`
-or the new :class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ContainerBagInterface`.
-However, in these cases it's usually better to refactor the service and avoid
-requiring so many parameters::
+:class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ContainerBagInterface`::
 
     // src/Service/MessageGenerator.php
     // ...
 
-    use Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface;
+    use Symfony\Component\DependencyInjection\ParameterBag\ContainerBagInterface;
 
     class MessageGenerator
     {
         private $params;
 
-        public function __construct(ParameterBagInterface $params)
+        public function __construct(ContainerBagInterface $params)
         {
             $this->params = $params;
         }
 
         public function someMethod()
         {
-            // get any param from $this->params, which stores all container parameters
+            // get any container parameter from $this->params, which stores all of them
             $sender = $this->params->get('mailer_sender');
             // ...
         }

service_container.rst

@@ -532,7 +532,7 @@ accessor methods for parameters::
 
 .. note::
 
-    You can only set a parameter before the container is compiled: not at run-time.
+    You can only set a parameter before the container is compiled, not at run-time.
     To learn more about compiling the container see
     :doc:`/components/dependency_injection/compilation`.