Docs: Fixed typos

Closes #10973

docs/community/clients.asciidoc

@@ -13,7 +13,7 @@ See the {client}/perl-api/current/index.html[official Elasticsearch Perl client]
 See the {client}/python-api/current/index.html[official Elasticsearch Python client].
 
 * http://github.com/elasticsearch/elasticsearch-dsl-py[elasticsearch-dsl-py]
-  chainable query and filter construction built on top of offical client.
+  chainable query and filter construction built on top of official client.
 
 * http://github.com/rhec/pyelasticsearch[pyelasticsearch]:
   Python client.

docs/java-api/query-dsl-filters.asciidoc

@@ -150,7 +150,7 @@ FilterBuilder filter = geoDistanceFilter("pin.location")    <1>
 <2> center point
 <3> distance from center point
 <4> optimize bounding box: `memory`, `indexed` or `none`
-<5> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slighly more precise but
+<5> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slightly more precise but
     significantly slower) or `GeoDistance.PLANE` (faster, but inaccurate on long distances and close to the poles)
 
 Note that you can cache the result using

docs/reference/aggregations/bucket/daterange-aggregation.asciidoc

@@ -2,7 +2,7 @@
 === Date Range Aggregation
 
 A range aggregation that is dedicated for date values. The main difference between this aggregation and the normal <<search-aggregations-bucket-range-aggregation,range>> aggregation is that the `from` and `to` values can be expressed in <<date-math,Date Math>> expressions, and it is also possible to specify a date format by which the `from` and `to` response fields will be returned.
-Note that this aggregration includes the `from` value and excludes the `to` value for each range.
+Note that this aggregation includes the `from` value and excludes the `to` value for each range.
 
 Example:
 

docs/reference/aggregations/bucket/geohashgrid-aggregation.asciidoc

@@ -119,7 +119,7 @@ size::          Optional. The maximum number of geohash buckets to return
                 prioritised based on the volumes of documents they contain.
                 A value of `0` will return all buckets that
                 contain a hit, use with caution as this could use a lot of CPU
-                and network bandwith if there are many buckets.
+                and network bandwidth if there are many buckets.
 
 shard_size::    Optional. To allow for more accurate counting of the top cells
                 returned in the final result the aggregation defaults to

docs/reference/aggregations/bucket/global-aggregation.asciidoc

@@ -30,7 +30,7 @@ Example:
 
 The above aggregation demonstrates how one would compute aggregations (`avg_price` in this example) on all the documents in the search context, regardless of the query (in our example, it will compute the average price over all products in our catalog, not just on the "shirts").
 
-The response for the above aggreation:
+The response for the above aggregation:
 
 [source,js]
 --------------------------------------------------

docs/reference/aggregations/bucket/histogram-aggregation.asciidoc

@@ -160,7 +160,7 @@ Example:
 
 ==== Order
 
-By default the returned buckets are sorted by their `key` ascending, though the order behaviour can be controled
+By default the returned buckets are sorted by their `key` ascending, though the order behaviour can be controlled
 using the `order` setting.
 
 Ordering the buckets by their key - descending:

docs/reference/aggregations/reducer/max-bucket-aggregation.asciidoc

@@ -1,7 +1,7 @@
 [[search-aggregations-reducer-max-bucket-aggregation]]
 === Max Bucket Aggregation
 
-A sibling reducer aggregation which identifies the bucket(s) with the maximum value of a specified metric in a sibing aggregation 
+A sibling reducer aggregation which identifies the bucket(s) with the maximum value of a specified metric in a sibling aggregation
 and outputs both the value and the key(s) of the bucket(s). The specified metric must be numeric and the sibling aggregation must 
 be a multi-bucket aggregation.
 

docs/reference/index-modules/allocation.asciidoc

@@ -43,7 +43,7 @@ to be allocated to a node. This is in contrast to `include` which will
 include a node if ANY rule matches.
 
 The `include`, `exclude` and `require` values can have generic simple
-matching wildcards, for example, `value1*`. Additonally, special attribute
+matching wildcards, for example, `value1*`. Additionally, special attribute
 names called `_ip`, `_name`, `_id` and `_host` can be used to match by node
 ip address, name, id or host name, respectively.
 

docs/reference/migration/migrate_1_0.asciidoc

@@ -59,7 +59,7 @@ you now use:
 GET /_cluster/state/nodes
 ---------------
 
-Simliarly for the `nodes_stats` API, if you want the `transport` and `http`
+Similarly for the `nodes_stats` API, if you want the `transport` and `http`
 metrics only, instead of:
 
 [source,sh]

docs/reference/migration/migrate_2_0.asciidoc

@@ -309,7 +309,7 @@ Fields of type `murmur3` can no longer change `doc_values` or `index` setting.
 They are always stored with doc values, and not indexed.
 
 ==== Source field configuration
