Merge branch '2.4'

Conflicts:	components/options_resolver.rst

Author: weaverryan

book/forms.rst

@@ -48,6 +48,7 @@ going to need to build a form. But before you begin, first focus on the generic
  {
  return $this->dueDate;
  }
+ 
  public function setDueDate(\DateTime $dueDate = null)
  {
  $this->dueDate = $dueDate;

book/http_cache.rst

@@ -795,13 +795,13 @@ Gateway caches are a great way to make your website perform better. But they
 have one limitation: they can only cache whole pages. If you can't cache
 whole pages or if parts of a page has "more" dynamic parts, you are out of
 luck. Fortunately, Symfony2 provides a solution for these cases, based on a
-technology called `ESI`_, or Edge Side Includes. Akamaï wrote this specification
+technology called `ESI`_, or Edge Side Includes. Akamai wrote this specification
 almost 10 years ago, and it allows specific parts of a page to have a different
 caching strategy than the main page.
 
 The ESI specification describes tags you can embed in your pages to communicate
 with the gateway cache. Only one tag is implemented in Symfony2, ``include``,
-as this is the only useful one outside of Akamaï context:
+as this is the only useful one outside of Akamai context:
 
 .. code-block:: html
 
@@ -936,7 +936,7 @@ used ``render``.
 
 .. note::
 
- Symfony2 detects if a gateway cache supports ESI via another Akamaï
+ Symfony2 detects if a gateway cache supports ESI via another Akamai
  specification that is supported out of the box by the Symfony2 reverse
  proxy.
 

book/includes/_service_container_my_mailer.rst.inc

@@ -16,8 +16,7 @@
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://symfony.com/schema/dic/services
  http://symfony.com/schema/dic/services/services-1.0.xsd"
- >
-
+ >
  <services>
  <service id="my_mailer" class="Acme\HelloBundle\Mailer">
  <argument>sendmail</argument>
@@ -33,4 +32,4 @@
  $container->setDefinition('my_mailer', new Definition(
  'Acme\HelloBundle\Mailer',
  array('sendmail')
- ));
+ ));

book/security.rst

@@ -764,13 +764,13 @@ is used to enforce access.
 Each ``access_control`` has several options that configure two different
 things:
 
-* (a) :ref:`should the incoming request match this access control entry <security-book-access-control-matching-options>`
-* (b) :ref:`once it matches, should some sort of access restriction be enforced <security-book-access-control-enforcement-options>`:
+#. :ref:`should the incoming request match this access control entry <security-book-access-control-matching-options>`
+#. :ref:`once it matches, should some sort of access restriction be enforced <security-book-access-control-enforcement-options>`:
 
 .. _security-book-access-control-matching-options:
 
-(a) Matching Options
-....................
+1. Matching Options
+...................
 
 Symfony2 creates an instance of :class:`Symfony\\Component\\HttpFoundation\\RequestMatcher`
 for each ``access_control`` entry, which determines whether or not a given
@@ -865,8 +865,8 @@ will match any ``ip``, ``host`` or ``method``:
 
 .. _security-book-access-control-enforcement-options:
 
-(b) Access Enforcement
-......................
+2. Access Enforcement
+.....................
 
 Once Symfony2 has decided which ``access_control`` entry matches (if any),
 it then *enforces* access restrictions based on the ``roles`` and ``requires_channel``

book/service_container.rst

@@ -103,7 +103,7 @@ for you. In order for this to work, you must *teach* the container how to
 create the ``Mailer`` service. This is done via configuration, which can
 be specified in YAML, XML or PHP:
 
-.. include includes/_service_container_my_mailer.rst.inc
+.. include:: includes/_service_container_my_mailer.rst.inc
 
 .. note::
 
@@ -643,7 +643,7 @@ which has a ``getMailerMethod()`` method on it, which will return a string
 like ``sendmail`` based on some configuration. Remember that the first argument
 to the ``my_mailer`` service is the simple string ``sendmail``:
 
-.. include includes/_service_container_my_mailer.rst.inc
+.. include:: includes/_service_container_my_mailer.rst.inc
 
 But instead of hardcoding this, how could we get this value from the ``getMailerMethod()``
 of the new ``mailer_configuration`` service? One way is to use an expression:
@@ -874,7 +874,7 @@ Now, just inject the ``request_stack``, which behaves like any normal service:
  # src/Acme/HelloBundle/Resources/config/services.yml
  services:
  newsletter_manager:
- class: "Acme\HelloBundle\Newsletter\NewsletterManager"
+ class: Acme\HelloBundle\Newsletter\NewsletterManager
  arguments: ["@request_stack"]
 
  .. code-block:: xml

book/translation.rst

@@ -392,7 +392,7 @@ key ``Symfony2 is great``. To find the French translation, Symfony actually
 checks translation resources for several different locales:
 
 1. First, Symfony looks for the translation in a ``fr_FR`` translation resource
- (e.g. ``messages.fr_FR.xfliff``);
+ (e.g. ``messages.fr_FR.xliff``);
 
 2. If it wasn't found, Symfony looks for the translation in a ``fr`` translation
  resource (e.g. ``messages.fr.xliff``);

components/config/definition.rst

@@ -390,8 +390,8 @@ process is used to remove some of the differences that result from different
 configuration formats, mainly the differences between YAML and XML.
 
 The separator used in keys is typically ``_`` in YAML and ``-`` in XML. For
-example, ``auto_connect`` in YAML and ``auto-connect``. The normalization would
-make both of these ``auto_connect``.
+example, ``auto_connect`` in YAML and ``auto-connect`` in XML.
+The normalization would make both of these ``auto_connect``.
 
 .. caution::
 

components/console/helpers/dialoghelper.rst

@@ -12,8 +12,8 @@ helper set, which you can get by calling
  $dialog = $this->getHelperSet()->get('dialog');
 
 All the methods inside the Dialog Helper have an
-:class:`Symfony\\Component\\Console\\Output\\OutputInterface` as first the
-argument, the question as the second argument and the default value as last
+:class:`Symfony\\Component\\Console\\Output\\OutputInterface` as the first
+argument, the question as the second argument and the default value as the last
 argument.
 
 Asking the User for confirmation
@@ -52,8 +52,9 @@ if you want to know a bundle name, you can add this to your command::
  );
 
 The user will be asked "Please enter the name of the bundle". They can type
-some name which will be returned by the ``ask`` method. If they leave it empty,
-the default value (``AcmeDemoBundle`` here) is returned.
+some name which will be returned by the
+:method:`Symfony\\Component\\Console\\Helper\\DialogHelper::ask` method.
+If they leave it empty, the default value (``AcmeDemoBundle`` here) is returned.
 
 Autocompletion
 ~~~~~~~~~~~~~~
@@ -222,9 +223,12 @@ this set the seventh argument to ``true``::
  return $colors[$c];
  }, $selected);
 
- $output->writeln('You have just selected: ' . implode(', ', $selectedColors));
+ $output->writeln(
+ 'You have just selected: ' . implode(', ', $selectedColors)
+ );
 
-Now, when the user enters ``1,2``, the result will be: ``You have just selected: blue, yellow``.
+Now, when the user enters ``1,2``, the result will be:
+``You have just selected: blue, yellow``.
 
 Testing a Command which expects input
 -------------------------------------

components/console/introduction.rst

@@ -233,7 +233,7 @@ method returns without actually printing.
  The MonologBridge provides a :class:`Symfony\\Bridge\\Monolog\\Handler\\ConsoleHandler`
  class that allows you to display messages on the console. This is cleaner
  than wrapping your output calls in conditions. For an example use in
- the Symfony Framework, see :doc:/cookbook/logging/monolog_console.
+ the Symfony Framework, see :doc:`/cookbook/logging/monolog_console`.
 
 Using Command Arguments
 -----------------------

components/dependency_injection/parameters.rst

@@ -295,7 +295,7 @@ keywords (respectively ``true``, ``false`` and ``null``):
 .. code-block:: xml
 
  <parameters>
- <parameter key="mailer.send_all_in_once">false</parameters>
+ <parameter key="mailer.send_all_in_once">false</parameter>
  </parameters>
 
  <!-- after parsing