minor #11044 be keen to newcomers (OskarStark)

This PR was squashed before being merged into the 3.4 branch (closes #11044).

Discussion
----------

be keen to newcomers

Do not use **easy**, **easily** and **simply**

This is a follow-up PR of #11036

Commits
-------

979274b be keen to newcomers

Author: javiereguiluz

best_practices/business-logic.rst

@@ -176,7 +176,7 @@ This practice is cumbersome and completely unnecessary for your own services.
     Don't define parameters for the classes of your services.
 
 This practice was wrongly adopted from third-party bundles. When Symfony
-introduced its service container, some developers used this technique to easily
+introduced its service container, some developers used this technique to
 allow overriding services. However, overriding a service by just changing its
 class name is a very rare use case because, frequently, the new service has
 different constructor arguments.

best_practices/controllers.rst

@@ -119,7 +119,7 @@ Fetching Services
 
 If you extend the base ``Controller`` class, you can access services directly from
 the container via ``$this->container->get()`` or ``$this->get()``. But instead, you
-should use dependency injection to fetch services: most easily done by
+should use dependency injection to fetch services by
 :ref:`type-hinting action method arguments <controller-accessing-services>`:
 
 .. best-practice::
@@ -208,9 +208,9 @@ flexible::
         // ...
     }
 
-The point is this: the ParamConverter shortcut is great for simple situations.
-But you shouldn't forget that querying for entities directly is still very
-easy.
+The point is this: the ParamConverter shortcut is great for most situations.
+However, there is nothing wrong with querying for entities directly if the
+ParamConverter would get complicated.
 
 Pre and Post Hooks
 ------------------

best_practices/security.rst

@@ -108,8 +108,7 @@ The @Security Annotation
 ------------------------
 
 For controlling access on a controller-by-controller basis, use the ``@Security``
-annotation whenever possible. It's easy to read and is placed consistently
-above each action.
+annotation whenever possible. Placing it above each action makes it consistent and readable.
 
 In our application, you need the ``ROLE_ADMIN`` in order to create a new post.
 Using ``@Security``, this looks like:
@@ -156,7 +155,7 @@ Notice that this requires the use of the `ParamConverter`_, which automatically
 queries for the ``Post`` object and puts it on the ``$post`` argument. This
 is what makes it possible to use the ``post`` variable in the expression.
 
-This has one major drawback: an expression in an annotation cannot easily
+This has one major drawback: an expression in an annotation cannot
 be reused in other parts of the application. Imagine that you want to add
 a link in a template that will only be seen by authors. Right now you'll
 need to repeat the expression code using Twig syntax:
@@ -167,7 +166,7 @@ need to repeat the expression code using Twig syntax:
         <a href=""> ... </a>
     {% endif %}
 
-The easiest solution - if your logic is simple enough - is to add a new method
+A good solution - if your logic is simple enough - can be to add a new method
 to the ``Post`` entity that checks if a given user is its author::
 
     // src/AppBundle/Entity/Post.php

best_practices/templates.rst

@@ -58,7 +58,7 @@ scattered through lots of bundles.
     Use a prefixed underscore for partial templates in template names.
 
 You often want to reuse template code using the ``include`` function to avoid
-redundant code. To determine those partials easily in the filesystem you should
+redundant code. To determine those partials in the filesystem you should
 prefix partials and any other template without HTML body or ``extends`` tag
 with a single underscore.
 

best_practices/web-assets.rst

@@ -37,11 +37,11 @@ Using Assetic
 
 .. include:: /assetic/_standard_edition_warning.rst.inc
 
-These days, you probably can't simply create static CSS and JavaScript files
-and include them in your template. Instead, you'll probably want to combine
-and minify these to improve client-side performance. You may also want to
-use LESS or Sass (for example), which means you'll need some way to process
-these into CSS files.
+These days, you probably can't create static CSS and JavaScript files and
+include them in your template without much effort. Instead, you'll probably
+want to combine and minify these to improve client-side performance. You may
+also want to use LESS or Sass (for example), which means you'll need some way
+to process these into CSS files.
 
 A lot of tools exist to solve these problems, including pure-frontend (non-PHP)
 tools like GruntJS.

bundles/best_practices.rst

@@ -9,8 +9,8 @@ There are two types of bundles:
 * Application-specific bundles: only used to build your application;
 * Reusable bundles: meant to be shared across many projects.
 
-This article is all about how to structure your **reusable bundles** so that
-they're easy to configure and extend. Many of these recommendations do not
+This article is all about how to structure your **reusable bundles** to be
+configurable and extendable. Many of these recommendations do not
 apply to application bundles because you'll want to keep those as simple
 as possible. For application bundles, just follow the practices shown throughout
 the guides.

bundles/inheritance.rst

@@ -35,8 +35,8 @@ Then, register the third-party FOSUserBundle as the "parent" of your bundle::
         }
     }
 
-By making this simple change, you can now override several parts of the FOSUserBundle
-simply by creating a file with the same name.
+By making this small change, you can now override several parts of the FOSUserBundle
+by creating a file with the same name.
 
 .. note::
 
@@ -82,8 +82,8 @@ original method, and change its functionality::
 Overriding Resources: Templates, Routing, etc
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Most resources can also be overridden, simply by creating a file in the same
-location as your parent bundle.
+Most resources can also be overridden by creating a file in the same location
+as your parent bundle.
 
 For example, it's very common to need to override the FOSUserBundle's
 ``layout.html.twig`` template so that it uses your application's base layout.

configuration/configuration_organization.rst

@@ -6,7 +6,7 @@ How to Organize Configuration Files
 
 The default Symfony Standard Edition defines three
 :doc:`execution environments </configuration/environments>` called
-``dev``, ``prod`` and ``test``. An environment simply represents a way to
+``dev``, ``prod`` and ``test``. An environment represents a way to
 execute the same codebase with different configurations.
 
 In order to select the configuration file to load for each environment, Symfony

configuration/external_parameters.rst

@@ -7,8 +7,7 @@ How to Set external Parameters in the Service Container
 In the article :doc:`/configuration`, you learned how to manage your application
 configuration. At times, it may benefit your application to store certain
 credentials outside of your project code. Database configuration is one such
-example. The flexibility of the Symfony service container allows you to easily
-do this.
+example. The flexibility of the Symfony service container allows you to do this.
 
 Environment Variables
 ---------------------

configuration/front_controllers_and_kernel.rst

@@ -55,7 +55,7 @@ The front controller can be chosen by requesting URLs like:
      http://localhost/app_dev.php/some/path/...
 
 As you can see, this URL contains the PHP script to be used as the front
-controller. You can use that to easily switch the front controller or use
+controller. You can use that to switch the front controller or use
 a custom one by placing it in the ``web/`` directory (e.g. ``app_cache.php``).
 
 When using Apache and the `RewriteRule shipped with the Symfony Standard Edition`_,
@@ -153,7 +153,7 @@ front controller to the ``AppKernel``'s constructor. This name can then be
 used in the :method:`Symfony\\Component\\HttpKernel\\KernelInterface::registerContainerConfiguration`
 method to decide which configuration files to load.
 
-The Symfony Standard Edition's `AppKernel`_ class implements this method by simply
+The Symfony Standard Edition's `AppKernel`_ class implements this method by
 loading the ``app/config/config_*environment*.yml`` file. You are, of course,
 free to implement this method differently if you need a more sophisticated
 way of loading your configuration.