Minor tweaks!

Author: weaverryan

configuration.rst

@@ -325,29 +325,32 @@ configure DoctrineBundle and other parts of Symfony:
             ),
         ));
 
-But the ``parameters.yml`` file *is* special: it contains any value that you do
-not want to commit to your repository or that changes on each server. Database configuration
-is a perfect example of both.
+But the ``parameters.yml`` file *is* special: it defines the values that usually
+change on each server. For example, the database credentials on your local
+development machine might be different from your workmates. That's why this file
+is not committed to the shared repository and is only stored on your machine.
 
 Because of that, **parameters.yml is not committed to your version control**. In fact,
 the ``.gitignore`` file that comes with Symfony prevents it from being committed.
 
 However, a ``parameters.yml.dist`` file *is* committed (with dummy values). This file
-isn't read by Symfony: it's just a template for what keys the ``parameters.yml``
-file you should. If you add or remove keys to ``parameters.yml``, you should add
-and remove them from ``parameters.yml.dist``.
-
-.. sidebar:: The Incenteev Parameter Handler
-
-    When you clone a new project, you will need to create the ``parameters.yml``
-    file from the committed ``parameters.yml.dist`` file. To help with this, after
-    you run ``composer install``, a script will automatically create this file by
-    interactively asking you to supply the value for each key in ``parameters.yml.dist``.
-    For more details - or to remove or control this behavior - see the
+isn't read by Symfony: it's just a reference so that Symfony knows which parameters
+need to be defined in the ``parameters.yml`` file. If you add or remove keys to
+``parameters.yml``, add or remove them from ``parameters.yml.dist`` too so both
+files are always in sync.
+
+.. sidebar:: The Interactive Parameter Handler
+
+    When you :ref:`install an existing Symfony project <install-existing-app>`, you
+    will need to create the ``parameters.yml`` file using the committed ``parameters.yml.dist``
+    file as a reference. To help with this, after you run ``composer install``, a
+    Symfony script will automatically create this file by interactively asking you
+    to supply the value for each parameter defined in ``parameters.yml.dist``. For
+    more details - or to remove or control this behavior - see the
     `Incenteev Parameter Handler`_ documentation.
 
-Environments & the Other Config Files (e.g. config_dev.yml)
------------------------------------------------------------
+Environments & the Other Config Files
+-------------------------------------
 
 You have just *one* app, but whether you realize it or not, you need it to behave
 *differently* at different times:
@@ -360,9 +363,8 @@ You have just *one* app, but whether you realize it or not, you need it to behav
 
 How can you make *one* application behave in two different ways? With *environments*.
 
-If you see the nice web debug toolbar at the bottom of your browser, then you're
-already running your application in the ``dev`` environment. After you deploy, you'll
-use the ``prod`` environment.
+You've probably already been using the ``dev`` environment without even knowing it.
+After you deploy, you'll use the ``prod`` environment.
 
 To learn more about *how* to execute and control each environment, see
 :doc:`/configuration/environments`.

configuration/environments.rst

@@ -138,7 +138,7 @@ either ``app.php`` (for the ``prod`` environment) or ``app_dev.php``
 
 If you don't have *either* filename in your URL, then it's up to your web server
 to decide *which* file to execute behind the scenes. If you're using the built-in
-PHP web server, it knows use the ``app_dev.php`` file. On production, you'll
+PHP web server, it knows to use the ``app_dev.php`` file. On production, you'll
 :doc:`configure your web server </setup/web_server_configuration>` to use ``app.php``.
 Either way: *one of these two files is always executed*.
 

page_creation.rst

@@ -208,7 +208,7 @@ Bundles are registered in your ``app/AppKernel.php`` file (a rare PHP file in th
 
 For example, ``TwigBundle`` is responsible for adding the Twig tool to your app!
 
-Eventually, you'll download and add more, third-party bundles to your app in order
+Eventually, you'll download and add more third-party bundles to your app in order
 to get even more tools. Imagine a bundle that helps you create paginated lists.
 That exists!
 

routing.rst

@@ -94,7 +94,7 @@ for you to use in your controller (keep reading). The ``blog_show`` is the
 internal name of the route, which doesn't have any meaning yet and just needs
 to be unique. Later, you'll use it to generate URLs.
 
-If you don't want to use annotations, you can also use Yaml, XML or PHP. In these
+If you don't want to use annotations, you can also use YAML, XML or PHP. In these
 formats, the ``_controller`` parameter is a special
 key that tells Symfony which controller should be executed when a URL matches
 this route. The ``_controller`` string is called the

setup.rst

@@ -322,6 +322,8 @@ you may use in your applications:
 * The `Symfony REST Edition`_ shows how to build an application that provides a
   RESTful API using the `FOSRestBundle`_ and several other related bundles.
 
+.. _install-existing-app:
+
 Installing an Existing Symfony Application
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~