symfony · weaverryan · Nov 12, 2013 · Oct 4, 2012 · Nov 8, 2013 · Nov 8, 2013
diff --git a/book/http_fundamentals.rst b/book/http_fundamentals.rst
@@ -551,7 +551,7 @@ So then, what *is* the Symfony2 *Framework*? The *Symfony2 Framework* is
 a PHP library that accomplishes two distinct tasks:
 
 #. Provides a selection of components (i.e. the Symfony2 Components) and
-   third-party libraries (e.g. `Swiftmailer`_ for sending emails);
+   third-party libraries (e.g. `Swift Mailer`_ for sending emails);
 
 #. Provides sensible configuration and a "glue" library that ties all of these
    pieces together.
@@ -577,4 +577,4 @@ sensible defaults. For more advanced users, the sky is the limit.
 .. _`Validator`: https://github.com/symfony/Validator
 .. _`Security`: https://github.com/symfony/Security
 .. _`Translation`: https://github.com/symfony/Translation
-.. _`Swiftmailer`: http://swiftmailer.org/
+.. _`Swift Mailer`: http://swiftmailer.org/
diff --git a/book/testing.rst b/book/testing.rst
@@ -677,7 +677,7 @@ The Client used by functional tests creates a Kernel that runs in a special
 in the ``test`` environment, you can tweak any of your application's settings
 specifically for testing.
 
-For example, by default, the swiftmailer is configured to *not* actually
+For example, by default, the Swift Mailer is configured to *not* actually
 deliver emails in the ``test`` environment. You can see this under the ``swiftmailer``
 configuration option:
 

diff --git a/components/dependency_injection/compilation.rst b/components/dependency_injection/compilation.rst
@@ -13,7 +13,7 @@ It is compiled by running::
 
     $container->compile();
 
-The compile method uses *Compiler Passes* for the compilation. The *Dependency Injection*
+The compile method uses *Compiler Passes* for the compilation. The Dependency Injection
 component comes with several passes which are automatically registered for
 compilation. For example the :class:`Symfony\\Component\\DependencyInjection\\Compiler\\CheckDefinitionValidityPass`
 checks for various potential issues with the definitions that have been set
@@ -40,7 +40,7 @@ and can be registered with the container with::
 
     $container->registerExtension($extension);
 
-The main work of the extension is done in the ``load`` method. In the load method
+The main work of the extension is done in the ``load`` method. In the ``load`` method
 you can load configuration from one or more configuration files as well as
 manipulate the container definitions using the methods shown in :doc:`/components/dependency_injection/definitions`.
 

diff --git a/components/dependency_injection/definitions.rst b/components/dependency_injection/definitions.rst
@@ -73,7 +73,7 @@ You can add a new argument to the end of the arguments array using::
     $definition->addArgument($argument);
 
 The argument can be a string, an array, a service parameter by using ``%parameter_name%``
-or a service id by using ::
+or a service id by using::
 
     use Symfony\Component\DependencyInjection\Reference;
 
@@ -122,6 +122,6 @@ You can also replace any existing method calls with an array of new ones with::
 .. note::
 
     The methods here that change service definitions can only be used before
-    the container is compiled, once the container is compiled you cannot
+    the container is compiled. Once the container is compiled you cannot
     manipulate service definitions further. To learn more about compiling
     the container see :doc:`/components/dependency_injection/compilation`.
diff --git a/components/dependency_injection/factories.rst b/components/dependency_injection/factories.rst
@@ -12,7 +12,7 @@ For this situation, you can use a factory to create the object and tell the
 service container to call a method on the factory rather than directly instantiating
 the class.
 
-Suppose you have a factory that configures and returns a new NewsletterManager
+Suppose you have a factory that configures and returns a new ``NewsletterManager``
 object::
 
     class NewsletterFactory

diff --git a/components/dependency_injection/parameters.rst b/components/dependency_injection/parameters.rst
@@ -60,7 +60,7 @@ One use for this is to inject the values into your services. This allows
 you to configure different versions of services between applications or multiple
 services based on the same class but configured differently within a single
 application. You could inject the choice of mail transport into the ``Mailer``
