minor #11218 use "application(s)" instead of "app(s)" (OskarStark)

javiereguiluz · javiereguiluz · commit e268bdd433e1 · 2019-03-25T15:25:04.000+01:00
This PR was merged into the 3.4 branch. Discussion ---------- use "application(s)" instead of "app(s)" Commits ------- ca97daa use application instead of app
diff --git a/_build/redirection_map b/_build/redirection_map
@@ -360,3 +360,4 @@
 /components/weblink /components/web_link
 /frontend/encore/installation-no-flex /frontend/encore/installation
 /console/logging /console
+/frontend/encore/legacy-apps /frontend/encore/legacy-applications
diff --git a/best_practices/configuration.rst b/best_practices/configuration.rst
@@ -94,8 +94,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
 
diff --git a/best_practices/creating-the-project.rst b/best_practices/creating-the-project.rst
@@ -101,13 +101,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 use bundles to divide their code into logical features: UserBundle,
+applications use 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::
 
diff --git a/best_practices/introduction.rst b/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.
+appications 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
diff --git a/contributing/community/releases.rst b/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::
 
diff --git a/controller.rst b/controller.rst
@@ -152,7 +152,8 @@ and many others that you'll learn about next.
     Symfony services. This forces you to write more robust code to access services.
 
     Moreover, in Symfony 4.2 ``Controller`` was deprecated in favor of
-    ``AbstractController``, so using the latter will make your apps future-proof.
+    ``AbstractController``, so using the latter will make your applications
+    future-proof.
 
 .. versionadded:: 3.3
 
diff --git a/email/gmail.rst b/email/gmail.rst
@@ -122,12 +122,12 @@ parameters.
 
 If your Gmail account uses 2-Step-Verification, you must `generate an App password`_
 and use it as the value of the ``mailer_password`` parameter. You must also ensure
-that you `allow less secure apps to access your Gmail account`_.
+that you `allow less secure applications to access your Gmail account`_.
 
 .. seealso::
 
     See the :doc:`Swiftmailer configuration reference </reference/configuration/swiftmailer>`
     for more details.
 
 .. _`generate an App password`: https://support.google.com/accounts/answer/185833
-.. _`allow less secure apps to access your Gmail account`: https://support.google.com/accounts/answer/6010255
+.. _`allow less secure applications to access your Gmail account`: https://support.google.com/accounts/answer/6010255
diff --git a/form/form_customization.rst b/form/form_customization.rst
@@ -303,7 +303,7 @@ Disabling Usage of Globally Defined Themes
 Sometimes you may want to disable the use of the globally defined form themes in order
 to have more control over the rendering of a form. You might want this, for example,
 when creating an admin interface for a bundle which can be installed on a wide range
-of Symfony apps (and so you can't control what themes are defined globally).
+of Symfony applications (and so you can't control what themes are defined globally).
 
 You can do this by including the ``only`` keyword after the list of form themes:
 
diff --git a/frontend.rst b/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>`
diff --git a/frontend/encore/faq.rst b/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
 ----------------------------------------------------
diff --git a/frontend/encore/legacy-applications.rst b/frontend/encore/legacy-applications.rst
diff --git a/frontend/encore/simple-example.rst b/frontend/encore/simple-example.rst
@@ -212,8 +212,8 @@ To import values, use ``import``:
 Page-Specific JavaScript or CSS (Multiple Entries)
 --------------------------------------------------
 
-So far, you only have one final JavaScript file: ``app.js``. For simple apps or
-SPA's (Single Page Applications), that might be fine! However, as your app grows,
+So far, you only have one final JavaScript file: ``app.js``. For small applications
+or SPA's (Single Page Applications), that might be fine! However, as your app grows,
 you may want to have page-specific JavaScript or CSS (e.g. checkout, account,
 etc.). To handle this, create a new "entry" JavaScript file for each page:
 
diff --git a/page_creation.rst b/page_creation.rst
@@ -234,7 +234,7 @@ What's Next?
 ------------
 
 Congrats! You're already starting to master Symfony and learn a whole new
-way of building beautiful, functional, fast and maintainable apps.
+way of building beautiful, functional, fast and maintainable applications.
 
 Ok, time to finish mastering the fundamentals by reading these articles:
 
diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst
@@ -2228,7 +2228,7 @@ A list of workflows to be created by the framework extension:
 
 .. seealso::
 
-    See also the article about :doc:`using workflows in Symfony apps </workflow>`.
+    See also the article about :doc:`using workflows in Symfony applications </workflow>`.
 
 .. _reference-workflows-enabled:
 
diff --git a/setup.rst b/setup.rst
@@ -249,8 +249,8 @@ Installing the Symfony Demo or Other Distributions
 --------------------------------------------------
 
 You've already downloaded the `Symfony Standard Edition`_: the default starting project
-for all Symfony apps. You'll use this project throughout the documentation to build
-your app!
+for all Symfony applications. You'll use this project throughout the documentation to
+build your application!
 
 Symfony also provides some other projects and starting skeletons that you can use:
 
diff --git a/web_link.rst b/web_link.rst
@@ -97,7 +97,7 @@ automatically trigger a push for the related file in the same HTTP/2 connection.
 
 Popular proxy services and CDNs including `Cloudflare`_, `Fastly`_ and `Akamai`_
 also leverage this feature. It means that you can push resources to clients and
-improve performance of your apps in production right now.
+improve performance of your applications in production right now.
 
 If you want to prevent the push but let the browser preload the resource by
 issuing an early separate HTTP request, use the ``nopush`` option:
