Use more Inclusive language and examples (#1195)

* Use more inclusive language

* Improve examples

Co-authored-by: Paula Mihu <97217318+nerpaula@users.noreply.github.com>

Author: Simran-B

3.10/administration-managing-users.md

@@ -350,7 +350,7 @@ There are a few differences to *normal* ArangoDB users:
 To grant access for an LDAP user you will need to create *roles* within the
 ArangoDB server. A role is just a user with the `:role:` prefix in its name.
 Role users cannot login as database users, the `:role:` prefix ensures this.
-Your LDAP users will need to have at least one role, once the user logs in he
-will be automatically granted the union of all access rights of all his roles.
+Your LDAP users will need to have at least one role; once users log in they
+will be automatically granted the union of all access rights of all their roles.
 Note that a lower right grant in one role will be overwritten by a higher
 access grant in a different role.

3.10/aql/examples-data-modification-queries.md

@@ -23,7 +23,7 @@ documents:
 
 ```aql
 FOR u IN users
-  UPDATE u WITH { gender: TRANSLATE(u.gender, { m: 'male', f: 'female' }) } IN users
+  UPDATE u WITH { gender: TRANSLATE(u.gender, { m: 'male', f: 'female', x: 'diverse' }) } IN users
 ```
 
 To add new attributes to existing documents, we can also use an `UPDATE` query.
@@ -130,11 +130,10 @@ FOR i IN 1..1000
     age: 18 + FLOOR(RAND() * 25),
     name: CONCAT('test', TO_STRING(i)),
     active: false,
-    gender: i % 2 == 0 ? 'male' : 'female'
+    gender: i % 3 == 0 ? 'male' : i % 3 == 1 ? 'female' : 'diverse'
   } IN users
 ```
 
-
 Copying data from one collection into another
 ---------------------------------------------
 

3.10/aql/examples.md

@@ -58,7 +58,7 @@ with the following initial data:
   { "id": 200, "name": "Sophia", "age": 37, "active": true, "gender": "f" },
   { "id": 201, "name": "Emma", "age": 36,  "active": true, "gender": "f" },
   { "id": 202, "name": "Olivia", "age": 35, "active": false, "gender": "f" },
-  { "id": 203, "name": "Madison", "age": 34, "active": true, "gender": "f" },
+  { "id": 203, "name": "Madison", "age": 34, "active": true, "gender": "x" },
   { "id": 204, "name": "Chloe", "age": 33, "active": true, "gender": "f" },
   { "id": 205, "name": "Eva", "age": 32, "active": false, "gender": "f" },
   { "id": 206, "name": "Abigail", "age": 31, "active": true, "gender": "f" },

3.10/aql/graphs-shortest-path.md

@@ -163,7 +163,7 @@ We start with the shortest path from **A** to **D** as above:
 {% include arangoshexample.html id=examplevar script=script result=result %}
 
 We can see our expectations are fulfilled. We find the vertices in the correct ordering and
-the first edge is *null*, because no edge is pointing to the start vertex on t his path.
+the first edge is *null*, because no edge is pointing to the start vertex on this path.
 
 We can also compute shortest paths based on documents found in collections:
 

3.10/aql/operations-filter.md

@@ -112,8 +112,8 @@ FOR u IN users
   RETURN u
 ```
 
