Merge branch 'docs/fix-vale-substitution-warn' into 'master'

Fix a few vale substitution warning: click->select

See merge request gitlab-org/gitlab!88145

doc/administration/auth/cognito.md

@@ -18,13 +18,13 @@ The following steps enable AWS Cognito as an authentication provider:
 1. Sign in to the [AWS console](https://console.aws.amazon.com/console/home).
 1. Select **Cognito** from the **Services** menu.
-1. Select **Manage User Pools**, and click the **Create a user pool** button in the top right corner.
-1. Enter the pool name and then click the **Step through settings** button.
+1. Select **Manage User Pools**, and select the **Create a user pool** button in the top right corner.
+1. Enter the pool name and then select the **Step through settings** button.
 1. Under **How do you want your end users to sign in?**, select **Email address or phone number** and **Allow email addresses**.
 1. Under **Which standard attributes do you want to require?**, select **email**.
 1. Go to the next steps of configuration and set the rest of the settings to suit your needs - in the basic setup they are not related to GitLab configuration.
-1. In the **App clients** settings, click **Add an app client**, add **App client name** and select the **Enable username password based authentication** checkbox.
-1. Click **Create app client**.
+1. In the **App clients** settings, select **Add an app client**, add **App client name** and select the **Enable username password based authentication** checkbox.
+1. Select **Create app client**.
 1. In the next step, you can set up AWS Lambda functions for sending emails. You can then finish creating the pool.
 1. After creating the user pool, go to **App client settings** and provide the required information:
@@ -85,7 +85,7 @@ Include the code block in the `/etc/gitlab/gitlab.rb` file:
 1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
 Your sign-in page should now display a Cognito button below the regular sign-in form.
-To begin the authentication process, click the icon, and AWS Cognito asks the user to sign in and authorize the GitLab application.
+To begin the authentication process, select the icon, and AWS Cognito asks the user to sign in and authorize the GitLab application.
 If successful, the user is redirected and signed in to your GitLab instance.
 For more information, see [Configure initial settings](../../integration/omniauth.md#configure-initial-settings).

doc/administration/auth/jwt.md

@@ -74,7 +74,7 @@ JWT provides you with a secret key for you to use.
    installed GitLab via Omnibus or from source respectively.
 On the sign in page there should now be a JWT icon below the regular sign in form.
-Click the icon to begin the authentication process. JWT asks the user to
+Select the icon to begin the authentication process. JWT asks the user to
 sign in and authorize the GitLab application. If everything goes well, the user
 is redirected to GitLab and signed in.

doc/administration/auth/ldap/google_secure_ldap.md

@@ -26,7 +26,7 @@ The steps below cover:
 1. Provide an `LDAP client name` and an optional `Description`. Any descriptive
    values are acceptable. For example, the name could be 'GitLab' and the
-   description could be 'GitLab LDAP Client'. Click the **Continue** button.
+   description could be 'GitLab LDAP Client'. Select the **Continue** button.
    ![Add LDAP Client Step 1](img/google_secure_ldap_add_step_1.png)
@@ -42,15 +42,15 @@ The steps below cover:
 1. Download the generated certificate. This is required for GitLab to
    communicate with the Google Secure LDAP service. Save the downloaded certificates
-   for later use. After downloading, click the **Continue to Client Details** button.
+   for later use. After downloading, select the **Continue to Client Details** button.
 1. Expand the **Service Status** section and turn the LDAP client 'ON for everyone'.
-   After selecting 'Save', click on the 'Service Status' bar again to collapse
+   After selecting 'Save', select the 'Service Status' bar again to collapse
    and return to the rest of the settings.
 1. Expand the **Authentication** section and choose 'Generate New Credentials'.
-   Copy/note these credentials for later use. After selecting 'Close', click
-   on the 'Authentication' bar again to collapse and return to the rest of the settings.
+   Copy/note these credentials for later use. After selecting 'Close', select
+   the 'Authentication' bar again to collapse and return to the rest of the settings.
 Now the Google Secure LDAP Client configuration is finished. The screenshot below
 shows an example of the final settings. Continue on to configure GitLab.

doc/administration/auth/oidc.md

@@ -120,7 +120,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
    for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 On the sign in page, there should now be an OpenID Connect icon below the regular sign in form.
-Click the icon to begin the authentication process. The OpenID Connect provider asks the user to
+Select the icon to begin the authentication process. The OpenID Connect provider asks the user to
 sign in and authorize the GitLab application (if confirmation required by the client). If everything goes well, the user
 is redirected to GitLab and signed in.

doc/administration/geo/replication/location_aware_git_url.md

@@ -57,34 +57,34 @@ routing configurations.
    ![Traffic policies](img/single_git_traffic_policies.png)
-1. Click the **Create traffic policy** button.
+1. Select the **Create traffic policy** button.
    ![Name policy](img/single_git_name_policy.png)
-1. Fill in the **Policy Name** field with `Single Git Host` and click **Next**.
+1. Fill in the **Policy Name** field with `Single Git Host` and select **Next**.
    ![Policy diagram](img/single_git_policy_diagram.png)
 1. Leave **DNS type** as `A: IP Address in IPv4 format`.
-1. Click **Connect to...** and select **Geolocation rule**.
+1. Select **Connect to...** and select **Geolocation rule**.
    ![Add geolocation rule](img/single_git_add_geolocation_rule.png)
 1. For the first **Location**, leave it as `Default`.
-1. Click **Connect to...** and select **New endpoint**.
+1. Select **Connect to...** and select **New endpoint**.
 1. Choose **Type** `value` and fill it in with `<your **primary** IP address>`.
 1. For the second **Location**, choose `Europe`.
-1. Click **Connect to...** and select **New endpoint**.
+1. Select **Connect to...** and select **New endpoint**.
 1. Choose **Type** `value` and fill it in with `<your **secondary** IP address>`.
    ![Add traffic policy endpoints](img/single_git_add_traffic_policy_endpoints.png)
-1. Click **Create traffic policy**.
+1. Select **Create traffic policy**.
    ![Create policy records with traffic policy](img/single_git_create_policy_records_with_traffic_policy.png)
 1. Fill in **Policy record DNS name** with `git`.
-1. Click **Create policy records**.
+1. Select **Create policy records**.
    ![Created policy record](img/single_git_created_policy_record.png)

doc/topics/autodevops/customize.md

@@ -670,7 +670,7 @@ The percentage is based on the `REPLICAS` CI/CD variable, and defines the number
 pods you want to have for your deployment. If the value is `10`, and you run the
 `10%` rollout job, there is `1` new pod and `9` old ones.
-To start a job, click the play icon (**{play}**) next to the job's name. You're not
+To start a job, select the play icon (**{play}**) next to the job's name. You're not
 required to go from `10%` to `100%`, you can jump to whatever job you want.
 You can also scale down by running a lower percentage job, just before hitting
 `100%`. Once you get to `100%`, you can't scale down, and you'd have to roll

doc/topics/git/feature_branch_development.md

@@ -83,7 +83,7 @@ we have selected `test-branch` as the source, and `release-13-0` as the target.
    ![Modify branches](img/modify_branches_v13_1.png)
-1. Once you've selected the Source and Target branches, click **Compare branches and continue**.
+1. Once you've selected the Source and Target branches, select **Compare branches and continue**.
    You should see an entry similar to:
    ```plaintext
@@ -94,7 +94,7 @@ we have selected `test-branch` as the source, and `release-13-0` as the target.
    An entry like this confirms your merge request's destination.
-1. Make any additional changes in the **New Merge Request** screen, and click **Submit merge request**.
+1. Make any additional changes in the **New Merge Request** screen, and select **Submit merge request**.
 1. In the new merge request, look for **Request to merge**. An entry similar to this displays:
    ```plaintext

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -121,7 +121,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    1. Navigate to your project's **Settings > Repository** and
    expand **Protected branches**.
-   1. Scroll down to locate the protected branches and click
+   1. Scroll down to locate the protected branches and select
    **Unprotect** the default branch.
 1. Force-push to GitLab:
@@ -162,7 +162,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    1. Select the default branch from the **Branch** dropdown menu,
    and set up the
    **Allowed to push** and **Allowed to merge** rules.
-   1. Click **Protect**.
+   1. Select **Protect**.
 <!-- ## Troubleshooting

doc/topics/offline/quick_start_guide.md

@@ -202,7 +202,7 @@ done.
 ### Disable Version Check and Service Ping
 The Version Check and Service Ping services improve the GitLab user experience and ensure that
-users are on the most up-to-date instances of GitLab. These two services can be turned off for air-gapped
+users are on the most up-to-date instances of GitLab. These two services can be turned off for offline
 environments so that they do not attempt and fail to reach out to GitLab services.
 Learn more about [disabling usage statistics](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics).

doc/user/application_security/api_fuzzing/index.md

@@ -883,7 +883,7 @@ Adding some basic logging to your overrides script is useful in case the script
 Following our example, we provided `renew_token.py` in the environmental variable `FUZZAPI_OVERRIDES_CMD`. Please notice two things in the script:
 - Log file is saved in the location indicated by the environment variable `CI_PROJECT_DIR`.
-- Log file name should match `gl-*.log`.
+- Log filename should match `gl-*.log`.
 ```python
 #!/usr/bin/env python
@@ -1476,9 +1476,9 @@ Follow these steps to view details of a fuzzing fault:
    - In a project, go to the project's **{shield}** **Security & Compliance > Vulnerability Report**
      page. This page shows all vulnerabilities from the default branch only.
-   - In a merge request, go the merge request's **Security** section and click the **Expand**
+   - In a merge request, go the merge request's **Security** section and select the **Expand**
      button. API Fuzzing faults are available in a section labeled
-     **API Fuzzing detected N potential vulnerabilities**. Click the title to display the fault
+     **API Fuzzing detected N potential vulnerabilities**. Select the title to display the fault
      details.
 1. Select the fault's title to display the fault's details. The table below describes these details.

doc/user/application_security/dast/index.md

@@ -493,7 +493,7 @@ To perform a [full scan](#full-scan) on the listed paths, use the `DAST_FULL_SCA
 ### List URLs scanned
 When DAST completes scanning, the merge request page states the number of URLs scanned.
-Click **View details** to view the web console output which includes the list of scanned URLs.
+Select **View details** to view the web console output which includes the list of scanned URLs.
 ![DAST Widget](img/dast_urls_scanned_v12_10.png)
@@ -846,7 +846,7 @@ Many web applications show the user the login form in a pop-up (modal) window.
 For these applications, navigating to the form requires both:
 - A starting URL.
-- A list of elements to click to display the modal window.
+- A list of elements to select to display the modal window.
 When `DAST_BROWSER_PATH_TO_LOGIN_FORM` is present, like in this example:

doc/user/application_security/dast_api/index.md

@@ -837,7 +837,7 @@ Adding some basic logging to your overrides script is useful in case the script
 Following our example, we provided `renew_token.py` in the environment variable `DAST_API_OVERRIDES_CMD`. Please notice two things in the script:
 - Log file is saved in the location indicated by the environmental variable `CI_PROJECT_DIR`.
-- Log file name should match `gl-*.log`.
+- Log filename should match `gl-*.log`.
 ```python
 #!/usr/bin/env python
@@ -1332,12 +1332,12 @@ Follow these steps to view details of a vulnerability:
    - In a project, go to the project's **{shield}** **Security & Compliance > Vulnerability Report**
      page. This page shows all vulnerabilities from the default branch only.
-   - In a merge request, go the merge request's **Security** section and click the **Expand**
+   - In a merge request, go the merge request's **Security** section and select the **Expand**
      button. DAST API vulnerabilities are available in a section labeled
-     **DAST detected N potential vulnerabilities**. Click the title to display the vulnerability
+     **DAST detected N potential vulnerabilities**. Select the title to display the vulnerability
      details.
-1. Click the vulnerabilities title to display the details. The table below describes these details.
+1. Select the vulnerabilities title to display the details. The table below describes these details.
    | Field               | Description                                                                             |
    |:--------------------|:----------------------------------------------------------------------------------------|

doc/user/application_security/vulnerability_report/index.md

@@ -249,7 +249,7 @@ To add a new vulnerability finding from your project level Vulnerability Report
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Security & Compliance > Vulnerability Report**.
-1. Click on **Submit Vulnerability**.
+1. Select **Submit Vulnerability**.
 1. Complete the fields and submit the form.
 You will be brought to the newly created vulnerability's detail page. Manually created records appear in the

doc/user/group/saml_sso/scim_setup.md

@@ -112,7 +112,7 @@ After the above steps are complete:
 1. Sign in to Okta.
 1. Ensure you are in the Admin Area by selecting the **Admin** button located in the top right. The button is not visible from the Admin Area.
 1. In the **Application** tab, select **Browse App Catalog**.
-1. Search for **GitLab**, find and select on the 'GitLab' application.
+1. Search for **GitLab**, find and select the 'GitLab' application.
 1. On the GitLab application overview page, select **Add**.
 1. Under **Application Visibility** select both checkboxes. Currently the GitLab application does not support SAML authentication so the icon should not be shown to users.
 1. Select **Done** to finish adding the application.

doc/user/profile/account/two_factor_authentication.md

@@ -206,7 +206,7 @@ To set up 2FA with a U2F device:
 1. Select **Account**.
 1. Select **Enable Two-Factor Authentication**.
 1. Connect your U2F device.
-1. Select on **Set up New U2F Device**.
+1. Select **Set up New U2F Device**.
 1. A light begins blinking on your device. Activate it by pressing its button.
 A message displays indicating that your device was successfully set up. Select **Register U2F Device** to complete the

doc/user/project/clusters/add_eks_clusters.md

@@ -58,7 +58,7 @@ cluster certificates:
    - Group's **Kubernetes** page, for a group-level cluster.
    - **Menu > Admin > Kubernetes**, for an instance-level cluster.
 1. Select **Integrate with a cluster certificate**.
-1. Under the **Create new cluster** tab, click **Amazon EKS** to display an
+1. Under the **Create new cluster** tab, select **Amazon EKS** to display an
    `Account ID` and `External ID` needed for later steps.
 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
    1. From the left panel, select **Policies**.
@@ -116,8 +116,8 @@ cluster certificates:
       If you get an error during this process, GitLab does not roll back the changes. You must remove resources manually. You can do this by deleting
       the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html).
-   1. Click **Review policy**.
-   1. Enter a suitable name for this policy, and click **Create Policy**. You can now close this window.
+   1. Select **Review policy**.
+   1. Enter a suitable name for this policy, and select **Create Policy**. You can now close this window.
 ### Prepare the cluster in Amazon
@@ -145,11 +145,11 @@ create another IAM role (**role B**) for GitLab authentication with AWS:
 1. Enter the Account ID from GitLab into the **Account ID** field.
 1. Check **Require external ID**.
 1. Enter the External ID from GitLab into the **External ID** field.
-1. Click **Next: Permissions**, and select the policy you just created.
-1. Click **Next: Tags**, and optionally enter any tags you wish to associate with this role.
-1. Click **Next: Review**.
+1. Select **Next: Permissions**, and select the policy you just created.
+1. Select **Next: Tags**, and optionally enter any tags you wish to associate with this role.
+1. Select **Next: Review**.
 1. Enter a role name and optional description into the fields provided.
-1. Click **Create role**. The new role name displays at the top. Click on its name and copy the
+1. Select **Create role**. The new role name displays at the top. Select its name and copy the
    `Role ARN` from the newly created role.
 ### Configure your cluster's data in GitLab
@@ -213,7 +213,7 @@ Otherwise, the deployed app isn't externally available outside of the cluster.
 GitLab creates a new pipeline, which begins to build, test, and deploy the app.
 After the pipeline has finished, your app runs in EKS, and is available
-to users. Click on **CI/CD > Environments**.
+to users. Select **CI/CD > Environments**.
 ![Deployed Environment](img/environment.png)
@@ -252,7 +252,7 @@ IAM user in the Amazon AWS console, and follow these steps:
 1. Check **Enable Amazon EKS integration**.
 1. Enter your **Account ID**.
 1. Enter your [access key and ID](#eks-access-key-and-id).
-1. Click **Save changes**.
+1. Select **Save changes**.
 #### EKS access key and ID

doc/user/project/deploy_boards.md

@@ -69,7 +69,7 @@ specific environment, there are a lot of use cases. To name a few:
 - You want to promote what's running in staging, to production. You go to the
   environments list, verify that what's running in staging is what you think is
-  running, then click on the [manual job](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually) to deploy to production.
+  running, then select the [manual job](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually) to deploy to production.
 - You trigger a deploy, and you have many containers to upgrade so you know
   this takes a while (you've also throttled your deploy to only take down X
   containers at a time). But you need to tell someone when it's deployed, so you
@@ -80,7 +80,7 @@ specific environment, there are a lot of use cases. To name a few:
   stuck or failed.
 - You've got an MR that looks good, but you want to run it on staging because
   staging is set up in some way closer to production. You go to the environment
-  list, find the [Review App](../../ci/review_apps/index.md) you're interested in, and click the
+  list, find the [Review App](../../ci/review_apps/index.md) you're interested in, and select the
   manual action to deploy it to staging.
 ## Enabling deploy boards
@@ -129,7 +129,7 @@ To display the deploy boards for a specific [environment](../../ci/environments/
 Once all of the above are set up and the pipeline has run at least once,
 navigate to the environments page under **Deployments > Environments**.
-Deploy boards are visible by default. You can explicitly click
+Deploy boards are visible by default. You can explicitly select
 the triangle next to their respective environment name in order to hide them.
 ### Example manifest file

doc/user/project/integrations/discord_notifications.md

@@ -32,6 +32,6 @@ With the webhook URL created in the Discord channel, you can set up the Discord
 1. Ensure that the **Active** toggle is enabled.
 1. Check the checkboxes corresponding to the GitLab events for which you want to send notifications to Discord.
 1. Paste the webhook URL that you copied from the create Discord webhook step.
-1. Configure the remaining options and click the **Save changes** button.
+1. Configure the remaining options and select the **Save changes** button.
 The Discord channel you created the webhook for now receives notification of the GitLab events that were configured.

doc/user/project/issues/multiple_assignees_for_issues.md

@@ -34,7 +34,7 @@ it clear that their role is complete.
 ## How it works
 From an opened issue, expand the right sidebar, locate the assignees entry,
-and click on **Edit**. From the dropdown menu, select as many users as you want
+and select **Edit**. From the dropdown menu, select as many users as you want
 to assign the issue to.
 ![adding multiple assignees](img/multiple_assignees.gif)

doc/user/project/merge_requests/cherry_pick_changes.md

@@ -18,7 +18,7 @@ to cherry-pick the changes introduced by that merge request.
 ![Cherry-pick merge request](img/cherry_pick_changes_mr.png)
-After you click that button, a modal displays a
+After you select that button, a modal displays a
 [branch filter search box](../repository/branches/index.md#branch-filter-search-box)
 where you can choose to either:
@@ -69,12 +69,12 @@ git cherry-pick -m 2 7a39eb0
 You can cherry-pick merge requests from the same project, or forks of the same
 project, from the GitLab user interface:
-1. In the merge request's secondary menu, click **Commits** to display the commit details page.
-1. Click on the **Options** dropdown and select **Cherry-pick** to show the cherry-pick modal.
+1. In the merge request's secondary menu, select **Commits** to display the commit details page.
+1. Select the **Options** dropdown and select **Cherry-pick** to show the cherry-pick modal.
 1. In **Pick into project** and **Pick into branch**, select the destination project and branch:
    ![Cherry-pick commit](img/cherry_pick_into_project_v13_11.png)
 1. Optional. Select **Start a new merge request** if you're ready to create a merge request.
-1. Click **Cherry-pick**.
+1. Select **Cherry-pick**.
 ## Related topics