Merge branch '3.4' into 4.2

* 3.4:
  use application instead of app
  be keen to newcomers

Author: javiereguiluz

_build/redirection_map

@@ -411,3 +411,4 @@
 /security/entity_provider /security/user_provider
 /session/avoid_session_start /session
 /session/sessions_directory /session
+/frontend/encore/legacy-apps /frontend/encore/legacy-applications

best_practices/configuration.rst

@@ -100,8 +100,8 @@ paginated results.
     Use constants to define configuration options that rarely change.
 
 The traditional approach for defining configuration options has caused many
-Symfony apps to include an option like the following, which would be used
-to control the number of posts to display on the blog homepage:
+Symfony applications to include an option like the following, which would be
+used to control the number of posts to display on the blog homepage:
 
 .. code-block:: yaml
 

best_practices/creating-the-project.rst

@@ -76,13 +76,13 @@ Application Bundles
 
 When Symfony 2.0 was released, most developers naturally adopted the symfony
 1.x way of dividing applications into logical modules. That's why many Symfony
-apps used bundles to divide their code into logical features: UserBundle,
+applications used bundles to divide their code into logical features: UserBundle,
 ProductBundle, InvoiceBundle, etc.
 
 But a bundle is *meant* to be something that can be reused as a stand-alone
 piece of software. If UserBundle cannot be used *"as is"* in other Symfony
-apps, then it shouldn't be its own bundle. Moreover, if InvoiceBundle depends on
-ProductBundle, then there's no advantage to having two separate bundles.
+applications, then it shouldn't be its own bundle. Moreover, if InvoiceBundle
+depends on ProductBundle, then there's no advantage to having two separate bundles.
 
 .. best-practice::
 

best_practices/introduction.rst

@@ -19,8 +19,8 @@ What is this Guide About?
 -------------------------
 
 This guide aims to fix that by describing the **best practices for developing
-web apps with the Symfony full-stack Framework**. These are best practices that
-fit the philosophy of the framework as envisioned by its original creator
+web applications with the Symfony full-stack Framework**. These are best practices
+that fit the philosophy of the framework as envisioned by its original creator
 `Fabien Potencier`_.
 
 .. note::
@@ -44,8 +44,8 @@ then **extend and fit to your specific needs**:
 
 We know that old habits die hard and some of you will be shocked by some
 of these best practices. But by following these, you'll be able to develop
-apps faster, with less complexity and with the same or even higher quality.
-It's also a moving target that will continue to improve.
+applications faster, with less complexity and with the same or even higher
+quality. It's also a moving target that will continue to improve.
 
 Keep in mind that these are **optional recommendations** that you and your
 team may or may not follow to develop Symfony applications. If you want to

contributing/community/releases.rst

@@ -8,13 +8,13 @@ Symfony releases follow the `semantic versioning`_ strategy and they are
 published through a *time-based model*:
 
 * A new **Symfony patch version** (e.g. 2.8.15, 4.1.7) comes out roughly every
-  month. It only contains bug fixes, so you can safely upgrade your apps;
+  month. It only contains bug fixes, so you can safely upgrade your applications;
 * A new **Symfony minor version** (e.g. 2.8, 3.2, 4.1) comes out every *six months*:
   one in *May* and one in *November*. It contains bug fixes and new features, but
-  it doesn't include any breaking change, so you can safely upgrade your apps;
+  it doesn't include any breaking change, so you can safely upgrade your applications;
 * A new **Symfony major version** (e.g. 3.0, 4.0) comes out every *two years*.
   It can contain breaking changes, so you may need to do some changes in your
-  apps before upgrading.
+  applications before upgrading.
 
 .. tip::
 

create_framework/http_kernel_httpkernelinterface.rst

@@ -90,11 +90,10 @@ to cache a response for 10 seconds, use the ``Response::setTtl()`` method::
 
 .. tip::
 
-    If, like me, you are running your framework from the command line by
-    simulating requests (``Request::create('/is_leap_year/2012')``), you can
-    debug Response instances by dumping their string representation
-    (``echo $response;``) as it displays all headers as well as the response
-    content.
+    If you are running your framework from the command line by simulating
+    requests (``Request::create('/is_leap_year/2012')``), you can debug Response
+    instances by dumping their string representation (``echo $response;``) as it
+    displays all headers as well as the response content.
 
 To validate that it works correctly, add a random number to the response
 content and check that the number only changes every 10 seconds::
@@ -113,9 +112,9 @@ expiration and the validation models of the HTTP specification. If you are not
 comfortable with these concepts, read the `HTTP caching`_ chapter of the
 Symfony documentation.
 
-The Response class contains methods that let you configure the
-HTTP cache. One of the most powerful is ``setCache()`` as it
-abstracts the most frequently used caching strategies into a single array::
+The Response class contains methods that let you configure the HTTP cache. One
+of the most powerful is ``setCache()`` as it abstracts the most frequently used
+caching strategies into a single array::
 
     $date = date_create_from_format('Y-m-d H:i:s', '2005-10-15 10:00:00');
 
@@ -135,8 +134,8 @@ abstracts the most frequently used caching strategies into a single array::
     $response->setSharedMaxAge(10);
 
 When using the validation model, the ``isNotModified()`` method allows you to
-cut on the response time by short-circuiting the response generation as
-early as possible::
+cut on the response time by short-circuiting the response generation as early as
+possible::
 
     $response->setETag('whatever_you_compute_as_an_etag');
 

forms.rst

@@ -166,7 +166,7 @@ That's it! The :ref:`form() function <reference-forms-twig-form>` renders all
 fields *and* the ``<form>`` start and end tags. By default, the form method is
 ``POST`` and the target URL is the same that displayed the form.
 
-As easy as this is, it's not very flexible. Usually, you'll need more control
+As short as this is, it's not very flexible. Usually, you'll need more control
 about how the entire form or some of its fields look. Symfony provides several
 ways of doing that:
 

frontend.rst

@@ -69,7 +69,7 @@ Guides
 
 * :doc:`Using Bootstrap CSS & JS </frontend/encore/bootstrap>`
 * :doc:`Creating Page-Specific CSS/JS </frontend/encore/page-specific-assets>`
-* :doc:`jQuery and Legacy Applications </frontend/encore/legacy-apps>`
+* :doc:`jQuery and Legacy Applications </frontend/encore/legacy-applications>`
 * :doc:`Passing Information from Twig to JavaScript </frontend/encore/server-data>`
 * :doc:`webpack-dev-server and Hot Module Replacement (HMR) </frontend/encore/dev-server>`
 * :doc:`Adding custom loaders & plugins </frontend/encore/custom-loaders-plugins>`

frontend/encore/faq.rst

@@ -92,7 +92,7 @@ or ``jQuery`` to be a global variable. But, when you use Webpack and ``require('
 no global variables are set.
 
 The fix depends on if the error is happening in your code or inside some third-party
-code that you're using. See :doc:`/frontend/encore/legacy-apps` for the fix.
+code that you're using. See :doc:`/frontend/encore/legacy-applications` for the fix.
 
 Uncaught ReferenceError: webpackJsonp is not defined
 ----------------------------------------------------