Merge branch '3.4' into 4.2

javiereguiluz · javiereguiluz · commit 8dd96b996c14 · 2019-07-01T10:56:58.000+02:00
* 3.4:
  Fix many typos and improve grammar
diff --git a/_build/maintainer_guide.rst b/_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
diff --git a/best_practices/introduction.rst b/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.
diff --git a/bundles/configuration.rst b/bundles/configuration.rst
@@ -381,7 +381,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
diff --git a/components/asset.rst b/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
diff --git a/components/cache.rst b/components/cache.rst
@@ -182,7 +182,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();
diff --git a/components/cache/adapters/memcached_adapter.rst b/components/cache/adapters/memcached_adapter.rst
@@ -241,7 +241,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*.
diff --git a/components/cache/cache_invalidation.rst b/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.
diff --git a/components/cache/cache_items.rst b/components/cache/cache_items.rst
@@ -67,7 +67,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.
 
diff --git a/components/cache/cache_pools.rst b/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.
 
diff --git a/components/config/definition.rst b/components/config/definition.rst
@@ -531,7 +531,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()``::
@@ -702,8 +702,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,
diff --git a/components/console/helpers/table.rst b/components/console/helpers/table.rst
@@ -88,7 +88,7 @@ You can optionally display titles at the top and the bottom of the table::
     | 80-902734-1-6 | And Then There Were None | Agatha Christie  |
     +---------------+--------- Page 1/2 -------+------------------+
 
-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::
 
diff --git a/components/dependency_injection/compilation.rst b/components/dependency_injection/compilation.rst
@@ -469,7 +469,7 @@ serves at dumping the compiled container::
     }
 
 ``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::
 
     // ...
diff --git a/components/event_dispatcher.rst b/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
diff --git a/components/http_foundation/session_php_bridge.rst b/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.
-
diff --git a/components/serializer.rst b/components/serializer.rst
@@ -719,15 +719,15 @@ 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.
 
 :class:`Symfony\\Component\\Serializer\\Normalizer\\DataUriNormalizer`
     This normalizer converts :phpclass:`SplFileInfo` objects into a data URI
     string (``data:...``) such that files can be embedded into serialized data.
 
 :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.
 
 :class:`Symfony\\Component\\Serializer\\Normalizer\\ConstraintViolationListNormalizer`
     This normalizer converts objects that implement
diff --git a/components/translation/usage.rst b/components/translation/usage.rst
@@ -31,7 +31,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::
diff --git a/components/var_dumper/advanced.rst b/components/var_dumper/advanced.rst
@@ -259,7 +259,7 @@ similar to PHP's short array notation::
     // ]
 
 If you would like to use both options, then you can combine them by
-using a the logical OR operator ``|``::
+using the logical OR operator ``|``::
 
     use Symfony\Component\VarDumper\Dumper\AbstractDumper;
     use Symfony\Component\VarDumper\Dumper\CliDumper;
diff --git a/components/yaml.rst b/components/yaml.rst
@@ -188,7 +188,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
@@ -277,7 +277,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::
 
@@ -294,7 +294,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_)::
 
@@ -309,7 +309,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"];
diff --git a/configuration/env_var_processors.rst b/configuration/env_var_processors.rst
@@ -1,4 +1,5 @@
 .. index::
+
     single: Environment Variable Processors; env vars
 
 Environment Variable Processors
diff --git a/configuration/using_parameters_in_dic.rst b/configuration/using_parameters_in_dic.rst
@@ -143,5 +143,5 @@ And set it in the constructor of ``Configuration`` via the ``Extension`` class::
 .. tip::
 
     There are some instances of ``%kernel.debug%`` usage within a
-    ``Configurator`` class for example in TwigBundle. However this is because
+    ``Configurator`` class for example in TwigBundle. However, this is because
     the default parameter value is set by the Extension class.
diff --git a/contributing/code/pull_requests.rst b/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
diff --git a/contributing/code/standards.rst b/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``;
diff --git a/contributing/code_of_conduct/reporting_guidelines.rst b/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
diff --git a/contributing/documentation/standards.rst b/contributing/documentation/standards.rst
@@ -135,7 +135,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
 
diff --git a/create_framework/front_controller.rst b/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.
diff --git a/create_framework/http_kernel_controller_resolver.rst b/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
diff --git a/create_framework/separation_of_concerns.rst b/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
diff --git a/form/data_transformers.rst b/form/data_transformers.rst
@@ -307,7 +307,7 @@ Now, you can use your ``TaskType``::
     // ...
 
 Cool, you're done! Your user will be able to enter an issue number into the
-text field and it will be transformed back into an Issue object. This means
+text field, which will be transformed back into an Issue object. This means
 that, after a successful submission, the Form component will pass a real
 ``Issue`` object to ``Task::setIssue()`` instead of the issue number.
 
diff --git a/form/dynamic_form_modification.rst b/form/dynamic_form_modification.rst
@@ -362,7 +362,7 @@ Dynamic Generation for Submitted Forms
 Another case that can appear is that you want to customize the form specific to
 the data that was submitted by the user. For example, imagine you have a registration
 form for sports gatherings. Some events will allow you to specify your preferred
