[DOCS] Replace irregular whitespaces in docs (elastic#128199)

* Replace irregular whitespaces

* More chars

Author: theletterf

docs/reference/aggregations/_snippets/search-aggregations-metrics-percentile-aggregation-approximate.md

@@ -1,6 +1,6 @@
 There are many different algorithms to calculate percentiles. The naive implementation simply stores all the values in a sorted array. To find the 50th percentile, you simply find the value that is at `my_array[count(my_array) * 0.5]`.
 
-Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
+Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
 
 The algorithm used by the `percentile` metric is called TDigest (introduced by Ted Dunning in [Computing Accurate Quantiles using T-Digests](https://github.com/tdunning/t-digest/blob/master/docs/t-digest-paper/histo.pdf)).
 

docs/reference/aggregations/pipeline.md

@@ -230,7 +230,7 @@ An alternate syntax is supported to cope with aggregations or metrics which have
 
 ## Dealing with gaps in the data [gap-policy]
 
-Data in the real world is often noisy and sometimes contains **gaps** — places where data simply doesn’t exist. This can occur for a variety of reasons, the most common being:
+Data in the real world is often noisy and sometimes contains **gaps** — places where data simply doesn’t exist. This can occur for a variety of reasons, the most common being:
 
 * Documents falling into a bucket do not contain a required field
 * There are no documents matching the query for one or more buckets

docs/reference/aggregations/search-aggregations-bucket-composite-aggregation.md

@@ -606,7 +606,7 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by `username` first then by `timestamp`.
-2. …​ in ascending order for the `username` field and in descending order for the `timestamp` field.1. could be used to optimize these composite aggregations:
+2. …  in ascending order for the `username` field and in descending order for the `timestamp` field.1. could be used to optimize these composite aggregations:
 
 
 

docs/reference/aggregations/search-aggregations-bucket-datehistogram-aggregation.md

@@ -679,7 +679,7 @@ Response:
 }
 ```
 
-The response will contain all the buckets having the relative day of the week as key : 1 for Monday, 2 for Tuesday…​ 7 for Sunday.
+The response will contain all the buckets having the relative day of the week as key : 1 for Monday, 2 for Tuesday…  7 for Sunday.
 
 
 

docs/reference/aggregations/search-aggregations-bucket-rare-terms-aggregation.md

@@ -7,7 +7,7 @@ mapped_pages:
 # Rare terms aggregation [search-aggregations-bucket-rare-terms-aggregation]
 
 
-A multi-bucket value source based aggregation which finds "rare" terms — terms that are at the long-tail of the distribution and are not frequent. Conceptually, this is like a `terms` aggregation that is sorted by `_count` ascending. As noted in the [terms aggregation docs](/reference/aggregations/search-aggregations-bucket-terms-aggregation.md#search-aggregations-bucket-terms-aggregation-order), actually ordering a `terms` agg by count ascending has unbounded error. Instead, you should use the `rare_terms` aggregation
+A multi-bucket value source based aggregation which finds "rare" terms — terms that are at the long-tail of the distribution and are not frequent. Conceptually, this is like a `terms` aggregation that is sorted by `_count` ascending. As noted in the [terms aggregation docs](/reference/aggregations/search-aggregations-bucket-terms-aggregation.md#search-aggregations-bucket-terms-aggregation-order), actually ordering a `terms` agg by count ascending has unbounded error. Instead, you should use the `rare_terms` aggregation
 
 ## Syntax [_syntax_3]
 
@@ -117,7 +117,7 @@ This does, however, mean that a large number of results can be returned if chose
 
 ## Max Bucket Limit [search-aggregations-bucket-rare-terms-aggregation-max-buckets]
 
-The Rare Terms aggregation is more liable to trip the `search.max_buckets` soft limit than other aggregations due to how it works. The `max_bucket` soft-limit is evaluated on a per-shard basis while the aggregation is collecting results. It is possible for a term to be "rare" on a shard but become "not rare" once all the shard results are merged together. This means that individual shards tend to collect more buckets than are truly rare, because they only have their own local view. This list is ultimately pruned to the correct, smaller list of rare terms on the coordinating node…​ but a shard may have already tripped the `max_buckets` soft limit and aborted the request.
+The Rare Terms aggregation is more liable to trip the `search.max_buckets` soft limit than other aggregations due to how it works. The `max_bucket` soft-limit is evaluated on a per-shard basis while the aggregation is collecting results. It is possible for a term to be "rare" on a shard but become "not rare" once all the shard results are merged together. This means that individual shards tend to collect more buckets than are truly rare, because they only have their own local view. This list is ultimately pruned to the correct, smaller list of rare terms on the coordinating node…  but a shard may have already tripped the `max_buckets` soft limit and aborted the request.
 
 When aggregating on fields that have potentially many "rare" terms, you may need to increase the `max_buckets` soft limit. Alternatively, you might need to find a way to filter the results to return fewer rare values (smaller time span, filter by category, etc), or re-evaluate your definition of "rare" (e.g. if something appears 100,000 times, is it truly "rare"?)
 

docs/reference/aggregations/search-aggregations-bucket-significanttext-aggregation.md

@@ -21,7 +21,7 @@ Re-analyzing *large* result sets will require a lot of time and memory. It is re
 * Suggesting "H5N1" when users search for "bird flu" to help expand queries
 * Suggesting keywords relating to stock symbol $ATI for use in an automated news classifier
 
-In these cases the words being selected are not simply the most popular terms in results. The most popular words tend to be very boring (*and, of, the, we, I, they* …​). The significant words are the ones that have undergone a significant change in popularity measured between a *foreground* and *background* set. If the term "H5N1" only exists in 5 documents in a 10 million document index and yet is found in 4 of the 100 documents that make up a user’s search results that is significant and probably very relevant to their search. 5/10,000,000 vs 4/100 is a big swing in frequency.
+In these cases the words being selected are not simply the most popular terms in results. The most popular words tend to be very boring (*and, of, the, we, I, they* … ). The significant words are the ones that have undergone a significant change in popularity measured between a *foreground* and *background* set. If the term "H5N1" only exists in 5 documents in a 10 million document index and yet is found in 4 of the 100 documents that make up a user’s search results that is significant and probably very relevant to their search. 5/10,000,000 vs 4/100 is a big swing in frequency.
 
 ## Basic use [_basic_use_2]
 

docs/reference/aggregations/search-aggregations-bucket-terms-aggregation.md

@@ -696,7 +696,7 @@ When aggregating on multiple indices the type of the aggregated field may not be
 
 ### Failed Trying to Format Bytes [_failed_trying_to_format_bytes]
 
-When running a terms aggregation (or other aggregation, but in practice usually terms) over multiple indices, you may get an error that starts with "Failed trying to format bytes…​".  This is usually caused by two of the indices not having the same mapping type for the field being aggregated.
+When running a terms aggregation (or other aggregation, but in practice usually terms) over multiple indices, you may get an error that starts with "Failed trying to format bytes… ".  This is usually caused by two of the indices not having the same mapping type for the field being aggregated.
 
 **Use an explicit `value_type`** Although it’s best to correct the mappings, you can work around this issue if the field is unmapped in one of the indices.  Setting the `value_type` parameter can resolve the issue by coercing the unmapped field into the correct type.
 

docs/reference/aggregations/search-aggregations-metrics-boxplot-aggregation.md

@@ -126,7 +126,7 @@ GET latency/_search
 1. Compression controls memory usage and approximation error
 
 
-The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
+The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
 
 Therefore, by increasing the compression value, you can increase the accuracy of your percentiles at the cost of more memory. Larger compression values also make the algorithm slower since the underlying tree data structure grows in size, resulting in more expensive operations. The default compression value is `100`.
 

docs/reference/aggregations/search-aggregations-metrics-percentile-aggregation.md

@@ -60,7 +60,7 @@ By default, the `percentile` metric will generate a range of percentiles: `[ 1,
 
 As you can see, the aggregation will return a calculated value for each percentile in the default range. If we assume response times are in milliseconds, it is immediately obvious that the webpage normally loads in 10-720ms, but occasionally spikes to 940-980ms.
 
-Often, administrators are only interested in outliers — the extreme percentiles. We can specify just the percents we are interested in (requested percentiles must be a value between 0-100 inclusive):
+Often, administrators are only interested in outliers — the extreme percentiles. We can specify just the percents we are interested in (requested percentiles must be a value between 0-100 inclusive):
 
 ```console
 GET latency/_search
@@ -177,7 +177,7 @@ GET latency/_search
 
 There are many different algorithms to calculate percentiles. The naive implementation simply stores all the values in a sorted array. To find the 50th percentile, you simply find the value that is at `my_array[count(my_array) * 0.5]`.
 
-Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
+Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
 
 The algorithm used by the `percentile` metric is called TDigest (introduced by Ted Dunning in [Computing Accurate Quantiles using T-Digests](https://github.com/tdunning/t-digest/blob/master/docs/t-digest-paper/histo.pdf)).
 
@@ -222,7 +222,7 @@ GET latency/_search
 1. Compression controls memory usage and approximation error
 
 
-The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
+The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
 
 Therefore, by increasing the compression value, you can increase the accuracy of your percentiles at the cost of more memory. Larger compression values also make the algorithm slower since the underlying tree data structure grows in size, resulting in more expensive operations. The default compression value is `100`.
 

docs/reference/aggregations/search-aggregations-metrics-weight-avg-aggregation.md

@@ -9,7 +9,7 @@ mapped_pages:
 
 A `single-value` metrics aggregation that computes the weighted average of numeric values that are extracted from the aggregated documents. These values can be extracted either from specific numeric fields in the documents.
 
-When calculating a regular average, each datapoint has an equal "weight" …​ it contributes equally to the final value. Weighted averages, on the other hand, weight each datapoint differently. The amount that each datapoint contributes to the final value is extracted from the document.
+When calculating a regular average, each datapoint has an equal "weight" …  it contributes equally to the final value. Weighted averages, on the other hand, weight each datapoint differently. The amount that each datapoint contributes to the final value is extracted from the document.
 
 As a formula, a weighted average is the `∑(value * weight) / ∑(weight)`