minor #11854 Fix many typos and improve grammar (Calinou)

This PR was merged into the 3.4 branch.

Discussion
----------

Fix many typos and improve grammar

Follow-up to #11645.

Commits
-------

97f4eeb Fix many typos and improve grammar

Author: javiereguiluz

_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.