Fix some mistakes

Author: ottaviano

components/http_kernel.rst

@@ -143,7 +143,6 @@ For general information on adding listeners to the events below, see
     As of 3.1 the :class:`Symfony\\Component\\HttpKernel\\HttpKernel` accepts a
     fourth argument, which must be an instance of
     :class:`Symfony\\Component\\HttpKernel\\Controller\\ArgumentResolverInterface`.
-    In 4.0 this argument will become mandatory.
 
 .. seealso::
 

doctrine/lifecycle_callbacks.rst

@@ -6,7 +6,7 @@ How to Work with Lifecycle Callbacks
 
 Sometimes, you need to perform an action right before or after an entity
 is inserted, updated, or deleted. These types of actions are known as "lifecycle"
-callbacks, as they're callback methods that you need to execute during different
+callbacks, as they're callback functions that you need to execute during different
 stages of the lifecycle of an entity (e.g. the entity is inserted, updated,
 deleted, etc).
 

form/create_custom_field_type.rst

@@ -146,7 +146,7 @@ link for details), create a ``shipping_widget`` block to handle this:
 
     You can further customize the template used to render each children of the
     choice type. The block to override in that case is named "block name" +
-    ``_entry`` + "element name" (``label``, ``errors`` or ``widget``) (e.g. to
+    ``_entry_`` + "element name" (``label``, ``errors`` or ``widget``) (e.g. to
     customize the labels of the children of the Shipping widget you'd need to
     define ``{% block shipping_entry_label %} ... {% endblock %}``).
 

form/form_customization.rst

@@ -43,6 +43,7 @@ above templates would render:
             <li>This field is required</li>
         </ul>
         <input type="number" id="form_age" name="form[age]" />
+        <p id="form_age_help" class="help-text">One help note.</p>
     </div>
 
 To quickly prototype and test a form, you can render the entire form with
@@ -718,7 +719,7 @@ Customizing the "Form Row"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When you can manage it, the easiest way to render a form field is via the
-``form_row()`` function, which renders the label, errors and HTML widget of
+``form_row()`` function, which renders the label, errors, help and HTML widget of
 a field. To customize the markup used for rendering *all* form field rows,
 override the ``form_row`` fragment. For example, suppose you want to add a
 class to the ``div`` element around each row:

form/rendering.rst

@@ -39,7 +39,7 @@ output can be customized on many different levels.
 
 .. code-block:: twig
 
-    {{ form.vars.value.task }}
+    {{ form.task.vars.value }}
 
 .. index::
    single: Forms; Rendering each field by hand

reference/constraints/Callback.rst

@@ -7,26 +7,26 @@ on your object. If you're using validation with forms, this means that you
 can make these custom errors display next to a specific field, instead of
 simply at the top of your form.
 
-This process works by specifying one or more *callback* methods, each of
-which will be called during the validation process. Each of those methods
+This process works by specifying one or more *callback* functions, each of
+which will be called during the validation process. Each of those functions
 can do anything, including creating and assigning validation errors.
 
 .. note::
 
-    A callback method itself doesn't *fail* or return any value. Instead,
-    as you'll see in the example, a callback method has the ability to directly
+    A callback function itself doesn't *fail* or return any value. Instead,
+    as you'll see in the example, a callback function has the ability to directly
     add validator "violations".
 
-+----------------+------------------------------------------------------------------------+
-| Applies to     | :ref:`class <validation-class-target>`                                 |
-+----------------+------------------------------------------------------------------------+
-| Options        | - :ref:`callback <callback-option>`                                    |
-|                | - `payload`_                                                           |
-+----------------+------------------------------------------------------------------------+
-| Class          | :class:`Symfony\\Component\\Validator\\Constraints\\Callback`          |
-+----------------+------------------------------------------------------------------------+
-| Validator      | :class:`Symfony\\Component\\Validator\\Constraints\\CallbackValidator` |
-+----------------+------------------------------------------------------------------------+
++----------------+-----------------------------------------------------------------------------------------------+
+| Applies to     | :ref:`class <validation-class-target>` or :ref:`property/method <validation-property-target>` |
++----------------+-----------------------------------------------------------------------------------------------+
+| Options        | - :ref:`callback <callback-option>`                                                           |
+|                | - `payload`_                                                                                  |
++----------------+-----------------------------------------------------------------------------------------------+
+| Class          | :class:`Symfony\\Component\\Validator\\Constraints\\Callback`                                 |
++----------------+-----------------------------------------------------------------------------------------------+
+| Validator      | :class:`Symfony\\Component\\Validator\\Constraints\\CallbackValidator`                        |
++----------------+-----------------------------------------------------------------------------------------------+
 
 Configuration
 -------------
@@ -88,10 +88,10 @@ Configuration
             }
         }
 
