More chars

theletterf · theletterf · commit dc31392b6a3c · 2025-05-20T16:10:40.000+02:00
diff --git a/docs/reference/aggregations/search-aggregations-bucket-composite-aggregation.md b/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:
 
 
 
diff --git a/docs/reference/aggregations/search-aggregations-bucket-datehistogram-aggregation.md b/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.
 
 
 
diff --git a/docs/reference/aggregations/search-aggregations-bucket-significanttext-aggregation.md b/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]
 
diff --git a/docs/reference/aggregations/search-aggregations-bucket-terms-aggregation.md b/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.
 
diff --git a/docs/reference/aggregations/search-aggregations-metrics-weight-avg-aggregation.md b/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)`
 
diff --git a/docs/reference/elasticsearch-plugins/integrations.md b/docs/reference/elasticsearch-plugins/integrations.md
@@ -31,7 +31,7 @@ Integrations are not plugins, but are external tools or modules that make it eas
 * [Ingest processor template](https://github.com/spinscale/cookiecutter-elasticsearch-ingest-processor): A template for creating new ingest processors.
 * [Kafka Standalone Consumer (Indexer)](https://github.com/BigDataDevs/kafka-elasticsearch-consumer): Kafka Standalone Consumer [Indexer] will read messages from Kafka in batches, processes(as implemented) and bulk-indexes them into Elasticsearch. Flexible and scalable. More documentation in above GitHub repo’s Wiki.
 * [Scrutineer](https://github.com/Aconex/scrutineer): A high performance consistency checker to compare what you’ve indexed with your source of truth content (e.g. DB)
-* [FS Crawler](https://github.com/dadoonet/fscrawler): The File System (FS) crawler allows to index documents (PDF, Open Office…​) from your local file system and over SSH. (by David Pilato)
+* [FS Crawler](https://github.com/dadoonet/fscrawler): The File System (FS) crawler allows to index documents (PDF, Open Office… ) from your local file system and over SSH. (by David Pilato)
 * [Elasticsearch Evolution](https://github.com/senacor/elasticsearch-evolution): A library to migrate elasticsearch mappings.
 * [PGSync](https://pgsync.com): A tool for syncing data from Postgres to Elasticsearch.
 
diff --git a/docs/reference/elasticsearch/configuration-reference/networking-settings.md b/docs/reference/elasticsearch/configuration-reference/networking-settings.md
@@ -428,7 +428,7 @@ The `transport.compress` setting always configures local cluster request compres
 
 ### Response compression [response-compression]
 
-The compression settings do not configure compression for responses. {{es}} will compress a response if the inbound request was compressed—​even when compression is not enabled. Similarly, {{es}} will not compress a response if the inbound request was uncompressed—​even when compression is enabled. The compression scheme used to compress a response will be the same scheme the remote node used to compress the request.
+The compression settings do not configure compression for responses. {{es}} will compress a response if the inbound request was compressed— even when compression is not enabled. Similarly, {{es}} will not compress a response if the inbound request was uncompressed— even when compression is enabled. The compression scheme used to compress a response will be the same scheme the remote node used to compress the request.
 
 
 
diff --git a/docs/reference/elasticsearch/index-settings/sorting-conjunctions.md b/docs/reference/elasticsearch/index-settings/sorting-conjunctions.md
@@ -5,7 +5,7 @@ mapped_pages:
 
 # Use index sorting to speed up conjunctions [index-modules-index-sorting-conjunctions]
 
-Index sorting can be useful in order to organize Lucene doc ids (not to be conflated with `_id`) in a way that makes conjunctions (a AND b AND …​) more efficient. In order to be efficient, conjunctions rely on the fact that if any clause does not match, then the entire conjunction does not match. By using index sorting, we can put documents that do not match together, which will help skip efficiently over large ranges of doc IDs that do not match the conjunction.
+Index sorting can be useful in order to organize Lucene doc ids (not to be conflated with `_id`) in a way that makes conjunctions (a AND b AND … ) more efficient. In order to be efficient, conjunctions rely on the fact that if any clause does not match, then the entire conjunction does not match. By using index sorting, we can put documents that do not match together, which will help skip efficiently over large ranges of doc IDs that do not match the conjunction.
 
 This trick only works with low-cardinality fields. A rule of thumb is that you should sort first on fields that both have a low cardinality and are frequently used for filtering. The sort order (`asc` or `desc`) does not matter as we only care about putting values that would match the same clauses close to each other.
 
diff --git a/docs/reference/elasticsearch/index-settings/sorting.md b/docs/reference/elasticsearch/index-settings/sorting.md
@@ -35,7 +35,7 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by the `date` field
-2. …​ in descending order.
+2. …  in descending order.
 
 
 It is also possible to sort the index by more than one field:
@@ -64,7 +64,7 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by `username` first then by `date`
-2. …​ in ascending order for the `username` field and in descending order for the `date` field.
+2. …  in ascending order for the `username` field and in descending order for the `date` field.
 
 
 Index sorting supports the following settings:
diff --git a/docs/reference/elasticsearch/mapping-reference/parent-join.md b/docs/reference/elasticsearch/mapping-reference/parent-join.md
@@ -139,7 +139,7 @@ The only case where the join field makes sense is if your data contains a one-to
 
 ## Searching with parent-join [_searching_with_parent_join]
 
-The parent-join creates one field to index the name of the relation within the document (`my_parent`, `my_child`, …​).
+The parent-join creates one field to index the name of the relation within the document (`my_parent`, `my_child`, … ).
 
 It also creates one field per parent/child relation. The name of this field is the name of the `join` field followed by `#` and the name of the parent in the relation. So for instance for the `my_parent` → [`my_child`, `another_child`] relation, the `join` field creates an additional field named `my_join_field#my_parent`.
 
diff --git a/docs/reference/elasticsearch/rest-apis/api-conventions.md b/docs/reference/elasticsearch/rest-apis/api-conventions.md
@@ -55,7 +55,7 @@ For example, the following `traceparent` value would produce the following `trac
 
 ## GET and POST requests [get-requests]
 
-A number of {{es}} GET APIs—​most notably the search API—​support a request body. While the GET action makes sense in the context of retrieving information, GET requests with a body are not supported by all HTTP libraries. All {{es}} GET APIs that require a body can also be submitted as POST requests. Alternatively, you can pass the request body as the [`source` query string parameter](#api-request-body-query-string) when using GET.
+A number of {{es}} GET APIs— most notably the search API— support a request body. While the GET action makes sense in the context of retrieving information, GET requests with a body are not supported by all HTTP libraries. All {{es}} GET APIs that require a body can also be submitted as POST requests. Alternatively, you can pass the request body as the [`source` query string parameter](#api-request-body-query-string) when using GET.
 
 
 ## Cron expressions [api-cron-expressions]
@@ -120,10 +120,10 @@ All elements are required except for `year`. See [Cron special characters](#cron
 :   Increment. Use to separate values when specifying a time increment. The first value represents the starting point, and the second value represents the interval. For example, if you want the schedule to trigger every 20 minutes starting at the top of the hour, you could specify `0/20` in the `minutes` field. Similarly, specifying `1/5` in `day_of_month` field will trigger every 5 days starting on the first day of the month.
 
 `L`
-:   Last. Use in the `day_of_month` field to mean the last day of the month—​day 31 for January, day 28 for February in non-leap years, day 30 for April, and so on. Use alone in the `day_of_week` field in place of `7` or `SAT`, or after a particular day of the week to select the last day of that type in the month. For example `6L` means the last Friday of the month. You can specify `LW` in the `day_of_month` field to specify the last weekday of the month. Avoid using the `L` option when specifying lists or ranges of values, as the results likely won’t be what you expect.
+:   Last. Use in the `day_of_month` field to mean the last day of the month— day 31 for January, day 28 for February in non-leap years, day 30 for April, and so on. Use alone in the `day_of_week` field in place of `7` or `SAT`, or after a particular day of the week to select the last day of that type in the month. For example `6L` means the last Friday of the month. You can specify `LW` in the `day_of_month` field to specify the last weekday of the month. Avoid using the `L` option when specifying lists or ranges of values, as the results likely won’t be what you expect.
 
 `W`
-:   Weekday. Use to specify the weekday (Monday-Friday) nearest the given day. As an example, if you specify `15W` in the `day_of_month` field and the 15th is a Saturday, the schedule will trigger on the 14th. If the 15th is a Sunday, the schedule will trigger on Monday the 16th. If the 15th is a Tuesday, the schedule will trigger on Tuesday the 15th. However if you specify `1W` as the value for `day_of_month`, and the 1st is a Saturday, the schedule will trigger on Monday the 3rd—​it won’t jump over the month boundary. You can specify `LW` in the `day_of_month` field to specify the last weekday of the month. You can only use the `W` option when the `day_of_month` is a single day—​it is not valid when specifying a range or list of days.
+:   Weekday. Use to specify the weekday (Monday-Friday) nearest the given day. As an example, if you specify `15W` in the `day_of_month` field and the 15th is a Saturday, the schedule will trigger on the 14th. If the 15th is a Sunday, the schedule will trigger on Monday the 16th. If the 15th is a Tuesday, the schedule will trigger on Tuesday the 15th. However if you specify `1W` as the value for `day_of_month`, and the 1st is a Saturday, the schedule will trigger on Monday the 3rd— it won’t jump over the month boundary. You can specify `LW` in the `day_of_month` field to specify the last weekday of the month. You can only use the `W` option when the `day_of_month` is a single day— it is not valid when specifying a range or list of days.
 
 `#`
 :   Nth XXX day in a month. Use in the `day_of_week` field to specify the nth XXX day of the month. For example, if you specify `6#1`, the schedule will trigger on the first Friday of the month. Note that if you specify `3#5` and there are not 5 Tuesdays in a particular month, the schedule won’t trigger that month.
diff --git a/docs/reference/elasticsearch/rest-apis/compatibility.md b/docs/reference/elasticsearch/rest-apis/compatibility.md
@@ -16,7 +16,7 @@ When an API is targeted for removal or is going to be changed in a non-compatibl
 
 When you request REST API compatibility, {{es}} attempts to honor the previous REST API version. {{es}} attempts to apply the most compatible URL, request body, response body, and HTTP parameters.
 
-For compatible APIs, this has no effect—​it only impacts calls to APIs that have breaking changes from the previous version. An error can still be returned in compatibility mode if {{es}} cannot automatically resolve the incompatibilities.
+For compatible APIs, this has no effect— it only impacts calls to APIs that have breaking changes from the previous version. An error can still be returned in compatibility mode if {{es}} cannot automatically resolve the incompatibilities.
 
 ::::{important}
 REST API compatibility does not guarantee the same behavior as the prior version. It instructs {{es}} to automatically resolve any incompatibilities so the request can be processed instead of returning an error.
diff --git a/docs/reference/query-languages/query-dsl/query-dsl-function-score-query.md b/docs/reference/query-languages/query-dsl/query-dsl-function-score-query.md
@@ -341,7 +341,7 @@ GET /_search
 :   The point of origin used for calculating distance. Must be given as a number for numeric field, date for date fields and geo point for geo fields. Required for geo and numeric field. For date fields the default is `now`. Date math (for example `now-1h`) is supported for origin.
 
 `scale`
-:   Required for all types. Defines the distance from origin + offset at which the computed score will equal `decay` parameter. For geo fields: Can be defined as number+unit (1km, 12m,…​). Default unit is meters. For date fields: Can to be defined as a number+unit ("1h", "10d",…​). Default unit is milliseconds. For numeric field: Any number.
+:   Required for all types. Defines the distance from origin + offset at which the computed score will equal `decay` parameter. For geo fields: Can be defined as number+unit (1km, 12m,… ). Default unit is meters. For date fields: Can to be defined as a number+unit ("1h", "10d",… ). Default unit is milliseconds. For numeric field: Any number.
 
 `offset`
 :   If an `offset` is defined, the decay function will only compute the decay function for documents with a distance greater than the defined `offset`. The default is 0.
diff --git a/docs/reference/query-languages/sql/sql-functions-conditional.md b/docs/reference/query-languages/sql/sql-functions-conditional.md
@@ -154,7 +154,7 @@ COALESCE(
 2. 2nd expression
 
 
-…​
+… 
 
 **N**th expression
 
@@ -196,7 +196,7 @@ GREATEST(
 2. 2nd expression
 
 
-…​
+… 
 
 **N**th expression
 
@@ -355,7 +355,7 @@ LEAST(
 2. 2nd expression
 
 
-…​
+… 
 
 **N**th expression
 
diff --git a/docs/reference/query-languages/sql/sql-functions-datetime.md b/docs/reference/query-languages/sql/sql-functions-datetime.md
@@ -1153,7 +1153,7 @@ DAY_NAME(datetime_exp) <1>
 
 **Output**: string
 
-**Description**: Extract the day of the week from a date/datetime in text format (`Monday`, `Tuesday`…​).
+**Description**: Extract the day of the week from a date/datetime in text format (`Monday`, `Tuesday`… ).
 
 ```sql
 SELECT DAY_NAME(CAST('2018-02-19T10:23:27Z' AS TIMESTAMP)) AS day;
@@ -1321,7 +1321,7 @@ MONTH_NAME(datetime_exp) <1>
 
 **Output**: string
 
-**Description**: Extract the month from a date/datetime in text format (`January`, `February`…​).
+**Description**: Extract the month from a date/datetime in text format (`January`, `February`… ).
 
 ```sql
 SELECT MONTH_NAME(CAST('2018-02-19T10:23:27Z' AS TIMESTAMP)) AS month;
diff --git a/docs/reference/query-languages/sql/sql-lexical-structure.md b/docs/reference/query-languages/sql/sql-lexical-structure.md
@@ -19,7 +19,7 @@ Take the following example:
 SELECT * FROM table
 ```
 
-This query has four tokens: `SELECT`, `*`, `FROM` and `table`. The first three, namely `SELECT`, `*` and `FROM` are *key words* meaning words that have a fixed meaning in SQL. The token `table` is an *identifier* meaning it identifies (by name) an entity inside SQL such as a table (in this case), a column, etc…​
+This query has four tokens: `SELECT`, `*`, `FROM` and `table`. The first three, namely `SELECT`, `*` and `FROM` are *key words* meaning words that have a fixed meaning in SQL. The token `table` is an *identifier* meaning it identifies (by name) an entity inside SQL such as a table (in this case), a column, etc… 
 
 As one can see, both key words and identifiers have the *same* lexical structure and thus one cannot know whether a token is one or the other without knowing the SQL language; the complete list of key words is available in the [reserved appendix](/reference/query-languages/sql/sql-syntax-reserved.md). Do note that key words are case-insensitive meaning the previous example can be written as:
 
@@ -127,7 +127,7 @@ A few characters that are not alphanumeric have a dedicated meaning different fr
 | --- | --- |
 | `*` | The asterisk (or wildcard) is used in some contexts to denote all fields for a table. Can be also used as an argument to some aggregate functions. |
 | `,` | Commas are used to enumerate the elements of a list. |
-| `.` | Used in numeric constants or to separate identifiers qualifiers (catalog, table, column names, etc…​). |
+| `.` | Used in numeric constants or to separate identifiers qualifiers (catalog, table, column names, etc… ). |
 | `()` | Parentheses are used for specific SQL commands, function declarations or to enforce precedence. |
 
 
diff --git a/docs/reference/query-languages/sql/sql-syntax-select.md b/docs/reference/query-languages/sql/sql-syntax-select.md
@@ -120,7 +120,7 @@ where:
 `table_name`
 :   Represents the name (optionally qualified) of an existing table, either a concrete or base one (actual index) or alias.
 
-If the table name contains special SQL characters (such as `.`,`-`,`*`,etc…​) use double quotes to escape them:
+If the table name contains special SQL characters (such as `.`,`-`,`*`,etc… ) use double quotes to escape them:
 
 ```sql
 SELECT * FROM "emp" LIMIT 1;

Original file line number	Diff line number	Diff line change
`@@ -679,7 +679,7 @@ Response:`
`679`	`679`	`}`
`680`	`680`	```
`681`	`681`
`682`		`-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.`
	`682`	`+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.`
`683`	`683`
`684`	`684`
`685`	`685`
Original file line number	Diff line number	Diff line change
@@ -428,7 +428,7 @@ The `transport.compress` setting always configures local cluster request compres
`428`	`428`
`429`	`429`	`### Response compression [response-compression]`
`430`	`430`
`431`		`-The compression settings do not configure compression for responses. {{es}} will compress a response if the inbound request was compressed—even when compression is not enabled. Similarly, {{es}} will not compress a response if the inbound request was uncompressed—even when compression is enabled. The compression scheme used to compress a response will be the same scheme the remote node used to compress the request.`
	`431`	`+The compression settings do not configure compression for responses. {{es}} will compress a response if the inbound request was compressed— even when compression is not enabled. Similarly, {{es}} will not compress a response if the inbound request was uncompressed— even when compression is enabled. The compression scheme used to compress a response will be the same scheme the remote node used to compress the request.`
`432`	`432`
`433`	`433`
`434`	`434`