Changed navigate to go

doc/administration/auth/ldap/google_secure_ldap.md

@@ -20,7 +20,7 @@ The steps below cover:
 
 ## Configuring Google LDAP client
 
-1. Navigate to <https://admin.google.com/Dashboard> and sign in as a Google Workspace domain administrator.
+1. Go to <https://admin.google.com/Dashboard> and sign in as a Google Workspace domain administrator.
 
 1. Go to **Apps > LDAP > Add Client**.
 

doc/administration/auth/ldap/index.md

@@ -705,8 +705,8 @@ When enabled, the following applies:
 To enable it you need to:
 
 1. [Enable LDAP](#configuration)
-1. Navigate to **Admin Area > Settings -> Visibility and access controls**.
-1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
+1. Go to **Admin Area > Settings > Visibility and access controls**.
+1. Make sure the **Lock memberships to LDAP synchronization** checkbox is selected.
 
 ### Adjusting LDAP group sync schedule **(PREMIUM SELF)**
 

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -330,10 +330,10 @@ things to check to debug the situation.
   group](index.md#adding-group-links).
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
-  1. Navigate to **Admin area -> Users**.
+  1. Go to **Admin area > Users**.
   1. Search for the user
-  1. Open the user, by clicking on their name. Do not click 'Edit'.
-  1. Navigate to the **Identities** tab. There should be an LDAP identity with
+  1. Open the user by clicking their name. Do not click **Edit**.
+  1. Select the **Identities** tab. There should be an LDAP identity with
      an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
      LDAP yet and must do so first.
 - You've waited an hour or [the configured

doc/administration/geo/disaster_recovery/background_verification.md

@@ -58,14 +58,14 @@ Feature.enable('geo_repository_verification')
 
 ## Repository verification
 
-Navigate to the **Admin Area > Geo** dashboard on the **primary** node and expand
+Go to the **Admin Area > Geo** dashboard on the **primary** node and expand
 the **Verification information** tab for that node to view automatic checksumming
 status for repositories and wikis. Successes are shown in green, pending work
 in gray, and failures in red.
 
 ![Verification status](img/verification-status-primary.png)
 
-Navigate to the **Admin Area > Geo** dashboard on the **secondary** node and expand
+Go to the **Admin Area > Geo** dashboard on the **secondary** node and expand
 the **Verification information** tab for that node to view automatic verification
 status for repositories and wikis. As with checksumming, successes are shown in
 green, pending work in gray, and failures in red.
@@ -92,7 +92,7 @@ data. The default and recommended re-verification interval is 7 days, though
 an interval as short as 1 day can be set. Shorter intervals reduce risk but
 increase load and vice versa.
 
-Navigate to the **Admin Area > Geo** dashboard on the **primary** node, and
+Go to the **Admin Area > Geo** dashboard on the **primary** node, and
 click the **Edit** button for the **primary** node to customize the minimum
 re-verification interval:
 
@@ -141,7 +141,7 @@ sudo gitlab-rake geo:verification:wiki:reset
 
 If the **primary** and **secondary** nodes have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
 
-1. Navigate to the **Admin Area > Overview > Projects** dashboard on the **primary** node, find the
+1. Go to the **Admin Area > Overview > Projects** dashboard on the **primary** node, find the
    project that you want to check the checksum differences and click on the
    **Edit** button:
    ![Projects dashboard](img/checksum-differences-admin-projects.png)
@@ -149,7 +149,7 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
 1. On the project administration page get the **Gitaly storage name**, and **Gitaly relative path**:
    ![Project administration page](img/checksum-differences-admin-project-page.png)
 
-1. Navigate to the project's repository directory on both **primary** and **secondary** nodes
+1. Go to the project's repository directory on both **primary** and **secondary** nodes
    (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
    is customized, check the directory layout on your server to be sure.
 

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -110,7 +110,7 @@ The maintenance window won't end until Geo replication and verification is
 completely finished. To keep the window as short as possible, you should
 ensure these processes are close to 100% as possible during active use.
 
-Navigate to the **Admin Area > Geo** dashboard on the **secondary** node to
+Go to the **Admin Area > Geo** dashboard on the **secondary** node to
 review status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the node more

doc/administration/geo/replication/configuration.md

@@ -252,7 +252,7 @@ on the **secondary** node.
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
 method to be enabled. This is enabled by default, but if converting an existing node to Geo it should be checked:
 
-1. Navigate to **Admin Area > Settings** (`/admin/application_settings/general`) on the **primary** node.
+1. Go to **Admin Area > Settings** (`/admin/application_settings/general`) on the **primary** node.
 1. Expand "Visibility and access controls".
 1. Ensure "Enabled Git access protocols" is set to either "Both SSH and HTTP(S)" or "Only HTTP(S)".
 

doc/administration/geo/replication/location_aware_git_url.md

@@ -51,8 +51,8 @@ If you haven't yet set up a Geo _primary_ node and _secondary_ node, see the
 In a Route53 Hosted Zone, traffic policies can be used to set up a variety of
 routing configurations.
 
-1. Navigate to the
-[Route53 dashboard](https://console.aws.amazon.com/route53/home) and click
+1. Go to the
+[Route53 dashboard](https://console.aws.amazon.com/route53/home) and select
 **Traffic policies**.
 
    ![Traffic policies](img/single_git_traffic_policies.png)

doc/administration/geo/replication/remove_geo_node.md

@@ -9,7 +9,7 @@ type: howto
 
 **Secondary** nodes can be removed from the Geo cluster using the Geo administration page of the **primary** node. To remove a **secondary** node:
 
-1. Navigate to **Admin Area > Geo** (`/admin/geo/nodes`).
+1. Go to **Admin Area > Geo** (`/admin/geo/nodes`).
 1. Click the **Remove** button for the **secondary** node you want to remove.
 1. Confirm by clicking **Remove** when the prompt appears.
 

doc/administration/integration/kroki.md

@@ -56,7 +56,7 @@ You need to enable Kroki integration from Settings under Admin Area.
 To do that, log in with an administrator account and follow these steps:
 
 1. Select the Admin Area (**{admin}**) icon.
-1. Navigate to **Settings > General**.
+1. Go to **Settings > General**.
 1. Expand the **Kroki** section.
 1. Select **Enable Kroki** checkbox.
 1. Enter the **Kroki URL**.

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -32,7 +32,7 @@ metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics
 
 ## Creating the self monitoring project
 
-1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
+1. Go to **Admin Area > Settings > Metrics and profiling** and expand the **Self monitoring** section.
 1. Toggle the **Create Project** button on.
 1. Once your GitLab instance creates the project, GitLab displays a link to the project in the text above the **Create Project** toggle. You can also find it under **Projects > Your projects**.
 
@@ -42,7 +42,7 @@ WARNING:
 Deleting the self monitoring project removes any changes made to the project. If
 you create the project again, it's created in its default state.
 
-1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
+1. Go to **Admin Area > Settings > Metrics and profiling** and expand the **Self monitoring** section.
 1. Toggle the **Create Project** button off.
 1. In the confirmation dialog that opens, click **Delete project**.
    It can take a few seconds for it to be deleted.

doc/administration/monitoring/performance/gitlab_configuration.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 GitLab Performance Monitoring is disabled by default. To enable it and change any of its
 settings:
 
-1. Navigate to **Admin Area > Settings > Metrics and profiling**
+1. Go to **Admin Area > Settings > Metrics and profiling**
   (`/admin/application_settings/metrics_and_profiling`).
 1. Add the necessary configuration changes.
 1. Restart all GitLab for the changes to take effect:

doc/administration/monitoring/performance/grafana_configuration.md

@@ -62,7 +62,7 @@ repository.
 After setting up Grafana, you can enable a link to access it easily from the
 GitLab sidebar:
 
-1. Navigate to the **Admin Area > Settings > Metrics and profiling**.
+1. Go to the **Admin Area > Settings > Metrics and profiling**.
 1. Expand **Metrics - Grafana**.
 1. Check the **Enable access to Grafana** checkbox.
 1. Configure the **Grafana URL**:

doc/administration/monitoring/performance/performance_bar.md

@@ -81,7 +81,7 @@ The GitLab Performance Bar is disabled by default. To enable it for a given grou
 
 1. Sign in as a user with Administrator [permissions](../../../user/permissions.md).
 1. In the menu bar, click **Admin Area**.
-1. Navigate to **Settings > Metrics and profiling**
+1. Go to **Settings > Metrics and profiling**
    (`admin/application_settings/metrics_and_profiling`), and expand the section
    **Profiling - Performance bar**.
 1. Click **Enable access to the Performance Bar**.

doc/administration/monitoring/performance/request_profiling.md

@@ -10,7 +10,7 @@ To profile a request:
 
 1. Sign in to GitLab as a user with Administrator or Maintainer [permissions](../../../user/permissions.md).
 1. In the navigation bar, click **Admin area**.
-1. Navigate to **Monitoring > Requests Profiles**.
+1. Go to **Monitoring > Requests Profiles**.
 1. In the **Requests Profiles** section, copy the token.
 1. Pass the headers `X-Profile-Token: <token>` and `X-Profile-Mode: <mode>`(where
    `<mode>` can be `execution` or `memory`) to the request you want to profile. When

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To enable the GitLab Prometheus metrics:
 
 1. Log into GitLab as a user with [administrator permissions](../../../user/permissions.md).
-1. Navigate to **Admin Area > Settings > Metrics and profiling**.
+1. Go to **Admin Area > Settings > Metrics and profiling**.
 1. Find the **Metrics - Prometheus** section, and click **Enable Prometheus Metrics**.
 1. [Restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) for the changes to take effect.
 

doc/administration/pages/index.md

@@ -351,7 +351,7 @@ When adding a custom domain, users are required to prove they own it by
 adding a GitLab-controlled verification code to the DNS records for that domain.
 
 If your user base is private or otherwise trusted, you can disable the
-verification requirement. Navigate to **Admin Area > Settings > Preferences** and
+verification requirement. Go to **Admin Area > Settings > Preferences** and
 uncheck **Require users to prove ownership of custom domains** in the **Pages** section.
 This setting is enabled by default.
 
@@ -366,7 +366,7 @@ sites served under a custom domain.
 To enable it, you must:
 
 1. Choose an email address on which you want to receive notifications about expiring domains.
-1. Navigate to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
+1. Go to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
 1. Enter the email address for receiving notifications and accept Let's Encrypt's Terms of Service as shown below.
 1. Click **Save changes**.
 
@@ -420,7 +420,7 @@ The scope to use for authentication must match the GitLab Pages OAuth applicatio
 pre-existing applications must modify the GitLab Pages OAuth application. Follow these steps to do
 this:
 
-1. Navigate to your instance's **Admin Area > Settings > Applications** and expand **GitLab Pages**
+1. Go to your instance's **Admin Area > Settings > Applications** and expand **GitLab Pages**
    settings.
 1. Clear the `api` scope's checkbox and select the desired scope's checkbox (for example,
    `read_api`).
@@ -438,7 +438,7 @@ This can be useful to preserve information published with Pages websites to the
 of your instance only.
 To do that:
 
-1. Navigate to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
+1. Go to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
 1. Check the **Disable public access to Pages sites** checkbox.
 1. Click **Save changes**.
 
@@ -624,13 +624,13 @@ The default is 100MB.
 
 To override the global maximum pages size for a specific project:
 
-1. Navigate to your project's **Settings > Pages** page.
+1. Go to your project's **Settings > Pages** page.
 1. Edit the **Maximum size of pages**.
 1. Click **Save changes**.
 
 To override the global maximum pages size for a specific group:
 
-1. Navigate to your group's **Settings > General** page and expand **Pages**.
+1. Go to your group's **Settings > General** page and expand **Pages**.
 1. Edit the **Maximum size of pages**.
 1. Click **Save changes**.
 

doc/administration/server_hooks.md

@@ -51,7 +51,7 @@ repository directory might not exactly match the instructions below. In that cas
 
 Follow the steps below to set up a server-side hook for a repository:
 
-1. Navigate to **Admin area > Projects** and click on the project you want to add a server hook to.
+1. Go to **Admin area > Projects** and select the project you want to add a server hook to.
 1. Locate the **Gitaly relative path** on the page that appears. This is where the server hook
    must be implemented. For information on interpreting the relative path, see
    [Translate hashed storage paths](repository_storage_types.md#translate-hashed-storage-paths).

doc/administration/static_objects_external_storage.md

@@ -16,7 +16,7 @@ from an external storage, such as a Content Delivery Network (CDN).
 
 To configure external storage for static objects:
 
-1. Navigate to **Admin Area > Settings > Repository**.
+1. Go to **Admin Area > Settings > Repository**.
 1. Expand the **Repository static objects** section.
 1. Enter the base URL and an arbitrary token. When you [set up external storage](#set-up-external-storage),
    use a script that sets these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.