some language tweaks (AE, third-person perspective)

book/forms.rst

@@ -281,7 +281,7 @@ Submitting Forms with Multiple Buttons
 
 When your form contains more than one submit button, you will want to check
 which of the buttons was clicked to adapt the program flow in your controller.
-Let's add a second button with the caption "Save and add" to our form::
+To do this, add a second button with the caption "Save and add" to your form::
 
     $form = $this->createFormBuilder($task)
         ->add('task', 'text')
@@ -552,8 +552,8 @@ Groups based on the Clicked Button
 When your form contains multiple submit buttons, you can change the validation
 group depending on which button is used to submit the form. For example,
 consider a form in a wizard that lets you advance to the next step or go back
-to the previous step. Let's assume also that when returning to the previous
-step, the data of the form should be saved, but not validated.
+to the previous step. Also assume that when returning to the previous step,
+the data of the form should be saved, but not validated.
 
 First, we need to add the two buttons to the form::
 

book/from_flat_php_to_symfony2.rst

@@ -75,8 +75,6 @@ to maintain. There are several problems that need to be addressed:
     tied to MySQL. Though not covered here, Symfony2 fully integrates `Doctrine`_,
     a library dedicated to database abstraction and mapping.
 
-Let's get to work on solving these problems and more.
-
 Isolating the Presentation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -673,8 +671,8 @@ Where Symfony2 Delivers
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 In the upcoming chapters, you'll learn more about how each piece of Symfony
-works and the recommended organization of a project. For now, let's see how
-migrating the blog from flat PHP to Symfony2 has improved life:
+works and the recommended organization of a project. For now, have a look
+at how migrating the blog from flat PHP to Symfony2 has improved life:
 
 * Your application now has **clear and consistently organized code** (though
   Symfony doesn't force you into this). This promotes **reusability** and

book/security.rst

@@ -148,8 +148,8 @@ that looks like the following:
 * All URLs *not* matching ``/admin/*`` are accessible by all users (and the
   user is never prompted to log in).
 
-Let's look briefly at how security works and how each part of the configuration
-comes into play.
+Read this short summary about how security works and how each part of the
+configuration comes into play.
 
 How Security Works: Authentication and Authorization
 ----------------------------------------------------
@@ -541,7 +541,7 @@ And that's it! When you submit the form, the security system will automatically
 check the user's credentials and either authenticate the user or send the
 user back to the login form where the error can be displayed.
 
-Let's review the whole process:
+To review the whole process:
 
 #. The user tries to access a resource that is protected;
 #. The firewall initiates the authentication process by redirecting the

components/console/introduction.rst

@@ -27,7 +27,7 @@ You can install the component in 2 different ways:
     configured with an ANSI driver and your console commands invoke other scripts which
     emit ANSI color sequences, they will be shown as raw escape characters.
 
-    To enable ANSI colour support for Windows, please install `ANSICON`_.
+    To enable ANSI color support for Windows, please install `ANSICON`_.
 
 Creating a basic Command
 ------------------------

components/filesystem.rst

@@ -162,8 +162,8 @@ the mode of a file. The fourth argument is a boolean recursive option::
 Remove
 ~~~~~~
 
-:method:`Symfony\\Component\\Filesystem\\Filesystem::remove` let's you remove
-files, symlink, directories easily::
+:method:`Symfony\\Component\\Filesystem\\Filesystem::remove` is used to remove
+files, symlinks, directories easily::
 
     $fs->remove(array('symlink', '/path/to/directory', 'activity.log'));
 

components/http_foundation/session_configuration.rst

@@ -7,7 +7,7 @@ Configuring Sessions and Save Handlers
 
 This section deals with how to configure session management and fine tune it
 to your specific needs. This documentation covers save handlers, which
-store and retrieve session data, and configuring session behaviour.
+store and retrieve session data, and configuring session behavior.
 
 Save Handlers
 ~~~~~~~~~~~~~
@@ -57,7 +57,7 @@ Example usage::
 
     Native save handlers provide a quick solution to session storage, however, in complex systems
     where you need more control, custom save handlers may provide more freedom and flexibility.
-    Symfony2 provides several implementations which you may further customise as required.
+    Symfony2 provides several implementations which you may further customize as required.
 
 Custom Save Handlers
 --------------------

components/routing/introduction.rst

@@ -25,7 +25,7 @@ In order to set up a basic routing system you need three parts:
 * A :class:`Symfony\\Component\\Routing\\RequestContext`, which has information about the request
 * A :class:`Symfony\\Component\\Routing\\Matcher\\UrlMatcher`, which performs the mapping of the request to a single route
 
-Let's see a quick example. Notice that this assumes that you've already configured
+Here is a quick example. Notice that this assumes that you've already configured
 your autoloader to load the Routing component::
 
     use Symfony\Component\Routing\Matcher\UrlMatcher;

components/serializer.rst

@@ -129,7 +129,7 @@ method on the normalizer definition::
 Deserializing an Object
 -----------------------
 
-Let's see now how to do the exactly the opposite. This time, the information
+You'll now learn how to do the exact opposite. This time, the information
 of the ``Person`` class would be encoded in XML format::
 
     $data = <<<EOF

cookbook/assetic/apply_to_option.rst

@@ -6,7 +6,7 @@ How to Apply an Assetic Filter to a Specific File Extension
 
 Assetic filters can be applied to individual files, groups of files or even,
 as you'll see here, files that have a specific extension. To show you how
-to handle each option, let's suppose that you want to use Assetic's CoffeeScript
+to handle each option, suppose that you want to use Assetic's CoffeeScript
 filter, which compiles CoffeeScript files into JavaScript.
 
 The main configuration is just the paths to coffee, node and node_modules.

cookbook/cache/varnish.rst

@@ -90,7 +90,7 @@ that will invalidate the cache for a given resource:
 
     sub vcl_recv {
         /*
-        Varnish default behaviour doesn't support PURGE.
+        Varnish default behavior doesn't support PURGE.
         Match the PURGE request and immediately do a cache lookup,
         otherwise Varnish will directly pipe the request to the backend
         and bypass the cache

cookbook/configuration/apache_router.rst

@@ -52,7 +52,7 @@ Symfony2 to use the ``ApacheUrlMatcher`` instead of the default one:
 Generating mod_rewrite rules
 ----------------------------
 
-To test that it's working, let's create a very basic route for the AcmeDemoBundle:
+To test that it's working, create a very basic route for the AcmeDemoBundle:
 
 .. configuration-block::
 

cookbook/configuration/override_dir_structure.rst

@@ -51,7 +51,7 @@ the location of the cache directory to ``app/{environment}/cache``.
 .. caution::
 
     You should keep the ``cache`` directory different for each environment,
-    otherwise some unexpected behaviour may happen. Each environment generates
+    otherwise some unexpected behavior may happen. Each environment generates
     its own cached config files, and so each needs its own directory to store
     those cache files.
 

cookbook/deployment-tools.rst

@@ -34,7 +34,7 @@ How to deploy a Symfony2 application
 
 There are several ways you can deploy a Symfony2 application.
 
-Let's start with a few basic deployment strategies and build up from there.
+Start with a few basic deployment strategies and build up from there.
 
 Basic File Transfer
 ~~~~~~~~~~~~~~~~~~~

cookbook/doctrine/dbal.rst

@@ -131,7 +131,7 @@ The SchemaTool is used to inspect the database to compare the schema. To
 achieve this task, it needs to know which mapping type needs to be used
 for each database types. Registering new ones can be done through the configuration.
 
-Let's map the ENUM type (not supported by DBAL by default) to a the ``string``
+Now, map the ENUM type (not supported by DBAL by default) to the ``string``
 mapping type:
 
 .. configuration-block::

cookbook/doctrine/resolve_target_entity.rst

@@ -34,8 +34,8 @@ with a real object that implements that interface.
 Set up
 ------
 
-Let's use the following basic entities (which are incomplete for brevity)
-to explain how to set up and use the RTEL.
+This article uses the following two basic entities (which are incomplete for
+brevity) to explain how to set up and use the ``ResolveTargetEntityListener``.
 
 A Customer entity::
 
@@ -53,7 +53,7 @@ A Customer entity::
      */
     class Customer extends BaseCustomer implements InvoiceSubjectInterface
     {
-        // In our example, any methods defined in the InvoiceSubjectInterface
+        // In this example, any methods defined in the InvoiceSubjectInterface
         // are already implemented in the BaseCustomer
     }
 

cookbook/form/create_custom_field_type.rst

@@ -99,10 +99,10 @@ part by the value of your ``getName()`` method. For more information, see
 
 In this case, since the 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),
