Added a bunch of fixes suggested by @xabbuh

symfony · javiereguiluz · Oct 25, 2014 · Oct 25, 2014 · Nov 1, 2014 · Nov 12, 2014
commit fe20efd3cb0aadfe437c86e178c73370077f3535
diff --git a/quick_tour/the_architecture.rst b/quick_tour/the_architecture.rst
@@ -122,7 +122,7 @@ a single ``Bundle`` class that describes it::
 
 In addition to the AppBundle that was already talked about, notice that the
 kernel also enables other bundles such as the FrameworkBundle, DoctrineBundle,
-SwiftmailerBundle and AsseticBundle bundle. They are all part of the core framework.
+SwiftmailerBundle and AsseticBundle. They are all part of the core framework.
 
 Configuring a Bundle
 ~~~~~~~~~~~~~~~~~~~~
@@ -213,7 +213,7 @@ the location of the AppBundle.
 Logical Controller Names
 ........................
 
-For controllers, you need to reference action using the format
+For controllers, you need to reference actions using the format
 ``BUNDLE_NAME:CONTROLLER_NAME:ACTION_NAME``. For instance,
 ``AppBundle:Default:index`` maps to the ``indexAction`` method from the
 ``AppBundle\Controller\DefaultController`` class.
@@ -240,7 +240,7 @@ Using Vendors
 Odds are that your application will depend on third-party libraries. Those
 should be stored in the ``vendor/`` directory and managed by Composer.
 This directory already contains the Symfony libraries, the SwiftMailer library,
-the Doctrine ORM, the Twig templating system, and some other third party
+the Doctrine ORM, the Twig templating system and some other third party
 libraries and bundles.
 
 Understanding the Cache and Logs

diff --git a/quick_tour/the_big_picture.rst b/quick_tour/the_big_picture.rst
@@ -16,7 +16,7 @@ to display the installed PHP version:
 
 .. code-block:: bash
 
-  php --version
+    $ php --version
 
 .. _installing-symfony2:
 
@@ -37,12 +37,13 @@ On **Linux** and **Mac OS X** systems, execute the following console commands:
 
 .. note::
 
-    If your system doesn't have cURL installed, execute instead the following
-    command:
+    If your system doesn't have cURL installed, execute the following
+    commands instead:
 
     .. code-block:: bash
 
         $ php -r "readfile('https://symfony.com/installer');" | php
+        $ sudo mv symfony.phar /usr/local/bin/symfony
 
 After installing the Symfony installer, you'll have to open a new console window
 to be able to execute the new ``symfony`` command:
@@ -214,16 +215,17 @@ A **PHP annotation** is a convenient way to configure a method without having to
 write regular PHP code. Beware that annotation blocks start with ``/**``, whereas
 regular PHP comments start with ``/*``.
 
-The first value of ``@Route()`` defines the path that will trigger the execution
-of the action. This path is configured via a relative URL, so you don't have to
-add the host of your application (e.g. ```http://example.com``). In this case,
-the value ``/`` refers to the application homepage. The second value of ``@Route()``
-(e.g. ``name="homepage"``) is optional and sets the name of this route. For now
-this name is not needed, but later it'll be useful for linking pages.
+The first value of ``@Route()`` defines the URL that will trigger the execution
+of the action. As you don't have to add the host of your application to the URL
+(e.g. ```http://example.com``), these URLs are always relative and they are usually
+called *paths*. In this case, the ``/`` path refers to the application homepage.
+The second value of ``@Route()`` (e.g. ``name="homepage"``) is optional and sets
+the name of this route. For now this name is not needed, but later it'll be useful
+for linking pages.
 
 Considering all this, the ``@Route("/", name="homepage")`` annotation creates a
 new route called ``homepage`` which makes Symfony execute the ``index`` action
-of the ``Default`` controller when the users browses the ``/`` URL of the application.
+of the ``Default`` controller when the user browses the ``/`` path of the application.
 
 .. tip::
 
@@ -259,7 +261,7 @@ the following code:
     {% endblock %}
 
 This template is created with `Twig`_, a new template engine created for modern
-PHP applications. The :doc:`second part of this tutorial</quick_tour/the_view>`
+PHP applications. The :doc:`second part of this tutorial </quick_tour/the_view>`
 will introduce how templates work in Symfony.
 
 .. _quick-tour-big-picture-environments:
@@ -287,8 +289,8 @@ may be worried about your visitors accessing sensible information. Symfony is
 aware of this issue and for that reason, it won't display this bar when your
 application is running in the production server.
    
-How does Symfony knows when is your application running locally or in a production
-server? Keep reading to discover the concept of **execution environments**.
+How does Symfony know  whether your application is running locally or on a
+production server? Keep reading to discover the concept of **execution environments**.
 
 .. _quick-tour-big-picture-environments-intro:
 

diff --git a/quick_tour/the_controller.rst b/quick_tour/the_controller.rst
@@ -14,7 +14,7 @@ any action of any controller is the creation of a ``Response`` object which
 Symfony uses to generate the HTML content returned to the user.
 
 So far, all the actions shown in this tutorial used the ``$this->render()``
-shortcut to return a rendered response as result. If case you need it, you can
+shortcut to return a rendered response as result. In case you need it, you can
 also create a raw ``Response`` object to return any text content::
 
     // src/AppBundle/Controller/DefaultController.php
@@ -125,7 +125,7 @@ its default value::
     }
 
 Obviously, when you support several request formats, you have to provide a
-tempalte for each of the supported formats. In this case, you should create a
+template for each of the supported formats. In this case, you should create a
 new ``hello.xml.twig`` template:
 
 .. code-block:: xml+php
@@ -144,7 +144,7 @@ in your browser.
 
 That's all there is to it. For standard formats, Symfony will also
 automatically choose the best ``Content-Type`` header for the response. To
-restrict the the formats supported by a given action, use the ``requirements``
+restrict the formats supported by a given action, use the ``requirements``
 option of the ``@Route()`` annotation::
 
     // src/AppBundle/Controller/DefaultController.php
@@ -190,9 +190,8 @@ method::
         }
     }
 
-The ``redirectToRoute()`` is similar to the ``path()`` function used in the
-templates. It takes the route name and an array of parameters as arguments and
-returns the associated friendly URL.
+The ``redirectToRoute()`` method takes as arguments the route name and an optional
+array of parameters and redirects the user to the URL generated with those arguments.
 
 You can also internally forward the action to another action of the same or
 different controller using the ``forward()`` method::
@@ -226,6 +225,7 @@ use in your controllers::
          */
         public function indexAction()
         {
+            // ...
             throw $this->createNotFoundException();
         }
     }
