Replace gendered pronouns with gender-neutral

epochblue · weaverryan · commit 66ee9448c1af · 2013-12-01T18:08:09.000-05:00
For consistency sake, instances of "he", "she", "his", "hers",
"his/hers", "he/she", etc were replaced with "they", "their", etc (or
were removed all together in cases where they weren't necessary). Verb
tenses should also have been corrected where changes were made.
diff --git a/book/http_cache.rst b/book/http_cache.rst
@@ -474,7 +474,7 @@ The resulting HTTP header will look like this:
 
 Note that in HTTP versions before 1.1 the origin server wasn't required to
 send the ``Date`` header. Consequently the cache (e.g. the browser) might
-need to rely onto his local clock to evaluate the ``Expires`` header making
+need to rely on the local clock to evaluate the ``Expires`` header making
 the lifetime calculation vulnerable to clock skew. Another limitation
 of the ``Expires`` header is that the specification states that "HTTP/1.1
 servers should not send ``Expires`` dates more than one year in the future."
diff --git a/book/installation.rst b/book/installation.rst
@@ -341,7 +341,7 @@ file:
 
 Now, the vendor directory won't be committed to source control. This is fine
 (actually, it's great!) because when someone else clones or checks out the
-project, he/she can simply run the ``php composer.phar install`` script to
+project, they can simply run the ``php composer.phar install`` script to
 install all the necessary project dependencies.
 
 .. _`enable ACL support`: https://help.ubuntu.com/community/FilePermissionsACLs
diff --git a/book/security.rst b/book/security.rst
@@ -5,7 +5,7 @@ Security
 ========
 
 Security is a two-step process whose goal is to prevent a user from accessing
-a resource that he/she should not have access to.
+a resource that they should not have access to.
 
 In the first step of the process, the security system identifies who the user
 is by requiring the user to submit some sort of identification. This is called
@@ -165,7 +165,7 @@ Firewalls (Authentication)
 
 When a user makes a request to a URL that's protected by a firewall, the
 security system is activated. The job of the firewall is to determine whether
-or not the user needs to be authenticated, and if he does, to send a response
+or not the user needs to be authenticated, and if they do, to send a response
 back to the user initiating the authentication process.
 
 A firewall is activated when the URL of an incoming request matches the configured
@@ -217,7 +217,7 @@ If the credentials are valid, the original request can be re-tried.
    :align: center
 
 In this example, the user ``ryan`` successfully authenticates with the firewall.
-But since ``ryan`` doesn't have the ``ROLE_ADMIN`` role, he's still denied
+But since ``ryan`` doesn't have the ``ROLE_ADMIN`` role, they're still denied
 access to ``/admin/foo``. Ultimately, this means that the user will see some
 sort of message indicating that access has been denied.
 
@@ -1041,7 +1041,7 @@ Access Control Lists (ACLs): Securing Individual Database Objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Imagine you are designing a blog system where your users can comment on your
-posts. Now, you want a user to be able to edit his own comments, but not
+posts. Now, you want a user to be able to edit their own comments, but not
 those of other users. Also, as the admin user, you yourself want to be able
 to edit *all* comments.
 
@@ -1809,7 +1809,7 @@ a route so that you can use it to generate the URL:
     As of Symfony 2.1, you *must* have a route that corresponds to your logout
     path. Without this route, logging out will not work.
 
-Once the user has been logged out, he will be redirected to whatever path
+Once the user has been logged out, they will be redirected to whatever path
 is defined by the ``target`` parameter above (e.g. the ``homepage``). For
 more information on configuring the logout, see the
 :doc:`Security Configuration Reference </reference/configuration/security>`.
diff --git a/book/templating.rst b/book/templating.rst
@@ -1362,7 +1362,7 @@ this classic example:
 
         Hello <?php echo $name ?>
 
-Imagine that the user enters the following code as his/her name:
+Imagine the user enters the following code for their name:
 
 .. code-block:: text
 
diff --git a/book/validation.rst b/book/validation.rst
@@ -694,7 +694,7 @@ on that class. To do this, you can organize each constraint into one or more
 constraints.
 
 For example, suppose you have a ``User`` class, which is used both when a
-user registers and when a user updates his/her contact information later:
+user registers and when a user updates their contact information later:
 
 .. configuration-block::
 
diff --git a/components/console/helpers/dialoghelper.rst b/components/console/helpers/dialoghelper.rst
@@ -49,8 +49,8 @@ if you want to know a bundle name, you can add this to your command::
         'AcmeDemoBundle'
     );
 
-The user will be asked "Please enter the name of the bundle". She can type
-some name which will be returned by the ``ask`` method. If she leaves it empty,
+The user will be asked "Please enter the name of the bundle". They can type
+some name which will be returned by the ``ask`` method. If they leave it empty,
 the default value (``AcmeDemoBundle`` here) is returned.
 
 Hiding the User's Response
@@ -120,8 +120,8 @@ function should also return the value of the user's input if the validation was
 You can set the max number of times to ask in the ``$attempts`` argument.
 If you reach this max number it will use the default value, which is given
 in the last argument. Using ``false`` means the amount of attempts is infinite.
-The user will be asked as long as he provides an invalid answer and will only
-be able to proceed if her input is valid.
+The user will be asked as long as they provide an invalid answer and will only
+be able to proceed if their input is valid.
 
 Validating a Hidden Response
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -184,7 +184,7 @@ The option which should be selected by default is provided with the fourth
 parameter. The default is ``null``, which means that no option is the default one.
 
 If the user enters an invalid string, an error message is shown and the user
-is asked to provide the answer another time, until she enters a valid string
+is asked to provide the answer another time, until they enter a valid string
 or the maximum attempts is reached (which you can define in the fifth
 parameter). The default value for the attempts is ``false``, which means infinite
 attempts. You can define your own error message in the sixth parameter.
diff --git a/components/event_dispatcher/introduction.rst b/components/event_dispatcher/introduction.rst
@@ -11,7 +11,7 @@ Introduction
 Objected Oriented code has gone a long way to ensuring code extensibility. By
 creating classes that have well defined responsibilities, your code becomes
 more flexible and a developer can extend them with subclasses to modify their
-behaviors. But if he wants to share his changes with other developers who have
+behaviors. But if they want to share the changes with other developers who have
 also made their own subclasses, code inheritance is no longer the answer.
 
 Consider the real-world example where you want to provide a plugin system for
diff --git a/components/security/authentication.rst b/components/security/authentication.rst
@@ -110,7 +110,7 @@ Authenticating Users by their Username and Password
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 An authentication provider will attempt to authenticate a user based on
-the credentials he provided. Usually these are a username and a password.
+the credentials they provided. Usually these are a username and a password.
 Most web applications store their user's username and a hash of the user's
 password combined with a randomly generated salt. This means that the average
 authentication would consist of fetching the salt and the hashed password
@@ -228,4 +228,4 @@ which should be used to encode this user's password::
         $user->getSalt());
 
 .. _`CVE-2013-5750`: http://symfony.com/blog/cve-2013-5750-security-issue-in-fosuserbundle-login-form
-.. _`BasePasswordEncoder::checkPasswordLength`: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Encoder/BasePasswordEncoder.php
+.. _`BasePasswordEncoder::checkPasswordLength`: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Encoder/BasePasswordEncoder.php
diff --git a/components/security/firewall.rst b/components/security/firewall.rst
@@ -101,7 +101,7 @@ firewall map will jump in.
 
 The exception listener determines what happens next, based on the arguments
 it received when it was created. It may start the authentication procedure,
-perhaps ask the user to supply his credentials again (when he has only been
+perhaps ask the user to supply their credentials again (when they have only been
 authenticated based on a "remember-me" cookie), or transform the exception
 into an :class:`Symfony\\Component\\HttpKernel\\Exception\\AccessDeniedHttpException`,
 which will eventually result in an "HTTP/1.1 403: Access Denied" response.
@@ -119,7 +119,7 @@ object and the exception by which the exception listener was triggered.
 The method should return a :class:`Symfony\\Component\\HttpFoundation\\Response`
 object. This could be, for instance, the page containing the login form or,
 in the case of Basic HTTP authentication, a response with a ``WWW-Authenticate``
-header, which will prompt the user to supply his username and password.
+header, which will prompt the user to supply their username and password.
 
 Flow: Firewall, Authentication, Authorization
 ---------------------------------------------
diff --git a/contributing/documentation/translations.rst b/contributing/documentation/translations.rst
@@ -58,7 +58,7 @@ Symfony2 documentation for a new language.
 As starting a translation is a lot of work, talk about your plan on the
 `Symfony docs mailing-list`_ and try to find motivated people willing to help.
 
-When the team is ready, nominate a team manager; he will be responsible for
+When the team is ready, nominate a team manager; they will be responsible for
 the *master* repository.
 
 Create the repository and copy the *English* documents.
diff --git a/cookbook/bundles/extension.rst b/cookbook/bundles/extension.rst
@@ -504,7 +504,7 @@ Modifying the configuration of another Bundle
 If you have multiple bundles that depend on each other, it may be useful
 to allow one ``Extension`` class to modify the configuration passed to another
 bundle's ``Extension`` class, as if the end-developer has actually placed that
-configuration in his/her ``app/config/config.yml`` file.
+configuration in their ``app/config/config.yml`` file.
 
 For more details, see :doc:`/cookbook/bundles/prepend_extension`.
 
diff --git a/cookbook/form/dynamic_form_modification.rst b/cookbook/form/dynamic_form_modification.rst
@@ -169,8 +169,8 @@ How to Dynamically Generate Forms based on user Data
 
 Sometimes you want a form to be generated dynamically based not only on data
 from the form but also on something else - like some data from the current user.
-Suppose you have a social website where a user can only message people who
-are his friends on the website. In this case, a "choice list" of whom to message
+Suppose you have a social website where a user can only message people marked 
+as friends on the website. In this case, a "choice list" of whom to message
 should only contain users that are the current user's friends.
 
 Creating the Form Type
diff --git a/cookbook/form/form_collections.rst b/cookbook/form/form_collections.rst
@@ -269,7 +269,7 @@ Allowing "new" tags with the "prototype"
 
 Allowing the user to dynamically add new tags means that you'll need to
 use some JavaScript. Previously you added two tags to your form in the controller.
-Now let the user add as many tag forms as he needs directly in the browser.
+Now let the user add as many tag forms as they need directly in the browser.
 This will be done through a bit of JavaScript.
 
 The first thing you need to do is to let the form collection know that it will
diff --git a/cookbook/security/acl.rst b/cookbook/security/acl.rst
@@ -21,7 +21,7 @@ the ACL system comes in.
     class will handle the logic behind the scenes, instead of the ACL system.
 
 Imagine you are designing a blog system where your users can comment on your
-posts. Now, you want a user to be able to edit his own comments, but not those
+posts. Now, you want a user to be able to edit their own comments, but not those
 of other users; besides, you yourself want to be able to edit all comments. In
 this scenario, ``Comment`` would be the domain object that you want to
 restrict access to. You could take several approaches to accomplish this using
diff --git a/cookbook/security/custom_provider.rst b/cookbook/security/custom_provider.rst
@@ -280,7 +280,7 @@ users, e.g. by filling in a login form. You can do this by adding a line to the
 
 The value here should correspond with however the passwords were originally
 encoded when creating your users (however those users were created). When
-a user submits her password, the salt value is appended to the password and
+a user submits their password, the salt value is appended to the password and
 then encoded using this algorithm before being compared to the hashed password
 returned by your ``getPassword()`` method. Additionally, depending on your
 options, the password may be encoded multiple times and encoded to base64.
diff --git a/cookbook/security/entity_provider.rst b/cookbook/security/entity_provider.rst
@@ -240,7 +240,7 @@ layer is a piece of cake. Everything resides in the configuration of the
 :doc:`SecurityBundle </reference/configuration/security>` stored in the
 ``app/config/security.yml`` file.
 
-Below is an example of configuration where the user will enter his/her
+Below is an example of configuration where the user will enter their 
 username and password via HTTP basic authentication. That information will
 then be checked against your User entity records in the database:
 
@@ -408,12 +408,12 @@ Now, if you try to authenticate as a user who's ``is_active`` database field
 is set to 0, you won't be allowed.
 
 The next session will focus on how to write a custom entity provider 
-to authenticate a user with his username or his email address.
+to authenticate a user with their username or email address.
 
 Authenticating Someone with a Custom Entity Provider
 ----------------------------------------------------
 
-The next step is to allow a user to authenticate with his username or his email
+The next step is to allow a user to authenticate with their username or email
 address as they are both unique in the database. Unfortunately, the native
 entity provider is only able to handle a single property to fetch the user from
 the database.
@@ -537,7 +537,7 @@ of the ``security.yml`` file.
 
 By doing this, the security layer will use an instance of ``UserRepository`` and
 call its ``loadUserByUsername()`` method to fetch a user from the database
-whether he filled in his username or email address.
+whether they filled in their username or email address.
 
 Managing Roles in the Database
 ------------------------------
@@ -708,7 +708,7 @@ Improving Performance with a Join
 To improve performance and avoid lazy loading of roles when retrieving a user
 from the custom entity provider, you can use a Doctrine join to the roles
 relationship in the ``UserRepository::loadUserByUsername()`` method. This will
-fetch the user and his associated roles with a single query::
+fetch the user and their associated roles with a single query::
 
     // src/Acme/UserBundle/Entity/UserRepository.php
     namespace Acme\UserBundle\Entity;
@@ -735,5 +735,5 @@ fetch the user and his associated roles with a single query::
     }
 
 The ``QueryBuilder::leftJoin()`` method joins and fetches related roles from
