Documentation improvments

Documentation/Books/AQL/Fundamentals/TypeValueOrder.mdpp

@@ -69,7 +69,9 @@ result is defined as follows:
 - null: *null* is equal to *null*
 - boolean: *false* is less than *true*
 - number: numeric values are ordered by their cardinal value
-- string: string values are ordered using a localized comparison,
+- string: string values are ordered using a localized comparison, using the configured
+  [server language](../../Manual/Administration/Configuration/index.html#default-language)
+  for sorting according to the alphabetical order rules of that language
 
 Note: unlike in SQL, *null* can be compared to any value, including *null*
 itself, without the result being converted into *null* automatically.

Documentation/Books/AQL/README.mdpp

@@ -21,6 +21,8 @@ and the different data models ArangoDB offers.
 In its purpose, AQL is similar to the Structured Query Language (SQL). AQL supports 
 reading and modifying collection data, but it doesn't support data-definition
 operations such as creating and dropping databases, collections and indexes.
+It is a pure data manipulation language (DML), not a data definition language
+(DDL) or a data control language (DCL).
 
 The syntax of AQL queries is different to SQL, even if some keywords overlap.
 Nevertheless, AQL should be easy to understand for anyone with an SQL background.

Documentation/Books/Manual/Graphs/README.mdpp

@@ -63,11 +63,11 @@ So this question boils down to 'Can I afford the additional effort or do I need
 
 If you want to only traverse edges of a specific type, there are two ways to achieve this. The first would be
 an attribute in the edge document - i.e. `type`, where you specify a differentiator for the edge -
-i.e. `"friends"`, `"family"`, `"maried"` or `"workmates"`, so you can later `FILTER e.type = "friends"`
+i.e. `"friends"`, `"family"`, `"married"` or `"workmates"`, so you can later `FILTER e.type = "friends"`
 if you only want to follow the friend edges.
 
 Another way, which may be more efficient in some cases, is to use different edge collections for different
-types of edges, so you have `friend_eges`, `family_edges`, `maried_edges` and `workmate_edges` as collection names.
+types of edges, so you have `friend_eges`, `family_edges`, `married_edges` and `workmate_edges` as collection names.
 You can then configure several named graphs including a subset of the available edge and vertex collections -
 or you use anonymous graph queries, where you specify a list of edge collections to take into account in that query.
 To only follow friend edges, you would specify `friend_edges` as sole edge collection.

Documentation/Books/Manual/Indexing/Geo.mdpp

@@ -110,3 +110,12 @@ the index attributes or have non-numeric values in the index attributes
 will not be indexed. *ensureGeoConstraint* is deprecated and *ensureGeoIndex*
 should be used instead.
 
+The index does not provide a `unique` option because of its limited usability.
+It would prevent identical coordinates from being inserted only, but even a
+slightly different location (like 1 inch or 1 cm off) would be unique again and
+not considered a duplicate, although it probably should. The desired threshold
+for detecting duplicates may vary for every project (including how to calculate
+the distance even) and needs to be implemented on the application layer as needed.
+You can write a [Foxx service](../Foxx/index.html) for this purpose and make use
+of the AQL [geo functions](../../AQL/Functions/Geo.html) to find nearby
+coordinates supported by a geo index.

Documentation/Books/Manual/Indexing/IndexBasics.mdpp

@@ -44,18 +44,18 @@ The primary index of a collection cannot be dropped or changed, and there is no
 mechanism to create user-defined primary indexes.
 
 
-!SUBSECTION Edges Index
+!SUBSECTION Edge Index
 
 Every [edge collection](../Appendix/Glossary.md#edge-collection) also has an 
-automatically created *edges index*. The edges index provides quick access to
+automatically created *edge index*. The edge index provides quick access to
 documents by either their `_from` or `_to` attributes. It can therefore be
 used to quickly find connections between vertex documents and is invoked when 
 the connecting edges of a vertex are queried.
 
-Edges indexes are used from within AQL when performing equality lookups on `_from`
+Edge indexes are used from within AQL when performing equality lookups on `_from`
 or `_to` values in an edge collections. There are also dedicated functions to 
 find edges given their `_from` or `_to` values that will always make use of the 
-edges index:
+edge index:
 
 ```js
 db.collection.edges("<from-value>");
@@ -66,13 +66,14 @@ db.collection.inEdges("<from-value>");
 db.collection.inEdges("<to-value>");
 ```
 
-Internally, the edges index is implemented as a hash index. It can be used for equality 
+Internally, the edge index is implemented as a hash index, which stores the union
-lookups, but not for range queries or for sorting. As edges indexes are automatically 
+of all `_from` and `_to` attributes. It can be used for equality 
-created for edge collections, it is not possible to create user-defined edges indexes.
+lookups, but not for range queries or for sorting. Edge indexes are automatically 
+created for edge collections. It is not possible to create user-defined edge indexes.
 However, it is possible to freely use the `_from` and `_to` attributes in user-defined
 indexes.
 
-An edges index cannot be dropped or changed.
+An edge index cannot be dropped or changed.
 
 
 !SUBSECTION Hash Index
@@ -354,7 +355,7 @@ FOR doc IN posts
   RETURN doc
 ```
 
-The following FILTER conditions will not use the array index:
+The following FILTER conditions will **not use** the array index:
 
 ```js
 FILTER doc.tags ANY == 'foobar'
@@ -365,7 +366,7 @@ FILTER 'foobar' == doc.tags
 ```
 
 It is also possible to create an index on subattributes of array values. This makes sense
-when the index attribute is an array of objects, e.g.
+if the index attribute is an array of objects, e.g.
 
 ```js
 db.posts.ensureIndex({ type: "hash", fields: [ "tags[*].name" ] });

Documentation/Books/Manual/Indexing/Persistent.mdpp

@@ -154,3 +154,15 @@ and
 ```
 will match.
 
+!SECTION Persistent Indexes and Server Language
+
+The order of index entries in persistent indexes adheres to the configured
+[server language](../Administration/Configuration/README.md#default-language).
+If, however, the server is restarted with a different language setting as when
+the persistent index was created, not all documents may be returned anymore and
+the sort order of those which are returned can be wrong (whenever the persistent
+index is consulted).
+
+To fix persistent indexes after a language change, delete and re-create them.
+Skiplist indexes are not affected, because they are not persisted and
+automatically rebuilt on every server start.

Documentation/Books/Manual/ReleaseNotes/README.mdpp

@@ -1 +1,26 @@
 !CHAPTER Release Notes
+
+!SECTION Whats New
+
+- [Whats New in 3.0](NewFeatures30.md)
+- [Whats New in 2.8](NewFeatures28.md)
+- [Whats New in 2.7](NewFeatures27.md)
+- [Whats New in 2.6](NewFeatures26.md)
+- [Whats New in 2.5](NewFeatures25.md)
+- [Whats New in 2.4](NewFeatures24.md)
+- [Whats New in 2.3](NewFeatures23.md)
+- [Whats New in 2.2](NewFeatures22.md)
+- [Whats New in 2.1](NewFeatures21.md)
+
+!SECTION Incompatible changes
+
+Also see [Upgrading](../Administration/Upgrading/README.md) in the 
+Administration chapter.
+
+- [Incompatible changes in 3.0](UpgradingChanges30.md)
+- [Incompatible changes in 2.8](UpgradingChanges28.md)
+- [Incompatible changes in 2.7](UpgradingChanges27.md)
+- [Incompatible changes in 2.6](UpgradingChanges26.md)
+- [Incompatible changes in 2.5](UpgradingChanges25.md)
+- [Incompatible changes in 2.4](UpgradingChanges24.md)
+- [Incompatible changes in 2.3](UpgradingChanges23.md)

Documentation/Books/Manual/Scalability/Architecture.mdpp

@@ -92,6 +92,9 @@ it will automatically figure out where the data is stored (read) or to
 be stored (write). The information about the shards is shared across the
 coordinators using the Agency.
 
+Also see [Sharding](../Administration/Sharding/README.md) in the
+Administration chapter.
+
 !SUBSECTION Many sensible configurations
 
 This architecture is very flexible and thus allows many configurations,