Use more Inclusive language and examples

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

3.10/indexing-multi-dim.md

@@ -74,7 +74,7 @@ FOR p IN points
 ## Example Use Case
 
 If you build a calendar using ArangoDB you could create a collection for each user
-that contains her appointments. The documents would roughly look as follows:
+that contains the appointments. The documents would roughly look as follows:
 
 ```json
 {

3.10/programs-arangod-ldap.md

@@ -44,8 +44,8 @@ authorization: (a) "roles attribute" and (b) "roles search".
 In method (a) ArangoDB acquires a list of roles the authenticated LDAP
 user has from the LDAP server. The actual access rights to databases
 and collections for these roles are configured in ArangoDB itself.
-The user effectively has the union of all access rights of all roles
-he has. This method is probably the most common one for production use
+Users effectively have the union of all access rights of all roles
+they have. This method is probably the most common one for production use
 cases. It combines the advantages of managing users and roles outside of
 ArangoDB in the LDAP server with the fine grained access control within
 ArangoDB for the individual roles. See [Roles attribute](#roles-attribute)

3.10/programs-starter-architecture.md

@@ -176,11 +176,11 @@ arangodb --starter.mode=cluster --starter.join=hostA:8528,hostB:8528,hostC:8528
 
 The state of the cluster (of Starters) is stored in a configuration file called
 `setup.json` in the data directory of every Starter and the ArangoDB
-Agency is used to elect a master among all Starters.
+The Agency is used to elect a leader (also called _master_) among all Starters.
 
-The master Starter is responsible for maintaining the list of all Starters
-involved in the cluster and their addresses. The slave Starters (all Starters
-except the elected master) fetch this list from the master Starter on regular
+The leader Starter is responsible for maintaining the list of all Starters
+involved in the cluster and their addresses. The follower Starters (all Starters
+except the elected leader) fetch this list from the leader Starter on regular
 basis and store it to its own `setup.json` config file.
 
 Note: The `setup.json` config file MUST NOT be edited manually.
@@ -201,26 +201,26 @@ from scratch.
 1. The list of `--starter.join` arguments is sorted
 1. All Starters request the unique ID from the first server in the sorted `--starter.join` list,
    and compares the result with its own unique ID.
-1. The Starter that finds its own unique ID, is continuing as `bootstrap master`
-   the other Starters are continuing as `bootstrap slaves`.
-1. The `bootstrap master` waits for at least 2 `bootstrap slaves` to join it.
-1. The `bootstrap slaves` contact the `bootstrap master` to join its cluster of Starters.
-1. Once the `bootstrap master` has received enough (at least 2) requests
+1. The Starter that finds its own unique ID, is continuing as _bootstrap leader_
+   the other Starters are continuing as _bootstrap followers_.
+1. The _bootstrap leader_ waits for at least 2 _bootstrap followers_ to join it.
+1. The _bootstrap followers_ contact the _bootstrap leader_ to join its cluster of Starters.
+1. Once the _bootstrap leader_ has received enough (at least 2) requests
    to join its cluster of Starters, it continues with the `running` phase.
-1. The `bootstrap slaves` keep asking the `bootstrap master` about its state.
+1. The _bootstrap followers_ keep asking the _bootstrap leader_ about its state.
    As soon as they receive confirmation to do so, they also continue with the `running` phase.
 
-In the `running` phase all Starters launch the desired servers and keeps monitoring those
+In the _running_ phase, all Starters launch the desired servers and keeps monitoring those
 servers. Once a functional Agency is detected, all Starters will try to be
-`running master` by trying to write their ID in a well known location in the Agency.
-The first Starter to succeed in doing so wins this master election.
+_running leader_ by trying to write their ID in a well known location in the Agency.
+The first Starter to succeed in doing so wins this leader election.
 
-The `running master` will keep writing its ID in the Agency in order to remaining
-the `running master`. Since this ID is written with a short time-to-live,
-other Starters are able to detect when the current `running master` has been stopped
+The _running leader_ will keep writing its ID in the Agency in order to remaining
+the _running leader_. Since this ID is written with a short time-to-live,
+other Starters are able to detect when the current _running leader_ has been stopped
 or is no longer responsible. In that case the remaining Starters will perform
-another master election to decide who will be the next `running master`.
+another leader election to decide who will be the next _running leader_.
 
 API requests that involve the state of the cluster of Starters are always answered
-by the current `running master`. All other Starters will refer the request to
-the current `running master`.
+by the current _running leader_. All other Starters will refer the request to
+the current _running leader_.

3.10/programs-starter-options.md

@@ -21,7 +21,7 @@ Different instances of `arangodb` must use different data directories.
 
 - `--starter.join=address`
 
-Join a cluster with master at address `address` (default "").
+Join a cluster with the leader (_master_) Starter at address `address` (default "").
 Address can be an host address or name, followed with an optional port.
 
 E.g. these are valid arguments.
@@ -62,8 +62,8 @@ outside.
 
 Use this option only in the case that `--cluster.agency-size` is set to 1. 
 In a single Agent setup, the sole starter has to start on its own with
-no reliable way to learn its own address. Using this option the master will 
-know under which address it can be reached from the outside. If you specify
+no reliable way to learn its own address. Using this option the leader (_master_)
+Starter will know under which address it can be reached from the outside. If you specify
 `localhost` here, then all instances must run on the local machine.
 
 - `--starter.host=addr`
@@ -365,8 +365,8 @@ Note: The starter will always perform log rotation when it receives a `HUP` sign
 
 - `--starter.unique-port-offsets=bool`
 
-If set to true, all port offsets (of slaves) will be made globally unique.
-By default (value is false), port offsets will be unique per slave address.
+If set to true, all port offsets (of follower Starters) will be made globally unique.
+By default (value is false), port offsets will be unique per follower address.
 
 - `--docker.user=user`
 

3.10/security-encryption.md

@@ -81,7 +81,7 @@ $ arangod \
 ```
 The file `/mytmpfs/mySecretKey` must contain the encryption key. This
 file must be secured, so that only `arangod` can access it. You should
