Merge branch 'fix_roles' of github.com:WouterJ/symfony-docs into WouterJ-fix_roles

Conflicts:
	book/http_fundamentals.rst
	cookbook/bundles/extension.rst

Author: weaverryan

book/controller.rst

@@ -196,7 +196,7 @@ see :ref:`controller-string-syntax`.
 
 .. tip::
 
-    You can learn much more about the routing system in the :doc:`Routing chapter</book/routing>`.
+    You can learn much more about the routing system in the :doc:`Routing chapter </book/routing>`.
 
 .. index::
    single: Controller; Controller arguments
@@ -397,7 +397,7 @@ itself.
 
 .. note::
 
-    You can also define your :doc:`Controllers as Services</cookbook/controller/service>`.
+    You can also define your :doc:`Controllers as Services </cookbook/controller/service>`.
     This is optional, but can give you more control over the exact dependencies
     that are injected into your controllers.
 
@@ -494,7 +494,7 @@ value to each variable.
     Like other base ``Controller`` methods, the ``forward`` method is just
     a shortcut for core Symfony2 functionality. A forward can be accomplished
     directly by duplicating the current request. When this
-    :ref:`sub request<http-kernel-sub-requests>` is executed via the ``http_kernel``
+    :ref:`sub request <http-kernel-sub-requests>` is executed via the ``http_kernel``
     service the ``HttpKernel`` returns a ``Response`` object::
     
         use Symfony\Component\HttpKernel/HttpKernelInterface;
@@ -549,7 +549,8 @@ The Symfony templating engine is explained in great detail in the
 .. tip::
 
     You can even avoid calling the ``render`` method by using the ``@Template``
-    annotation. See the :doc:`FrameworkExtraBundle documentation</bundles/SensioFrameworkExtraBundle/annotations/view>`
+    annotation. See the
+    :doc:`FrameworkExtraBundle documentation </bundles/SensioFrameworkExtraBundle/annotations/view>`
     more details.
 
 .. tip::

book/doctrine.rst

@@ -473,7 +473,7 @@ in your application. To do this, run:
     new column to the existing ``product`` table.
 
     An even better way to take advantage of this functionality is via
-    :doc:`migrations</bundles/DoctrineMigrationsBundle/index>`, which allow you to
+    :doc:`migrations </bundles/DoctrineMigrationsBundle/index>`, which allow you to
     generate these SQL statements and store them in migration classes that
     can be run systematically on your production server in order to track
     and migrate your database schema safely and reliably.
@@ -581,7 +581,7 @@ on its ``id`` value::
 
     You can achieve the equivalent of this without writing any code by using
     the ``@ParamConverter`` shortcut. See the
-    :doc:`FrameworkExtraBundle documentation</bundles/SensioFrameworkExtraBundle/annotations/converters>`
+    :doc:`FrameworkExtraBundle documentation </bundles/SensioFrameworkExtraBundle/annotations/converters>`
     for more details.
 
 When you query for a particular type of object, you always use what's known
@@ -758,7 +758,7 @@ for just one object, you can use the ``getSingleResult()`` method instead::
         // ...
 
 The DQL syntax is incredibly powerful, allowing you to easily join between
