[3.1.x] Changed docs and a code comment to use gender-neutral pronouns.

Follow up to e1b7723817.

Backport of 477c800443 from master.

docs/internals/contributing/writing-code/working-with-git.txt

@@ -142,7 +142,7 @@ Pull requests at GitHub have only two states: open and closed. The committer
 who will deal with your pull request has only two options: merge it or close
 it. For this reason, it isn't useful to make a pull request until the code is
 ready for merging -- or sufficiently close that a committer will finish it
-himself.
+themselves.
 
 Rebasing branches
 -----------------

docs/ref/contrib/admin/actions.txt

@@ -186,7 +186,7 @@ provided by the admin.
 
 .. _custom-admin-action:
 
-For example, we can use ``self`` to flash a message to the user informing her
+For example, we can use ``self`` to flash a message to the user informing them
 that the action was successful::
 
     from django.contrib import messages

docs/releases/1.5.3.txt

@@ -32,7 +32,7 @@ Mitigating a remote-code execution vulnerability in :mod:`django.contrib.session
 session data before storing it in the backend. If you're using the :ref:`signed
 cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
 known by an attacker (there isn't an inherent vulnerability in Django that
-would cause it to leak), the attacker could insert a string into his session
+would cause it to leak), the attacker could insert a string into their session
 which, when unpickled, executes arbitrary code on the server. The technique for
 doing so is simple and easily available on the internet. Although the cookie
 session storage signs the cookie-stored data to prevent tampering, a

docs/releases/1.6.txt

@@ -797,7 +797,7 @@ Historically, :mod:`django.contrib.sessions` used :mod:`pickle` to serialize
 session data before storing it in the backend. If you're using the :ref:`signed
 cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
 known by an attacker (there isn't an inherent vulnerability in Django that
-would cause it to leak), the attacker could insert a string into his session
+would cause it to leak), the attacker could insert a string into their session
 which, when unpickled, executes arbitrary code on the server. The technique for
 doing so is simple and easily available on the internet. Although the cookie
 session storage signs the cookie-stored data to prevent tampering, a

docs/topics/db/examples/many_to_one.txt

@@ -185,7 +185,7 @@ Queries can go round in circles::
     >>> Reporter.objects.filter(article__reporter=r).distinct()
     <QuerySet [<Reporter: John Smith>]>
 
-If you delete a reporter, his articles will be deleted (assuming that the
+If you delete a reporter, their articles will be deleted (assuming that the
 ForeignKey was defined with :attr:`django.db.models.ForeignKey.on_delete` set to
 ``CASCADE``, which is the default)::
 

tests/many_to_one/tests.py

@@ -377,7 +377,7 @@ class ManyToOneTests(TestCase):
             pub_date=datetime.date(2005, 7, 27),
             reporter_id=str(self.r.id),
         )
-        # If you delete a reporter, his articles will be deleted.
+        # If you delete a reporter, their articles will be deleted.
         self.assertQuerysetEqual(
             Article.objects.all(),
             [

tests/template_tests/views.py

@@ -24,4 +24,4 @@ def template_response_view(request):
 
 
 def snark(request):
-    return HttpResponse('Found him!')
+    return HttpResponse('Found them!')