Removed gender-based pronouns per [c0a2daad78].

11 files changed, 18 insertions, 19 deletions

diff --git a/docs/ref/clickjacking.txt b/docs/ref/clickjacking.txt
index cb3ac1bcd1..bb50f97f08 100644
--- a/docs/ref/clickjacking.txt
+++ b/docs/ref/clickjacking.txt
@@ -20,8 +20,8 @@ purchase an item. A user has chosen to stay logged into the store all the time
 for convenience. An attacker site might create an "I Like Ponies" button on one
 of their own pages, and load the store's page in a transparent iframe such that
 the "Buy Now" button is invisibly overlaid on the "I Like Ponies" button. If the
-user visits the attacker site and clicks "I Like Ponies" he or she will inadvertently
-click on the online store's "Buy Now" button and unknowingly purchase the item.
+user visits the attacker's site, clicking "I Like Ponies" will cause an
+inadvertent click on the "Buy Now" button and an unknowing purchase of the item.
 
 .. _clickjacking-prevention:
 
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 225475803f..24b6294278 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -172,7 +172,7 @@ Getting the current domain for display
 
 LJWorld.com and Lawrence.com both have email alert functionality, which lets
 readers sign up to get notifications when news happens. It's pretty basic: A
-reader signs up on a Web form, and he or she immediately gets an email saying,
+reader signs up on a Web form and immediately gets an email saying,
 "Thanks for your subscription."
 
 It'd be inefficient and redundant to implement this signup-processing code
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index a1207fb0f8..d9cb07e9b3 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -2468,7 +2468,7 @@ SESSION_EXPIRE_AT_BROWSER_CLOSE
 
 Default: ``False``
 
-Whether to expire the session when the user closes his or her browser. See
+Whether to expire the session when the user closes their browser. See
 :ref:`browser-length-vs-persistent-sessions`.
 
 .. setting:: SESSION_FILE_PATH
diff --git a/docs/releases/1.3-beta-1.txt b/docs/releases/1.3-beta-1.txt
index 8719221ddd..907625a7f4 100644
--- a/docs/releases/1.3-beta-1.txt
+++ b/docs/releases/1.3-beta-1.txt
@@ -73,8 +73,7 @@ The Django admin has long had an undocumented "feature" allowing savvy
 users to manipulate the query string of changelist pages to filter the
 list of objects displayed. However, this also creates a security
 issue, as a staff user with sufficient knowledge of model structure
-could use this "feature" to gain access to information he or she would
-not normally have.
+could use this "feature" to gain access to information not normally accessible.
 
 As a result, changelist filtering now explicitly validates all lookup
 arguments in the query string, and permits only fields which are
diff --git a/docs/releases/1.4.6.txt b/docs/releases/1.4.6.txt
index e3ccbbb344..cac640ad97 100644
--- a/docs/releases/1.4.6.txt
+++ b/docs/releases/1.4.6.txt
@@ -19,7 +19,7 @@ The security checks for these redirects (namely
 ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
 and as such allowed ``javascript:...`` URLs to be entered. If a developer
 relied on ``is_safe_url()`` to provide safe redirect targets and put such a
-URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
+URL into a link, they could suffer from a XSS attack. This bug doesn't affect
 Django currently, since we only put this URL into the ``Location`` response
 header and browsers seem to ignore JavaScript there.
 
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 1ba2c6ac7f..f8c23728b9 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -811,7 +811,7 @@ instance:
 
   * Consequences: The user will see an error about the form having expired
     and will be sent back to the first page of the wizard, losing the data
-    he or she has entered so far.
+    entered so far.
 
   * Time period: The amount of time you expect users to take filling out the
     affected forms.
diff --git a/docs/releases/1.5.2.txt b/docs/releases/1.5.2.txt
index 2a2cf9195d..6414aab509 100644
--- a/docs/releases/1.5.2.txt
+++ b/docs/releases/1.5.2.txt
@@ -16,7 +16,7 @@ The security checks for these redirects (namely
 ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
 and as such allowed ``javascript:...`` URLs to be entered. If a developer
 relied on ``is_safe_url()`` to provide safe redirect targets and put such a
-URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
+URL into a link, they could suffer from a XSS attack. This bug doesn't affect
 Django currently, since we only put this URL into the ``Location`` response
 header and browsers seem to ignore JavaScript there.
 
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index e08ea5f960..7ef7285fb7 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -1123,10 +1123,10 @@ Controlling cache: Using other headers
 Other problems with caching are the privacy of data and the question of where
 data should be stored in a cascade of caches.
 
-A user usually faces two kinds of caches: his or her own browser cache (a
-private cache) and his or her provider's cache (a public cache). A public cache
-is used by multiple users and controlled by someone else. This poses problems
-with sensitive data--you don't want, say, your bank account number stored in a
+A user usually faces two kinds of caches: their own browser cache (a private
+cache) and their provider's cache (a public cache). A public cache is used by
+multiple users and controlled by someone else. This poses problems with
+sensitive data--you don't want, say, your bank account number stored in a
 public cache. So Web applications need a way to tell caches which data is
 private and which is public.
 
diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt
index 1024d6b0c2..9e02b50c67 100644
--- a/docs/topics/db/aggregation.txt
+++ b/docs/topics/db/aggregation.txt
@@ -241,7 +241,7 @@ such alias were specified, it would be the rather long ``'book__pubdate__min'``.
 
 This doesn't apply just to foreign keys. It also works with many-to-many
 relations. For example, we can ask for every author, annotated with the total
-number of pages considering all the books he/she has (co-)authored (note how we
+number of pages considering all the books the author has (co-)authored (note how we
 use ``'book'`` to specify the ``Author`` -> ``Book`` reverse many-to-many hop)::
 
     >>> Author.objects.annotate(total_pages=Sum('book__pages'))
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index d39b8344c6..f7e8807945 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -166,7 +166,7 @@ and the :setting:`SECRET_KEY` setting.
     cookie backend might open you up to `replay attacks`_. Unlike other session
     backends which keep a server-side record of each session and invalidate it
     when a user logs out, cookie-based sessions are not invalidated when a user
-    logs out. Thus if an attacker steals a user's cookie, he or she can use that
+    logs out. Thus if an attacker steals a user's cookie, they can use that
     cookie to login as that user even if the user logs out. Cookies will only
     be detected as 'stale' if they are older than your
     :setting:`SESSION_COOKIE_AGE`.
@@ -590,8 +590,8 @@ log in every time they open a browser.
 
 If :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``True``, Django will
 use browser-length cookies -- cookies that expire as soon as the user closes
-his or her browser. Use this if you want people to have to log in every time
-they open a browser.
+their browser. Use this if you want people to have to log in every time they
+open a browser.
 
 This setting is a global default and can be overwritten at a per-session level
 by explicitly calling the :meth:`~backends.base.SessionBase.set_expiry` method
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 66b9a99e21..6e56831a6b 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1579,8 +1579,8 @@ If all you want is to run Django with your native language all you need to do
 is set :setting:`LANGUAGE_CODE` and make sure the corresponding :term:`message
 files <message file>` and their compiled versions (``.mo``) exist.
 
-If you want to let each individual user specify which language he or she
-prefers, then you also need to use use the ``LocaleMiddleware``.
+If you want to let each individual user specify which language they
+prefer, then you also need to use use the ``LocaleMiddleware``.
 ``LocaleMiddleware`` enables language selection based on data from the request.
 It customizes content for each user.