diff --git a/docs/plugins/mapper-annotated-text.asciidoc b/docs/plugins/mapper-annotated-text.asciidoc index 8cac0aec7080f..151fccfd73344 100644 --- a/docs/plugins/mapper-annotated-text.asciidoc +++ b/docs/plugins/mapper-annotated-text.asciidoc @@ -245,7 +245,7 @@ However, a problem arises if your named entity happens to be a single term and l company `elastic`. In this case, a search on the annotated text field for the token `elastic` may match a text document such as this: - he fired an elastic band + they fired an elastic band To avoid such false matches users should consider prefixing annotation values to ensure they don't name clash with text tokens e.g. diff --git a/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc b/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc index 30d5dbb23d221..e28863ffe7485 100644 --- a/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc @@ -7,7 +7,7 @@ An aggregation that returns interesting or unusual occurrences of terms in a set * Suggesting "H5N1" when users search for "bird flu" in text * Identifying the merchant that is the "common point of compromise" from the transaction history of credit card owners reporting loss * Suggesting keywords relating to stock symbol $ATI for an automated news classifier -* Spotting the fraudulent doctor who is diagnosing more than his fair share of whiplash injuries +* Spotting the fraudulent doctor who is diagnosing more than their fair share of whiplash injuries * Spotting the tire manufacturer who has a disproportionate number of blow-outs In all these cases the terms being selected are not simply the most popular terms in a set. @@ -388,7 +388,7 @@ By default this produces a score greater than zero and less than one. The benefit of this heuristic is that the scoring logic is simple to explain to anyone familiar with a "per capita" statistic. However, for fields with high cardinality there is a tendency for this heuristic to select the rarest terms such as typos that occur only once because they score 1/1 = 100%. -It would be hard for a seasoned boxer to win a championship if the prize was awarded purely on the basis of percentage of fights won - by these rules a newcomer with only one fight under his belt would be impossible to beat. +It would be hard for a seasoned boxer to win a championship if the prize was awarded purely on the basis of percentage of fights won - by these rules a newcomer with only one fight under their belt would be impossible to beat. Multiple observations are typically required to reinforce a view so it is recommended in these cases to set both `min_doc_count` and `shard_min_doc_count` to a higher value such as 10 in order to filter out the low-frequency terms that otherwise take precedence. [source,js] diff --git a/docs/reference/search/request/track-total-hits.asciidoc b/docs/reference/search/request/track-total-hits.asciidoc index efd6156e36d01..a1e76580de297 100644 --- a/docs/reference/search/request/track-total-hits.asciidoc +++ b/docs/reference/search/request/track-total-hits.asciidoc @@ -112,7 +112,7 @@ For instance the following response: \... indicates that the number of hits returned in the `total` is accurate. -If the total number of his that match the query is greater than the +If the total number of hits that match the query is greater than the value set in `track_total_hits`, the total hits in the response will indicate that the returned value is a lower bound: diff --git a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc index decea0678a385..e0c71c9f9f54b 100644 --- a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc @@ -66,7 +66,7 @@ You can change this default behavior by changing the this is a common setting in Elasticsearch, changing its value might effect other schedules in the system. -While the _role mapping APIs_ is he preferred way to manage role mappings, using +While the _role mapping APIs_ is the preferred way to manage role mappings, using the `role_mappings.yml` file becomes useful in a couple of use cases: . If you want to define fixed role mappings that no one (besides an administrator diff --git a/x-pack/docs/en/security/configuring-es.asciidoc b/x-pack/docs/en/security/configuring-es.asciidoc index a2194df77c764..bfeb77a082fda 100644 --- a/x-pack/docs/en/security/configuring-es.asciidoc +++ b/x-pack/docs/en/security/configuring-es.asciidoc @@ -84,7 +84,7 @@ your subscription. For more information, see https://www.elastic.co/subscription + -- For example, to grant _John Doe_ full access to all indices that match -the pattern `events*` and enable him to create visualizations and dashboards +the pattern `events*` and enable them to create visualizations and dashboards for those indices in {kib}, you could create an `events_admin` role and assign the role to a new `johndoe` user.