Not use contraction

.doctor-rst.yaml

@@ -29,6 +29,7 @@ rules:
     no_blank_line_after_filepath_in_yaml_code_block: ~
     no_brackets_in_method_directive: ~
     no_composer_req: ~
+    no_contraction: ~
     no_directive_after_shorthand: ~
     no_explicit_use_of_code_block_php: ~
     no_inheritdoc: ~

_build/maintainer_guide.rst

@@ -3,7 +3,7 @@ Symfony Docs Maintainer Guide
 
 The `symfony/symfony-docs`_ repository stores the Symfony project documentation
 and is managed by the `Symfony Docs team`_. This article explains in detail some
-of those management tasks, so it's only useful for maintainers and not regular
+of those management tasks, so it is only useful for maintainers and not regular
 readers or Symfony developers.
 
 Reviewing Pull Requests
@@ -17,7 +17,7 @@ but there are extra things to keep in mind for maintainers:
 * Don't assume that contributors know what you think is obvious (e.g. lots of
   them don't know what to "squash commits" means).
 * Don't use acronyms like IMO, IIRC, etc. or complex English words (most
-  contributors are not native in English and it's intimidating for them).
+  contributors are not native in English and it is intimidating for them).
 * Never engage in a heated discussion. Lock it right away using GitHub.
 * Never discuss non-tech issues. Some PRs are related to our Diversity initiative
   and some people always try to drag you into politics. Never engage in that and
@@ -26,14 +26,14 @@ but there are extra things to keep in mind for maintainers:
 Fixing Minor Issues Yourself
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-It's common for new contributors to make lots of minor mistakes in the syntax
-of the RST format used in the docs. It's also common for non English speakers to
+It is common for new contributors to make lots of minor mistakes in the syntax
+of the RST format used in the docs. It is also common for non English speakers to
 make minor typos.
 
 Even if your intention is good, if you add lots of comments when reviewing a
-first contribution, that person will probably not contribute again. It's better
+first contribution, that person will probably not contribute again. It is better
 to fix the minor errors and typos yourself while merging. If that person
-contributes again, it's OK to mention some of the minor issues to educate them.
+contributes again, it is OK to mention some of the minor issues to educate them.
 
 .. code-block:: terminal
 
@@ -53,7 +53,7 @@ contributes again, it's OK to mention some of the minor issues to educate them.
       $ git commit -a
       # Use "Minor reword", "Minor tweak", etc. as the commit message
 
-      # now run the 'push' command shown above by 'gh' (it's different each time)
+      # now run the 'push' command shown above by 'gh' (it is different each time)
       $ git push gh "5.4" refs/notes/github-comments
 
 Merging Pull Requests
@@ -93,8 +93,8 @@ interface. Then:
 Merging Process
 ~~~~~~~~~~~~~~~
 
-At first, it's common to make mistakes and merge things badly. Don't worry. This
-has happened to all of us and we've always been able to recover from any mistake.
+At first, it is common to make mistakes and merge things badly. Don't worry. This
+has happened to all of us and we have always been able to recover from any mistake.
 
 Step 1: Select the right branch to merge
 ........................................
@@ -107,7 +107,7 @@ PRs must be merged in the oldest maintained branch where they are applicable:
   usually means ``master``. And don't forget to check that new feature includes
   the ``versionadded`` directive.
 
-It's very common for contributors (specially newcomers) to select the wrong
+It is very common for contributors (specially newcomers) to select the wrong
 branch for their PRs, so we must always check if the change should go to the
 proposed branch or not.
 
@@ -121,12 +121,12 @@ Never use GitHub's web interface (or desktop clients) to merge PRs or to solve
 merge conflicts. Always use the ``gh`` tool for anything related to merges.
 
 We require two approval votes from team members before merging a PR, except if
-it's a typo, a small change or clearly an error.
+it is a typo, a small change or clearly an error.
 
 If a PR contains lots of commits, there's no need to ask the contributor to
 squash them. The ``gh`` tool does that automatically. The only exceptions are
 when commits are made by more than one person and when there's a merge commit.
-``gh`` can't squash commits in those cases, so it's better to ask to the
+``gh`` cannot squash commits in those cases, so it is better to ask to the
 original contributor.
 
 .. code-block:: terminal
@@ -147,13 +147,13 @@ original contributor.
     $ git push origin
     $ git push upstream
 
-It's common to have to change the branch where a PR is merged. Instead of asking
+It is common to have to change the branch where a PR is merged. Instead of asking
 the contributors to rebase their PRs, the "gh" tool can change the branch with
 the ``-s`` option:
 
 .. code-block:: terminal
 
-    # e.g. this PR was sent against 'master', but it's merged in '4.4'
+    # e.g. this PR was sent against 'master', but it is merged in '4.4'
     $ gh merge 11160 -s 4.4
 
 Sometimes, when changing the branch, you may face rebase issues, but they are
@@ -228,7 +228,7 @@ maintained branches until ``master``. Imagine that you are merging a PR against
 
 .. tip::
 
-    When the support of a Symfony branch ends, it's recommended to delete your
+    When the support of a Symfony branch ends, it is recommended to delete your
     local branch to avoid merging in it unawarely:
 
     .. code-block:: terminal
@@ -250,12 +250,12 @@ When updating your local branches before merging:
     $ git checkout 4.4
     $ git merge upstream/4.4
 
-It's possible that you merge a wrong upstream branch unawarely. It's usually
-easy to spot because you'll see lots of conflicts:
+It is possible that you merge a wrong upstream branch unawarely. It is usually
+easy to spot because you will see lots of conflicts:
 
 .. code-block:: terminal
 
-    # DON'T DO THIS! It's a wrong branch merge
+    # DON'T DO THIS! It is a wrong branch merge
     $ git checkout 4.4
     $ git merge upstream/5.0
 
@@ -269,12 +269,12 @@ local branch and check it out again:
     $ git checkout 4.4 upstream/4.4
 
 If you did push the wrong branch merge, ask for help in the documentation
-mergers chat and we'll help solve the problem.
+mergers chat and we will help solve the problem.
 
 Solving merge conflicts
 .......................
 
-When merging things to upper branches, most of the times you'll see conflicts:
+When merging things to upper branches, most of the times you will see conflicts:
 
 .. code-block:: terminal
 
@@ -303,7 +303,7 @@ the marker used by Git for conflicts) and then do this:
 .. tip::
 
     When there are lots of conflicts, look for ``<<<<<`` with your editor in all
-    docs before committing the changes. It's common to forget about some of them.
+    docs before committing the changes. It is common to forget about some of them.
     If you prefer, you can run this too: ``git grep --cached "<<<<<"``.
 
 Merging deleted files

_includes/_annotation_loader_tip.rst.inc

@@ -5,7 +5,7 @@
 
 .. tip::
 
-    Annotation classes aren't loaded automatically, so you must load them
+    Annotation classes are not loaded automatically, so you must load them
     using a class loader like this::
 
         use Composer\Autoload\ClassLoader;

_includes/_rewrite_rule_tip.rst.inc

@@ -2,5 +2,5 @@
 
     By using rewrite rules in your
     :doc:`web server configuration </setup/web_server_configuration>`,
-    the ``index.php`` won't be needed and you will have beautiful, clean URLs
+    the ``index.php`` will not be needed and you will have beautiful, clean URLs
     (e.g. ``/show``).

best_practices.rst

@@ -40,7 +40,7 @@ Use the Default Directory Structure
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Unless your project follows a development practice that imposes a certain
-directory structure, follow the default Symfony directory structure. It's flat,
+directory structure, follow the default Symfony directory structure. It is flat,
 self-explanatory and not coupled to Symfony:
 
 .. code-block:: text
@@ -123,7 +123,7 @@ Then, use just one or two words to describe the purpose of the parameter:
         app.dir: '...'
         # do this: short but easy to understand names
         app.contents_dir: '...'
-        # it's OK to use dots, underscores, dashes or nothing, but always
+        # it is OK to use dots, underscores, dashes or nothing, but always
         # be consistent and use the same format for all the parameters
         app.dir.contents: '...'
         app.contents-dir: '...'
@@ -150,7 +150,7 @@ Twig templates and Doctrine entities, whereas parameters are only available
 from places with access to the :doc:`service container </service_container>`.
 
 The only notable disadvantage of using constants for this kind of configuration
-values is that it's complicated to redefine their values in your tests.
+values is that it is complicated to redefine their values in your tests.
 
 Business Logic
 --------------
