update ordered list syntax

Author: xabbuh

book/translation.rst

@@ -394,13 +394,13 @@ Imagine that the user's locale is ``fr_FR`` and that you're translating the
 key ``Symfony 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
+#. First, Symfony looks for the translation in a ``fr_FR`` translation resource
    (e.g. ``messages.fr_FR.xliff``);
 
-2. If it wasn't found, Symfony looks for the translation in a ``fr`` translation
+#. If it wasn't found, Symfony looks for the translation in a ``fr`` translation
    resource (e.g. ``messages.fr.xliff``);
 
-3. If the translation still isn't found, Symfony uses the ``fallback`` configuration
+#. If the translation still isn't found, Symfony uses the ``fallback`` configuration
    parameter, which defaults to ``en`` (see `Configuration`_).
 
 .. _book-translation-user-locale:

components/routing/introduction.rst

@@ -72,25 +72,25 @@ Defining Routes
 
 A full route definition can contain up to seven parts:
 
-1. The URL path route. This is matched against the URL passed to the `RequestContext`,
+#. The URL path route. This is matched against the URL passed to the `RequestContext`,
    and can contain named wildcard placeholders (e.g. ``{placeholders}``)
    to match dynamic parts in the URL.
 
-2. An array of default values. This contains an array of arbitrary values
+#. An array of default values. This contains an array of arbitrary values
    that will be returned when the request matches the route.
 
-3. An array of requirements. These define constraints for the values of the
+#. An array of requirements. These define constraints for the values of the
    placeholders as regular expressions.
 
-4. An array of options. These contain internal settings for the route and
+#. An array of options. These contain internal settings for the route and
    are the least commonly needed.
 
-5. A host. This is matched against the host of the request. See
+#. A host. This is matched against the host of the request. See
    :doc:`/components/routing/hostname_pattern` for more details.
 
-6. An array of schemes. These enforce a certain HTTP scheme (``http``, ``https``).
+#. An array of schemes. These enforce a certain HTTP scheme (``http``, ``https``).
 
-7. An array of methods. These enforce a certain HTTP request method (``HEAD``,
+#. An array of methods. These enforce a certain HTTP request method (``HEAD``,
    ``GET``, ``POST``, ...).
 
 .. versionadded:: 2.2

components/serializer.rst

@@ -144,9 +144,9 @@ of the ``Person`` class would be encoded in XML format::
 In this case, :method:`Symfony\\Component\\Serializer\\Serializer::deserialize`
 needs three parameters:
 
-1. The information to be decoded
-2. The name of the class this information will be decoded to
-3. The encoder used to convert that information into an array
+#. The information to be decoded
+#. The name of the class this information will be decoded to
+#. The encoder used to convert that information into an array
 
 Using Camelized Method Names for Underscored Attributes
 -------------------------------------------------------

components/translation/introduction.rst

@@ -159,12 +159,12 @@ If the message is not located in the catalog of the specific locale, the
 translator will look into the catalog of one or more fallback locales. For
 example, assume you're trying to translate into the ``fr_FR`` locale:
 
-1. First, the translator looks for the translation in the ``fr_FR`` locale;
+#. First, the translator looks for the translation in the ``fr_FR`` locale;
 
-2. If it wasn't found, the translator looks for the translation in the ``fr``
+#. If it wasn't found, the translator looks for the translation in the ``fr``
    locale;
 
-3. If the translation still isn't found, the translator uses the one or more
+#. If the translation still isn't found, the translator uses the one or more
    fallback locales set explicitly on the translator.
 
 For (3), the fallback locales can be set by calling

contributing/code/security.rst

@@ -19,10 +19,10 @@ Resolving Process
 For each report, we first try to confirm the vulnerability. When it is
 confirmed, the core-team works on a solution following these steps:
 
-1. Send an acknowledgement to the reporter;
-2. Work on a patch;
-3. Get a CVE identifier from mitre.org;
-4. Write a security announcement for the official Symfony `blog`_ about the
+#. Send an acknowledgement to the reporter;
+#. Work on a patch;
+#. Get a CVE identifier from mitre.org;
+#. Write a security announcement for the official Symfony `blog`_ about the
    vulnerability. This post should contain the following information:
 
    * a title that always include the "Security release" string;
@@ -32,12 +32,12 @@ confirmed, the core-team works on a solution following these steps:
    * how to patch/upgrade/workaround affected applications;
    * the CVE identifier;
    * credits.
-5. Send the patch and the announcement to the reporter for review;
-6. Apply the patch to all maintained versions of Symfony;
-7. Package new versions for all affected versions;
-8. Publish the post on the official Symfony `blog`_ (it must also be added to
+#. Send the patch and the announcement to the reporter for review;
+#. Apply the patch to all maintained versions of Symfony;
+#. Package new versions for all affected versions;
+#. Publish the post on the official Symfony `blog`_ (it must also be added to
    the "`Security Advisories`_" category);
-9. Update the security advisory list (see below).
+#. Update the security advisory list (see below).
 
 .. note::
 
@@ -61,23 +61,23 @@ As Symfony is used by many large Open-Source projects, we standardized the way
 the Symfony security team collaborates on security issues with downstream
 projects. The process works as follows:
 