-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:
+type. But for the sake of this example, suppose that when your field is "expanded"
+(i.e. radio buttons or checkboxes, instead of a select field), 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:
 
 .. configuration-block::
 

cookbook/form/create_form_type_extension.rst

@@ -39,9 +39,9 @@ template. But field type extensions allow you to do this in a nice DRY fashion.
 Defining the Form Type Extension
 --------------------------------
 
-Your first task will be to create the form type extension class. Let's
-call it ``ImageTypeExtension``. By standard, form extensions usually live
-in the ``Form\Extension`` directory of one of your bundles.
+Your first task will be to create the form type extension class (called ``ImageTypeExtension``
+in this article). By standard, form extensions usually live in the ``Form\Extension``
+directory of one of your bundles.
 
 When creating a form type extension, you can either implement the
 :class:`Symfony\\Component\\Form\\FormTypeExtensionInterface` interface
@@ -133,8 +133,8 @@ Adding the extension Business Logic
 -----------------------------------
 
 The goal of your extension is to display nice images next to file inputs
-(when the underlying model contains images). For that purpose, let's assume
-that you use an approach similar to the one described in
+(when the underlying model contains images). For that purpose, suppose that
+you use an approach similar to the one described in
 :doc:`How to handle File Uploads with Doctrine </cookbook/doctrine/file_uploads>`:
 you have a Media model with a file property (corresponding to the file field
 in the form) and a path property (corresponding to the image path in the

cookbook/form/dynamic_form_modification.rst

@@ -29,8 +29,8 @@ field.
 Customizing your Form based on the underlying Data
 --------------------------------------------------
 
-Before jumping right into dynamic form generation, let's have a quick review
-of what a bare form class looks like::
+Before jumping right into dynamic form generation, hold on and recall what
+a bare form class looks like::
 
     // src/Acme/DemoBundle/Form/Type/ProductType.php
     namespace Acme\DemoBundle\Form\Type;
@@ -226,7 +226,7 @@ How to Dynamically Generate Forms based on user Data
 
 Sometimes you want a form to be generated dynamically based not only on data
 from the form but also on something else - like some data from the current user.
-Suppose you have a social website where a user can only message people marked 
+Suppose you have a social website where a user can only message people marked
 as friends on the website. In this case, a "choice list" of whom to message
 should only contain users that are the current user's friends.
 

cookbook/form/form_collections.rst

@@ -20,8 +20,8 @@ that Task, right inside the same form.
     including the ``ManyToMany`` association mapping definition on the Task's
     ``tags`` property.
 
-Let's start there: suppose that each ``Task`` belongs to multiple ``Tag``
-objects. Start by creating a simple ``Task`` class::
+First, suppose that each ``Task`` belongs to multiple ``Tag`` objects. Start
+by creating a simple ``Task`` class::
 
     // src/Acme/TaskBundle/Entity/Task.php
     namespace Acme\TaskBundle\Entity;
@@ -77,8 +77,7 @@ objects::
     The ``name`` property is public here, but it can just as easily be protected
     or private (but then it would need ``getName`` and ``setName`` methods).
 
-Now let's get to the forms. Create a form class so that a ``Tag`` object
-can be modified by the user::
+Then, create a form class so that a ``Tag`` object can be modified by the user::
 
     // src/Acme/TaskBundle/Form/Type/TagType.php
     namespace Acme\TaskBundle\Form\Type;

cookbook/form/inherit_data_option.rst

@@ -44,7 +44,7 @@ entities, a ``Company`` and a ``Customer``::
 As you can see, each entity shares a few of the same fields: ``address``,
 ``zipcode``, ``city``, ``country``.
 
-Let's build two forms for these entities, ``CompanyType`` and ``CustomerType``::
+Start with building two forms for these entities, ``CompanyType`` and ``CustomerType``::
 
     // src/Acme/HelloBundle/Form/Type/CompanyType.php
     namespace Acme\HelloBundle\Form\Type;
@@ -81,8 +81,8 @@ Let's build two forms for these entities, ``CompanyType`` and ``CustomerType``::
     }
 
 Instead of including the duplicated fields ``address``, ``zipcode``, ``city``
-and ``country`` in both of these forms, we will create a third form for that.
-We will call this form simply ``LocationType``::
+and ``country`` in both of these forms, create a third form called ``LocationType``
+for that::
 
     // src/Acme/HelloBundle/Form/Type/LocationType.php
     namespace Acme\HelloBundle\Form\Type;
@@ -127,7 +127,7 @@ access the properties of the ``Customer`` instance instead. Easy, eh?
     can also (just like with any option) pass it in the third argument of
     ``$builder->add()``.
 
-Let's make this work by adding the location form to our two original forms::
+Finally, make this work by adding the location form to your two original forms::
 
     // src/Acme/HelloBundle/Form/Type/CompanyType.php
     public function buildForm(FormBuilderInterface $builder, array $options)

cookbook/form/unit_testing.rst

@@ -73,7 +73,7 @@ The simplest ``TypeTestCase`` implementation looks like the following::
         }
     }
 
-So, what does it test? Let's explain it line by line.
+So, what does it test? Here comes a detailed explanation.
 
 First you verify if the ``FormType`` compiles. This includes basic class
 inheritance, the ``buildForm`` function and options resolution. This should

cookbook/routing/custom_route_loader.rst

@@ -202,9 +202,9 @@ Instead, you only need to add a few extra lines to the routing configuration:
         return $collection;
 
 The important part here is the ``type`` key. Its value should be "extra".