-The `_source` field no longer supports `includes` and `excludes` paramters. When
+The `_source` field no longer supports `includes` and `excludes` parameters. When
 `_source` is enabled, the entire original source will be stored.
 
 ==== Config based mappings

docs/reference/modules/advanced-scripting.asciidoc

@@ -69,7 +69,7 @@ Field statistics can be accessed with a subscript operator like this:
     documents.
 
 
-Field statistics are computed per shard and therfore these numbers can vary
+Field statistics are computed per shard and therefore these numbers can vary
 depending on the shard the current document resides in.
 The number of terms in a field cannot be accessed using the `_index` variable. See <<mapping-core-types, word count mapping type>> on how to do that.
 
@@ -90,7 +90,7 @@ affect is your set the `index_options` to `docs` (see <<mapping-core-types, mapp
 
 `_index['FIELD']['TERM'].ttf()`::
 
-    The sum of term frequencys of term `TERM` in field `FIELD` over all
+    The sum of term frequencies of term `TERM` in field `FIELD` over all
     documents. Will be returned, even if the term is not present in the
     current document.
 
@@ -108,7 +108,7 @@ If you need information on the positions of terms in a field, call
 
 [horizontal]
 `_POSITIONS`::      if you need the positions of the term
-`_OFFSETS`::        if you need the offests of the term
+`_OFFSETS`::        if you need the offsets of the term
 `_PAYLOADS`::       if you need the payloads of the term
 `_CACHE`::          if you need to iterate over all positions several times
 

docs/reference/query-dsl/filters/geo-distance-filter.asciidoc

@@ -148,7 +148,7 @@ The following are options allowed on the filter:
 
 `distance_type`::
 
-    How to compute the distance. Can either be `sloppy_arc` (default), `arc` (slighly more precise but significantly slower) or `plane` (faster, but inaccurate on long distances and close to the poles).
+    How to compute the distance. Can either be `sloppy_arc` (default), `arc` (slightly more precise but significantly slower) or `plane` (faster, but inaccurate on long distances and close to the poles).
 
 `optimize_bbox`::
 

docs/reference/query-dsl/filters/has-child-filter.asciidoc

@@ -75,7 +75,7 @@ is specified.
 
 In order to support parent-child joins, all of the (string) parent IDs 
 must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
-Additionaly, every child document is mapped to its parent using a long 
+Additionally, every child document is mapped to its parent using a long
 value (approximately). It is advisable to keep the string parent ID short
 in order to reduce memory usage.
 

docs/reference/query-dsl/filters/has-parent-filter.asciidoc

@@ -50,7 +50,7 @@ The `has_parent` filter also accepts a filter instead of a query:
 
 In order to support parent-child joins, all of the (string) parent IDs 
 must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
-Additionaly, every child document is mapped to its parent using a long 
+Additionally, every child document is mapped to its parent using a long
 value (approximately). It is advisable to keep the string parent ID short
 in order to reduce memory usage.
 

docs/reference/query-dsl/queries/common-terms-query.asciidoc

@@ -55,7 +55,7 @@ Terms are allocated to the high or low frequency groups based on the
 `cutoff_frequency`, which can be specified as an absolute frequency
 (`>=1`) or as a relative frequency (`0.0 .. 1.0`). (Remember that document
 frequencies are computed on a per shard level as explained in the blog post
-{defguide}/relevance-is-broken.html[Relevence is broken].)
+{defguide}/relevance-is-broken.html[Relevance is broken].)
 
 Perhaps the most interesting property of this query is that it adapts to
 domain specific stopwords automatically. For example, on a video hosting

docs/reference/query-dsl/queries/has-child-query.asciidoc

@@ -86,7 +86,7 @@ the `score_mode` parameter.
 
 In order to support parent-child joins, all of the (string) parent IDs
 must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
-Additionaly, every child document is mapped to its parent using a long
+Additionally, every child document is mapped to its parent using a long
 value (approximately). It is advisable to keep the string parent ID short
 in order to reduce memory usage.
 

docs/reference/query-dsl/queries/has-parent-query.asciidoc

@@ -54,7 +54,7 @@ matching parent document. The score type can be specified with the
 
 In order to support parent-child joins, all of the (string) parent IDs 
 must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
-Additionaly, every child document is mapped to its parent using a long 
+Additionally, every child document is mapped to its parent using a long
 value (approximately). It is advisable to keep the string parent ID short
 in order to reduce memory usage.
 

docs/reference/query-dsl/queries/span-not-query.asciidoc

@@ -30,7 +30,7 @@ The `include` and `exclude` clauses can be any span type query. The
 `exclude` clause is the span query whose matches must not overlap those
 returned.
 
