minor #14215 Update some terminology based on AlexJS reports (wouterj)

This PR was merged into the 4.4 branch.

Discussion
----------

Update some terminology based on AlexJS reports

This PR replaces some insensitive/inconsiderate terminology based on [AlexJS](https://alexjs.com/) reports. It's very much subjective, I've not fixed all things AlexJS provided and even AlexJS (while based on official sources) implements some sort of subjective list of words to be considered insensitive/inconsiderate.

99% of the changes in this PR are:

* Removing "just", "basically", "simple", "easy" as much as possible (most of the time, removing the word was enough);
* Replacing "execute" with "run" (commands) or "call" (methods/controllers/etc)

Because sometimes AlexJS reports words that are fine in that context (and AlexJS has some trouble understanding rst syntax), I don't think we can run AlexJS as part of our GitHub actions. I did however commit the `.alexjsrc` file to ease local use. For instance, I'm using Vim with [ALE](https://github.com/dense-analysis/ale). This asynchronously runs everything I type in `*.rst` or `*.md` files through Alex; commiting the Alex config makes it easier for me to spot mistakes.

cc @lsmith77 @javiereguiluz

Commits
-------

36f44c9 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

@@ -113,7 +113,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::
 

console/command_in_controller.rst

@@ -8,11 +8,11 @@ The :doc:`Console component documentation </components/console>` covers how to
 create a console command. This article covers how to use a console command
 directly from your controller.
 
-You may have the need to execute some function that is only available in a
-console command. Usually, you should refactor the command and move some logic
-into a service that can be reused in the controller. However, when the command
-is part of a third-party library, you wouldn't want to modify or duplicate
-their code. Instead, you can execute the command directly.
+You may have the need to call some function that is only available in a console
+command. Usually, you should refactor the command and move some logic into a
+service that can be reused in the controller. However, when the command is part
+of a third-party library, you don't want to modify or duplicate their code.
+Instead, you can run the command directly from the controller.
 
 .. caution::
 

console/commands_as_services.rst

@@ -52,8 +52,9 @@ For example, suppose you want to log something from within your command::
 
 If you're using the :ref:`default services.yaml configuration <service-container-services-load-example>`,
 the command class will automatically be registered as a service and passed the ``$logger``
-argument (thanks to autowiring). In other words, *just* by creating this class, everything
-works! You can call the ``app:sunshine`` command and start logging.
+argument (thanks to autowiring). In other words, you only need to create this
+class and everything works automatically! You can call the ``app:sunshine``
+command and start logging.
 
 .. caution::
 

console/hide_commands.rst

@@ -4,9 +4,9 @@ How to Hide Console Commands
 By default, all console commands are listed when executing the console application
 script without arguments or when using the ``list`` command.
 
-However, sometimes commands are not intended to be executed by end-users; for
+However, sometimes commands are not intended to be run by end-users; for
 example, commands for the legacy parts of the application, commands exclusively
-executed through scheduled tasks, etc.
+run through scheduled tasks, etc.
 
 In those cases, you can define the command as **hidden** by setting the
 ``setHidden()`` method to ``true`` in the command configuration::

console/input.rst

@@ -184,13 +184,13 @@ flag:
         ;
 
 Note that to comply with the `docopt standard`_, long options can specify their
-values after a white space or an ``=`` sign (e.g. ``--iterations 5`` or
-``--iterations=5``), but short options can only use white spaces or no
+values after a whitespace or an ``=`` sign (e.g. ``--iterations 5`` or
+``--iterations=5``), but short options can only use whitespaces or no
 separation at all (e.g. ``-i 5`` or ``-i5``).
 
 .. caution::
 
-    While it is possible to separate an option from its value with a white space,
+    While it is possible to separate an option from its value with a whitespace,
     using this form leads to an ambiguity should the option appear before the
     command name. For example, ``php bin/console --iterations 5 app:greet Fabien``
     is ambiguous; Symfony would interpret ``5`` as the command name. To avoid

console/lockable_trait.rst

@@ -1,9 +1,9 @@
-Prevent Multiple Executions of a Console Command
-================================================
+Prevent Running the Same Console Command Multiple Times
+=======================================================
 
-A simple but effective way to prevent multiple executions of the same command in
-a single server is to use `locks`_. The :doc:`Lock component </components/lock>`
-provides multiple classes to create locks based on the filesystem (:ref:`FlockStore <lock-store-flock>`),
+You can use `locks`_ to prevent the same command from running multiple times on
+the same server. The :doc:`Lock component </components/lock>` provides multiple
+classes to create locks based on the filesystem (:ref:`FlockStore <lock-store-flock>`),
 shared memory (:ref:`SemaphoreStore <lock-store-semaphore>`) and even databases
 and Redis servers.
 

controller.rst

@@ -7,7 +7,7 @@ Controller
 A controller is a PHP function you create that reads information from the
 ``Request`` object and creates and returns a ``Response`` object. The response could
 be an HTML page, JSON, XML, a file download, a redirect, a 404 error or anything
-else. The controller executes whatever arbitrary logic *your application* needs
+else. The controller runs whatever arbitrary logic *your application* needs
 to render the content of a page.
 
 .. tip::
@@ -16,9 +16,9 @@ to render the content of a page.
     :doc:`/page_creation` and then come back!
 
 .. index::
-   single: Controller; Simple example
+   single: Controller; Basic example
 
-A Simple Controller
+A Basic Controller
 -------------------
 
 While a controller can be any PHP callable (function, method on an object,

controller/argument_value_resolver.rst

@@ -137,7 +137,7 @@ and defining a service for it. The interface defines two methods:
 
 ``supports()``
     This method is used to check whether the value resolver supports the
-    given argument. ``resolve()`` will only be executed when this returns ``true``.
+    given argument. ``resolve()`` will only be called when this returns ``true``.
 ``resolve()``
     This method will resolve the actual value for the argument. Once the value
     is resolved, you must `yield`_ the value to the ``ArgumentResolver``.

controller/error_pages.rst

@@ -6,8 +6,8 @@ How to Customize Error Pages
 ============================
 
 In Symfony applications, all errors are treated as exceptions, no matter if they
-are just a 404 Not Found error or a fatal error triggered by throwing some
-exception in your code.
+are a 404 Not Found error or a fatal error triggered by throwing some exception
+in your code.
 
 In the :ref:`development environment <configuration-environments>`,
 Symfony catches all the exceptions and displays a special **exception page**
@@ -19,7 +19,7 @@ with lots of debug information to help you discover the root problem:
    :class: with-browser
 
 Since these pages contain a lot of sensitive internal information, Symfony won't
-display them in the production environment. Instead, it'll show a simple and
+display them in the production environment. Instead, it'll show a minimal and
 generic **error page**:
 
 .. image:: /_images/controller/error_pages/errors-in-prod-environment.png
@@ -30,7 +30,7 @@ generic **error page**:
 Error pages for the production environment can be customized in different ways
 depending on your needs:
 
-#. If you just want to change the contents and styles of the error pages to match
+#. If you only want to change the contents and styles of the error pages to match
    the rest of your application, :ref:`override the default error templates <use-default-error-controller>`;
 
 #. If you want to change the contents of non-HTML error output,
@@ -39,7 +39,7 @@ depending on your needs:
 #. If you also want to tweak the logic used by Symfony to generate error pages,
    :ref:`override the default error controller <custom-error-controller>`;
 
-#. If you need total control of exception handling to execute your own logic
+#. If you need total control of exception handling to run your own logic
    :ref:`use the kernel.exception event <use-kernel-exception-event>`.
 
 .. _use-default-error-controller:

controller/forwarding.rst

@@ -34,5 +34,5 @@ The target controller method might look something like this::
         // ... create and return a Response object
     }
 
-Just like when creating a controller for a route, the order of the arguments
-of the ``fancy()`` method doesn't matter: the matching is done by name.
+Like when creating a controller for a route, the order of the arguments of the
+``fancy()`` method doesn't matter: the matching is done by name.

deployment.rst

@@ -128,7 +128,7 @@ While developing locally, you'll usually store these in ``.env`` and ``.env.loca
    on your setup: they can be set at the command line, in your Nginx configuration,
    or via other methods provided by your hosting service.
 
-2. Or, create a ``.env.local`` file just like your local development (see note below)
+2. Or, create a ``.env.local`` file like your local development (see note below)
 
 There is no significant advantage to either of the two options: use whatever is
 most natural in your hosting environment.

doctrine/associations.rst

@@ -15,7 +15,7 @@ There are **two** main relationship/association types:
 ``ManyToOne`` / ``OneToMany``
     The most common relationship, mapped in the database with a foreign
     key column (e.g. a ``category_id`` column on the ``product`` table). This is
-    actually just *one* association type, but seen from the two different *sides*
+    actually only *one* association type, but seen from the two different *sides*
     of the relation.
 
 ``ManyToMany``
@@ -299,7 +299,7 @@ config.
     *exactly* like an array, but has some added flexibility. Just imagine that
     it is an ``array`` and you'll be in good shape.
 
-Your database is setup! Now, execute the migrations like normal:
+Your database is setup! Now, run the migrations like normal:
 
 .. code-block:: terminal
 
@@ -374,8 +374,8 @@ Doctrine takes care of the rest when saving.
 Fetching Related Objects
 ------------------------
 
-When you need to fetch associated objects, your workflow looks just like it
-did before. First, fetch a ``$product`` object and then access its related
+When you need to fetch associated objects, your workflow looks like it did
+before. First, fetch a ``$product`` object and then access its related
 ``Category`` object::
 
     use App\Entity\Product;
@@ -395,7 +395,7 @@ did before. First, fetch a ``$product`` object and then access its related
     }
 
 In this example, you first query for a ``Product`` object based on the product's
-``id``. This issues a query for *just* the product data and hydrates the
+``id``. This issues a query to fetch *only* the product data and hydrates the
 ``$product``. Later, when you call ``$product->getCategory()->getName()``,
 Doctrine silently makes a second query to find the ``Category`` that's related
 to this ``Product``. It prepares the ``$category`` object and returns it to
@@ -493,7 +493,7 @@ This will *still* return an array of ``Product`` objects. But now, when you call
 ``$product->getCategory()`` and use that data, no second query is made.
 
 Now, you can use this method in your controller to query for a ``Product``
-object and its related ``Category`` with just one query::
+object and its related ``Category`` in one query::
 
     public function show($id)
     {

doctrine/events.rst

@@ -7,7 +7,7 @@ Doctrine Events
 `Doctrine`_, the set of PHP libraries used by Symfony to work with databases,
 provides a lightweight event system to update entities during the application
 execution. These events, called `lifecycle events`_, allow to perform tasks such
-as *"update the createdAt property automatically just before persisting entities
+as *"update the createdAt property automatically right before persisting entities
 of this type"*.
 
 Doctrine triggers events before/after performing the most common entity

doctrine/multiple_entity_managers.rst

@@ -249,7 +249,7 @@ the default entity manager (i.e. ``default``) is returned::
         }
     }
 
-You can now use Doctrine just as you did before - using the ``default`` entity
+You can now use Doctrine like you did before - using the ``default`` entity
 manager to persist and fetch entities that it manages and the ``customer``
 entity manager to persist and fetch its entities.