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

Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>

diff --git a/docs/en/docs/advanced/security/http-basic-auth.md b/docs/en/docs/advanced/security/http-basic-auth.md
index 1d2e050f57446e4fcd30fc4e1699959404f653cb..c0ebea4fed9f7c074654459a31a9eba0954a2d50 100644 (file)
--- a/docs/en/docs/advanced/security/http-basic-auth.md
+++ b/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()`
 

diff --git a/docs/en/docs/tutorial/background-tasks.md b/docs/en/docs/tutorial/background-tasks.md
index 7ee8d8a78ec9956fd23efa6ea04387971e639b2f..a12362ebdbe0b57772bb1dcf2e10da80f395ceab 100644 (file)
--- a/docs/en/docs/tutorial/background-tasks.md
+++ b/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:
 

diff --git a/docs/en/docs/tutorial/handling-errors.md b/docs/en/docs/tutorial/handling-errors.md
index c2a130a1276f5fae39f0d1c2cef25b15f378c687..714c4c94a57ad28b96459a6d5f5cf126269874a9 100644 (file)
--- a/docs/en/docs/tutorial/handling-errors.md
+++ b/docs/en/docs/tutorial/handling-errors.md
@@ -47,7 +47,7 @@ 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
 {
@@ -55,7 +55,7 @@ If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), he
 }
 ```
 
-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
 {

diff --git a/docs/en/docs/tutorial/security/first-steps.md b/docs/en/docs/tutorial/security/first-steps.md
index d1d2725b0abbc59f8299f829ad43a34ee58f3650..360d85ae4d92360ddb3f4f8a23e184aed296d908 100644 (file)
--- a/docs/en/docs/tutorial/security/first-steps.md
+++ b/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.

diff --git a/docs/en/docs/tutorial/security/oauth2-jwt.md b/docs/en/docs/tutorial/security/oauth2-jwt.md
index a647db3eba3ebda7f081debe24217ee804f62c8a..b65a9f58c28b297decc56728da995b66ab877d51 100644 (file)
--- a/docs/en/docs/tutorial/security/oauth2-jwt.md
+++ b/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.