symfony · weaverryan · Nov 9, 2012 · Nov 8, 2012
diff --git a/cookbook/form/create_custom_field_type.rst b/cookbook/form/create_custom_field_type.rst
@@ -5,17 +5,17 @@ How to Create a Custom Form Field Type
 ======================================
 
 Symfony comes with a bunch of core field types available for building forms.
-However there are situations where we want to create a custom form field
-type for a specific purpose. This recipe assumes we need a field definition
+However there are situations where you may want to create a custom form field
+type for a specific purpose. This recipe assumes you need a field definition
 that holds a person's gender, based on the existing choice field. This section
-explains how the field is defined, how we can customize its layout and finally,
-how we can register it for use in our application.
+explains how the field is defined, how you can customize its layout and finally,
+how you can register it for use in your application.
 
 Defining the Field Type
 -----------------------
 
-In order to create the custom field type, first we have to create the class
-representing the field. In our situation the class holding the field type
+In order to create the custom field type, first you have to create the class
+representing the field. In this situation the class holding the field type
 will be called `GenderType` and the file will be stored in the default location
 for form fields, which is ``<BundleName>\Form\Type``. Make sure the field extends
 :class:`Symfony\\Component\\Form\\AbstractType`::
@@ -54,8 +54,8 @@ for form fields, which is ``<BundleName>\Form\Type``. Make sure the field extend
     The location of this file is not important - the ``Form\Type`` directory
     is just a convention.
 
-Here, the return value of the ``getParent`` function indicates that we're
-extending the ``choice`` field type. This means that, by default, we inherit
+Here, the return value of the ``getParent`` function indicates that you're
+extending the ``choice`` field type. This means that, by default, you inherit
 all of the logic and rendering of that field type. To see some of the logic,
 check out the `ChoiceType`_ class. There are three methods that are particularly
 important:
@@ -86,7 +86,7 @@ The ``getName()`` method returns an identifier which should be unique in
 your application. This is used in various places, such as when customizing
 how your form type will be rendered.
 
-The goal of our field was to extend the choice type to enable selection of
+The goal of this field was to extend the choice type to enable selection of
 a gender. This is achieved by fixing the ``choices`` to a list of possible
 genders.
 
@@ -97,11 +97,11 @@ Each field type is rendered by a template fragment, which is determined in
 part by the value of your ``getName()`` method. For more information, see
 :ref:`cookbook-form-customization-form-themes`.
 
-In this case, since our parent field is ``choice``, we don't *need* to do
-any work as our custom field type will automatically be rendered like a ``choice``
-type. But for the sake of this example, let's suppose that when our field
+In this case, since tge parent field is ``choice``, you don't *need* to do
+any work as the custom field type will automatically be rendered like a ``choice``
+type. But for the sake of this example, let's suppose that when your field
 is "expanded" (i.e. radio buttons or checkboxes, instead of a select field),
-we want to always render it in a ``ul`` element. In your form theme template
+you want to always render it in a ``ul`` element. In your form theme template
 (see above link for details), create a ``gender_widget`` block to handle this:
 
 .. code-block:: html+jinja
@@ -172,12 +172,12 @@ Creating your Field Type as a Service
 So far, this entry has assumed that you have a very simple custom field type.
 But if you need access to configuration, a database connection, or some other
 service, then you'll want to register your custom type as a service. For
-example, suppose that we're storing the gender parameters in configuration:
+example, suppose that you're storing the gender parameters in configuration:
 
 .. configuration-block::
 
     .. code-block:: yaml
-    
+
         # app/config/config.yml
         parameters:
             genders:
@@ -194,7 +194,7 @@ example, suppose that we're storing the gender parameters in configuration:
             </parameter>
         </parameters>
 
-To use the parameter, we'll define our custom field type as a service, injecting
+To use the parameter, define your custom field type as a service, injecting
 the ``genders`` parameter value as the first argument to its to-be-created
 ``__construct`` function:
 
@@ -225,8 +225,8 @@ the ``genders`` parameter value as the first argument to its to-be-created
     for details.
 
 Be sure that the ``alias`` attribute of the tag corresponds with the value
-returned by the ``getName`` method defined earlier. We'll see the importance
-of this in a moment when we use the custom field type. But first, add a ``__construct``
+returned by the ``getName`` method defined earlier. You'll see the importance
+of this in a moment when you use the custom field type. But first, add a ``__construct``
 argument to ``GenderType``, which receives the gender configuration::
 
     // src/Acme/DemoBundle/Form/Type/GenderType.php
@@ -236,24 +236,24 @@ argument to ``GenderType``, which receives the gender configuration::
     class GenderType extends AbstractType
     {
         private $genderChoices;
-        
+
         public function __construct(array $genderChoices)
         {
             $this->genderChoices = $genderChoices;
         }
-    
+
         public function getDefaultOptions(array $options)
         {
             return array(
                 'choices' => $this->genderChoices,
             );
         }
-        
+
         // ...
     }
 
 Great! The ``GenderType`` is now fueled by the configuration parameters and