-In the above example all documents with the term hoya are filtered except the ones that have 'la' preceeding them.
+In the above example all documents with the term hoya are filtered except the ones that have 'la' preceding them.
 
 Other top level options:
 

docs/reference/query-dsl/queries/top-children-query.asciidoc

@@ -68,7 +68,7 @@ same scope name that will work against the child documents. For example:
 
 In order to support parent-child joins, all of the (string) parent IDs 
 must be resident in memory (in the <<index-modules-fielddata,field data cache>>. 
-Additionaly, every child document is mapped to its parent using a long 
+Additionally, every child document is mapped to its parent using a long
 value (approximately). It is advisable to keep the string parent ID short
 in order to reduce memory usage.
 

docs/reference/search/request/rescore.asciidoc

@@ -73,7 +73,7 @@ curl -s -XPOST 'localhost:9200/_search' -d '{
 '
 --------------------------------------------------
 
-The way the scores are combined can be controled with the `score_mode`:
+The way the scores are combined can be controlled with the `score_mode`:
 [cols="<,<",options="header",]
 |=======================================================================
 |Score Mode |Description

docs/reference/search/request/search-type.asciidoc

@@ -21,10 +21,10 @@ it does not take into account term frequencies and other search engine
 information from the other shards. If we want to support accurate
 ranking, we would need to first gather the term frequencies from all
 shards to calculate global term frequencies, then execute the query on
-each shard using these globale frequencies.
+each shard using these global frequencies.
 
 Also, because of the need to sort the results, getting back a large
-document set, or even scrolling it, while maintaing the correct sorting
+document set, or even scrolling it, while maintaining the correct sorting
 behavior can be a very expensive operation. For large result set
 scrolling without sorting, the `scan` search type (explained below) is
 also available.

docs/reference/search/request/sort.asciidoc

@@ -192,7 +192,7 @@ Allow to sort by `_geo_distance`. Here is an example:
 
 `distance_type`::
 
-    How to compute the distance. Can either be `sloppy_arc` (default), `arc` (slighly more precise but significantly slower) or `plane` (faster, but inaccurate on long distances and close to the poles).
+    How to compute the distance. Can either be `sloppy_arc` (default), `arc` (slightly more precise but significantly slower) or `plane` (faster, but inaccurate on long distances and close to the poles).
 
 Note: the geo distance sorting supports `sort_mode` options: `min`,
 `max` and `avg`.

docs/reference/search/suggesters/phrase-suggest.asciidoc

@@ -125,7 +125,7 @@ can contain misspellings (See parameter descriptions below).
     query terms a number `>=1` as an absolute number of query terms. The
     default is set to `1.0` which corresponds to that only corrections with
     at most 1 misspelled term are returned.  Note that setting this too high
-    can negativly impact performance. Low values like `1` or `2` are recommended
+    can negatively impact performance. Low values like `1` or `2` are recommended
     otherwise the time spend in suggest calls might exceed the time spend in 
     query execution.
 

docs/reference/setup/configuration.asciidoc

@@ -134,7 +134,7 @@ by running `ulimit -l unlimited` as `root` before starting Elasticsearch.
 
 Another possible reason why `mlockall` can fail is that the temporary directory
 (usually `/tmp`) is mounted with the `noexec` option. This can be solved by
-specfying a new temp directory, by starting Elasticsearch with:
+specifying a new temp directory, by starting Elasticsearch with:
 
 [source,sh]
 --------------

docs/resiliency/index.asciidoc

@@ -217,7 +217,7 @@ starts.  See {GIT}9899[#9899] (STATUS; DONE, fixed in v1.5.0)
 
 Setting `zen.discovery.minimum_master_nodes` to a value higher than the current node count
 effectively leaves the cluster without a master and unable to process requests.  The only
-way to fix this is to add more master-eligibile nodes.  {GIT}8321[#8321] adds a mechanism
+way to fix this is to add more master-eligible nodes.  {GIT}8321[#8321] adds a mechanism
 to validate settings before applying them, and {GIT}9051[#9051] extends this validation
 support to settings applied during a cluster restore. (STATUS: DONE, Fixed in v1.5.0)
 

docs/ruby/persistence.asciidoc

@@ -142,7 +142,7 @@ class Article
 
   # Execute code after saving the model.
   #
-  after_save { puts "Successfuly saved: #{self}" }
+  after_save { puts "Successfully saved: #{self}" }
 end
 ------------------------------------
 
@@ -215,7 +215,7 @@ Any callbacks defined in the model will be triggered during the persistence oper
 [source,ruby]
 ------------------------------------
 article.save
-# Successfuly saved: #<Article {...}>
+# Successfully saved: #<Article {...}>
 ------------------------------------
 
 Please see the extensive documentation in the library