Merge branch '2.7' into 2.8

* 2.7:
  Some fixes for testing/* articles in 2.7 docs
  Fixed some issues in PHPUnit XML config examples
  Removed a wrong note about controllers as services
  Removed lots of redundant contents
  [#8650] Minor rewording
  [#8649] Small reword
  Improved the link to the Symfony events reference
  Minor fixes for upload_file.rst
  Fixed a typo
  Added getSubscribedEvents() to UserLocaleSubscriber
  Reworded the explanation about service tags
  Reworded the intro of reference/dic_tags.rst
  Fixed RST syntax issue
  Revamped the reference/events.rst article
  Change some docs to be gender-neutral

Author: weaverryan

controller/service.rst

@@ -104,8 +104,9 @@ defined above with the id ``app.hello_controller``::
 
 .. note::
 
-    You cannot drop the ``Action`` part of the method name when using this
-    syntax.
+    Make sure the method name in your route (e.g. ``indexAction``) matches the
+    method name exactly. Unlike the traditional ``Bundle:Controller:method``
+    notation, the ``Action`` suffix is not automatically added for you.
 
 You can also route to the service by using the same notation when defining
 the route ``_controller`` value:

controller/upload_file.rst

@@ -108,7 +108,7 @@ to :doc:`customize form rendering </form/form_customization>`):
 Finally, you need to update the code of the controller that handles the form::
 
     // src/AppBundle/Controller/ProductController.php
-    namespace AppBundle\ProductController;
+    namespace AppBundle\Controller;
 
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
     use Symfony\Bundle\FrameworkBundle\Controller\Controller;
@@ -391,15 +391,16 @@ Now, register this class as a Doctrine listener:
                 http://symfony.com/schema/dic/services/services-1.0.xsd">
             <!-- ... -->
 
-            <service id="app.doctrine_brochure_listener"
-                class="AppBundle\EventListener\BrochureUploaderListener"
-            >
-                <argument type="service" id="app.brochure_uploader"/>
-
-                <tag name="doctrine.event_listener" event="prePersist"/>
-                <tag name="doctrine.event_listener" event="preUpdate"/>
-            </service>
+            <services>
+                <service id="app.doctrine_brochure_listener"
+                    class="AppBundle\EventListener\BrochureUploaderListener"
+                >
+                    <argument type="service" id="app.brochure_uploader"/>
 
+                    <tag name="doctrine.event_listener" event="prePersist"/>
+                    <tag name="doctrine.event_listener" event="preUpdate"/>
+                </service>
+            </services>
         </container>
 
     .. code-block:: php

event_dispatcher.rst

@@ -64,8 +64,8 @@ The most common way to listen to an event is to register an **event listener**::
 
     Each event receives a slightly different type of ``$event`` object. For
     the ``kernel.exception`` event, it is :class:`Symfony\\Component\\HttpKernel\\Event\\GetResponseForExceptionEvent`.
-    To see what type of object each event listener receives, see :class:`Symfony\\Component\\HttpKernel\\KernelEvents`
-    or the documentation about the specific event you're listening to.
+    Check out the :doc:`Symfony events reference </reference/events>` to see
+    what type of object each event provides.
 
 Now that the class is created, you just need to register it as a service and
 notify Symfony that it is a "listener" on the ``kernel.exception`` event by

form/events.rst

@@ -295,7 +295,7 @@ Creating and binding an event listener to the form is very easy::
                 return;
             }
 
-            // Check whether the user has chosen to display his email or not.
+            // Check whether the user has chosen to display their email or not.
             // If the data was submitted previously, the additional value that is
             // included in the request variables needs to be removed.
             if (true === $user['show_email']) {
@@ -376,7 +376,7 @@ Event subscribers have different uses:
             $form = $event->getForm();
 
             // Check whether the user from the initial data has chosen to
-            // display his email or not.
+            // display their email or not.
             if (true === $user->isShowEmail()) {
                 $form->add('email', EmailType::class);
             }
@@ -391,7 +391,7 @@ Event subscribers have different uses:
                 return;
             }
 
-            // Check whether the user has chosen to display his email or not.
+            // Check whether the user has chosen to display their email or not.
             // If the data was submitted previously, the additional value that
             // is included in the request variables needs to be removed.
             if (true === $user['show_email']) {

reference/dic_tags.rst

@@ -1,16 +1,12 @@
-The Dependency Injection Tags
+Built-in Symfony Service Tags
 =============================
 
-Dependency Injection Tags are little strings that can be applied to a service
-to "flag" it to be used in some special way. For example, if you have a
-service that you would like to register as a listener to one of Symfony's
-core events, you can flag it with the ``kernel.event_listener`` tag.
+:doc:`Service tags </service_container/tags>` are the mechanism used by the
+:doc:`DependencyInjection component </components/dependency_injection>` to flag
+services that require special processing, like console commands or Twig extensions.
 
-You can learn a little bit more about "tags" by reading the ":doc:`/service_container/tags`"
-article.
-
-Below is information about all of the tags available inside Symfony. There
-may also be tags in other bundles you use that aren't listed here.
+These are the most common tags provided by Symfony components, but in your
+application there could be more tags available provided by third-party bundles:
 
 ========================================  ========================================================================
 Tag Name                                  Usage