-entities (the topic of :ref:`relations<book-doctrine-relations>` will be
+entities (the topic of :ref:`relations <book-doctrine-relations>` will be
 covered later), group, etc. For more information, see the official Doctrine
 `Doctrine Query Language`_ documentation.
 
@@ -1112,7 +1112,7 @@ table, and ``product.category_id`` column, and new foreign key:
 
     This task should only be really used during development. For a more robust
     method of systematically updating your production database, read about
-    :doc:`Doctrine migrations</bundles/DoctrineMigrationsBundle/index>`.
+    :doc:`Doctrine migrations </bundles/DoctrineMigrationsBundle/index>`.
 
 Saving Related Entities
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -1300,7 +1300,7 @@ Configuration
 
 Doctrine is highly configurable, though you probably won't ever need to worry
 about most of its options. To find out more about configuring Doctrine, see
-the Doctrine section of the :doc:`reference manual</reference/configuration/doctrine>`.
+the Doctrine section of the :doc:`reference manual </reference/configuration/doctrine>`.
 
 Lifecycle Callbacks
 -------------------
@@ -1412,7 +1412,7 @@ These include thing such as *Sluggable*, *Timestampable*, *Loggable*, *Translata
 and *Tree*.
 
 For more information on how to find and use these extensions, see the cookbook
-article about :doc:`using common Doctrine extensions</cookbook/doctrine/common_extensions>`.
+article about :doc:`using common Doctrine extensions </cookbook/doctrine/common_extensions>`.
 
 .. _book-doctrine-field-types:
 
@@ -1591,7 +1591,7 @@ that allow you to take different actions as objects go through their persistence
 lifecycle.
 
 For more information about Doctrine, see the *Doctrine* section of the
-:doc:`cookbook</cookbook/index>`, which includes the following articles:
+:doc:`cookbook </cookbook/index>`, which includes the following articles:
 
 * :doc:`/bundles/DoctrineFixturesBundle/index`
 * :doc:`/cookbook/doctrine/common_extensions`

book/forms.rst

@@ -382,7 +382,7 @@ corresponding errors printed out with the form.
    blank fields.
 
 Validation is a very powerful feature of Symfony2 and has its own
-:doc:`dedicated chapter</book/validation>`.
+:doc:`dedicated chapter </book/validation>`.
 
 .. index::
    single: Forms; Validation groups
@@ -399,7 +399,7 @@ you'll need to specify which validation group(s) your form should use::
         'validation_groups' => array('registration'),
     ))->add(...);
 
-If you're creating :ref:`form classes<book-form-creating-form-classes>` (a
+If you're creating :ref:`form classes <book-form-creating-form-classes>` (a
 good practice), then you'll need to add the following to the ``setDefaultOptions()``
 method::
 
@@ -484,7 +484,7 @@ Field Type Options
 
 Each field type has a number of options that can be used to configure it.
 For example, the ``dueDate`` field is currently being rendered as 3 select
-boxes. However, the :doc:`date field</reference/forms/types/date>` can be
+boxes. However, the :doc:`date field </reference/forms/types/date>` can be
 configured to be rendered as a single text box (where the user would enter
 the date as a string in the box)::
 
@@ -503,7 +503,8 @@ the documentation for each type.
     any field. By default, the ``required`` option is set to ``true``, meaning
     that HTML5-ready browsers will apply client-side validation if the field
     is left blank. If you don't want this behavior, either set the ``required``
