Fix some mistakes

ottaviano · ottaviano · commit c545e1781c74 · 2019-02-13T21:21:04.000+01:00
diff --git a/best_practices/security.rst b/best_practices/security.rst
@@ -161,7 +161,7 @@ be reused in other parts of the application. Imagine that you want to add
 a link in a template that will only be seen by authors. Right now you'll
 need to repeat the expression code using Twig syntax:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {% if app.user and app.user.email == post.authorEmail %}
         <a href=""> ... </a>
@@ -203,7 +203,7 @@ Now you can reuse this method both in the template and in the security expressio
         // ...
     }
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {% if post.isAuthor(app.user) %}
         <a href=""> ... </a>
diff --git a/components/http_kernel.rst b/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::
 
diff --git a/components/serializer.rst b/components/serializer.rst
@@ -578,7 +578,7 @@ There are several types of normalizers available:
     calling the constructor during the denormalization process.
 
     Objects are normalized to a map of property names and values (names are
-    generated removing the ``get``, ``set``, ``has`` or ``remove`` prefix from
+    generated removing the ``get``, ``set``, ``has``, ``is`` or ``remove`` prefix from
     the method name and lowercasing the first letter; e.g. ``getFirstName()`` ->
     ``firstName``).
 
@@ -936,9 +936,7 @@ Use the special ``#`` key to define the data of a node::
     // is encoded as follows:
     // <?xml version="1.0"?>
     // <response>
-    //     <foo bar="value">
-    //        baz
-    //     </foo>
+    //     <foo bar="value">baz</foo>
     // </response>
 
 Context
diff --git a/doctrine/lifecycle_callbacks.rst b/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).
 
diff --git a/email.rst b/email.rst
@@ -138,7 +138,7 @@ To keep things decoupled, the email body has been stored in a template and
 rendered with the ``renderView()`` method. The ``registration.html.twig``
 template might look something like this:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {# app/Resources/views/Emails/registration.html.twig #}
     <h3>You did it! You registered!</h3>
diff --git a/form/create_custom_field_type.rst b/form/create_custom_field_type.rst
@@ -141,7 +141,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 %}``).
 
diff --git a/form/form_customization.rst b/form/form_customization.rst
@@ -42,6 +42,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
@@ -720,7 +721,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:
diff --git a/form/rendering.rst b/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
diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst
@@ -1936,7 +1936,7 @@ ships with multiple adapters: ``cache.adapter.apcu``, ``cache.adapter.doctrine``
     given the adapter they are based on. Internally, a pool wraps the definition
     of an adapter.
 
-.. _reference-cache-systen:
+.. _reference-cache-system:
 
 system
 ......
diff --git a/reference/constraints/Callback.rst b/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;
 
diff --git a/reference/constraints/Choice.rst b/reference/constraints/Choice.rst
@@ -297,7 +297,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.
 
diff --git a/reference/forms/twig_reference.rst b/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.                                                  |
diff --git a/security.rst b/security.rst
@@ -941,7 +941,7 @@ You can also use expressions inside your templates:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {% if is_granted(expression(
             '"ROLE_ADMIN" in roles or (not is_anonymous() and user.isSuperAdmin())'
diff --git a/serializer.rst b/serializer.rst
@@ -233,7 +233,7 @@ Enabling the Metadata Cache
 
 Metadata used by the Serializer component such as groups can be cached to
 enhance application performance. By default, the serializer uses the ``cache.system``
-cache pool which is configured using the :ref:`cache.system <reference-cache-systen>`
+cache pool which is configured using the :ref:`cache.system <reference-cache-system>`
 option.
 
 Enabling a Name Converter
diff --git a/templating.rst b/templating.rst
@@ -660,7 +660,7 @@ being used and generating the correct paths accordingly.
 If you need absolute URLs for assets, use the ``absolute_url()`` Twig function
 as follows:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <img src="{{ absolute_url(asset('images/logo.png')) }}" alt="Symfony!" />
 
diff --git a/validation.rst b/validation.rst
@@ -151,7 +151,7 @@ message:
 
 .. code-block:: text
 
-    AppBundle\Entity\Author.name:
+    Object(AppBundle\Entity\Author).name:
         This value should not be blank
 
 If you insert a value into the ``name`` property, the happy success message
diff --git a/validation/groups.rst b/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``.
 
diff --git a/validation/severity.rst b/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 -%}