-This is the type which our ``ExtraLoader`` supports and this will make sure
+This is the type which the ``ExtraLoader`` supports and this will make sure
 its ``load()`` method gets called. The ``resource`` key is insignificant
-for the ``ExtraLoader``, so we set it to ".".
+for the ``ExtraLoader``, so it is set to ".".
 
 .. note::
 

cookbook/security/acl.rst

@@ -87,8 +87,8 @@ Fortunately, there is a task for this. Simply run the following command:
 Getting Started
 ---------------
 
-Coming back to the small example from the beginning, let's implement ACL for
-it.
+Coming back to the small example from the beginning, you can now implement
+ACL for it.
 
 Creating an ACL, and adding an ACE
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cookbook/security/acl_advanced.rst

@@ -77,7 +77,7 @@ Symfony2, there are basically two different scopes:
   it only applies to one specific object.
 
 Sometimes, you will find the need to apply an ACE only to a specific field of
-the object. Let's say you want the ID only to be viewable by an administrator,
+the object. Suppose you want the ID only to be viewable by an administrator,
 but not by your customer service. To solve this common problem, two more sub-scopes
 have been added:
 

cookbook/security/custom_provider.rst

@@ -33,7 +33,7 @@ which defines a method to check if the user is equal to the current user. This
 interface requires an :method:`Symfony\\Component\\Security\\Core\\User\\EquatableInterface::isEqualTo`
 method.
 
-Let's see this in action::
+This is how your ``WebserviceUser`` class looks in action::
 
     // src/Acme/WebserviceUserBundle/Security/User/WebserviceUser.php
     namespace Acme\WebserviceUserBundle\Security\User;

cookbook/service_container/scopes.rst

@@ -1,7 +1,7 @@
 .. index::
    single: DependencyInjection; Scopes
 
-How to work with Scopes
+How to Work with Scopes
 =======================
 
 This entry is all about scopes, a somewhat advanced topic related to the
@@ -42,12 +42,12 @@ when compiling the container. Read the sidebar below for more details.
 
     Imagine, however, that you need the ``request`` service in your ``my_mailer``
     service, maybe because you're reading the URL of the current request.
-    So, you add it as a constructor argument. Let's look at why this presents
-    a problem:
+    So, you add it as a constructor argument. There are several reasons why
+    this presents a problem:
 
-    * When requesting ``my_mailer``, an instance of ``my_mailer`` (let's call
-      it *MailerA*) is created and the ``request`` service (let's call it
-      *RequestA*) is passed to it. Life is good!
+    * When requesting ``my_mailer``, an instance of ``my_mailer`` (called
+      *MailerA*) is created and the ``request`` service (called *RequestA*)
+      is passed to it. Life is good!
 
     * You've now made a subrequest in Symfony, which is a fancy way of saying
       that you've called, for example, the ``{{ render(...) }}`` Twig function,

cookbook/symfony1.rst

@@ -50,8 +50,8 @@ directory is a bit like the ``plugins`` directory in symfony1, but much more
 flexible. Additionally, while *your* bundles will live in the ``src/`` directory,
 third-party bundles will live somewhere in the ``vendor/`` directory.
 
-To get a better picture of the ``src/`` directory, let's first think of a
-symfony1 application. First, part of your code likely lives inside one or
+To get a better picture of the ``src/`` directory, first think of the structure
+of a symfony1 application. First, part of your code likely lives inside one or
 more applications. Most commonly these include modules, but could also include
 any other PHP classes you put in your application. You may have also created
 a ``schema.yml`` file in the ``config`` directory of your project and built

cookbook/templating/PHP.rst

@@ -100,7 +100,7 @@ is the same notation used to reference a template. The ``::`` part simply
 means that the controller element is empty, so the corresponding file is
 directly stored under ``views/``.
 
-Now, let's have a look at the ``layout.html.php`` file:
+Now, have a look at the ``layout.html.php`` file:
 
 .. code-block:: html+php