-1. After the Symfony security team has acknowledged a security issue, it
-immediately sends an email to the downstream project security teams to inform
-them of the issue;
+#. After the Symfony security team has acknowledged a security issue, it
+   immediately sends an email to the downstream project security teams to
+   inform them of the issue;
 
-2. The Symfony security team creates a private Git repository to ease the
-collaboration on the issue and access to this repository is given to the
-Symfony security team, to the Symfony contributors that are impacted by the
-issue, and to one representative of each downstream projects;
+#. The Symfony security team creates a private Git repository to ease the
+   collaboration on the issue and access to this repository is given to the
+   Symfony security team, to the Symfony contributors that are impacted by
+   the issue, and to one representative of each downstream projects;
 
-3. All people with access to the private repository work on a solution to
-solve the issue via pull requests, code reviews, and comments;
+#. All people with access to the private repository work on a solution to
+   solve the issue via pull requests, code reviews, and comments;
 
-4. Once the fix is found, all involved projects collaborate to find the best
-date for a joint release (there is no guarantee that all releases will be at
-the same time but we will try hard to make them at about the same time). When
-the issue is not known to be exploited in the wild, a period of two weeks
-seems like a reasonable amount of time.
+#. Once the fix is found, all involved projects collaborate to find the best
+   date for a joint release (there is no guarantee that all releases will
+   be at the same time but we will try hard to make them at about the same
+   time). When the issue is not known to be exploited in the wild, a period
+   of two weeks seems like a reasonable amount of time.
 
 The list of downstream projects participating in this process is kept as small
 as possible in order to better manage the flow of confidential information

cookbook/deployment/heroku.rst

@@ -81,9 +81,9 @@ Creating a Procfile
 By default, Heroku will launch an Apache web server together with PHP to serve
 applications. However, two special circumstances apply to Symfony applications:
 
-1. The document root is in the ``web/`` directory and not in the root directory
+#. The document root is in the ``web/`` directory and not in the root directory
    of the application;
-2. The Composer ``bin-dir``, where vendor binaries (and thus Heroku's own boot
+#. The Composer ``bin-dir``, where vendor binaries (and thus Heroku's own boot
    scripts) are placed, is ``bin/`` , and not the default ``vendor/bin``.
 
 .. note::

cookbook/security/custom_authentication_provider.rst

@@ -20,9 +20,9 @@ The following chapter demonstrates how to create a custom authentication
 provider for WSSE authentication. The security protocol for WSSE provides
 several security benefits:
 
-1. Username / Password encryption
-2. Safe guarding against replay attacks
-3. No web server configuration required
+#. Username / Password encryption
+#. Safe guarding against replay attacks
+#. No web server configuration required
 
 WSSE is very useful for the securing of web services, may they be SOAP or
 REST.

cookbook/workflow/new_project_svn.rst

@@ -48,26 +48,26 @@ Initial Project Setup
 
 To get started, you'll need to download Symfony and get the basic Subversion setup:
 
-1. Download the `Symfony Standard Edition`_ with or without vendors.
+#. Download the `Symfony Standard Edition`_ with or without vendors.
 
-2. Unzip/untar the distribution. It will create a folder called Symfony with
+#. Unzip/untar the distribution. It will create a folder called Symfony with
    your new project structure, config files, etc. Rename it to whatever you
    like.
 
-3. Checkout the Subversion repository that will host this project. Suppose
+#. Checkout the Subversion repository that will host this project. Suppose
    it is hosted on `Google code`_ and called ``myproject``:
 
    .. code-block:: bash
 
         $ svn checkout http://myproject.googlecode.com/svn/trunk myproject
 
-4. Copy the Symfony project files in the Subversion folder:
+#. Copy the Symfony project files in the Subversion folder:
 
    .. code-block:: bash
 
         $ mv Symfony/* myproject/
 
-5. Now, set the ignore rules. Not everything *should* be stored in your Subversion
+#. Now, set the ignore rules. Not everything *should* be stored in your Subversion
    repository. Some files (like the cache) are generated and others (like
    the database configuration) are meant to be customized on each machine.
    This makes use of the ``svn:ignore`` property, so that specific files can
@@ -88,21 +88,21 @@ To get started, you'll need to download Symfony and get the basic Subversion set
 
         $ svn ci -m "commit basic Symfony ignore list (vendor, app/bootstrap*, app/config/parameters.yml, app/cache/*, app/logs/*, web/bundles)"
 
-6. The rest of the files can now be added and committed to the project:
+#. The rest of the files can now be added and committed to the project:
 
    .. code-block:: bash
 
         $ svn add --force .
         $ svn ci -m "add basic Symfony Standard 2.X.Y"
 
-7. Copy ``app/config/parameters.yml`` to ``app/config/parameters.yml.dist``.
+#. Copy ``app/config/parameters.yml`` to ``app/config/parameters.yml.dist``.
    The ``parameters.yml`` file is ignored by svn (see above) so that
    machine-specific settings like database passwords aren't committed. By
    creating the ``parameters.yml.dist`` file, new developers can quickly clone
    the project, copy this file to ``parameters.yml``, customize it, and start
    developing.
 
-8. Finally, download all of the third-party vendor libraries by
+#. Finally, download all of the third-party vendor libraries by
    executing Composer. For details, see :ref:`installation-updating-vendors`.
 
 .. tip::