@@ -241,6 +241,7 @@ Symfony will transform it into a proper ``500`` error page::
          */
         public function indexAction()
         {
+            // ...
             throw new \Exception('Something went horribly wrong!');
         }
     }
@@ -249,7 +250,7 @@ Getting Information from the Request
 ------------------------------------
 
 Sometimes your controllers need to access the information related to the user
-request, such as his/her preferred language, IP address or the URL query parameters.
+request, such as their preferred language, IP address or the URL query parameters.
 To get access to this information, add a new argument of type ``Request`` to the
 action. The name of this new argument doesn't matter, but it must be preceded
 by the ``Request`` type in order to work (don't forget to add the new ``use``
@@ -346,4 +347,4 @@ That's all there is to it, and I'm not even sure you'll have spent the full
 10 minutes. You were briefly introduced to bundles in the first part, and all the
 features you've learned about so far are part of the core framework bundle.
 But thanks to bundles, everything in Symfony can be extended or replaced.
-That's the topic of the :doc:`next part of this tutorial<the_architecture>`.
+That's the topic of the :doc:`next part of this tutorial <the_architecture>`.
diff --git a/quick_tour/the_view.rst b/quick_tour/the_view.rst
@@ -50,7 +50,7 @@ Below is a minimal template that illustrates a few basics, using two variables
 
 To render a template in Symfony, use the ``render`` method from within a controller.
 If the template needs variables to generate its contents, pass them as an array
-using the second optional second argument::
+using the second optional argument::
 
     $this->render('default/index.html.twig', array(
         'variable_name' => 'variable_value',
@@ -156,7 +156,7 @@ The best way to share a snippet of code between several templates is to create a
 new template fragment that can then be included from other templates.
 
 Imagine that we want to display ads on some pages of our application. First,
-create an ``banner.html.twig`` template:
+create a ``banner.html.twig`` template:
 
 .. code-block:: jinja
 
@@ -229,8 +229,8 @@ updated by just changing the configuration:
 
     <a href="{{ path('homepage') }}">Return to homepage</a>
 
-The ``path`` function takes the route name as the first argument and optionally
-you can pass an array of route parameters as the second argument.
+The ``path`` function takes the route name as the first argument and you can
+optionally pass an array of route parameters as the second argument.
 
 .. tip::
 
@@ -251,8 +251,8 @@ Symfony provides the ``asset`` function to deal with them easily:
     <img src="{{ asset('images/logo.png') }}" />
 
 The ``asset()`` function looks for the web assets inside the ``web/`` directory.
-If you store them in other directory, read ..... this article to learn how to
-manage web assets.
+If you store them in another directory, read :doc:`this article <cookbook/assetic/asset_management>`
+to learn how to manage web assets.
 
 Using the ``asset`` function, your application is more portable. The reason is
 that you can move the application root directory anywhere under your web root