Merge branch 'docs/clean-up-vale-latin-terms-276202-part3' into 'master'

Updates files to address Vale latin terms rule

See merge request gitlab-org/gitlab!75423

doc/install/aws/gitlab_hybrid_on_aws.md

@@ -50,7 +50,7 @@ It is helpful to review the [GitLab Environment Toolkit (GET) Issues](https://gi
 | Amazon Well Architected Compliant                            | Yes<br />(via Quick Start program)                           | Critical portions <br />reviewed by AWS                      |
 | Target Cloud Platforms                                       | AWS                                                          | AWS, Google, Azure                                           |
 | IaC Languages                                                | CloudFormation (Quick Starts)                                | Terraform, Ansible                                           |
-| Community Contributions and Participation (EcoSystem)        | <u>GitLab QSG</u>: Getting Started<br /><u>For QSG Dependencies (e.g. EKS)</u>: Substantial | Getting Started                                              |
+| Community Contributions and Participation (EcoSystem)        | <u>GitLab QSG</u>: Getting Started<br /><u>For QSG Dependencies (for example, EKS)</u>: Substantial | Getting Started                                              |
 | Compatible with AWS Meta-Automation Services (via CloudFormation) | - [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) (Direct Import)<br>- [ServiceNow via an AWS Service Catalog Connector](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/integrations-servicenow.html#integrations-servicenow)<br>- [Jira Service Manager via an AWS Service Catalog Connector](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/integrations-jiraservicedesk.html#integrations-jiraservicedesk)<br>- [AWS Control Tower](https://docs.aws.amazon.com/controltower/) ([Integration](https://aws.amazon.com/blogs/infrastructure-and-automation/deploy-aws-quick-start-to-multiple-accounts-using-aws-control-tower/))<br>- Quick Starts<br>- [AWS SaaS Factory](https://aws.amazon.com/partners/programs/saas-factory/) | No |
 | Results in a Ready-to-Use instance                           | Yes                                                          | Manual Actions or <br />Supplemental IaC Required            |
 | **<u>Configuration Features</u>**                            |                                                              |                                                              |

doc/install/aws/manual_install_aws.md

@@ -391,7 +391,7 @@ persistence and is used to store session data, temporary cache information, and
    chance to deploy Redis in multiple availability zones.
 1. In the settings section:
    1. Give the cluster a name (`gitlab-redis`) and a description.
-   1. For the version, select the latest of `5.0` series (e.g., `5.0.6`).
+   1. For the version, select the latest of the `5.0` series (for example, `5.0.6`).
    1. Leave the port as `6379` since this is what we used in our Redis security group above.
    1. Select the node type (at least `cache.t3.medium`, but adjust to your needs) and the number of replicas.
 1. In the advanced settings section:
@@ -856,7 +856,7 @@ to request additional material:
 
 ### Instances are failing health checks
 
-If your instances are failing the load balancer's health checks, verify that they are returning a status `200` from the health check endpoint we configured earlier. Any other status, including redirects (e.g. status `302`) will cause the health check to fail.
+If your instances are failing the load balancer's health checks, verify that they are returning a status `200` from the health check endpoint we configured earlier. Any other status, including redirects like status `302`, will cause the health check to fail.
 
 You may have to set a password on the `root` user to prevent automatic redirects on the sign-in endpoint before health checks will pass.
 

doc/install/installation.md

@@ -1034,7 +1034,7 @@ To use GitLab with HTTPS:
    1. Set the `port` option in section 1 to `443`.
    1. Set the `https` option in section 1 to `true`.
 1. In the `config.yml` of GitLab Shell:
-   1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
+   1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (for example, `https://git.example.com`).
    1. Set the certificates using either the `ca_file` or `ca_path` option.
 1. Use the `gitlab-ssl` NGINX example configuration instead of the `gitlab` configuration.
    1. Update `YOUR_SERVER_FQDN`.
@@ -1119,7 +1119,7 @@ host localhost          # Give your setup a name (here: override localhost)
     hostname 127.0.0.1; # Your server name or IP
 ```
 
-You also need to change the corresponding options (e.g. `ssh_user`, `ssh_host`, `admin_uri`) in the `config\gitlab.yml` file.
+You also need to change the corresponding options (for example, `ssh_user`, `ssh_host`, `admin_uri`) in the `config\gitlab.yml` file.
 
 ### Additional Markup Styles
 

doc/integration/mattermost/index.md

@@ -18,8 +18,8 @@ Each release of GitLab Mattermost is compiled and manually tested on an AMD 64 c
 
 ## Getting started
 
-GitLab Mattermost expects to run on its own virtual host. In your DNS settings you will need
-two entries pointing to the same machine, e.g., `gitlab.example.com` and
+GitLab Mattermost expects to run on its own virtual host. In your DNS settings, you will need
+two entries pointing to the same machine. For example, `gitlab.example.com` and
 `mattermost.example.com`.
 
 GitLab Mattermost is disabled by default. To enable it:
@@ -346,8 +346,8 @@ When upgrading the Mattermost version, it is essential to check the
 for Mattermost to address any changes or migrations that need to be performed.
 
 Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Omnibus GitLab update process. When upgrading previous versions of
-GitLab that process can only be used if Mattermost configuration settings have not been changed outside of GitLab (i.e., no changes to Mattermost's `config.json`
-file have been made, either directly or via the Mattermost **System Console** which saves back changes to `config.json`.)
+GitLab, the update process can only be used if Mattermost configuration settings have not been changed outside of GitLab. That is, no changes to Mattermost's `config.json`
+file have been made - either directly or via the Mattermost **System Console**, which saves changes to `config.json`.
 
 If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using Omnibus and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
 

doc/operations/metrics/dashboards/yaml_number_format.md

@@ -15,7 +15,7 @@ You can select units to format your charts by adding `format` to your
 
 ## Internationalization and localization
 
-Currently, your [internationalization and localization options](https://en.wikipedia.org/wiki/Internationalization_and_localization) for number formatting are dependent on the system you are using i.e. your OS or browser.
+Currently, your [internationalization and localization options](https://en.wikipedia.org/wiki/Internationalization_and_localization) for number formatting are dependent on the system you are using (that is, your OS or browser).
 
 ## Engineering Notation
 

doc/security/webhooks.md

@@ -26,11 +26,11 @@ sent.
 
 Webhook requests are made by the GitLab server itself and use a single
 (optional) secret token per hook for authorization (instead of a user or
-repository-specific token). As a result, these may have broader access than
-intended to everything running on the server hosting the webhook (which
-may include the GitLab server or API itself, e.g., `http://localhost:123`).
+repository-specific token). As a result, these requests may have broader access than
+intended, including access to everything running on the server hosting the webhook. This 
+may include the GitLab server or API itself (for example, `http://localhost:123`).
 Depending on the called webhook, this may also result in network access
-to other servers within that webhook server's local network (e.g.,
+to other servers within that webhook server's local network (for example,
 `http://192.168.1.12:345`), even if these services are otherwise protected
 and inaccessible from the outside world.