minor symfony#5464 Removed the glossary (WouterJ)

This PR was submitted for the 2.3 branch but it was merged into the 2.7 branch instead (closes symfony#5464).

Discussion
----------

Removed the glossary

| Q | A
| --- | ---
| Doc fix? | yes
| New docs? | no
| Applies to | all
| Fixed tickets | symfony#5462

It's funny that 99% of the `:term:` usages were located in sentences describing a term. So we didn't loose any information there. In some cases, I've tweaked the sentence a bit not loose any important information.

As for the genindex mentioned by @xabbuh in the issue, I believe this one is created automatically by Sphinx based on all `.. index::` directives in the documentation. When removing the glossary, the genindex will automatically not include the terms anymore (/cc @javiereguiluz please confirm).

Commits
-------

1c05aad Removed the glossary

book/from_flat_php_to_symfony2.rst

@@ -123,9 +123,9 @@ is primarily an HTML file that uses a template-like PHP syntax:
     </html>
 
 By convention, the file that contains all the application logic - ``index.php`` -
-is known as a "controller". The term :term:`controller` is a word you'll hear
-a lot, regardless of the language or framework you use. It refers simply
-to the area of *your* code that processes user input and prepares the response.
+is known as a "controller". The term controller is a word you'll hear a lot,
+regardless of the language or framework you use. It refers simply to the area
+of *your* code that processes user input and prepares the response.
 
 In this case, the controller prepares data from the database and then includes
 a template to present that data. With the controller isolated, you could
@@ -312,8 +312,8 @@ to security...
 A "Front Controller" to the Rescue
 ----------------------------------
 
-The solution is to use a :term:`front controller`: a single PHP file through
-which *all* requests are processed. With a front controller, the URIs for the
+The solution is to use a front controller: a single PHP file through which
+*all* requests are processed. With a front controller, the URIs for the
 application change slightly, but start to become more flexible:
 
 .. code-block:: text

book/http_cache.rst

@@ -26,11 +26,11 @@ websites, or is it? In this chapter, you'll see how the Symfony cache
 system works and why this is the best possible approach.
 
 The Symfony cache system is different because it relies on the simplicity
-and power of the HTTP cache as defined in the :term:`HTTP specification`.
-Instead of reinventing a caching methodology, Symfony embraces the standard
-that defines basic communication on the Web. Once you understand the fundamental
-HTTP validation and expiration caching models, you'll be ready to master
-the Symfony cache system.
+and power of the HTTP cache as defined in the `HTTP specification`_. Instead of
+reinventing a caching methodology, Symfony embraces the standard that defines
+basic communication on the Web. Once you understand the fundamental HTTP
+validation and expiration caching models, you'll be ready to master the Symfony
+cache system.
 
 For the purposes of learning how to cache with Symfony, the
 subject is covered in four steps:
@@ -1260,3 +1260,4 @@ Learn more from the Cookbook
 .. _`FrameworkExtraBundle documentation`: https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/cache.html
 .. _`ESI`: http://www.w3.org/TR/esi-lang
 .. _`FOSHttpCacheBundle`: http://foshttpcachebundle.readthedocs.org/
+.. _`HTTP specification`: http://www.w3.org/Protocols/rfc2616/rfc2616.html

book/http_fundamentals.rst

@@ -334,8 +334,8 @@ breaking all of your links?) and the fact that each file *must* manually
 include some set of core files so that security, database connections and
 the "look" of the site can remain consistent.
 
-A much better solution is to use a :term:`front controller`: a single PHP
-file that handles every request coming into your application. For example:
+A much better solution is to use a front controller: a single PHP file that
+handles every request coming into your application. For example:
 
 +------------------------+------------------------+
 | ``/index.php``         | executes ``index.php`` |
@@ -401,8 +401,8 @@ the same simple pattern for every request:
 
 Each "page" of your site is defined in a routing configuration file that
 maps different URLs to different PHP functions. The job of each PHP function,
-called a :term:`controller`, is to use information from the request - along
-with many other tools Symfony makes available - to create and return a ``Response``
+called a controller, is to use information from the request - along with many
+other tools Symfony makes available - to create and return a ``Response``
 object. In other words, the controller is where *your* code goes: it's where
 you interpret the request and create a response.
 

book/service_container.rst

@@ -39,13 +39,13 @@ the service container makes writing good code so easy.
 What is a Service?
 ------------------
 
-Put simply, a :term:`Service` is any PHP object that performs some sort of
-"global" task. It's a purposefully-generic name used in computer science
-to describe an object that's created for a specific purpose (e.g. delivering
-emails). Each service is used throughout your application whenever you need
-the specific functionality it provides. You don't have to do anything special
-to make a service: simply write a PHP class with some code that accomplishes
-a specific task. Congratulations, you've just created a service!
+Put simply, a service is any PHP object that performs some sort of "global"
+task. It's a purposefully-generic name used in computer science to describe an
+object that's created for a specific purpose (e.g. delivering emails). Each
+service is used throughout your application whenever you need the specific
+functionality it provides. You don't have to do anything special to make a
+service: simply write a PHP class with some code that accomplishes a specific
+task. Congratulations, you've just created a service!
 
 .. note::
 
