Fix many typos and improve grammar

_build/maintainer_guide.rst

@@ -93,7 +93,7 @@ interface. Then:
 Merging Process
 ~~~~~~~~~~~~~~~
 
-At first it's common to make mistakes and merge things badly. Don't worry. This
+At first, it's common to make mistakes and merge things badly. Don't worry. This
 has happened to all of us and we've always been able to recover from any mistake.
 
 Step 1: Select the right branch to merge

best_practices/controllers.rst

@@ -6,8 +6,8 @@ means that controllers should hold just the thin layer of *glue-code*
 needed to coordinate the different parts of the application.
 
 As a rule of thumb, you should follow the 5-10-20 rule, where controllers should
-only define 5 variables or less, contain 10 actions or less and include 20 lines
-of code or less in each action. This isn't an exact science, but it should
+only define 5 variables or fewer, contain 10 actions or fewer and include 20 lines
+of code or fewer in each action. This isn't an exact science, but it should
 help you realize when code should be refactored out of the controller and
 into a service.
 

best_practices/i18n.rst

@@ -54,7 +54,7 @@ Traditionally, Symfony developers have created these files in the
 ``app/Resources/`` directory is considered the global location for the
 application's resources, storing translations in ``app/Resources/translations/``
 centralizes them *and* gives them priority over any other translation file.
-This let's you override translations defined in third-party bundles.
+This lets you override translations defined in third-party bundles.
 
 Translation Keys
 ----------------

best_practices/introduction.rst

@@ -25,7 +25,7 @@ that fit the philosophy of the framework as envisioned by its original creator
 
 .. note::
 
-    **Best practice** is a noun that means *"a well defined procedure that is
+    **Best practice** is a noun that means *"a well-defined procedure that is
     known to produce near-optimum results"*. And that's exactly what this
     guide aims to provide. Even if you don't agree with every recommendation,
     we believe these will help you build great applications with less complexity.

bundles/configuration.rst

@@ -390,7 +390,7 @@ Providing an XML Schema
 
 XML has a very useful feature called `XML schema`_. This allows you to
 describe all possible elements and attributes and their values in an XML Schema
-Definition (an xsd file). This XSD file is used by IDEs for auto completion and
+Definition (an XSD file). This XSD file is used by IDEs for auto completion and
 it is used by the Config component to validate the elements.
 
 In order to use the schema, the XML configuration file must provide an

components/asset.rst

@@ -30,7 +30,7 @@ simple. Hardcoding URLs can be a disadvantage because:
   is essential for some applications because it allows you to control how
   the assets are cached. The Asset component allows you to define different
   versioning strategies for each package;
-* **Moving assets location** is cumbersome and error-prone: it requires you to
+* **Moving assets' location** is cumbersome and error-prone: it requires you to
   carefully update the URLs of all assets included in all templates. The Asset
   component allows to move assets effortlessly just by changing the base path
   value associated with the package of assets;
@@ -302,7 +302,7 @@ constructor::
     // result: http://static2.example.com/images/icon.png?v1
 
 For each asset, one of the URLs will be randomly used. But, the selection
-is deterministic, meaning that each asset will be always served by the same
+is deterministic, meaning that each asset will always be served by the same
 domain. This behavior simplifies the management of HTTP cache.
 
 Request Context Aware Assets

components/cache.rst

@@ -70,7 +70,7 @@ Now you can create, retrieve, update and delete items using this object::
 
     // retrieve the cache item
     if (!$cache->has('stats.products_count')) {
-        // ... item does not exists in the cache
+        // ... item does not exist in the cache
     }
 
     // retrieve the value stored by the item
@@ -171,7 +171,7 @@ Now you can create, retrieve, update and delete items using this cache pool::
     // retrieve the cache item
     $productsCount = $cache->getItem('stats.products_count');
     if (!$productsCount->isHit()) {
-        // ... item does not exists in the cache
+        // ... item does not exist in the cache
     }
     // retrieve the value stored by the item
     $total = $productsCount->get();

components/cache/adapters/memcached_adapter.rst

@@ -240,7 +240,7 @@ Available Options
 
 ``server_failure_limit`` (type: ``int``, default: ``0``)
     Specifies the failure limit for server connection attempts before marking
-    the server as "dead". The server will remaining in the server pool unless
+    the server as "dead". The server will remain in the server pool unless
     ``auto_eject_hosts`` is enabled.
 
     Valid option values include *any positive integer*.

components/cache/cache_invalidation.rst

@@ -10,7 +10,7 @@ change in the state of your model. The most basic kind of invalidation is direct
 items deletion. But when the state of a primary resource has spread across
 several cached items, keeping them in sync can be difficult.
 
-The Symfony Cache component provides two mechanisms to help solving this problem:
+The Symfony Cache component provides two mechanisms to help solve this problem:
 
 * :ref:`Tags-based invalidation <cache-component-tags>` for managing data dependencies;
 * :ref:`Expiration based invalidation <cache-component-expiration>` for time related dependencies.

components/cache/cache_items.rst

@@ -58,7 +58,7 @@ corresponding *getter* methods::
 Cache Item Expiration
 ~~~~~~~~~~~~~~~~~~~~~
 
-By default cache items are stored permanently. In practice, this "permanent
+By default, cache items are stored permanently. In practice, this "permanent
 storage" can vary greatly depending on the type of cache being used, as
 explained in the :doc:`/components/cache/cache_pools` article.
 

components/cache/cache_pools.rst

@@ -16,7 +16,7 @@ Cache Pools and Supported Adapters
 
 Cache Pools are the logical repositories of cache items. They perform all the
 common operations on items, such as saving them or looking for them. Cache pools
-are independent from the actual cache implementation. Therefore, applications
+are independent of the actual cache implementation. Therefore, applications
 can keep using the same cache pool even if the underlying cache mechanism
 changes from a file system based cache to a Redis or database based cache.
 

components/class_loader.rst

@@ -9,7 +9,7 @@ The ClassLoader Component
 
 .. caution::
 
-    The ClassLoader component was deprecated in Symfony 3.3 and it will be
+    The ClassLoader component was deprecated in Symfony 3.3 and will be
     removed in 4.0. As an alternative, use any of the `class loading optimizations`_
     provided by Composer.
 

components/config/definition.rst

@@ -538,7 +538,7 @@ For all nodes:
 Appending Sections
 ------------------
 
-If you have a complex configuration to validate then the tree can grow to
+If you have a complex configuration to validate, then the tree can grow to
 be large and you may want to split it up into sections. You can do this
 by making a section a separate node and then appending it into the main
 tree with ``append()``::
@@ -711,8 +711,8 @@ and sometimes only:
 
     <connection>default</connection>
 
-By default ``connection`` would be an array in the first case and a string
-in the second making it difficult to validate. You can ensure it is always
+By default, ``connection`` would be an array in the first case and a string
+in the second, making it difficult to validate. You can ensure it is always
 an array with ``fixXmlConfig()``.
 
 You can further control the normalization process if you need to. For example,

components/console/helpers/table.rst

@@ -69,7 +69,7 @@ You can add a table separator anywhere in the output by passing an instance of
     | 80-902734-1-6 | And Then There Were None | Agatha Christie  |
     +---------------+--------------------------+------------------+
 
-By default the width of the columns is calculated automatically based on their
+By default, the width of the columns is calculated automatically based on their
 contents. Use the :method:`Symfony\\Component\\Console\\Helper\\Table::setColumnWidths`
 method to set the column widths explicitly::
 

components/dependency_injection/compilation.rst

@@ -473,7 +473,7 @@ makes dumping the compiled container easy::
     }
 
 ``ProjectServiceContainer`` is the default name given to the dumped container
-class. However you can change this with the ``class`` option when you
+class. However, you can change this with the ``class`` option when you
 dump it::
 
     // ...

components/event_dispatcher.rst