@@ -191,9 +191,9 @@ Use the YAML Format to Configure your own Services
 
 If you use the :ref:`default services.yaml configuration <service-container-services-load-example>`,
 most services will be configured automatically. However, in some edge cases
-you'll need to configure services (or parts of them) manually.
+you will need to configure services (or parts of them) manually.
 
-YAML is the format recommended configuring services because it's friendly to
+YAML is the format recommended configuring services because it is friendly to
 newcomers and concise, but Symfony also supports XML and PHP configuration.
 
 Use Attributes to Define the Doctrine Entity Mapping
@@ -203,7 +203,7 @@ Doctrine entities are plain PHP objects that you store in some "database".
 Doctrine only knows about your entities through the mapping metadata configured
 for your model classes.
 
-Doctrine supports several metadata formats, but it's recommended to use PHP
+Doctrine supports several metadata formats, but it is recommended to use PHP
 attributes because they are by far the most convenient and agile way of setting
 up and looking for mapping information.
 
@@ -222,7 +222,7 @@ or checking security permissions.
 
 Extending your controllers from this base controller couples your application
 to Symfony. Coupling is generally wrong, but it may be OK in this case because
-controllers shouldn't contain any business logic. Controllers should contain
+controllers should not contain any business logic. Controllers should contain
 nothing more than a few lines of *glue-code*, so you are not coupling the
 important parts of your application.
 
@@ -257,12 +257,12 @@ constructor arguments.
 Use ParamConverters If They Are Convenient
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you're using :doc:`Doctrine </doctrine>`, then you can *optionally* use the
+If you are using :doc:`Doctrine </doctrine>`, then you can *optionally* use the
 `ParamConverter`_ to automatically query for an entity and pass it as an argument
 to your controller. It will also show a 404 page if no entity can be found.
 
 If the logic to get an entity from a route variable is more complex, instead of
-configuring the ParamConverter, it's better to make the Doctrine query inside
+configuring the ParamConverter, it is better to make the Doctrine query inside
 the controller (e.g. by calling to a :doc:`Doctrine repository method </doctrine>`).
 
 Templates
@@ -298,16 +298,16 @@ Add Form Buttons in Templates
 
 Form classes should be agnostic to where they will be used. For example, the
 button of a form used to both create and edit items should change from "Add new"
-to "Save changes" depending on where it's used.
+to "Save changes" depending on where it is used.
 
-Instead of adding buttons in form classes or the controllers, it's recommended
+Instead of adding buttons in form classes or the controllers, it is recommended
 to add buttons in the templates. This also improves the separation of concerns
 because the button styling (CSS class and other attributes) is defined in the
 template instead of in a PHP class.
 
 However, if you create a :doc:`form with multiple submit buttons </form/multiple_buttons>`
 you should define them in the controller instead of the template. Otherwise, you
-won't be able to check which button was clicked when handling the form in the controller.
+will not be able to check which button was clicked when handling the form in the controller.
 
 Define Validation Constraints on the Underlying Object
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -323,7 +323,7 @@ Use a Single Action to Render and Process the Form
 
 :ref:`Rendering forms <rendering-forms>` and :ref:`processing forms <processing-forms>`
 are two of the main tasks when handling forms. Both are too similar (most of the
-time, almost identical), so it's much simpler to let a single controller action
+time, almost identical), so it is much simpler to let a single controller action
 handle both.
 
 .. _best-practice-internationalization:
@@ -336,7 +336,7 @@ Use the XLIFF Format for Your Translation Files
 
 Of all the translation formats supported by Symfony (PHP, Qt, ``.po``, ``.mo``,
 JSON, CSV, INI, etc.), ``XLIFF`` and ``gettext`` have the best support in the tools used
-by professional translators. And since it's based on XML, you can validate ``XLIFF``
+by professional translators. And since it is based on XML, you can validate ``XLIFF``
 file contents as you write them.
 
 Symfony also supports notes in XLIFF files, making them more user-friendly for
@@ -361,7 +361,7 @@ Define a Single Firewall
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Unless you have two legitimately different authentication systems and users
-(e.g. form login for the main site and a token system for your API only), it's
+(e.g. form login for the main site and a token system for your API only), it is
 recommended to have only one firewall to keep things simple.
 
 Additionally, you should use the ``anonymous`` key under your firewall. If you