-class directly but by making it a parameter. This makes it easier to change
+class directly. But declaring it as a parameter makes it easier to change
 rather than being tied up and hidden with the service definition:
 
 .. configuration-block::
@@ -343,7 +343,7 @@ Start the string with  ``@`` or ``@?`` to reference a service in Yaml.
     converted into the string ``"@mailer"`` instead of referencing the
     ``mailer`` service.
 
-Xml
+XML
 ~~~
 
 In XML, use the ``service`` type. The behavior if the service does not exist
@@ -352,7 +352,7 @@ is thrown. Valid values for ``on-invalid`` are ``null`` (uses ``null`` in place
 of the missing service) or ``ignored`` (very similar, except if used on a
 method call, the method call is removed).
 
-Php
+PHP
 ~~~
 
 In PHP, you can use the

diff --git a/components/dependency_injection/tags.rst b/components/dependency_injection/tags.rst
@@ -27,7 +27,7 @@ To begin with, define the ``TransportChain`` class::
             $this->transports = array();
         }
 
-        public function addTransport(\Swift_Transport  $transport)
+        public function addTransport(\Swift_Transport $transport)
         {
             $this->transports[] = $transport;
         }
@@ -176,7 +176,7 @@ Adding additional attributes on Tags
 ------------------------------------
 
 Sometimes you need additional information about each service that's tagged with your tag.
-For example, you might want to add an alias to each TransportChain.
+For example, you might want to add an alias to each member of the transport chain.
 
 To begin with, change the ``TransportChain`` class::
 

diff --git a/components/event_dispatcher/introduction.rst b/components/event_dispatcher/introduction.rst
@@ -564,7 +564,7 @@ Or::
 
 Or::
 
-    $response = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
+    $bar = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
 
 and so on...
 

diff --git a/components/form/introduction.rst b/components/form/introduction.rst
@@ -334,12 +334,12 @@ and then access it whenever you need to build a form.
 
 .. note::
 
-    In this document, the form factory is always a locally variable called
+    In this document, the form factory is always a local variable called
     ``$formFactory``. The point here is that you will probably need to create
     this object in some more "global" way so you can access it from anywhere.
 
 Exactly how you gain access to your one form factory is up to you. If you're
-using a :term`Service Container`, then you should add the form factory to
+using a :term:`Service Container`, then you should add the form factory to
 your container and grab it out whenever you need to. If your application
 uses global or static variables (not usually a good idea), then you can store
 the object on some static class or do something similar.
@@ -414,7 +414,7 @@ it and :ref:`process the form submission <component-form-intro-handling-submissi
 Setting Default Values
 ~~~~~~~~~~~~~~~~~~~~~~
 
-If you need you form to load with some default values (or you're building
+If you need your form to load with some default values (or you're building
 an "edit" form), simply pass in the default data when creating your form
 builder:
 

diff --git a/components/http_foundation/introduction.rst b/components/http_foundation/introduction.rst
@@ -61,7 +61,7 @@ can be accessed via several public properties:
 
 * ``cookies``: equivalent of ``$_COOKIE``;
 
-* ``attributes``: no equivalent - used by your app to store other data (see :ref:`below <component-foundation-attributes>`)
+* ``attributes``: no equivalent - used by your app to store other data (see :ref:`below <component-foundation-attributes>`);
 
 * ``files``: equivalent of ``$_FILES``;
 
@@ -109,7 +109,7 @@ methods to retrieve and update its data:
   parameter by name;
 
 * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::has`: Returns