@@ -13,7 +13,7 @@ Introduction
 ------------
 
 Object-oriented code has gone a long way to ensuring code extensibility.
-By creating classes that have well defined responsibilities, your code becomes
+By creating classes that have well-defined responsibilities, your code becomes
 more flexible and a developer can extend them with subclasses to modify
 their behaviors. But if they want to share the changes with other developers
 who have also made their own subclasses, code inheritance is no longer the

components/event_dispatcher/container_aware_dispatcher.rst

@@ -7,7 +7,7 @@ The Container Aware Event Dispatcher
 .. deprecated:: 3.3
 
     The ``ContainerAwareEventDispatcher`` class has been deprecated in Symfony 3.3
-    and it will be removed in Symfony 4.0. Use ``EventDispatcher`` with
+    and will be removed in Symfony 4.0. Use ``EventDispatcher`` with
     closure-proxy injection instead.
 
 Introduction

components/filesystem/lock_handler.rst

@@ -3,7 +3,7 @@ LockHandler
 
 .. deprecated:: 3.4
 
-    The ``LockHandler`` class was deprecated in Symfony 3.4 and it will be
+    The ``LockHandler`` class was deprecated in Symfony 3.4 and will be
     removed in Symfony 4.0. Use :ref:`SemaphoreStore <lock-store-semaphore>`
     or :ref:`FlockStore <lock-store-flock>` from the Lock component instead.
 

components/http_foundation/session_php_bridge.rst

@@ -12,7 +12,7 @@ As stated elsewhere, Symfony Sessions are designed to replace the use of
 PHP's native ``session_*()`` functions and use of the ``$_SESSION``
 superglobal. Additionally, it is mandatory for Symfony to start the session.
 