-the ``AcmeUserBundle:User`` model class when a user is retrieved with his email
+the ``AcmeUserBundle:User`` model class when a user is retrieved by their email
 address or username.
diff --git a/cookbook/security/form_login.rst b/cookbook/security/form_login.rst
@@ -23,7 +23,7 @@ You can change where the login form redirects after a successful login using
 the various config options. By default the form will redirect to the URL the
 user requested (i.e. the URL which triggered the login form being shown).
 For example, if the user requested ``http://www.example.com/admin/post/18/edit``,
-then after she successfully logs in, she will eventually be sent back to
+then after they successfully log in, they will eventually be sent back to
 ``http://www.example.com/admin/post/18/edit``.
 This is done by storing the requested URL in the session.
 If no URL is present in the session (perhaps the user went
@@ -33,7 +33,7 @@ in several ways.
 
 .. note::
 
-    As mentioned, by default the user is redirected back to the page he originally
+    As mentioned, by default the user is redirected back to the page originally
     requested. Sometimes, this can cause problems, like if a background Ajax
     request "appears" to be the last visited URL, causing the user to be
     redirected there. For information on controlling this behavior, see
diff --git a/cookbook/security/remember_me.rst b/cookbook/security/remember_me.rst
@@ -112,7 +112,7 @@ the cookie remains valid.
 Forcing the User to Re-authenticate before accessing certain Resources
 ----------------------------------------------------------------------
 
-When the user returns to your site, he/she is authenticated automatically based
+When the user returns to your site, they are authenticated automatically based
 on the information stored in the remember me cookie. This allows the user
 to access protected resources as if the user had actually authenticated upon
 visiting the site.
@@ -195,16 +195,16 @@ which can secure your controller using annotations:
     * If a non-authenticated (or anonymously authenticated user) tries to
       access the account area, the user will be asked to authenticate.
 
-    * Once the user has entered his username and password, assuming the
+    * Once the user has entered their username and password, assuming the
       user receives the ``ROLE_USER`` role per your configuration, the user
       will have the ``IS_AUTHENTICATED_FULLY`` role and be able to access
       any page in the account section, including the ``editAction`` controller.
 
-    * If the user's session ends, when the user returns to the site, he will
+    * If the user's session ends, when the user returns to the site, they will
       be able to access every account page - except for the edit page - without
-      being forced to re-authenticate. However, when he tries to access the
-      ``editAction`` controller, he will be forced to re-authenticate, since
-      he is not, yet, fully authenticated.
+      being forced to re-authenticate. However, when they try to access the
+      ``editAction`` controller, they will be forced to re-authenticate, since
+      they are not, yet, fully authenticated.
 
 For more information on securing services or methods in this way,
 see :doc:`/cookbook/security/securing_services`.
diff --git a/cookbook/security/target_path.rst b/cookbook/security/target_path.rst
@@ -7,8 +7,8 @@ How to change the Default Target Path Behavior
 By default, the Security component retains the information of the last request
 URI in a session variable named ``_security.main.target_path`` (with ``main`` being
 the name of the firewall, defined in ``security.yml``). Upon a successful
-login, the user is redirected to this path, as to help her continue from the
-last known page she visited.
+login, the user is redirected to this path, as to help them continue from the
+last known page they visited.
 
 On some occasions, this is unexpected. For example when the last request
 URI was an HTTP POST against a route which is configured to allow only a POST
diff --git a/cookbook/workflow/_vendor_deps.rst.inc b/cookbook/workflow/_vendor_deps.rst.inc
@@ -59,7 +59,7 @@ and download the exact same set of vendor libraries. This means that you're
 controlling exactly what each vendor library looks like, without needing to
 actually commit them to *your* repository.
 
-So, whenever a developer uses your project, he/she should run the ``php composer.phar install``
+So, whenever a developer uses your project, they should run the ``php composer.phar install``
 script to ensure that all of the needed vendor libraries are downloaded.
 
 .. sidebar:: Upgrading Symfony
diff --git a/reference/configuration/security.rst b/reference/configuration/security.rst
@@ -117,7 +117,7 @@ Each part will be explained in the next section.
                         # submit the login form here
                         check_path: /login_check
 
-                        # the user is redirected here when he/she needs to log in
+                        # the user is redirected here when they need to log in
                         login_path: /login
 
                         # if true, forward the user to the login form instead of redirecting
@@ -231,7 +231,7 @@ The Login Form and Process
 
 *   ``login_path`` (type: ``string``, default: ``/login``)
     This is the route or path that the user will be redirected to (unless
-    ``use_forward`` is set to ``true``) when he/she tries to access a
+    ``use_forward`` is set to ``true``) when they try to access a
     protected resource but isn't fully authenticated.
 
     This path **must** be accessible by a normal, un-authenticated user, else
diff --git a/reference/constraints/UserPassword.rst b/reference/constraints/UserPassword.rst
diff --git a/reference/forms/types/repeated.rst b/reference/forms/types/repeated.rst