-This will return the users *Mariah* and *Mary*. If sorted by age in `DESC` order,
-then the Sophia, Emma and Madison documents are returned. A `FILTER` after a
+This will return the users *Mariah*, *Mary*, and *Isabella*. If sorted by age in
+`DESC` order, then the *Sophia* and *Emma* documents are returned. A `FILTER` after a
 `LIMIT` is not very common however, and you probably want such a query instead:
 
 ```aql

3.10/arangosync.md

@@ -42,7 +42,7 @@ load, network & computer capacity.
 
 _ArangoSync_ performs replication in a **single direction** only. That means that
 you can replicate data from cluster _A_ to cluster _B_ or from cluster _B_ to
-cluster _A_, but never at the same time (one master, one or more slave clusters).
+cluster _A_, but never at the same time (one leader, one or more follower clusters).
 <br/>Data modified in the destination cluster **will be lost!**
 
 Replication is a completely **autonomous** process. Once it is configured it is
@@ -51,14 +51,14 @@ designed to run 24/7 without frequent manual intervention.
 <br/>As with any distributed system some attention is needed to monitor its operation
 and keep it secure (e.g. certificate & password rotation).
 
-In the event of an outage of the master cluster, user intervention is required
-to either bring the master back up or to decide on making a slave cluster the
-new master. There is no automatic failover as slave clusters lag behind the master
-because of network latency etc. and resuming operation with the state of a slave
+In the event of an outage of the leader cluster, user intervention is required
+to either bring the leader back up or to decide on making a follower cluster the
+new leader. There is no automatic failover as follower clusters lag behind the leader
+because of network latency etc. and resuming operation with the state of a follower
 cluster can therefore result in the loss of recent writes. How much can be lost
-largely depends on the data rate of the master cluster and the delay between
-the master and the slaves. Slaves will typically be behind the master by a couple
-of seconds or minutes.
+largely depends on the data rate of the leader cluster and the delay between
+the leader and the follower clusters. Followers will typically be behind the
+leader by a couple of seconds or minutes.
 
 Once configured, _ArangoSync_ will replicate both **structure and data** of an
 **entire cluster**. This means that there is no need to make additional configuration

3.10/deployment-cluster-using-the-starter.md

@@ -134,15 +134,16 @@ docker run -it --name=adb --rm -p 8528:8528 \
 
 Under the Hood
 --------------
-The first `arangodb` you ran will become the _master_ of your _Starter_
-setup, the other `arangodb` instances will become the _slaves_ of your _Starter_
-setup. Please do not confuse the terms _master_ and _slave_ above with the Leader/Follower
-("master/slave") technology of ArangoDB. The terms above refers to the _Starter_ setup.
 
-The _Starter_ _master_ determines which ArangoDB server processes to launch on which
-_Starter_ _slave_, and how they should communicate. 
+The first `arangodb` you ran will become the _leader_ of your _Starter_ setup
+(also called _master_), the other `arangodb` instances will become the
+_followers_ of your _Starter_ setup. This is not to be confused with the
+Leader/Follower replication of ArangoDB. The terms above refers to the _Starter_ setup.
+
+The _Starter_ _leader_ determines which ArangoDB server processes to launch on which
+_Starter_ _follower_, and how they should communicate.
 
 It will then launch the server processes and monitor them. Once it has detected
 that the setup is complete you will get the prompt. 
 
-The _Starter_ _master_ will save the setup for subsequent starts. 
+The _Starter_ _leader_ will save the setup for subsequent starts.

3.10/deployment-dc2dc.md

@@ -41,8 +41,8 @@ more information.
 The Sync Master is responsible for managing all synchronization, creating tasks and assigning
 those to workers.
 <br/> At least 2 instances must be deployed in each datacenter.
-One instance will be the "leader", the other will be an inactive slave. When the leader
-is gone for a short while, one of the other instances will take over.
+One instance will be the leader cluster, the other will be an inactive follower cluster.
+When the leader is gone for a short while, one of the other instances will take over.
 
 With clusters of a significant size, the sync master will require a significant set of resources.
 Therefore it is recommended to deploy sync masters on their own servers, equipped with sufficient

3.10/graphs.md

@@ -169,7 +169,7 @@ We can use an edge collection to store relations between users and groups. Since
 number of groups, this is an **m:n** relation. The edge collection can be called `UsersInGroups` with i.e. one edge
 with `_from` pointing to `Users/John` and `_to` pointing to `Groups/BowlingGroupHappyPin`. This makes the user **John**
 a member of the group **Bowling Group Happy Pin**. Attributes of this relation may contain qualifiers to this relation,
-like the permissions of **John** in this group, the date when he joined the group etc.
+like the permissions of **John** in this group, the date when John joined the group etc.
 
 ![User in group example](images/graph_user_in_group.png)
 

3.10/http/bulk-imports-importing-headers-and-values.md

@@ -19,13 +19,14 @@ curl --data-binary @- -X POST --dump - "http://localhost:8529/_api/import?collec
 [ "firstName", "lastName", "age", "gender" ]
 [ "Joe", "Public", 42, "male" ]
 [ "Jane", "Doe", 31, "female" ]
+[ "Robin", "Mayfield", 56, "diverse" ]
 
 HTTP/1.1 201 Created
 Server: ArangoDB
 Connection: Keep-Alive
 Content-type: application/json; charset=utf-8
 
-{"error":false,"created":2,"empty":0,"errors":0}
+{"error":false,"created":3,"empty":0,"errors":0}
 ```
 
 The server will again respond with an HTTP 201 if everything went well. The