-    option on your field to ``false`` or :ref:`disable HTML5 validation<book-forms-html5-validation-disable>`.
+    option on your field to ``false`` or
+    :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`.
 
     Also note that setting the ``required`` option to ``true`` will **not**
     result in server-side validation to be applied. In other words, if a
@@ -656,7 +657,7 @@ Take a look at each part:
   It's usually a good idea to place a call to this helper at the bottom of
   each form (in case you forgot to output a field or don't want to bother
   manually rendering hidden fields). This helper is also useful for taking
-  advantage of the automatic :ref:`CSRF Protection<forms-csrf>`.
+  advantage of the automatic :ref:`CSRF Protection <forms-csrf>`.
 
 The majority of the work is done by the ``form_row`` helper, which renders
 the label, errors and HTML form widget of each field inside a ``div`` tag
@@ -789,7 +790,7 @@ Twig Template Function Reference
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you're using Twig, a full reference of the form rendering functions is
-available in the :doc:`reference manual</reference/forms/twig_reference>`.
+available in the :doc:`reference manual </reference/forms/twig_reference>`.
 Read this to know everything about the helpers available and the options
 that can be used with each.
 
@@ -984,7 +985,7 @@ HTML form and then translate user-submitted data back to the original object. As
 such, the topic of persisting the ``Task`` object to the database is entirely
 unrelated to the topic of forms. But, if you've configured the ``Task`` class
 to be persisted via Doctrine (i.e. you've added
-:ref:`mapping metadata<book-doctrine-adding-mapping>` for it), then persisting
+:ref:`mapping metadata <book-doctrine-adding-mapping>` for it), then persisting
 it after a form submission can be done when the form is valid::
 
     if ($form->isValid()) {
@@ -1000,7 +1001,7 @@ you can fetch it from the form::
 
     $task = $form->getData();
 
-For more information, see the :doc:`Doctrine ORM chapter</book/doctrine>`.
+For more information, see the :doc:`Doctrine ORM chapter </book/doctrine>`.
 
 The key thing to understand is that when the form is bound, the submitted
 data is transferred to the underlying object immediately. If you want to
@@ -1165,7 +1166,7 @@ form with many ``Product`` sub-forms). This is done by using the ``collection``
 field type.
 
 For more information see the ":doc:`/cookbook/form/form_collections`" cookbook
-entry and  the :doc:`collection</reference/forms/types/collection>` field type reference.
+entry and  the :doc:`collection </reference/forms/types/collection>` field type reference.
 
 .. index::
    single: Forms; Theming
@@ -1353,7 +1354,7 @@ override the default error rendering for *all* fields, copy and customize the
 .. tip::
 
     The "parent" type of each field type is available in the
-    :doc:`form type reference</reference/forms/types>` for each field type.
+    :doc:`form type reference </reference/forms/types>` for each field type.
 
 .. index::
    single: Forms; Global Theming
@@ -1642,7 +1643,7 @@ array of your submitted data, how can you add constraints to the data of your
 form?
 
 The answer is to setup the constraints yourself, and attach them to the individual
-fields. The overall approach is covered a bit more in the :ref:`validation chapter<book-validation-raw-values>`,
+fields. The overall approach is covered a bit more in the :ref:`validation chapter <book-validation-raw-values>`,
 but here's a short example:
 
 .. versionadded:: 2.1
@@ -1688,11 +1689,11 @@ take the data submitted by the user and to re-apply it to the object.
 
 There's still much more to learn about the powerful world of forms, such as
 how to handle :doc:`file uploads with Doctrine
-</cookbook/doctrine/file_uploads>` or how to create a form where a dynamic
+ </cookbook/doctrine/file_uploads>` or how to create a form where a dynamic
 number of sub-forms can be added (e.g. a todo list where you can keep adding
 more fields via Javascript before submitting). See the cookbook for these
 topics. Also, be sure to lean on the
-:doc:`field type reference documentation</reference/forms/types>`, which
+:doc:`field type reference documentation </reference/forms/types>`, which
 includes examples of how to use each field type and its options.
 
 Learn more from the Cookbook

book/from_flat_php_to_symfony2.rst

@@ -582,7 +582,7 @@ them for you. Here's the same sample application, now built in Symfony2::
         }
     }
 
-The two controllers are still lightweight. Each uses the :doc:`Doctrine ORM library</book/doctrine>`
+The two controllers are still lightweight. Each uses the :doc:`Doctrine ORM library </book/doctrine>`
 to retrieve objects from the database and the ``Templating`` component to
 render a template and return a ``Response`` object. The list template is
 now quite a bit simpler:
@@ -667,7 +667,7 @@ controller method is responsible for returning the final ``Response`` object.
 There's really not much else to it.
 
 For a visual representation of how Symfony2 handles each request, see the
-:ref:`request flow diagram<request-flow-figure>`.
+:ref:`request flow diagram <request-flow-figure>`.
 
 Where Symfony2 Delivers
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -681,8 +681,8 @@ migrating the blog from flat PHP to Symfony2 has improved life:
   allows for new developers to be productive in your project more quickly;
 
 * 100% of the code you write is for *your* application. You **don't need
-  to develop or maintain low-level utilities** such as :ref:`autoloading<autoloading-introduction-sidebar>`,
-  :doc:`routing</book/routing>`, or rendering :doc:`controllers</book/controller>`;
+  to develop or maintain low-level utilities** such as :ref:`autoloading <autoloading-introduction-sidebar>`,
+  :doc:`routing </book/routing>`, or rendering :doc:`controllers </book/controller>`;
 
 * Symfony2 gives you **access to open source tools** such as Doctrine and the
   Templating, Security, Form, Validation and Translation components (to name
@@ -694,7 +694,7 @@ migrating the blog from flat PHP to Symfony2 has improved life:
 * Symfony2's HTTP-centric architecture gives you access to powerful tools
   such as **HTTP caching** powered by **Symfony2's internal HTTP cache** or
   more powerful tools such as `Varnish`_. This is covered in a later chapter
-  all about :doc:`caching</book/http_cache>`.
+  all about :doc:`caching </book/http_cache>`.
 
 And perhaps best of all, by using Symfony2, you now have access to a whole
 set of **high-quality open source tools developed by the Symfony2 community**!
@@ -745,7 +745,7 @@ The corresponding ``layout.html.twig`` template is also easier to write:
 
 Twig is well-supported in Symfony2. And while PHP templates will always
 be supported in Symfony2, the many advantages of Twig will continue to
-be discussed. For more information, see the :doc:`templating chapter</book/templating>`.
+be discussed. For more information, see the :doc:`templating chapter </book/templating>`.
 
 Learn more from the Cookbook
 ----------------------------

book/http_fundamentals.rst

@@ -455,12 +455,12 @@ by adding an entry for ``/contact`` to your routing configuration file:
 
 .. note::
 
-   This example uses :doc:`YAML</components/yaml/yaml_format>` to define the routing
+   This example uses :doc:`YAML </components/yaml/yaml_format>` to define the routing
    configuration. Routing configuration can also be written in other formats
    such as XML or PHP.
 
 When someone visits the ``/contact`` page, this route is matched, and the
-specified controller is executed. As you'll learn in the :doc:`routing chapter</book/routing>`,
+specified controller is executed. As you'll learn in the :doc:`routing chapter </book/routing>`,
 the ``AcmeDemoBundle:Main:contact`` string is a short syntax that points to a
 specific PHP method ``contactAction`` inside a class called ``MainController``::
 
@@ -479,7 +479,7 @@ specific PHP method ``contactAction`` inside a class called ``MainController``::
 
 In this very simple example, the controller simply creates a
 :class:`Symfony\\Component\\HttpFoundation\\Response` object with the HTML
-"``<h1>Contact us!</h1>"``. In the :doc:`controller chapter</book/controller>`,
+"`` <h1>Contact us! </h1>"``. In the :doc:`controller chapter </book/controller>`,
 you'll learn how a controller can render templates, allowing your "presentation"
 code (i.e. anything that actually writes out HTML) to live in a separate
 template file. This frees up the controller to worry only about the hard
@@ -512,11 +512,11 @@ libraries that can be used inside *any* PHP project. These libraries, called
 the *Symfony2 Components*, contain something useful for almost any situation,
 regardless of how your project is developed. To name a few:
 
-* :doc:`HttpFoundation</components/http_foundation/introduction>` - Contains
+* :doc:`HttpFoundation </components/http_foundation/introduction>` - Contains
   the ``Request`` and ``Response`` classes, as well as other classes for handling
   sessions and file uploads;
 
-* :doc:`Routing</components/routing/introduction>` - Powerful and fast routing system that
+* :doc:`Routing </components/routing/introduction>` - Powerful and fast routing system that
   allows you to map a specific URI (e.g. ``/contact``) to some information
   about how that request should be handled (e.g. execute the ``contactAction()``
   method);
@@ -527,11 +527,11 @@ regardless of how your project is developed. To name a few:
 * `Validator`_ A system for creating rules about data and then validating
   whether or not user-submitted data follows those rules;
 
-* :doc:`ClassLoader</components/class_loader/introduction>` An autoloading library that allows
+* :doc:`ClassLoader </components/class_loader/introduction>` An autoloading library that allows
   PHP classes to be used without needing to manually ``require`` the files
   containing those classes;
 
-* :doc:`Templating</components/templating/introduction>` A toolkit for rendering
+* :doc:`Templating </components/templating/introduction>` A toolkit for rendering
   templates, handling template inheritance (i.e. a template is decorated with
   a layout) and performing other common template tasks;
 

book/installation.rst

@@ -21,7 +21,7 @@ Installing a Symfony2 Distribution
 
     First, check that you have installed and configured a Web server (such
     as Apache) with PHP 5.3.8 or higher. For more information on Symfony2
-    requirements, see the :doc:`requirements reference</reference/requirements>`.
+    requirements, see the :doc:`requirements reference </reference/requirements>`.
 
 Symfony2 packages "distributions", which are fully-functional applications
 that include the Symfony2 core libraries, a selection of useful bundles, a
@@ -308,7 +308,7 @@ If you're new to Symfony, check out ":doc:`page_creation`", where you'll
 learn how to create pages, change configuration, and do everything else you'll
 need in your new application.
 
-Be sure to also check out the :doc:`Cookbook</cookbook/index>`, which contains
+Be sure to also check out the :doc:`Cookbook </cookbook/index>`, which contains
 a wide variety of articles about solving specific problems with Symfony.
 
 .. note::

book/internals.rst

@@ -236,7 +236,7 @@ add the following code at the beginning of your listener method::
 .. tip::
 
     If you are not yet familiar with the Symfony2 Event Dispatcher, read the
-    :doc:`Event Dispatcher Component Documentation</components/event_dispatcher/introduction>`
+    :doc:`Event Dispatcher Component Documentation </components/event_dispatcher/introduction>`
     section first.
 
 .. index::
@@ -432,7 +432,7 @@ The Event Dispatcher
 
 The event dispatcher is a standalone component that is responsible for much
 of the underlying logic and flow behind a Symfony request. For more information,
-see the :doc:`Event Dispatcher Component Documentation</components/event_dispatcher/introduction>`.
+see the :doc:`Event Dispatcher Component Documentation </components/event_dispatcher/introduction>`.
 
 .. seealso::
 

book/page_creation.rst

@@ -286,7 +286,7 @@ application should greet you:
 
 .. tip::
 
-    You can also view your app in the "prod" :ref:`environment<environments-summary>`
+    You can also view your app in the "prod" :ref:`environment <environments-summary>`
     by visiting:
 
     .. code-block:: text
@@ -600,7 +600,7 @@ in your application and to optimize them the way you want.
 .. note::
 
    While you'll learn the basics here, an entire cookbook entry is devoted
-   to the organization and best practices of :doc:`bundles</cookbook/bundles/best_practices>`.
+   to the organization and best practices of :doc:`bundles </cookbook/bundles/best_practices>`.
 
 A bundle is simply a structured set of files within a directory that implement
 a single feature. You might create a ``BlogBundle``, a ``ForumBundle`` or
@@ -675,7 +675,7 @@ called ``AcmeTestBundle.php``::
 
 .. tip::
 
-   The name ``AcmeTestBundle`` follows the standard :ref:`Bundle naming conventions<bundles-naming-conventions>`.
+   The name ``AcmeTestBundle`` follows the standard :ref:`Bundle naming conventions <bundles-naming-conventions>`.
    You could also choose to shorten the name of the bundle to simply ``TestBundle``
    by naming this class ``TestBundle`` (and naming the file ``TestBundle.php``).
 
@@ -884,7 +884,7 @@ The extension alias (configuration key) can also be used:
 .. note::
 
     See the cookbook article: :doc:`How to expose a Semantic Configuration for
-    a Bundle</cookbook/bundles/extension>` for information on adding
+    a Bundle </cookbook/bundles/extension>` for information on adding
     configuration for your own bundle.
 
 .. index::
@@ -942,7 +942,7 @@ cached files and allow them to rebuild:
 .. note::
 
     The ``test`` environment is used when running automated tests and cannot
-    be accessed directly through the browser. See the :doc:`testing chapter</book/testing>`
+    be accessed directly through the browser. See the :doc:`testing chapter </book/testing>`
     for more details.
 
 .. index::