-position on the field. This would be a ``choice`` field for example. However the
+position on the field. This would be a ``choice`` field for example. However, the
 possible choices will depend on each sport. Football will have attack, defense,
 goalkeeper etc... Baseball will have a pitcher but will not have a goalkeeper. You
 will need the correct options in order for validation to pass.
diff --git a/form/embedded.rst b/form/embedded.rst
@@ -60,7 +60,7 @@ Next, add a new ``category`` property to the ``Task`` class::
 .. tip::
 
     The ``Valid`` Constraint has been added to the property ``category``. This
-    cascades the validation to the corresponding entity. If you omit this constraint
+    cascades the validation to the corresponding entity. If you omit this constraint,
     the child entity would not be validated.
 
 Now that your application has been updated to reflect the new requirements,
diff --git a/frontend/encore/installation.rst b/frontend/encore/installation.rst
@@ -71,7 +71,7 @@ is the main config file for both Webpack and Webpack Encore:
          * (including one that's included on every page - e.g. "app")
          *
          * Each entry will result in one JavaScript file (e.g. app.js)
-         * and one CSS file (e.g. app.css) if you JavaScript imports CSS.
+         * and one CSS file (e.g. app.css) if your JavaScript imports CSS.
          */
         .addEntry('app', './assets/js/app.js')
         //.addEntry('page1', './assets/js/page1.js')
diff --git a/http_cache.rst b/http_cache.rst
@@ -303,7 +303,7 @@ two things:
   and mutating your application.
 
 * POST requests are generally considered uncacheable, but `they can be cached`_
-  when they include explicit freshness information. However POST caching is not
+  when they include explicit freshness information. However, POST caching is not
   widely implemented, so you should avoid it if possible.
 
 * You should *never* change the state of your application (e.g. update a blog post)
diff --git a/logging/channels_handlers.rst b/logging/channels_handlers.rst
@@ -96,7 +96,7 @@ from the ``security`` channel:
 
 .. caution::
 
-    The ``channels`` configuration only works for top level handlers. Handlers
+    The ``channels`` configuration only works for top-level handlers. Handlers
     that are nested inside a group, buffer, filter, fingers crossed or other
     such handler will ignore this configuration and will process every message
     passed to them.
diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst
@@ -810,7 +810,7 @@ name
 
 **type**: ``string`` **default**: ``null``
 
-This specifies the name of the session cookie. By default it will use the
+This specifies the name of the session cookie. By default, it will use the
 cookie name which is defined in the ``php.ini`` with the ``session.name``
 directive.
 
@@ -829,15 +829,15 @@ cookie_path
 
 **type**: ``string`` **default**: ``/``
 
-This determines the path to set in the session cookie. By default it will
+This determines the path to set in the session cookie. By default, it will
 use ``/``.
 
 cookie_domain
 .............
 
 **type**: ``string`` **default**: ``''``
 
-This determines the domain to set in the session cookie. By default it's
+This determines the domain to set in the session cookie. By default, it's
 blank, meaning the host name of the server which generated the cookie according
 to the cookie specification.
 
@@ -1025,7 +1025,7 @@ use_cookies
 **type**: ``boolean`` **default**: ``null``
 
 This specifies if the session ID is stored on the client side using cookies or
-not. By default it will use the value defined in the ``php.ini`` with the
+not. By default, it will use the value defined in the ``php.ini`` with the
 ``session.use_cookies`` directive.
 
 assets
diff --git a/reference/configuration/security.rst b/reference/configuration/security.rst
diff --git a/reference/configuration/web_profiler.rst b/reference/configuration/web_profiler.rst
diff --git a/reference/forms/types/options/_error_bubbling_hint.rst.inc b/reference/forms/types/options/_error_bubbling_hint.rst.inc
diff --git a/reference/forms/types/options/checkbox_compound.rst.inc b/reference/forms/types/options/checkbox_compound.rst.inc
diff --git a/reference/forms/types/options/required.rst.inc b/reference/forms/types/options/required.rst.inc
diff --git a/reference/forms/types/options/select_how_rendered.rst.inc b/reference/forms/types/options/select_how_rendered.rst.inc
diff --git a/reference/forms/types/tel.rst b/reference/forms/types/tel.rst
diff --git a/routing.rst b/routing.rst
diff --git a/routing/hostname_pattern.rst b/routing/hostname_pattern.rst
diff --git a/session/locale_sticky_session.rst b/session/locale_sticky_session.rst
diff --git a/templating.rst b/templating.rst
diff --git a/testing.rst b/testing.rst
diff --git a/testing/insulating_clients.rst b/testing/insulating_clients.rst
diff --git a/translation/debug.rst b/translation/debug.rst

Original file line number	Diff line number	Diff line change
`@@ -182,7 +182,7 @@ Now you can create, retrieve, update and delete items using this cache pool::`
`182`	`182`	`// retrieve the cache item`
`183`	`183`	`$productsCount = $cache->getItem('stats.products_count');`
`184`	`184`	`if (!$productsCount->isHit()) {`
`185`		`- // ... item does not exists in the cache`
	`185`	`+ // ... item does not exist in the cache`
`186`	`186`	`}`
`187`	`187`	`// retrieve the value stored by the item`
`188`	`188`	`$total = $productsCount->get();`