Merge branch '6.4' into 7.3

* 6.4:
  Simplify some wording to make docs more approachable

bundles/best_practices.rst

@@ -204,7 +204,7 @@ A bundle should at least test:
 * All supported major Symfony versions (e.g. both ``6.4`` and ``7.x`` if
   support is claimed for both).
 
-Thus, a bundle supporting PHP 7.4, 8.3 and 8.4, and Symfony 6.4 and 7.x should
+Therefore, a bundle supporting PHP 7.4, 8.3 and 8.4, and Symfony 6.4 and 7.x should
 have at least this test matrix:
 
 ===========  ===============  ===================

components/dependency_injection.rst

@@ -194,7 +194,7 @@ These are all the possible behaviors:
 Avoiding your Code Becoming Dependent on the Container
 ------------------------------------------------------
 
-Whilst you can retrieve services from the container directly it is best
+While you can retrieve services from the container directly it is best
 to minimize this. For example, in the ``NewsletterManager`` you injected
 the ``mailer`` service in rather than asking for it from the container.
 You could have injected the container in and retrieved the ``mailer`` service

components/dependency_injection/compilation.rst

@@ -533,7 +533,7 @@ way further optimizes how the services are created by the container.
 In the above example you will need to delete the cached container file whenever
 you make any changes. Adding a check for a variable that determines if you
 are in debug mode allows you to keep the speed of the cached container in
-production but getting an up to date configuration whilst developing your
+production but getting an up to date configuration while developing your
 application::
 
     // ...

components/messenger.rst

@@ -178,8 +178,8 @@ Here are some important envelope stamps that are shipped with the Symfony Messen
     :class:`Symfony\\Component\\Messenger\\Transport\\Serialization\\Normalizer\\FlattenExceptionNormalizer`
     which helps error reporting in the Messenger context.
 
-Instead of dealing directly with the messages in the middleware you receive the envelope.
-Hence you can inspect the envelope content and its stamps, or add any::
+Instead of dealing directly with the messages in the middleware, you receive the envelope.
+Therefore, you can inspect the envelope content and its stamps, or add any::
 
     use App\Message\Stamp\AnotherStamp;
     use Symfony\Component\Messenger\Envelope;

components/process.rst

@@ -263,7 +263,7 @@ are done doing other stuff::
     after the request is sent, but to use a job queue instead.
 
 :method:`Symfony\\Component\\Process\\Process::wait` takes one optional argument:
-a callback that is called repeatedly whilst the process is still running, passing
+a callback that is called repeatedly while the process is still running, passing
 in the output and its type::
 
     $process = new Process(['ls', '-lsa']);

components/var_dumper.rst

@@ -238,7 +238,7 @@ Choosing between both is mostly a matter of personal taste, still:
 * ``{% dump foo.bar %}`` is the way to go when the original template output
   shall not be modified: variables are not dumped inline, but in the web
   debug toolbar;
-* on the contrary, ``{{ dump(foo.bar) }}`` dumps inline and thus may or not
+* on the contrary, ``{{ dump(foo.bar) }}`` dumps inline and may or not
   be suited to your use case (e.g. you shouldn't use it in an HTML
   attribute or a ``<script>`` tag).
 

create_framework/http_kernel_controller_resolver.rst

@@ -2,7 +2,7 @@ The HttpKernel Component: the Controller Resolver
 =================================================
 
 You might think that our framework is already pretty solid and you are
-probably right. But let's see how we can improve it nonetheless.
+probably right. But it can still be improved.
 
 Right now, all our examples use procedural code, but remember that controllers
 can be any valid PHP callbacks. Let's convert our controller to a proper

create_framework/unit_testing.rst

@@ -1,8 +1,8 @@
 Unit Testing
 ============
 
-You might have noticed some subtle but nonetheless important bugs in the
-framework we built in the previous chapter. When creating a framework, you
+You might have noticed some subtle but important bugs in the framework built in
+the previous chapter. When creating a framework, you
 must be sure that it behaves as advertised. If not, all the applications based
 on it will exhibit the same bugs. The good news is that whenever you fix a
 bug, you are fixing a bunch of applications too.

frontend/encore/faq.rst

@@ -179,7 +179,7 @@ locally or on your Continuous Integration server:
     ("Could not find the entrypoints file from Webpack:
     the file "/var/www/html/public/build/entrypoints.json" does not exist.
 
-This is happening because you did not build your Encore assets, hence no
+This is happening because you did not build your Encore assets, so there is no
 ``entrypoints.json`` file. To solve this error, either build Encore assets or
 set the ``strict_mode`` option to ``false`` (this prevents Encore's Twig
 functions to trigger exceptions when there's no ``entrypoints.json`` file):

messenger.rst

@@ -1674,7 +1674,7 @@ your Envelope::
     the ``messenger:stop-workers`` command inefficient, as they all rely on the fact that
     the receiver returns immediately no matter if it finds a message or not. The consume
     worker is responsible for iterating until it receives a message to handle and/or until one
-    of the stop conditions is reached. Thus, the worker's stop logic cannot be reached if it
+    of the stop conditions is reached. Therefore, the worker's stop logic cannot be reached if it
     is stuck in a blocking call.
 
 .. tip::
@@ -2498,7 +2498,7 @@ handler is registered. The ``HandleTrait`` can be used in any class that has a
         }
     }
 
-Hence, you can use the trait to create command & query bus classes.
+Therefore, you can use the trait to create command & query bus classes.
 For example, you could create a special ``QueryBus`` class and inject it
 wherever you need a query bus behavior instead of the ``MessageBusInterface``::
 

migration.rst

@@ -318,7 +318,7 @@ somewhat like this::
          * architecture of the legacy code and how it's executed.
          *
          * If your mapping is complicated, you may want to write unit tests
-         * to verify your logic, hence this is public static.
+         * to verify your logic, so this method is public static.
          */
         public static function getLegacyScript(Request $request): string
         {

validation/severity.rst

@@ -5,7 +5,7 @@ Sometimes, you may want to display constraint validation error messages differen
 based on some rules. For example, you have a registration form for new users
 where they enter some personal information and choose their authentication
 credentials. They would have to choose a username and a secure password,
-but providing bank account information would be optional. Nonetheless, you
+but providing bank account information would be optional. However, you
 want to make sure that these optional fields, if entered, are still valid,
 but display their errors differently.