-  true if the parameter is defined;
+  ``true`` if the parameter is defined;
 
 * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::remove`: Removes
   a parameter.
@@ -461,7 +461,7 @@ whether or not the ``X-Sendfile-Type`` header should be trusted and call
 :method:`Symfony\\Component\\HttpFoundation\\BinaryFileResponse::trustXSendfileTypeHeader`
 if it should::
 
-    $response::trustXSendfileTypeHeader();
+    BinaryFileResponse::trustXSendfileTypeHeader();
 
 You can still set the ``Content-Type`` of the sent file, or change its ``Content-Disposition``::
 

diff --git a/components/http_foundation/session_configuration.rst b/components/http_foundation/session_configuration.rst
@@ -119,7 +119,7 @@ be securely controlled from the server side.
 
     The ``cookie_lifetime`` setting is the number of seconds the cookie should live
     for, it is not a Unix timestamp. The resulting session cookie will be stamped
-    with an expiry time of ``time()``+``cookie_lifetime`` where the time is taken
+    with an expiry time of ``time()`` + ``cookie_lifetime`` where the time is taken
     from the server.
 
 Configuring Garbage Collection
@@ -132,7 +132,7 @@ of 5%. Similarly, ``3/4`` would mean a 3 in 4 chance of being called, i.e. 75%.
 
 If the garbage collection handler is invoked, PHP will pass the value stored in
 the ``php.ini`` directive ``session.gc_maxlifetime``. The meaning in this context is
-that any stored session that was saved more than ``maxlifetime`` ago should be
+that any stored session that was saved more than ``gc_maxlifetime`` ago should be
 deleted. This allows one to expire records based on idle time.
 
 You can configure these settings by passing ``gc_probability``, ``gc_divisor``
@@ -173,8 +173,8 @@ example, it is common for banking applications to log the user out after just
 5 to 10 minutes of inactivity. Setting the cookie lifetime here is not
 appropriate because that can be manipulated by the client, so we must do the expiry
 on the server side. The easiest way is to implement this via garbage collection
-which runs reasonably frequently. The cookie ``lifetime`` would be set to a
-relatively high value, and the garbage collection ``maxlifetime`` would be set
+which runs reasonably frequently. The ``cookie_lifetime`` would be set to a
+relatively high value, and the garbage collection ``gc_maxlifetime`` would be set
 to destroy sessions at whatever the desired idle period is.
 
 The other option is to specifically checking if a session has expired after the
@@ -258,7 +258,7 @@ without knowledge of the specific save handler.
 
 .. note::
 
-    Before PHP 5.4, you can only proxy user-land save handlers but not 
+    Before PHP 5.4, you can only proxy user-land save handlers but not
     native PHP save handlers.
 
 .. _`php.net/session.customhandler`: http://php.net/session.customhandler

diff --git a/components/http_foundation/session_testing.rst b/components/http_foundation/session_testing.rst
@@ -18,7 +18,7 @@ starting one allowing you to test your code without complications. You may also
 run multiple instances in the same PHP process.
 
 The mock storage drivers do not read or write the system globals
-`session_id()` or `session_name()`. Methods are provided to simulate this if
+``session_id()`` or ``session_name()``. Methods are provided to simulate this if
 required:
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\SessionStorageInterface::getId`: Gets the

diff --git a/components/http_foundation/sessions.rst b/components/http_foundation/sessions.rst
@@ -66,24 +66,24 @@ as follows divided into a couple of groups.
 Session workflow
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::start`:
-  Starts the session - do not use ``session_start()``.
+  Starts the session - do not use ``session_start()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::migrate`:
   Regenerates the session ID - do not use ``session_regenerate_id()``.
   This method can optionally change the lifetime of the new cookie that will
-  be emitted by calling this method.
+  be emitted by calling this method;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::invalidate`:
-  Clears all session data and regenerates session ID. Do not use ``session_destroy()``.
+  Clears all session data and regenerates session ID. Do not use ``session_destroy()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getId`: Gets the
-  session ID. Do not use ``session_id()``.
+  session ID. Do not use ``session_id()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setId`: Sets the
-  session ID. Do not use ``session_id()``.
+  session ID. Do not use ``session_id()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getName`: Gets the
-  session name. Do not use ``session_name()``.
+  session name. Do not use ``session_name()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setName`: Sets the
   session name. Do not use ``session_name()``.
@@ -103,23 +103,23 @@ Session attributes
   Returns true if the attribute exists;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::replace`:
-  Sets multiple attributes at once: takes a keyed array and sets each key => value pair.
+  Sets multiple attributes at once: takes a keyed array and sets each key => value pair;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::remove`:
   Deletes an attribute by key;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::clear`:
-  Clear all attributes;
+  Clear all attributes.
 
 The attributes are stored internally in an "Bag", a PHP object that acts like
 an array. A few methods exist for "Bag" management:
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::registerBag`:
-  Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface`
+  Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface`;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getBag`:
   Gets a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface` by
-  bag name.
+  bag name;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getFlashBag`:
   Gets the :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\FlashBagInterface`.
@@ -242,7 +242,7 @@ would be displayed immediately on the subsequent page load for that session.
 This is however just one application for flash messages.
 
 * :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\AutoExpireFlashBag`
-   This implementation messages set in one page-load will
+   In this implementation, messages set in one page-load will
    be available for display only on the next page load. These messages will auto
    expire regardless of if they are retrieved or not.
 
@@ -306,7 +306,7 @@ Examples of setting multiple flashes::
     $session->getFlashBag()->add('error', 'Failed to update name');
     $session->getFlashBag()->add('error', 'Another error');
 
-Displaying the flash messages might look like this:
+Displaying the flash messages might look as follows.
 
 Simple, display one type of message::
 

diff --git a/components/http_kernel/introduction.rst b/components/http_kernel/introduction.rst
@@ -104,7 +104,7 @@ listeners to the events discussed below::
     // by dispatching events, calling a controller, and returning the response
     $response = $kernel->handle($request);
 
-    // echo the content and send the headers
+    // send the headers and echo the content
     $response->send();
 
     // triggers the kernel.terminate event
@@ -464,7 +464,7 @@ because it occurs *after* the ``HttpKernel::handle`` method, and after the
 response is sent to the user. Recall from above, then the code that uses
 the kernel, ends like this::
 
-    // echo the content and send the headers
+    // send the headers and echo the content
     $response->send();
 
     // triggers the kernel.terminate event

diff --git a/contributing/code/tests.rst b/contributing/code/tests.rst
@@ -25,7 +25,7 @@ autoloaded from `vendor/` under the main root directory (see
 The test suite needs the following third-party libraries:
 
 * Doctrine
-* Swiftmailer
+* Swift Mailer
 * Twig
 * Monolog
 

diff --git a/cookbook/controller/error_pages.rst b/cookbook/controller/error_pages.rst
@@ -63,7 +63,7 @@ end-user, create a new template located at
 .. tip::
 
     If you're not familiar with Twig, don't worry. Twig is a simple, powerful
-    and optional templating engine that integrates with ``Symfony2``. For more
+    and optional templating engine that integrates with Symfony2. For more
     information about Twig see :doc:`/book/templating`.
 
 In addition to the standard HTML error page, Symfony provides a default error

diff --git a/cookbook/deployment-tools.rst b/cookbook/deployment-tools.rst
@@ -84,7 +84,7 @@ B) Update your vendors
 Your vendors can be updated before transferring your source code (i.e.
 update the ``vendor/`` directory, then transfer that with your source
 code) or afterwards on the server. Either way, just update your vendors
-as your normally do:
+as you normally do:
 
 .. code-block:: bash
 

diff --git a/cookbook/email/dev_environment.rst b/cookbook/email/dev_environment.rst
@@ -109,13 +109,13 @@ Now, suppose you're sending an email to ``recipient@example.com``.
     }
 
 In the ``dev`` environment, the email will instead be sent to ``dev@example.com``.
-Swiftmailer will add an extra header to the email, ``X-Swift-To``, containing
+Swift Mailer will add an extra header to the email, ``X-Swift-To``, containing
 the replaced address, so you can still see who it would have been sent to.
 
 .. note::
 
     In addition to the ``to`` addresses, this will also stop the email being
-    sent to any ``CC`` and ``BCC`` addresses set for it. Swiftmailer will add
+    sent to any ``CC`` and ``BCC`` addresses set for it. Swift Mailer will add
     additional headers to the email with the overridden addresses in them.
     These are ``X-Swift-Cc`` and ``X-Swift-Bcc`` for the ``CC`` and ``BCC``
     addresses respectively.
-Original file line number
+Diff line change
@@ Expand Up / @@ -564,7 +564,7 @@ Or:: @@
     Or::
-        $response = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
+        $bar = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
     and so on...
@@ Expand Down @@