@@ -72,8 +72,8 @@ are key to being a good developer in almost any language.
 What is a Service Container?
 ----------------------------
 
-A :term:`Service Container` (or *dependency injection container*) is simply
-a PHP object that manages the instantiation of services (i.e. objects).
+A service container (or *dependency injection container*) is simply a PHP
+object that manages the instantiation of services (i.e. objects).
 
 For example, suppose you have a simple PHP class that delivers email messages.
 Without a service container, you must manually create the object whenever

book/translation.rst

@@ -51,9 +51,9 @@ to learn even more. Overall, the process has several steps:
 Configuration
 -------------
 
-Translations are handled by a ``translator`` :term:`service` that uses the
-user's locale to lookup and return translated messages. Before using it,
-enable the ``translator`` in your configuration:
+Translations are handled by a ``translator`` service that uses the user's
+locale to lookup and return translated messages. Before using it, enable the
+``translator`` in your configuration:
 
 .. configuration-block::
 

components/form/introduction.rst

@@ -362,10 +362,12 @@ and then access it whenever you need to build a form.
     this object in some more "global" way so you can access it from anywhere.
 
 Exactly how you gain access to your one form factory is up to you. If you're
-using a :term:`Service Container`, then you should add the form factory to
-your container and grab it out whenever you need to. If your application
-uses global or static variables (not usually a good idea), then you can store
-the object on some static class or do something similar.
+using a service container (like provided with the
+:doc:`DependencyInjection component </components/dependency_injection/introduction>`),
+then you should add the form factory to your container and grab it out whenever
+you need to. If your application uses global or static variables (not usually a
+good idea), then you can store the object on some static class or do something
+similar.
 
 Regardless of how you architect your application, just remember that you
 should only have one form factory and that you'll need to be able to access

cookbook/symfony1.rst

@@ -218,11 +218,6 @@ Of course, there's nothing wrong with having multiple applications in your
 project, that's entirely up to you. A second application would mean a new
 directory, e.g. ``my_app/``, with the same basic setup as the ``app/`` directory.
 
-.. tip::
-
-    Read the definition of a :term:`Project`, an :term:`Application`, and a
-    :term:`Bundle` in the glossary.
-
 Bundles and Plugins
 -------------------
 

quick_tour/the_architecture.rst

@@ -10,8 +10,8 @@ into the architecture now.
 Understanding the Directory Structure
 -------------------------------------
 
-The directory structure of a Symfony :term:`application` is rather flexible,
-but the recommended structure is as follows:
+The directory structure of a Symfony application is rather flexible, but the
+recommended structure is as follows:
 
 ``app/``
     The application configuration, templates and translations.
@@ -26,8 +26,9 @@ The ``web/`` Directory
 ~~~~~~~~~~~~~~~~~~~~~~
 
 The web root directory is the home of all public and static files like images,
-stylesheets and JavaScript files. It is also where each :term:`front controller`
-lives, such as the production controller shown here::
+stylesheets and JavaScript files. It is also where each front controller (the
+file that handles all requests to your application) lives, such as the
+production controller shown here::
 
     // web/app.php
     require_once __DIR__.'/../app/bootstrap.php.cache';
@@ -72,7 +73,7 @@ Understanding the Bundle System
 -------------------------------
 
 This section introduces one of the greatest and most powerful features of
-Symfony, the :term:`bundle` system.
+Symfony: The bundle system.
 
 A bundle is kind of like a plugin in other software. So why is it
 called a *bundle* and not a *plugin*? This is because *everything* is a
@@ -179,8 +180,8 @@ defines the configuration for a specific bundle. For example, ``framework``
 configures the FrameworkBundle while ``swiftmailer`` configures the
 SwiftmailerBundle.
 
-Each :term:`environment` can override the default configuration by providing
-a specific configuration file. For example, the ``dev`` environment loads
+Each environment can override the default configuration by providing a
+specific configuration file. For example, the ``dev`` environment loads
 the ``config_dev.yml`` file, which loads the main configuration (i.e.
 ``config.yml``) and then modifies it to add some debugging tools:
 

quick_tour/the_big_picture.rst

@@ -199,10 +199,10 @@ environments**.
 What is an Environment?
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-An :term:`environment` represents a group of configurations that's used
-to run your application. Symfony defines two environments by default: ``dev``
-(suited for when developing the application locally) and ``prod`` (optimized
-for when executing the application on production).
+An environment represents a group of configurations that's used to run your
+application. Symfony defines two environments by default: ``dev`` (suited for
+when developing the application locally) and ``prod`` (optimized for when
+executing the application on production).
 
 When you visit the ``http://localhost:8000`` URL in your browser, you're
 executing your Symfony application in the ``dev`` environment. To visit

reference/constraints/Callback.rst

@@ -244,7 +244,7 @@ You can then use the following configuration to invoke this validator:
 .. note::
 
     The Callback constraint does *not* support global callback functions
-    nor is it possible to specify a global function or a :term:`service` method
+    nor is it possible to specify a global function or a service method
     as callback. To validate using a service, you should
     :doc:`create a custom validation constraint </cookbook/validation/custom_constraint>`
     and add that new constraint to your class.