-also ensure that in case someone steals the hardware, he will not be
+also ensure that in case someone steals the hardware, they will not be
 able to read the file. For example, by encrypting `/mytmpfs` or
 creating an in-memory file-system under `/mytmpfs`.
 

3.10/tutorials-starter.md

@@ -172,22 +172,22 @@ On host C:
 arangodb --starter.join A,B,C
 ```
 
-This starts a cluster where the starter on host A is chosen to be master during the bootstrap phase.
+This starts a cluster where the starter on host A is chosen to be leader (_master_) during the bootstrap phase.
 
 Note: `arangodb --starter.join A,B,C` is equal to `arangodb --starter.join A --starter.join B --starter.join C`.
 
-During the bootstrap phase of the cluster, the starters will all choose the "master" starter
+During the bootstrap phase of the cluster, the starters will all choose the leader starter
 based on list of given `starter.join` arguments.
 
-The "master" starter is chosen as follows:
+The leader starter is chosen as follows:
 
-- If there are no `starter.join` arguments, the starter becomes a master.
+- If there are no `starter.join` arguments, the starter becomes a leader.
 - If there are multiple `starter.join` arguments, these arguments are sorted. If a starter is the first
   in this sorted list, it becomes a starter.
-- In all other cases, the starter becomes a slave.
+- In all other cases, the starter becomes a follower.
 
 Note: Once the bootstrap phase is over (all arangod servers have started and are running), the bootstrap
-phase ends and the starters use the Arango Agency to elect a master for the runtime phase.
+phase ends and the starters use the Arango Agency to elect a leader for the runtime phase.
 
 ## Starting a local test cluster
 
@@ -310,7 +310,7 @@ This command will make the starter run another starter process in the background
 then exit. The starter that was started in the background will keep running until you stop it.
 
 The `--starter.wait` option makes the `start` command wait until all ArangoDB server
-are really up, before ending the master process.
+are really up, before ending the process of the leader starter.
 
 To stop a starter use this command.
 

3.11/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.11/administration-reduce-memory-footprint.md

@@ -1,6 +1,8 @@
 ---
 layout: default
 description: Reducing the Memory Footprint of ArangoDB servers
+redirect_from:
+  - tutorials-reduce-memory-footprint.html # 3.10 -> 3.10
 ---
 Reducing the Memory Footprint of ArangoDB servers
 =================================================

3.11/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.11/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.11/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: