Merge branch '4.4' into 5.1

* 4.4:
  Update some terminology based on AlexJS reports

Author: wouterj

.alexrc

@@ -0,0 +1,16 @@
+{
+  "allow": [
+      "attack",
+      "attacks",
+      "bigger",
+      "color",
+      "colors",
+      "failure",
+      "hook",
+      "hooks",
+      "host-hostess",
+      "invalid",
+      "remain",
+      "special"
+  ]
+}

bundles.rst

@@ -45,9 +45,9 @@ Creating a Bundle
 -----------------
 
 This section creates and enables a new bundle to show there are only a few steps required.
-The new bundle is called AcmeTestBundle, where the ``Acme`` portion is just a
-dummy name that should be replaced by some "vendor" name that represents you or
-your organization (e.g. ABCTestBundle for some company named ``ABC``).
+The new bundle is called AcmeTestBundle, where the ``Acme`` portion is a dummy
+name that should be replaced by some "vendor" name that represents you or your
+organization (e.g. ABCTestBundle for some company named ``ABC``).
 
 Start by creating a ``src/Acme/TestBundle/`` directory and adding a new file
 called ``AcmeTestBundle.php``::

configuration.rst

@@ -351,7 +351,7 @@ a new ``locale`` parameter is added to the ``config/services.yaml`` file).
 Configuration Environments
 --------------------------
 
-You have just one application, but whether you realize it or not, you need it
+You have only one application, but whether you realize it or not, you need it
 to behave differently at different times:
 
 * While **developing**, you want to log everything and expose nice debugging tools;

configuration/dot-env-changes.rst

@@ -20,8 +20,8 @@ important changes:
 
 * B) The ``.env`` file **is** now committed to your repository. It was previously ignored
   via the ``.gitignore`` file (the updated recipe does not ignore this file). Because
-  this file is committed, it should contain non-sensitive, default values. Basically,
-  the ``.env.dist`` file was moved to ``.env``.
+  this file is committed, it should contain non-sensitive, default values. The
+  ``.env`` can be seen as the previous ``.env.dist`` file.
 
 * C) A ``.env.local`` file can now be created to *override* values in ``.env`` for
   your machine. This file is ignored in the new ``.gitignore``.

configuration/front_controllers_and_kernel.rst

@@ -30,7 +30,7 @@ The `front controller`_ is a design pattern; it is a section of code that *all*
 requests served by an application run through.
 
 In the Symfony Skeleton, this role is taken by the ``index.php`` file in the
-``public/`` directory. This is the very first PHP script executed when a
+``public/`` directory. This is the very first PHP script that is run when a
 request is processed.
 
 The main purpose of the front controller is to create an instance of the

configuration/micro_kernel_trait.rst

@@ -20,7 +20,7 @@ via Composer:
       symfony/http-foundation symfony/routing \
       symfony/dependency-injection symfony/framework-bundle
 
-Next, create an ``index.php`` file that defines the kernel class and executes it::
+Next, create an ``index.php`` file that defines the kernel class and runs it::
 
     // index.php
     use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;

configuration/multiple_kernels.rst

@@ -16,8 +16,8 @@ request to generate the response.
 
 This single kernel approach is a convenient default, but Symfony applications
 can define any number of kernels. Whereas
-:ref:`environments <configuration-environments>` execute the same application
-with different configurations, kernels can execute different parts of the same
+:ref:`environments <configuration-environments>` run the same application with
+different configurations, kernels can run different parts of the same
 application.
 
 These are some of the common use cases for creating multiple kernels:
@@ -123,7 +123,7 @@ Finally, define the configuration files that the new ``ApiKernel`` will load.
 According to the above code, this config will live in one or multiple files
 stored in ``config/api/`` and ``config/api/ENVIRONMENT_NAME/`` directories.
 
-The new configuration files can be created from scratch when you load just a few
+The new configuration files can be created from scratch when you load only a few
 bundles, because it will be small. Otherwise, duplicate the existing
 config files in ``config/packages/`` or better, import them and override the
 needed options.
@@ -133,13 +133,12 @@ Executing Commands with a Different Kernel
 
 The ``bin/console`` script used to run Symfony commands always uses the default
 ``Kernel`` class to build the application and load the commands. If you need
-to execute console commands using the new kernel, duplicate the ``bin/console``
+to run console commands using the new kernel, duplicate the ``bin/console``
 script and rename it (e.g. ``bin/api``).
 
 Then, replace the ``Kernel`` instance by your own kernel instance
-(e.g. ``ApiKernel``) and now you can execute commands using the new kernel
-(e.g. ``php bin/api cache:clear``) Now you can use execute commands using the
-new kernel.
+(e.g. ``ApiKernel``). Now you can run commands using the new kernel
+(e.g. ``php bin/api cache:clear``).
 
 .. note::
 

configuration/using_parameters_in_dic.rst

@@ -10,8 +10,8 @@ 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,
-your parameter ``%kernel.debug%`` will be treated as a
-simple string. Consider the following example::
+your parameter ``%kernel.debug%`` will be treated as a string. Consider the
+following example::
 
     // inside Configuration class
     $rootNode

console.rst

@@ -127,7 +127,7 @@ this is already done for you, thanks to :ref:`autoconfiguration <services-autoco
 Executing the Command
 ---------------------
 
-After configuring and registering the command, you can execute it in the terminal:
+After configuring and registering the command, you can run it in the terminal:
 
 .. code-block:: terminal
 

console/calling_commands.rst

@@ -1,12 +1,12 @@
 How to Call Other Commands
 ==========================
 
-If a command depends on another one being run before it, instead of asking the
-user to remember the order of execution, you can call it directly yourself.
-This is also useful if you want to create a "meta" command that just runs a
-bunch of other commands (for instance, all commands that need to be run when
-the project's code has changed on the production servers: clearing the cache,
-generating Doctrine2 proxies, dumping web assets, ...).
+If a command depends on another one being run before it you can call in the
+console command itself. This is useful if a command depends on another command
+or if you want to create a "meta" command that runs a bunch of other commands
+(for instance, all commands that need to be run when the project's code has
+changed on the production servers: clearing the cache, generating Doctrine
+proxies, dumping web assets, ...).
 
 Calling a command from another one is straightforward::
 
@@ -31,13 +31,13 @@ Calling a command from another one is straightforward::
     }
 
 First, you :method:`Symfony\\Component\\Console\\Application::find` the
-command you want to execute by passing the command name. Then, you need to create
+command you want to run by passing the command name. Then, you need to create
 a new :class:`Symfony\\Component\\Console\\Input\\ArrayInput` with the arguments
 and options you want to pass to the command.
 
-Eventually, calling the ``run()`` method actually executes the command and
-returns the returned code from the command (return value from command's
-``execute()`` method).
+Eventually, calling the ``run()`` method actually runs the command and returns
+the returned code from the command (return value from command's ``execute()``
+method).
 
 .. tip::