@@ -439,21 +439,21 @@ checks that all application URLs load successfully::
     }
 
 Add this test while creating your application because it requires little effort
-and checks that none of your pages returns an error. Later, you'll add more
+and checks that none of your pages returns an error. Later, you will add more
 specific tests for each page.
 
 .. _hardcode-urls-in-a-functional-test:
 
 Hard-code URLs in a Functional Test
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In Symfony applications, it's recommended to :ref:`generate URLs <routing-generating-urls>`
+In Symfony applications, it is recommended to :ref:`generate URLs <routing-generating-urls>`
 using routes to automatically update all links when a URL changes. However, if a
-public URL changes, users won't be able to browse it unless you set up a
+public URL changes, users will not be able to browse it unless you set up a
 redirection to the new URL.
 
-That's why it's recommended to use raw URLs in tests instead of generating them
-from routes. Whenever a route changes, tests will fail, and you'll know that
+That's why it is recommended to use raw URLs in tests instead of generating them
+from routes. Whenever a route changes, tests will fail, and you will know that
 you must set up a redirection.
 
 .. _`Symfony Demo`: https://github.com/symfony/demo

bundles.rst

@@ -30,7 +30,7 @@ file::
         Symfony\Bundle\MonologBundle\MonologBundle::class => ['all' => true],
         Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
         Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle::class => ['all' => true],
-        // this bundle is enabled only in 'dev' and 'test', so you can't use it in 'prod'
+        // this bundle is enabled only in 'dev' and 'test', so you cannot use it in 'prod'
         Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true],
     ];
 
@@ -69,7 +69,7 @@ called ``AcmeTestBundle.php``::
 
 This empty class is the only piece you need to create the new bundle. Though
 commonly empty, this class is powerful and can be used to customize the behavior
-of the bundle. Now that you've created the bundle, enable it::
+of the bundle. Now that you have created the bundle, enable it::
 
     // config/bundles.php
     return [
@@ -111,7 +111,7 @@ to be adjusted if needed:
 A bundle can be as small or large as the feature it implements. It contains
 only the files you need and nothing else.
 
-As you move through the guides, you'll learn how to persist objects to a
+As you move through the guides, you will learn how to persist objects to a
 database, create and validate forms, create translations for your application,
 write tests and much more. Each of these has their own place and role within
 the bundle.

bundles/best_practices.rst

@@ -165,7 +165,7 @@ CSS or any other language.
 Doctrine Entities/Documents
 ---------------------------
 
-If the bundle includes Doctrine ORM entities and/or ODM documents, it's
+If the bundle includes Doctrine ORM entities and/or ODM documents, it is
 recommended to define their mapping using XML files stored in
 ``Resources/config/doctrine/``. This allows to override that mapping using the
 :doc:`standard Symfony mechanism to override bundle parts </bundles/override>`.
@@ -255,7 +255,7 @@ Installation
 
 Bundles should set ``"type": "symfony-bundle"`` in their ``composer.json`` file.
 With this, :ref:`Symfony Flex <symfony-flex>` will be able to automatically
-enable your bundle when it's installed.
+enable your bundle when it is installed.
 
 If your bundle requires any setup (e.g. configuration, new files, changes to
 ``.gitignore``, etc), then you should create a `Symfony Flex recipe`_.
@@ -467,7 +467,7 @@ Services
 If the bundle defines services, they must be prefixed with the bundle alias
 instead of using fully qualified class names like you do in your project
 services. For example, AcmeBlogBundle services must be prefixed with ``acme_blog``.
-The reason is that bundles shouldn't rely on features such as service autowiring
+The reason is that bundles should not rely on features such as service autowiring
 or autoconfiguration to not impose an overhead when compiling application services.
 
 In addition, services not meant to be used by the application directly, should
@@ -508,7 +508,7 @@ The ``composer.json`` file should include at least the following metadata:
     a string (or array of strings) with a `valid license identifier`_, such as ``MIT``.
 
 ``autoload``
-    This information is used by Symfony to load the classes of the bundle. It's
+    This information is used by Symfony to load the classes of the bundle. It is
     recommended to use the `PSR-4`_ autoload standard: use the namespace as key,
     and the location of the bundle's main class (relative to ``composer.json``)
     as value. As the main class is located in the ``src/`` directory of the bundle: