spotted minor EN mistakes and coherence issues between the different chapters

Author: Ca-Jou

create_framework/dependency_injection.rst

@@ -201,7 +201,7 @@ Now, here is how you can register a custom listener in the front controller::
         ->addMethodCall('addSubscriber', [new Reference('listener.string_response')])
     ;
 
-Beside describing your objects, the dependency injection container can also be
+Besides describing your objects, the dependency injection container can also be
 configured via parameters. Let's create one that defines if we are in debug
 mode or not::
 

create_framework/event_dispatcher.rst

@@ -23,7 +23,7 @@ version of this pattern:
 How does it work? The *dispatcher*, the central object of the event dispatcher
 system, notifies *listeners* of an *event* dispatched to it. Put another way:
 your code dispatches an event to the dispatcher, the dispatcher notifies all
-registered listeners for the event, and each listener do whatever it wants
+registered listeners for the event, and each listener does whatever it wants
 with the event.
 
 As an example, let's create a listener that transparently adds the Google
@@ -45,6 +45,9 @@ the Response instance::
 
     class Framework
     {
+        
+    	/* all properties are now declared as private, they were protected until this chapter -> either there is a good reason and it might be useful to explain this change, or there could be better coherence by keeping them protected *or* private in the entire book */
+
         private $dispatcher;
         private $matcher;
         private $controllerResolver;

create_framework/front_controller.rst

@@ -132,7 +132,7 @@ its sub-directories (only if needed -- see above tip).
     like ``$request = Request::create('/hello?name=Fabien');`` where the
     argument is the URL path you want to simulate.
 
-Now that the web server always access the same script (``front.php``) for all
+Now that the web server always accesses the same script (``front.php``) for all
 pages, we can secure the code further by moving all other PHP files outside the
 web root directory:
 

create_framework/http_foundation.rst

@@ -273,7 +273,7 @@ cases by yourself. Why not using a technology that already works?
     a look at the ``Symfony\Component\HttpFoundation`` API or read
     its dedicated :doc:`documentation </components/http_foundation>`.
 
-Believe or not but we have our first framework. You can stop now if you want.
+Believe it or not but we have our first framework. You can stop now if you want.
 Using just the Symfony HttpFoundation component already allows you to write
 better and more testable code. It also allows you to write code faster as many
 day-to-day problems have already been solved for you.
@@ -282,7 +282,7 @@ As a matter of fact, projects like Drupal have adopted the HttpFoundation
 component; if it works for them, it will probably work for you. Don't reinvent
 the wheel.
 
-I've almost forgot to talk about one added benefit: using the HttpFoundation
+I've almost forgotten to talk about one added benefit: using the HttpFoundation
 component is the start of better interoperability between all frameworks and
 `applications using it`_ (like `Symfony`_, `Drupal 8`_, `phpBB 3`_, `Laravel`_
 and `ezPublish 5`_,  and `more`_).

create_framework/http_kernel_controller_resolver.rst

@@ -31,7 +31,7 @@ The move is pretty straightforward and makes a lot of sense as soon as you
 create more pages but you might have noticed a non-desirable side effect...
 The ``LeapYearController`` class is *always* instantiated, even if the
 requested URL does not match the ``leap_year`` route. This is bad for one main
-reason: performance wise, all controllers for all routes must now be
+reason: performance-wise, all controllers for all routes must now be
 instantiated for every request. It would be better if controllers were
 lazy-loaded so that only the controller associated with the matched route is
 instantiated.

create_framework/http_kernel_httpkernelinterface.rst

@@ -46,8 +46,8 @@ Update your framework so that it implements this interface::
         }
     }
 
-Even if this change looks not too complex, it brings us a lot! Let's talk about one of
-the most impressive one: transparent :doc:`HTTP caching </http_cache>` support.
+Even if this change doesn't look like much, it brings us a lot! Let's talk about one of
+the most impressive ones: transparent :doc:`HTTP caching </http_cache>` support.
 
 The ``HttpCache`` class implements a fully-featured reverse proxy, written in
 PHP; it implements ``HttpKernelInterface`` and wraps another
@@ -64,6 +64,7 @@ PHP; it implements ``HttpKernelInterface`` and wraps another
         new HttpKernel\HttpCache\Store(__DIR__.'/../cache')
     );
 
+    /* $response variable used before and after this chapter -> keep it in this chapter for more global coherence? */
     $framework->handle($request)->send();
 
 That's all it takes to add HTTP caching support to our framework. Isn't it