-The Callback Method
--------------------
+The Callback Function
+---------------------
 
-The callback method is passed a special ``ExecutionContextInterface`` object.
+The callback function is passed a special ``ExecutionContextInterface`` object.
 You can set "violations" directly on this object and determine to which
 field those errors should be attributed::
 
@@ -260,7 +260,7 @@ callback
 **type**: ``string``, ``array`` or ``Closure`` [:ref:`default option <validation-default-option>`]
 
 The callback option accepts three different formats for specifying the
-callback method:
+callback function:
 
 * A **string** containing the name of a concrete or static method;
 

reference/constraints/Choice.rst

@@ -292,7 +292,7 @@ callback
 
 **type**: ``string|array|Closure``
 
-This is a callback method that can be used instead of the `choices`_ option
+This is a callback function that can be used instead of the `choices`_ option
 to return the choices array. See
 `Supplying the Choices with a Callback Function`_ for details on its usage.
 

reference/forms/twig_reference.rst

@@ -152,7 +152,7 @@ form_row(view, variables)
 -------------------------
 
 Renders the "row" of a given field, which is the combination of the field's
-label, errors and widget.
+label, errors, widget and help.
 
 .. code-block:: twig
 
@@ -339,7 +339,7 @@ done by using a public ``vars`` property on the
 | ``full_name``          | The ``name`` HTML attribute to be rendered.                                         |
 +------------------------+-------------------------------------------------------------------------------------+
 | ``errors``             | An array of any errors attached to *this* specific field                            |
-|                        | (e.g. ``form.title.errors``).                                                       |
+|                        | (e.g. ``form.title.vars.errors``).                                                  |
 |                        | Note that you can't use ``form.errors`` to determine if a form is valid,            |
 |                        | since this only returns "global" errors: some individual fields may have errors.    |
 |                        | Instead, use the ``valid`` option.                                                  |

templating.rst

@@ -313,7 +313,7 @@ Template Naming and Locations
 By default, templates can live in two different locations:
 
 ``templates/``
-    The application's ``views`` directory can contain application-wide base templates
+    This directory can contain application-wide base templates
     (i.e. your application's layouts and templates of the application bundle) as
     well as templates that :ref:`override third party bundle templates <override-templates>`.
 

validation.rst

@@ -161,8 +161,8 @@ message:
 
 .. code-block:: text
 
-    App\Entity\Author.name:
-        This value should not be blank
+    Object(App\Entity\Author).name:
+        This value should not be blank (code c1051bb4-d103-4f74-8988-acbcafc7fdc3)
 
 If you insert a value into the ``name`` property, the happy success message
 will appear.

validation/groups.rst

@@ -142,7 +142,7 @@ With this configuration, there are three validation groups:
 ``registration``
     Contains the constraints on the ``email`` and ``password`` fields only.
 
-Constraints in the ``Default`` group of a class are the constraints that have
+Constraints in the ``User`` group of a class are the constraints that have
 either no explicit group configured or that are configured to a group equal to
 the class name or the string ``Default``.
 

validation/severity.rst

@@ -142,7 +142,7 @@ method. Each constraint exposes the attached payload as a public property::
 For example, you can leverage this to customize the ``form_errors`` block
 so that the severity is added as an additional HTML class:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {%- block form_errors -%}
         {%- if errors|length > 0 -%}