diff --git a/bundles/best_practices.rst b/bundles/best_practices.rst
index 5f0259e074e..1597b5a26ee 100644
--- a/bundles/best_practices.rst
+++ b/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:
 
 ===========  ===============  ===================
diff --git a/components/dependency_injection.rst b/components/dependency_injection.rst
index d146f553a0c..29918556dcb 100644
--- a/components/dependency_injection.rst
+++ b/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
diff --git a/components/dependency_injection/compilation.rst b/components/dependency_injection/compilation.rst
index 7db22a68d5f..d0b89496c63 100644
--- a/components/dependency_injection/compilation.rst
+++ b/components/dependency_injection/compilation.rst
@@ -537,7 +537,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::
 
     // ...
diff --git a/components/messenger.rst b/components/messenger.rst
index fe3d2926714..063e5e3284b 100644
--- a/components/messenger.rst
+++ b/components/messenger.rst
@@ -183,8 +183,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;
diff --git a/components/process.rst b/components/process.rst
index 10e7e0777af..ffb6a5867c6 100644
--- a/components/process.rst
+++ b/components/process.rst
@@ -261,7 +261,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']);
diff --git a/components/var_dumper.rst b/components/var_dumper.rst
index cfc57140b52..88922a5b724 100644
--- a/components/var_dumper.rst
+++ b/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).
 
diff --git a/create_framework/http_kernel_controller_resolver.rst b/create_framework/http_kernel_controller_resolver.rst
index 6c7e469da27..80b3a590e0e 100644
--- a/create_framework/http_kernel_controller_resolver.rst
+++ b/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
diff --git a/create_framework/unit_testing.rst b/create_framework/unit_testing.rst
index 8d35b3a310c..e0474eeefcc 100644
--- a/create_framework/unit_testing.rst
+++ b/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.
diff --git a/frontend/encore/faq.rst b/frontend/encore/faq.rst
index 24091ff4c07..2d76a6f29b1 100644
--- a/frontend/encore/faq.rst
+++ b/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):
diff --git a/messenger.rst b/messenger.rst
index f8597d78e33..61558dbeb21 100644
--- a/messenger.rst
+++ b/messenger.rst
@@ -1542,7 +1542,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::
@@ -2291,7 +2291,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``::
 
diff --git a/migration.rst b/migration.rst
index e332ba72d9a..39f38d9b255 100644
--- a/migration.rst
+++ b/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
         {
diff --git a/validation/severity.rst b/validation/severity.rst
index 632a99519d9..72860a6477d 100644
--- a/validation/severity.rst
+++ b/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.