✏️ Update docs to remove gender-specific references (#1824)

Co-authored-by: Sebastián Ramírez <[email protected]>

Author: Mause

docs/en/docs/advanced/security/http-basic-auth.md

@@ -54,9 +54,9 @@ But by using the `secrets.compare_digest()` it will be secure against a type of
 
 But what's a "timing attack"?
 
-Let's imagine an attacker is trying to guess the username and password.
+Let's imagine some attackers are trying to guess the username and password.
 
-And that attacker sends a request with a username `johndoe` and a password `love123`.
+And they send a request with a username `johndoe` and a password `love123`.
 
 Then the Python code in your application would be equivalent to something like:
 
@@ -67,7 +67,7 @@ if "johndoe" == "stanleyjobson" and "love123" == "swordfish":
 
 But right at the moment Python compares the first `j` in `johndoe` to the first `s` in `stanleyjobson`, it will return `False`, because it already knows that those two strings are not the same, thinking that "there's no need to waste more computation comparing the rest of the letters". And your application will say "incorrect user or password".
 
-But then the attacker tries with username `stanleyjobsox` and password `love123`.
+But then the attackers try with username `stanleyjobsox` and password `love123`.
 
 And your application code does something like:
 
@@ -78,17 +78,17 @@ if "stanleyjobsox" == "stanleyjobson" and "love123" == "swordfish":
 
 Python will have to compare the whole `stanleyjobso` in both `stanleyjobsox` and `stanleyjobson` before realizing that both strings are not the same. So it will take some extra microseconds to reply back "incorrect user or password".
 
-#### The time to answer helps the attacker
+#### The time to answer helps the attackers
 
-At that point, by noticing that the server took some microseconds longer to send the "incorrect user or password" response, the attacker will know that she/he got _something_ right, some of the initial letters were right.
+At that point, by noticing that the server took some microseconds longer to send the "incorrect user or password" response, the attackers will know that they got _something_ right, some of the initial letters were right.
 
-And then she/he can try again knowing that it's probably something more similar to `stanleyjobsox` than to `johndoe`.
+And then they can try again knowing that it's probably something more similar to `stanleyjobsox` than to `johndoe`.
 
 #### A "professional" attack
 
-Of course, the attacker would not try all this by hand, she/he would write a program to do it, possibly with thousands or millions of tests per second. And would get just one extra correct letter at a time.
+Of course, the attackers would not try all this by hand, they would write a program to do it, possibly with thousands or millions of tests per second. And would get just one extra correct letter at a time.
 
-But doing that, in some minutes or hours the attacker would have guessed the correct username and password, with the "help" of our application, just using the time taken to answer.
+But doing that, in some minutes or hours the attackers would have guessed the correct username and password, with the "help" of our application, just using the time taken to answer.
 
 #### Fix it with `secrets.compare_digest()`
 

docs/en/docs/tutorial/background-tasks.md

@@ -2,7 +2,7 @@
 
 You can define background tasks to be run *after* returning a response.
 
-This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving his response.
+This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving the response.
 
 This includes, for example:
 

docs/en/docs/tutorial/handling-errors.md

@@ -47,15 +47,15 @@ In this example, when the client request an item by an ID that doesn't exist, ra
 
 ### The resulting response
 
-If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), he will receive an HTTP status code of 200, and a JSON response of:
+If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), that client will receive an HTTP status code of 200, and a JSON response of:
 
 ```JSON
 {
   "item": "The Foo Wrestlers"
 }
 ```
 
-But if the client requests `http://example.com/items/bar` (a non-existent `item_id` `"bar"`), he will receive an HTTP status code of 404 (the "not found" error), and a JSON response of:
+But if the client requests `http://example.com/items/bar` (a non-existent `item_id` `"bar"`), that client will receive an HTTP status code of 404 (the "not found" error), and a JSON response of:
 
 ```JSON
 {

docs/en/docs/tutorial/security/first-steps.md

@@ -85,7 +85,7 @@ But in this case, the same **FastAPI** application will handle the API and the a
 
 So, let's review it from that simplified point of view:
 
-* The user types his `username` and `password` in the frontend, and hits `Enter`.
+* The user types the `username` and `password` in the frontend, and hits `Enter`.
 * The frontend (running in the user's browser) sends that `username` and `password` to a specific URL in our API (declared with `tokenUrl="token"`).
 * The API checks that `username` and `password`, and responds with a "token" (we haven't implemented any of this yet).
     * A "token" is just a string with some content that we can use later to verify this user.

docs/en/docs/tutorial/security/oauth2-jwt.md

@@ -20,7 +20,7 @@ It is not encrypted, so, anyone could recover the information from the contents.
 
 But it's signed. So, when you receive a token that you emitted, you can verify that you actually emitted it.
 
-That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still logged in to your system.
+That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know that user is still logged in to your system.
 
 After a week, the token will be expired and the user will not be authorized and will have to sign in again to get a new token. And if the user (or a third party) tried to modify the token to change the expiration, you would be able to discover it, because the signatures would not match.