-However when there really are circumstances where this is not possible, you
+However, when there really are circumstances where this is not possible, you
 can use a special storage bridge
 :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\PhpBridgeSessionStorage`
 which is designed to allow Symfony to work with a session started outside of
@@ -46,4 +46,3 @@ of your application to Symfony sessions.
     cannot access arbitrary keys in ``$_SESSION`` that may be set by the legacy
     application, although all the ``$_SESSION`` contents will be saved when
     the session is saved.
-

components/serializer.rst

@@ -630,7 +630,7 @@ There are several types of normalizers available:
 :class:`Symfony\\Component\\Serializer\\Normalizer\\DateTimeNormalizer`
     This normalizer converts :phpclass:`DateTimeInterface` objects (e.g.
     :phpclass:`DateTime` and :phpclass:`DateTimeImmutable`) into strings.
-    By default it uses the RFC3339_ format.
+    By default, it uses the RFC3339_ format.
 
     .. versionadded:: 3.2
 
@@ -643,7 +643,7 @@ There are several types of normalizers available:
 
 :class:`Symfony\\Component\\Serializer\\Normalizer\\DateIntervalNormalizer`
     This normalizer converts :phpclass:`DateInterval` objects into strings.
-    By default it uses the ``P%yY%mM%dDT%hH%iM%sS`` format.
+    By default, it uses the ``P%yY%mM%dDT%hH%iM%sS`` format.
 
     .. versionadded:: 3.4
 

components/translation/usage.rst

@@ -104,7 +104,7 @@ for the individual translation, and can be the message in the main locale (e.g.
 *"Symfony is great"*) of your application or a unique identifier (e.g.
 ``symfony.great`` - see the sidebar below).
 
-Translation files can be created in several different formats, XLIFF being the
+Translation files can be created in several formats, XLIFF being the
 recommended format. These files are parsed by one of the loader classes.
 
 .. configuration-block::
@@ -351,7 +351,7 @@ effect after removing the explicit rules:
     '{0} There are no apples|[20,Inf[ There are many apples|There is one apple|a_few: There are %count% apples'
 
 For example, for ``1`` apple, the standard rule ``There is one apple`` will
-be used. For ``2-19`` apples, the second standard rule 
+be used. For ``2-19`` apples, the second standard rule
 ``There are %count% apples`` will be selected.
 
 An :class:`Symfony\\Component\\Translation\\Interval` can represent a finite set

components/var_dumper/advanced.rst

@@ -278,8 +278,8 @@ similar to PHP's short array notation::
     //   0 => "test"
     // ]
 
-If you would like to use both options, then you can just    combine them by
-using a the logical OR operator ``|``::
+If you would like to use both options, then you can just combine them by
+using the logical OR operator ``|``::
 
     use Symfony\Component\VarDumper\Dumper\AbstractDumper;
     use Symfony\Component\VarDumper\Dumper\CliDumper;

components/yaml.rst

@@ -192,7 +192,7 @@ representation to the inline one::
 Indentation
 ...........
 
-By default the YAML component will use 4 spaces for indentation. This can be
+By default, the YAML component will use 4 spaces for indentation. This can be
 changed using the third argument as follows::
 
     // uses 8 spaces for indentation
@@ -290,7 +290,7 @@ representation of the object as a map.
 Handling Invalid Types
 ~~~~~~~~~~~~~~~~~~~~~~
 
-By default the parser will encode invalid types as ``null``. You can make the
+By default, the parser will encode invalid types as ``null``. You can make the
 parser throw exceptions by using the ``PARSE_EXCEPTION_ON_INVALID_TYPE``
 flag::
 
@@ -307,7 +307,7 @@ Similarly you can use ``DUMP_EXCEPTION_ON_INVALID_TYPE`` when dumping::
 Date Handling
 ~~~~~~~~~~~~~
 
-By default the YAML parser will convert unquoted strings which look like a
+By default, the YAML parser will convert unquoted strings which look like a
 date or a date-time into a Unix timestamp; for example ``2016-05-27`` or
 ``2016-05-27T02:59:43.1Z`` (ISO-8601_)::
 
@@ -322,7 +322,7 @@ flag::
 Dumping Multi-line Literal Blocks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In YAML multiple lines can be represented as literal blocks, by default the
+In YAML, multiple lines can be represented as literal blocks. By default, the
 dumper will encode multiple lines as an inline string::
 
     $string = ["string" => "Multiple\nLine\nString"];

configuration/external_parameters.rst

@@ -125,7 +125,7 @@ of the following:
     .. deprecated:: 3.3
 
         The support of the special ``SYMFONY__`` environment variables was
-        deprecated in Symfony 3.3 and it will be removed in 4.0. Instead of
+        deprecated in Symfony 3.3 and will be removed in 4.0. Instead of
         using those variables, define regular environment variables and get
         their values using the ``%env(...)%`` syntax in your config files.
 

configuration/using_parameters_in_dic.rst

@@ -144,7 +144,7 @@ And set it in the constructor of ``Configuration`` via the ``Extension`` class::
 .. sidebar:: Setting the Default in the Extension
 
     There are some instances of ``%kernel.debug%`` usage within a ``Configurator``
-    class in TwigBundle and AsseticBundle. However this is because the default
+    class in TwigBundle and AsseticBundle. However, this is because the default
     parameter value is set by the Extension class. For example in AsseticBundle,
     you can find::
 

console/commands_as_services.rst

@@ -10,7 +10,7 @@ recommended setup.
 
 Symfony also looks in the ``Command/`` directory of each bundle for commands
 non registered as a service and automatically registers those classes as
-commands. However this auto-registration was deprecated in Symfony 3.4. In
+commands. However, this auto-registration was deprecated in Symfony 3.4. In
 Symfony 4.0, commands won't be auto-registered anymore.
 
 .. note::

contributing/code/pull_requests.rst

@@ -361,7 +361,7 @@ As long as you have items in the todo-list, please prefix the pull request
 title with "[WIP]". If you do not yet want to trigger the automated tests,
 you can also set the PR to `draft status`_.
 
-In the pull request description, give as much details as possible about your
+In the pull request description, give as much detail as possible about your
 changes (don't hesitate to give code examples to illustrate your points). If
 your pull request is about adding a new feature or modifying an existing one,
 explain the rationale for the changes. The pull request description helps the

contributing/code/reproducer.rst

@@ -37,7 +37,7 @@ a PHP script, it's better to reproduce the bug by forking the Symfony Standard
 edition. To do so:
 
 #. Go to https://github.com/symfony/symfony-standard and click on the **Fork**
-   button to make a fork of that repository or go to your already forked copy.
+   button to make a fork of that repository or go to your already-forked copy.
 #. Clone the forked repository into your computer:
    ``git clone git://github.com/YOUR-GITHUB-USERNAME/symfony-standard.git``
 #. Browse the project and create a new branch (e.g. ``issue_23567``,

contributing/code/standards.rst

@@ -209,7 +209,7 @@ Naming Conventions
 
 * Prefix all abstract classes with ``Abstract`` except PHPUnit ``*TestCase``.
   Please note some early Symfony classes do not follow this convention and
-  have not been renamed for backward compatibility reasons. However all new
+  have not been renamed for backward compatibility reasons. However, all new
   abstract classes must follow this naming convention;
 
 * Suffix interfaces with ``Interface``;

contributing/code_of_conduct/reporting_guidelines.rst

@@ -69,7 +69,7 @@ let them know what action (if any) we'll be taking. We'll take into account feed
 from the reporter on the appropriateness of our response, but our response will be
 determined by what will be best for community safety.
 
-The CARE team keeps a private record of all incidents. By default all reports
+The CARE team keeps a private record of all incidents. By default, all reports
 are shared with the entire CARE team unless the reporter specifically asks
 to exclude specific CARE team members, in which case these CARE team
 members will not be included in any communication on the incidents as well as records

contributing/documentation/standards.rst

@@ -137,7 +137,7 @@ Files and Directories
 * When referencing file extensions explicitly, you should include a leading dot
   for every extension (e.g. "XML files use the ``.xml`` extension").
 * When you list a Symfony file/directory hierarchy, use ``your-project/`` as the
-  top level directory. E.g.
+  top-level directory. E.g.
 
   .. code-block:: text
 

create_framework/front_controller.rst

@@ -220,7 +220,7 @@ We have the first version of our framework::
 
     $response->send();
 
-Adding a new page is a two step process: add an entry in the map and create a
+Adding a new page is a two-step process: add an entry in the map and create a
 PHP template in ``src/pages/``. From a template, get the Request data via the
 ``$request`` variable and tweak the Response headers via the ``$response``
 variable.

create_framework/http_kernel_controller_resolver.rst

@@ -28,7 +28,7 @@ Update the route definition accordingly::
     ]));
 
 The move is pretty straightforward and makes a lot of sense as soon as you
-create more pages but you might have noticed a non-desirable side-effect...
+create more pages but you might have noticed a non-desirable side effect...
 The ``LeapYearController`` class is *always* instantiated, even if the
 requested URL does not match the ``leap_year`` route. This is bad for one main
 reason: performance wise, all controllers for all routes must now be

create_framework/separation_of_concerns.rst

@@ -163,7 +163,7 @@ To sum up, here is the new file layout:
         └── front.php
 
 That's it! Our application has now four different layers and each of them has
-a well defined goal:
+a well-defined goal:
 
 * ``web/front.php``: The front controller; the only exposed PHP code that
   makes the interface with the client (it gets the Request and sends the

deployment/azure-website.rst

@@ -156,7 +156,7 @@ Enabling the PHP intl Extension
 no longer necessary.** You can check if the ``intl`` extension is enabled in the
 :phpfunction:`phpinfo` page.
 
-However if the ``intl`` extension is not enabled you can follow these steps.
+However, if the ``intl`` extension is not enabled you can follow these steps.
 
 This is the tricky part of the guide! To enable the ``intl`` extension, there is
 no need to upload any DLL files as the ``php_intl.dll`` file already exists on