be keen to newcomers

Author: OskarStark

create_framework/http_kernel_httpkernelinterface.rst

@@ -90,11 +90,10 @@ to cache a response for 10 seconds, use the ``Response::setTtl()`` method::
 
 .. tip::
 
-    If, like me, you are running your framework from the command line by
-    simulating requests (``Request::create('/is_leap_year/2012')``), you can
-    easily debug Response instances by dumping their string representation
-    (``echo $response;``) as it displays all headers as well as the response
-    content.
+    If you are running your framework from the command line by simulating
+    requests (``Request::create('/is_leap_year/2012')``), you can debug
+    Response instances by dumping their string representation (``echo $response;``)
+    as it displays all headers as well as the response content.
 
 To validate that it works correctly, add a random number to the response
 content and check that the number only changes every 10 seconds::
@@ -114,8 +113,8 @@ comfortable with these concepts, read the `HTTP caching`_ chapter of the
 Symfony documentation.
 
 The Response class contains many other methods that let you configure the
-HTTP cache very easily. One of the most powerful is ``setCache()`` as it
-abstracts the most frequently used caching strategies into one simple array::
+HTTP cache. One of the most powerful is ``setCache()`` as it abstracts the
+most frequently used caching strategies into one array::
 
     $date = date_create_from_format('Y-m-d H:i:s', '2005-10-15 10:00:00');
 
@@ -135,8 +134,8 @@ abstracts the most frequently used caching strategies into one simple array::
     $response->setSharedMaxAge(10);
 
 When using the validation model, the ``isNotModified()`` method allows you to
-easily cut on the response time by short-circuiting the response generation as
-early as possible::
+cut on the response time by short-circuiting the response generation as early
+as possible::
 
     $response->setETag('whatever_you_compute_as_an_etag');
 

forms.rst

@@ -178,9 +178,9 @@ That's it! Just three lines are needed to render the complete form:
 
 .. seealso::
 
-    As easy as this is, it's not very flexible (yet). Usually, you'll want to
-    render each form field individually so you can control how the form looks.
-    You'll learn how to do that in the ":doc:`/form/rendering`" section.
+    Usually, you'll want to render each form field individually to be more
+    flexible so you can control how the form looks. You'll learn how to do
+    that in the ":doc:`/form/rendering`" section.
 
 Before moving on, notice how the rendered ``task`` input field has the value
 of the ``task`` property from the ``$task`` object (i.e. "Write a blog post").
@@ -611,9 +611,9 @@ be used to quickly build a form object in the controller::
         // ...
     }
 
-Placing the form logic into its own class means that the form can be easily
-reused elsewhere in your project. This is the best way to create forms, but
-the choice is ultimately up to you.
+Placing the form logic into its own class means that the form can be reused
+elsewhere in your project. This is the best way to create forms, but the
+choice is ultimately up to you.
 
 .. _form-data-class:
 

http_cache/esi.rst

@@ -250,6 +250,6 @@ The ``render_esi`` helper supports two other useful options:
 ``ignore_errors``
     If set to true, an ``onerror`` attribute will be added to the ESI with a value
     of ``continue`` indicating that, in the event of a failure, the gateway cache
-    will simply remove the ESI tag silently.
+    will remove the ESI tag silently.
 
 .. _`ESI`: http://www.w3.org/TR/esi-lang

http_cache/expiration.rst

@@ -15,10 +15,10 @@ HTTP headers: ``Expires`` or ``Cache-Control``.
 .. sidebar:: Expiration and Validation
 
     You can of course use both validation and expiration within the same ``Response``.
-    As expiration wins over validation, you can easily benefit from the best of
-    both worlds. In other words, by using both expiration and validation, you
-    can instruct the cache to serve the cached content, while checking back
-    at some interval (the expiration) to verify that the content is still valid.
+    As expiration wins over validation, you can benefit from the best of both worlds.
+    In other words, by using both expiration and validation, you can instruct the cache
+    to serve the cached content, while checking back at some interval (the expiration)
+    to verify that the content is still valid.
 
     .. tip::
 

http_cache/validation.rst

@@ -23,7 +23,7 @@ page again (see below for an implementation example).
 
     The 304 status code means "Not Modified". It's important because with
     this status code the response does *not* contain the actual content being
-    requested. Instead, the response is simply a light-weight set of directions that
+    requested. Instead, the response is a light-weight set of directions that
     tells the cache that it should use its stored version.
 
 Like with expiration, there are two different HTTP headers that can be used
@@ -32,10 +32,10 @@ to implement the validation model: ``ETag`` and ``Last-Modified``.
 .. sidebar:: Expiration and Validation
 
     You can of course use both validation and expiration within the same ``Response``.
-    As expiration wins over validation, you can easily benefit from the best of
-    both worlds. In other words, by using both expiration and validation, you
-    can instruct the cache to serve the cached content, while checking back
-    at some interval (the expiration) to verify that the content is still valid.
+    As expiration wins over validation, you can benefit from the best of both worlds.
+    In other words, by using both expiration and validation, you can instruct the cache
+    to serve the cached content, while checking back at some interval (the expiration)
+    to verify that the content is still valid.
 
     .. tip::