Changed the doc to use gender-neutral pronouns when possible.

docs/ref/clickjacking.txt

@@ -20,7 +20,7 @@ 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 will inadvertently
+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.
 
 .. _clickjacking-prevention:

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 immediately gets an email saying,
+reader signs up on a Web form, and he or she immediately gets an email saying,
 "Thanks for your subscription."
 
 It'd be inefficient and redundant to implement this signup-processing code

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 could suffer from a XSS attack. This bug doesn't affect
+URL into a link, he or she 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.
 

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 has entered so far.
+    he or she has entered so far.
 
   * Time period: The amount of time you expect users to take filling out the
     affected forms.

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 could suffer from a XSS attack. This bug doesn't affect
+URL into a link, he or she 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.
 

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 can use that
+    logs out. Thus if an attacker steals a user's cookie, he or she 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`.