minor #7930 Minor tweaks for the article that explains the new 3.3 DI features (javiereguiluz)

This PR was submitted for the master branch but it was merged into the 3.3 branch instead (closes #7930).

Discussion
----------

Minor tweaks for the article that explains the new 3.3 DI features

This proposes some minor changes to #7921.

I propose to replace "opt-in" by "optional" because the first one is uncommon for lots of non native English speakers (Google returns 562 million results for "optional" but only 16 million results for "opt-in").

Commits
-------

c49b176 Minor tweaks for the article that explains the new 3.3 DI features

Author: weaverryan

service_container/3.3-di-changes.rst

@@ -8,19 +8,19 @@ without sacrificing predictability, which is very important! Another goal is to
 controllers and services behave more consistently. In Symfony 3.3, controllers *are*
 services by default.
 
-The documentation has already been updated to assume you have these new features enabled.
-If you're an existing Symfony user and want to understand the "what" and "why" behind
-these changes, this chapter is for you!
+The documentation has already been updated to assume you have these new features
+enabled. If you're an existing Symfony user and want to understand the "what"
+and "why" behind these changes, this article is for you!
 
-All Changes are Opt-In
-----------------------
+All Changes are Optional
+------------------------
 
 Most importantly, **you can upgrade to Symfony 3.3 today without making any changes to your app**.
 Symfony has a strict :doc:`backwards compatibility promise </contributing/code/bc>`,
 which means it's always safe to upgrade across minor versions.
 
-All of the new features are **opt-in**: you need to actually change your configuration
-files to use them.
+All of the new features are **optional**: they are not enabled by default, so you
+need to actually change your configuration files to use them.
 
 The new Default services.yml File
 ---------------------------------
@@ -151,7 +151,7 @@ thanks to the following config:
         // services cannot be automatically loaded with PHP configuration
         // you need to define your services one-by-one
 
-This means that every class in ``src/AppBundle`` is *available* to be used as a
+This means that every class in ``src/AppBundle/`` is *available* to be used as a
 service. And thanks to the ``_defaults`` section at the top of the file, all of
 these services are **autowired** and **private** (i.e. ``public: false``).
 
@@ -166,7 +166,7 @@ to determine most arguments automatically. But, you can always override the serv
 and :ref:`manually configure arguments <services-manually-wire-args>` or anything
 else special about your service.
 
-    But wait, if I have some model (non-service) classes in my ``src/AppBundle``
+    But wait, if I have some model (non-service) classes in my ``src/AppBundle/``
     directory, doesn't this mean that *they* will also be registered as services?
     Isn't that a problem?
 
@@ -230,12 +230,12 @@ To pass the ``InvoiceGenerator`` as an argument to ``InvoiceMailer``, you needed
 to specify the service's *id* as an argument: ``app.invoice_generator``. Service
 id's were the main way that you configured things.
 
-But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the argument
-with ``InvoiceGenerator``::
+But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the
+argument with ``InvoiceGenerator``::
 
     // src/AppBundle/Service/InvoiceMailer.php
     // ...
-    
+
     class InvoiceMailer
     {
         private $generator;
@@ -288,7 +288,7 @@ was designed with that in mind. Specifically:
   a service whose id matches the type-hint exactly. It does *not* scan all services
   looking for objects that have that class/interface (actually, it *does* do this
   in Symfony 3.3, but has been deprecated. If you rely on this, you will see a clear
-  deprecation warning). 
+  deprecation warning).
 
 Autowiring aims to *automate* configuration without magic.
 
@@ -387,7 +387,7 @@ create the class::
 
     // src/AppBundle/EventSubscriber/SetHeaderSusbcriber.php
     // ...
-    
+
     use Symfony\Component\EventDispatcher\EventSubscriberInterface;
     use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
     use Symfony\Component\HttpKernel\KernelEvents;
@@ -398,7 +398,7 @@ create the class::
         {
             $event->getResponse()->headers->set('X-SYMFONY-3.3', 'Less config');
         }
-    
+
         public static function getSubscribedEvents()
         {
             return [
@@ -499,8 +499,8 @@ Start by adding a ``_defaults`` section with ``autowire`` and ``autoconfigure``.
         # ...
 
 This step is easy: you're already *explicitly* configuring all of your services.
-So, ``autowire`` does nothing. You're also already tagging your services, so ``autoconfigure``
-also doesn't change any existing services.
+So, ``autowire`` does nothing. You're also already tagging your services, so
+``autoconfigure`` also doesn't change any existing services.
 
 You have not added ``public: false`` yet. That will come in a minute.
 
@@ -574,7 +574,7 @@ Now you're ready to default all services to be private:
 
     # app/config/services.yml
     # ...
-    
+
     services:
          _defaults:
              autowire: true
@@ -592,7 +592,7 @@ instances of the same class), you may need to make those public:
 
     # app/config/services.yml
     # ...
-    
+
     services:
         # ...
 
@@ -602,7 +602,7 @@ instances of the same class), you may need to make those public:
     +        # remove this if/when you are not fetching this
     +        # directly from the container via $container->get()
     +        public: true
- 
+
          app.api_client_sl_connect:
              # ...
     +        public: true
@@ -614,8 +614,8 @@ clean that up.
 Step 4) Auto-registering Services
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You're now ready to automatically register all services in ``src/AppBundle`` (and/or
-any other directory/bundle you have):
+You're now ready to automatically register all services in ``src/AppBundle/``
+(and/or any other directory/bundle you have):
 
 .. code-block:: diff
 
@@ -697,7 +697,7 @@ these directly from the container, you can remove the ``public: true`` flag:
          app.api_client_github:
              # ...
     -        public: true
- 
+
          app.api_client_sl_connect:
              # ...
     -        public: true