some tweaks and fixes to d417f7b and 3dcbbc2

Author: xabbuh

book/service_container.rst

@@ -763,8 +763,9 @@ Injecting the Request
     The ``request_stack`` service was introduced in version 2.4.
 
 As of Symfony 2.4, instead of injecting the ``request`` service, you should
-inject the ``request_stack`` service instead and access the Request by calling
-the ``getCurrentRequest()`` method:
+inject the ``request_stack`` service and access the ``Request`` by calling
+the :method:`Symfony\\Component\\HttpFoundation\\RequestStack::getCurrentRequest`
+method::
 
     namespace Acme\HelloBundle\Newsletter;
 
@@ -830,7 +831,7 @@ Now, just inject the ``request_stack``, which behaves like any normal service:
             array(new Reference('request_stack'))
         ));
 
-.. sidebar: Why not Inject the request Service?
+.. sidebar:: Why not Inject the ``request`` Service?
 
     Almost all Symfony2 built-in services behave in the same way: a single
     instance is created by the container which it returns whenever you get it or

cookbook/service_container/scopes.rst

@@ -12,10 +12,11 @@ This entry is all about scopes, a somewhat advanced topic related to the
 
     If you are trying to inject the ``request`` service, the simple solution
     is to inject the ``request_stack`` service instead and access the current
-    Request by calling the ``getCurrentRequest()`` method (see :ref:`book-container-request-stack`).
-    The rest of this entry talks about scopes in a theoretical and more advanced
-    way. If you're dealing with scopes for the ``request`` service, simply
-    inject ``request_stack``.
+    Request by calling the
+    :method:`Symfony\\Component\\HttpFoundation\\RequestStack::getCurrentRequest`
+    method (see :ref:`book-container-request-stack`). The rest of this entry
+    talks about scopes in a theoretical and more advanced way. If you're
+    dealing with scopes for the ``request`` service, simply inject ``request_stack``.
 
 Understanding Scopes
 --------------------
@@ -35,7 +36,7 @@ also defines a third scope: ``request``. This scope is tied to the request,
 meaning a new instance is created for each subrequest and is unavailable
 outside the request (for instance in the CLI).
 
-An Example: client Scope
+An Example: Client Scope
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Other than the ``request`` service (which has a simple solution, see the
@@ -92,13 +93,13 @@ when compiling the container. Read the sidebar below for more details.
     A service can of course depend on a service from a wider scope without
     any issue.
 
-Using a Service from a narrower Scope
+Using a Service from a Narrower Scope
 -------------------------------------
 
 There are several solutions to the scope problem:
 
-* A) Use setter injection if the dependency is "synchronized"; (see
-  :ref:`using-synchronized-service`).
+* A) Use setter injection if the dependency is ``synchronized`` (see
+  :ref:`using-synchronized-service`);
 
 * B) Put your service in the same scope as the dependency (or a narrower one). If
   you depend on the ``client_configuration`` service, this means putting your
@@ -107,13 +108,13 @@ There are several solutions to the scope problem:
 * C) Pass the entire container to your service and retrieve your dependency from
   the container each time you need it to be sure you have the right instance
   -- your service can live in the default ``container`` scope (see
-  :ref:`passing-container`);
+  :ref:`passing-container`).
 
 Each scenario is detailed in the following sections.
 
 .. _using-synchronized-service:
 
-A) Using a synchronized Service
+A) Using a Synchronized Service
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. versionadded:: 2.3