Fix up the docs warning detected by the vale latin term rule PART 3

doc/administration/packages/container_registry.md

@@ -1025,15 +1025,15 @@ You may want to add the `-m` flag to [remove untagged manifests and unreferenced
 Before diving in to the following sections, here's some basic troubleshooting:
 
 1. Check to make sure that the system clock on your Docker client and GitLab server have
-   been synchronized (e.g. via NTP).
+   been synchronized (for example, via NTP).
 
 1. If you are using an S3-backed Registry, double check that the IAM
    permissions and the S3 credentials (including region) are correct. See [the
    sample IAM policy](https://docs.docker.com/registry/storage-drivers/s3/)
    for more details.
 
-1. Check the Registry logs (e.g. `/var/log/gitlab/registry/current`) and the GitLab production logs
-   for errors (e.g. `/var/log/gitlab/gitlab-rails/production.log`). You may be able to find clues
+1. Check the Registry logs (for example `/var/log/gitlab/registry/current`) and the GitLab production logs
+   for errors (for example `/var/log/gitlab/gitlab-rails/production.log`). You may be able to find clues
    there.
 
 ### Using self-signed certificates with Container Registry
@@ -1461,7 +1461,7 @@ no errors are generated by the curl commands.
 #### Running the Docker daemon with a proxy
 
 For Docker to connect through a proxy, you must start the Docker daemon with the
-proper environment variables. The easiest way is to shutdown Docker (e.g. `sudo initctl stop docker`)
+proper environment variables. The easiest way is to shutdown Docker (for example `sudo initctl stop docker`)
 and then run Docker by hand. As root, run:
 
 ```shell

doc/administration/polling.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Polling configuration **(FREE SELF)**
 
 The GitLab UI polls for updates for different resources (issue notes, issue
-titles, pipeline statuses, etc.) on a schedule appropriate to the resource.
+titles, pipeline statuses, and so on) on a schedule appropriate to the resource.
 
 To configure the polling interval multiplier:
 

doc/administration/postgresql/replication_and_failover.md

@@ -97,8 +97,8 @@ This is why you will need:
 
 - IP address of each nodes network interface. This can be set to `0.0.0.0` to
   listen on all interfaces. It cannot be set to the loopback address `127.0.0.1`.
-- Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
-  or CIDR (i.e. `192.168.0.0/24`) form.
+- Network Address. This can be in subnet (that is, `192.168.0.0/255.255.255.0`)
+  or CIDR (that is, `192.168.0.0/24`) form.
 
 #### Consul information
 

doc/administration/redis/replication_and_failover_external.md

@@ -73,7 +73,7 @@ requirements:
   instead of a socket. To configure Redis to use TCP connections you need to
   define both `bind` and `port` in the Redis configuration file. You can bind to all
   interfaces (`0.0.0.0`) or specify the IP of the desired interface
-  (e.g., one from an internal network).
+  (for example, one from an internal network).
 - Since Redis 3.2, you must define a password to receive external connections
   (`requirepass`).
 - If you are using Redis with Sentinel, you also need to define the same

doc/administration/reference_architectures/10k_users.md

@@ -2395,7 +2395,7 @@ future with further specific cloud provider details.
 |-------------------------------------------------------|----------|-------------------------|------------------|-----------------------------|
 | Webservice                                            | 4        | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | 127.5 vCPU, 118 GB memory   |
 | Sidekiq                                               | 4        | 4 vCPU, 15 GB memory    | `n1-standard-4`  | 15.5 vCPU, 50 GB memory     |
-| Supporting services such as NGINX, Prometheus, etc.   | 2        | 4 vCPU, 15 GB memory    | `n1-standard-4`  | 7.75 vCPU, 25 GB memory     |
+| Supporting services such as NGINX or Prometheus   | 2        | 4 vCPU, 15 GB memory    | `n1-standard-4`  | 7.75 vCPU, 25 GB memory     |
 
 <!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
 <!-- markdownlint-disable MD029 -->

doc/administration/troubleshooting/debug.md

@@ -111,7 +111,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
    ```
 
    In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
-   logs (e.g. `/var/log/mail.log`) for more details.
+   logs (for example, `/var/log/mail.log`) for more details.
 
 1. Send a test message via the console.
 
@@ -237,7 +237,7 @@ are concerned about affecting others during a production system, you can run a
 separate Rails process to debug the issue:
 
 1. Log in to your GitLab account.
-1. Copy the URL that is causing problems (e.g. `https://gitlab.com/ABC`).
+1. Copy the URL that is causing problems (for example, `https://gitlab.com/ABC`).
 1. Create a Personal Access Token for your user (User Settings -> Access Tokens).
 1. Bring up the [GitLab Rails console.](../operations/rails_console.md#starting-a-rails-console-session)
 1. At the Rails console, run:
@@ -258,12 +258,12 @@ separate Rails process to debug the issue:
 ### GitLab: API is not accessible
 
 This often occurs when GitLab Shell attempts to request authorization via the
-[internal API](../../development/internal_api.md) (e.g., `http://localhost:8080/api/v4/internal/allowed`), and
+[internal API](../../development/internal_api.md) (for example, `http://localhost:8080/api/v4/internal/allowed`), and
 something in the check fails. There are many reasons why this may happen:
 
-1. Timeout connecting to a database (e.g., PostgreSQL or Redis)
+1. Timeout connecting to a database (for example, PostgreSQL or Redis)
 1. Error in Git hooks or push rules
-1. Error accessing the repository (e.g., stale NFS handles)
+1. Error accessing the repository (for example, stale NFS handles)
 
 To diagnose this problem, try to reproduce the problem and then see if there
 is a Unicorn worker that is spinning via `top`. Try to use the `gdb`

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -1236,7 +1236,7 @@ Open the rails console (`gitlab rails c`) and run the following command to see a
 ApplicationSetting.last.attributes
 ```
 
-Among other attributes, in the output you will notice that all the settings available in the [Elasticsearch Integration page](../../integration/elasticsearch.md), like: `elasticsearch_indexing`, `elasticsearch_url`, `elasticsearch_replicas`, `elasticsearch_pause_indexing`, etc.
+Among other attributes, in the output you will notice that all the settings available in the [Elasticsearch Integration page](../../integration/elasticsearch.md), like: `elasticsearch_indexing`, `elasticsearch_url`, `elasticsearch_replicas`, `elasticsearch_pause_indexing`, and so on.
 
 #### Setting attributes
 

doc/api/commits.md

@@ -638,8 +638,8 @@ GET /projects/:id/repository/commits/:sha/statuses
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user
 | `sha`     | string  | yes | The commit SHA
 | `ref`     | string  | no  | The name of a repository branch or tag or, if not given, the default branch
-| `stage`   | string  | no  | Filter by [build stage](../ci/yaml/index.md#stages), e.g., `test`
-| `name`    | string  | no  | Filter by [job name](../ci/yaml/index.md#job-keywords), e.g., `bundler:audit`
+| `stage`   | string  | no  | Filter by [build stage](../ci/yaml/index.md#stages), for example, `test`
+| `name`    | string  | no  | Filter by [job name](../ci/yaml/index.md#job-keywords), for example, `bundler:audit`
 | `all`     | boolean | no  | Return all statuses, not only the latest ones
 
 ```shell

doc/api/group_labels.md

@@ -116,7 +116,7 @@ POST /groups/:id/labels
 | ------------- | ------- | -------- | ---------------------------- |
 | `id` | integer/string | yes | The ID or [URL-encoded path of the group](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `name`        | string  | yes      | The name of the label        |
-| `color`       | string  | yes      | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
+| `color`       | string  | yes      | The color of the label given in 6-digit hex notation with leading '#' sign (for example, #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description` | string  | no       | The description of the label, |
 
 ```shell
@@ -155,7 +155,7 @@ PUT /groups/:id/labels/:label_id
 | `id` | integer/string | yes | The ID or [URL-encoded path of the group](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `label_id` | integer or string | yes | The ID or title of a group's label. |
 | `new_name`    | string  | no      | The new name of the label        |
-| `color`       | string  | no      | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
+| `color`       | string  | no      | The color of the label given in 6-digit hex notation with leading '#' sign (for example, #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description` | string  | no       | The description of the label. |
 
 ```shell

doc/api/groups.md

@@ -1402,11 +1402,11 @@ POST /groups/:id/push_rule
 | `deny_delete_tag`                             | boolean        | no       | Deny deleting a tag |
 | `member_check`                                | boolean        | no       | Allows only GitLab users to author commits |
 | `prevent_secrets`                             | boolean        | no       | [Files that are likely to contain secrets](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/checks/files_denylist.yml) are rejected |
-| `commit_message_regex`                        | string         | no       | All commit messages must match the regular expression provided in this attribute, e.g. `Fixed \d+\..*` |
-| `commit_message_negative_regex`               | string         | no       | Commit messages matching the regular expression provided in this attribute aren't allowed, e.g. `ssh\:\/\/` |
-| `branch_name_regex`                           | string         | no       | All branch names must match the regular expression provided in this attribute, e.g. `(feature|hotfix)\/*` |
-| `author_email_regex`                          | string         | no       | All commit author emails must match the regular expression provided in this attribute, e.g. `@my-company.com$` |
-| `file_name_regex`                             | string         | no       | Filenames matching the regular expression provided in this attribute are **not** allowed, e.g. `(jar|exe)$` |
+| `commit_message_regex`                        | string         | no       | All commit messages must match the regular expression provided in this attribute, for example, `Fixed \d+\..*` |
+| `commit_message_negative_regex`               | string         | no       | Commit messages matching the regular expression provided in this attribute aren't allowed, for example, `ssh\:\/\/` |
+| `branch_name_regex`                           | string         | no       | All branch names must match the regular expression provided in this attribute, for example, `(feature|hotfix)\/*` |
+| `author_email_regex`                          | string         | no       | All commit author emails must match the regular expression provided in this attribute, for example, `@my-company.com$` |
+| `file_name_regex`                             | string         | no       | Filenames matching the regular expression provided in this attribute are **not** allowed, for example, `(jar|exe)$` |
 | `max_file_size`                               | integer        | no       | Maximum file size (MB) allowed |
 | `commit_committer_check`                      | boolean        | no       | Only commits pushed using verified emails are allowed |
 | `reject_unsigned_commits`                     | boolean        | no       | Only commits signed through GPG are allowed |
@@ -1449,11 +1449,11 @@ PUT /groups/:id/push_rule
 | `deny_delete_tag`                             | boolean        | no       | Deny deleting a tag |
 | `member_check`                                | boolean        | no       | Restricts commits to be authored by existing GitLab users only |
 | `prevent_secrets`                             | boolean        | no       | [Files that are likely to contain secrets](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/checks/files_denylist.yml) are rejected |
-| `commit_message_regex`                        | string         | no       | All commit messages must match the regular expression provided in this attribute, e.g. `Fixed \d+\..*` |
-| `commit_message_negative_regex`               | string         | no       | Commit messages matching the regular expression provided in this attribute aren't allowed, e.g. `ssh\:\/\/` |
-| `branch_name_regex`                           | string         | no       | All branch names must match the regular expression provided in this attribute, e.g. `(feature|hotfix)\/*` |
-| `author_email_regex`                          | string         | no       | All commit author emails must match the regular expression provided in this attribute, e.g. `@my-company.com$` |
-| `file_name_regex`                             | string         | no       | Filenames matching the regular expression provided in this attribute are **not** allowed, e.g. `(jar|exe)$` |
+| `commit_message_regex`                        | string         | no       | All commit messages must match the regular expression provided in this attribute, for example, `Fixed \d+\..*` |
+| `commit_message_negative_regex`               | string         | no       | Commit messages matching the regular expression provided in this attribute aren't allowed, for example, `ssh\:\/\/` |
+| `branch_name_regex`                           | string         | no       | All branch names must match the regular expression provided in this attribute, for example, `(feature|hotfix)\/*` |
+| `author_email_regex`                          | string         | no       | All commit author emails must match the regular expression provided in this attribute, for example, `@my-company.com$` |
+| `file_name_regex`                             | string         | no       | Filenames matching the regular expression provided in this attribute are **not** allowed, for example, `(jar|exe)$` |
 | `max_file_size`                               | integer        | no       | Maximum file size (MB) allowed |
 | `commit_committer_check`                      | boolean        | no       | Only commits pushed using verified emails are allowed |
 | `reject_unsigned_commits`                     | boolean        | no       | Only commits signed through GPG are allowed |

doc/api/labels.md

@@ -158,7 +158,7 @@ POST /projects/:id/labels
 | ------------- | ------- | -------- | ---------------------------- |
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `name`        | string  | yes      | The name of the label        |
-| `color`       | string  | yes      | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
+| `color`       | string  | yes      | The color of the label given in 6-digit hex notation with leading '#' sign (for example, #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description` | string  | no       | The description of the label |
 | `priority`    | integer | no       | The priority of the label. Must be greater or equal than zero or `null` to remove the priority. |
 
@@ -219,7 +219,7 @@ PUT /projects/:id/labels/:label_id
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `label_id` | integer or string | yes | The ID or title of a group's label. |
 | `new_name`      | string  | yes if `color` is not provided    | The new name of the label        |
-| `color`         | string  | yes if `new_name` is not provided | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
+| `color`         | string  | yes if `new_name` is not provided | The color of the label given in 6-digit hex notation with leading '#' sign (for example, #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description`   | string  | no                                | The new description of the label |
 | `priority`    | integer | no       | The new priority of the label. Must be greater or equal than zero or `null` to remove the priority. |
 

doc/api/oauth2.md

@@ -218,7 +218,7 @@ https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIREC
 This prompts the user to approve the applications access to their account
 based on the scopes specified in `REQUESTED_SCOPES` and then redirect back to
 the `REDIRECT_URI` you provided. The [scope parameter](https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-Scopes#requesting-particular-scopes)
-   is a space separated list of scopes you want to have access to (e.g. `scope=read_user+profile`
+   is a space separated list of scopes you want to have access to (for example, `scope=read_user+profile`
 would request `read_user` and `profile` scopes). The redirect
 includes a fragment with `access_token` as well as token details in GET
 parameters, for example:

doc/architecture/blueprints/container_registry_metadata_database/index.md

@@ -26,7 +26,7 @@ graph LR
    R -- Write/read metadata --> B
 ```
 
-Client applications (e.g. GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed in the [Request flow](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
+Client applications (for example, GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed in the [Request flow](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
 
 The registry supports multiple [storage backends](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#storage), including Google Cloud Storage (GCS) which is used for the GitLab.com registry. In the storage backend, images are stored as blobs, deduplicated, and shared across repositories. These are then linked (like a symlink) to each repository that relies on them, giving them access to the central storage location.
 
@@ -54,7 +54,7 @@ sequenceDiagram
 
   C->>R: docker login gitlab.example.com
   R->>C: 401 Unauthorized
-  Note left of R: The response includes the realm (e.g., https://gitlab.example.com/jwt/auth)<br> from where a token should be obtained
+  Note left of R: The response includes the realm (for example, https://gitlab.example.com/jwt/auth)<br> from where a token should be obtained
   C->>G: Obtain Bearer token
   G->>C: 200 OK
   C-->>R: Push/pull requests

doc/architecture/blueprints/database_testing/index.md

@@ -97,11 +97,11 @@ The short-term goal is detailed in [this epic](https://gitlab.com/groups/gitlab-
 
 ### Mid-term - Improved feedback, query testing and background migration testing
 
-Mid-term, we plan to expand the level of detail the testing pipeline reports back to the Merge Request and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (`postgres.ai`, `joe`, Slack, plan visualizations etc.) we bring this back to GitLab and working directly on the Merge Request.
+Mid-term, we plan to expand the level of detail the testing pipeline reports back to the Merge Request and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (`postgres.ai`, `joe`, Slack, plan visualizations, and so on) we bring this back to GitLab and working directly on the Merge Request.
 
 Secondly, we plan to cover background migrations testing, too. These are typically data migrations that are scheduled to run over a long period of time. The success of both the scheduling phase and the job execution phase typically depends a lot on data distribution - which only surfaces when running these migrations on actual production data. In order to become confident about a background migration, we plan to provide the following feedback:
 
-1. Scheduling phase - query statistics (for example a histogram of query execution times), job statistics (how many jobs, overall duration etc.), batch sizes.
+1. Scheduling phase - query statistics (for example a histogram of query execution times), job statistics (how many jobs, overall duration, and so on), batch sizes.
 1. Execution phase - using a few instances of a job as examples, we execute those to gather query and runtime statistics.
 
 ### Long-term - incorporate into GitLab product
@@ -114,7 +114,7 @@ At the core of this problem lies the concern about executing (potentially arbitr
 
 An alternative approach we have discussed and abandoned is to "scrub" and anonymize production data. The idea is to remove any sensitive data from the database and use the resulting dataset for database testing. This has a lot of downsides which led us to abandon the idea:
 
-- Anonymization is complex by nature - it is a hard problem to call a "scrubbed clone" actually safe to work with in public. Different data types may require different anonymization techniques (e.g. anonymizing sensitive information inside a JSON field) and only focusing on one attribute at a time does not guarantee that a dataset is fully anonymized (for example join attacks or using timestamps in conjunction to public profiles/projects to de-anonymize users by there activity).
+- Anonymization is complex by nature - it is a hard problem to call a "scrubbed clone" actually safe to work with in public. Different data types may require different anonymization techniques (for example, anonymizing sensitive information inside a JSON field) and only focusing on one attribute at a time does not guarantee that a dataset is fully anonymized (for example join attacks or using timestamps in conjunction to public profiles/projects to de-anonymize users by there activity).
 - Anonymization requires an additional process to keep track and update the set of attributes considered as sensitive, ongoing maintenance and security reviews every time the database schema changes.
 - Annotating data as "sensitive" is error prone, with the wrong anonymization approach used for a data type or one sensitive attribute accidentally not marked as such possibly leading to a data breach.
 - Scrubbing not only removes sensitive data, but it also changes data distribution, which greatly affects performance of migrations and queries.

doc/architecture/blueprints/image_resizing/index.md

@@ -39,7 +39,7 @@ Content image resizing is a more complex problem to tackle. There are no set siz
 - Extract first image of GIF's so we can prevent from loading 10MB pixels
 - Check Device Pixel Ratio to deliver nice images on High DPI screens
 - Progressive image loading, similar to what is described in [this article about how to build a progressive image loader](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/)
-- Resizing recommendations (size, clarity, etc.)
+- Resizing recommendations (size, clarity, and so on)
 - Storage
 
 The MVC Avatar resizing implementation is integrated into Workhorse. With the extra requirements for content image resizing, this may require further use of GraphicsMagik (GM) or a similar library and breaking it out of Workhorse.

doc/ci/cloud_deployment/index.md

@@ -101,7 +101,7 @@ GitLab also provides [Docker images](https://gitlab.com/gitlab-org/cloud-deploy/
 - Use `registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest` to deploy your application to AWS ECS.
 
 Before getting started with this process, you need a cluster on AWS ECS, as well as related
-components, like an ECS service, ECS task definition, a database on AWS RDS, etc.
+components, like an ECS service, ECS task definition, a database on AWS RDS, and so on.
 [Read more about AWS ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html).
 
 The ECS task definition can be:

doc/ci/environments/environments_dashboard.md

@@ -29,7 +29,7 @@ The Environments dashboard displays a paginated list of projects that includes
 up to three environments per project.
 
 The listed environments for each project are unique, such as
-"production", "staging", etc. Review apps and other grouped
+"production", "staging", and so on. Review apps and other grouped
 environments are not displayed.
 
 ## Adding a project to the dashboard