-registered as a service. And because we used the ``form.type`` alias in its
+registered as a service. Additionally because you used the ``form.type`` alias in its
 configuration, using the field is now much easier::
 
     // src/Acme/DemoBundle/Form/Type/AuthorType.php
@@ -270,8 +270,8 @@ configuration, using the field is now much easier::
         }
     }
 
-Notice that instead of instantiating a new instance, we can just refer to
-it by the alias used in our service configuration, ``gender``. Have fun!
+Notice that instead of instantiating a new instance, you can just refer to
+it by the alias used in your service configuration, ``gender``. Have fun!
 
 .. _`ChoiceType`: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php
 .. _`FieldType`: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/Type/FieldType.php
diff --git a/cookbook/form/data_transformers.rst b/cookbook/form/data_transformers.rst
@@ -117,7 +117,7 @@ issue field in some form.
                 $entityManager = $options['em'];
                 $transformer = new IssueToNumberTransformer($entityManager);
 
-                // add a normal text field, but add our transformer to it
+                // add a normal text field, but add your transformer to it
                 $builder->add(
                     $builder->create('issue', 'text')
                         ->prependNormTransformer($transformer)
@@ -164,11 +164,11 @@ types of underlying data.
 In any form, the 3 different types of data are:
 
 1) **App data** - This is the data in the format used in your application
-(e.g. an ``Issue`` object). If you call ``Form::getData`` or ``Form::setData``, 
+(e.g. an ``Issue`` object). If you call ``Form::getData`` or ``Form::setData``,
 you're dealing with the "app" data.
 
 2) **Norm Data** - This is a normalized version of your data, and is commonly
-the same as your "app" data (though not in our example). It's not commonly
+the same as your "app" data (though not in this example). It's not commonly
 used directly.
 
 3) **Client Data** - This is the format that's used to fill in the form fields
@@ -190,11 +190,11 @@ Which transformer you need depends on your situation.
 
 To use the client transformer, call ``appendClientTransformer``.
 
-So why did we use the norm transformer?
----------------------------------------
+So why use the norm transformer?
+--------------------------------
 
-In our example, the field is a ``text`` field, and we always expect a text
-field to be a simple, scalar format in the "norm" and "client" formats. For
+In this example, the field is a ``text`` field, and a text field is always
+expected to be a simple, scalar format in the "norm" and "client" formats. For
 this reason, the most appropriate transformer was the "norm" transformer
 (which converts to/from the *norm* format - string issue number - to the *app*
 format - Issue object).

diff --git a/cookbook/form/dynamic_form_generation.rst b/cookbook/form/dynamic_form_generation.rst
@@ -49,7 +49,7 @@ flexibility to your forms.
 Adding An Event Subscriber To A Form Class
 ------------------------------------------
 
-So, instead of directly adding that "name" widget via our ProductType form
+So, instead of directly adding that "name" widget via your ProductType form
 class, let's delegate the responsibility of creating that particular field
 to an Event Subscriber::
 
@@ -76,7 +76,7 @@ to an Event Subscriber::
     }
 
 The event subscriber is passed the FormFactory object in its constructor so
-that our new subscriber is capable of creating the form widget once it is
+that your new subscriber is capable of creating the form widget once it is
 notified of the dispatched event during form creation.
 
 .. _`cookbook-forms-inside-subscriber-class`:
@@ -107,7 +107,7 @@ might look like the following::
 
         public static function getSubscribedEvents()
         {
-            // Tells the dispatcher that we want to listen on the form.pre_set_data
+            // Tells the dispatcher that you want to listen on the form.pre_set_data
             // event and that the preSetData method should be called.
             return array(FormEvents::PRE_SET_DATA => 'preSetData');
         }
@@ -118,7 +118,7 @@ might look like the following::
             $form = $event->getForm();
 
             // During form creation setData() is called with null as an argument
-            // by the FormBuilder constructor. We're only concerned with when
+            // by the FormBuilder constructor. You're only concerned with when
             // setData is called with an actual Entity object in it (whether new
             // or fetched with Doctrine). This if statement lets us skip right
             // over the null condition.
@@ -146,7 +146,7 @@ The `FormEvents class`_ serves an organizational purpose. It is a centralized lo
 in which you can find all of the various form events available.
 
 While this example could have used the ``form.set_data`` event or even the ``form.post_set_data``
-events just as effectively, by using ``form.pre_set_data`` we guarantee that
+events just as effectively, by using ``form.pre_set_data`` you guarantee that
 the data being retrieved from the ``Event`` object has in no way been modified
 by any other subscribers or listeners. This is because ``form.pre_set_data``
 passes a `DataEvent`_ object instead of the `FilterDataEvent`_ object passed