Remove inline admin area icon from docs

doc/administration/geo/disaster_recovery/background_verification.md

@@ -58,14 +58,14 @@ Feature.enable('geo_repository_verification')
 
 ## Repository verification
 
-Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
+Navigate to the **Admin Area >** **{location-dot}** **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}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
+Navigate to the **Admin Area >** **{location-dot}** **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}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node, and
+Navigate to the **Admin Area >** **{location-dot}** **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}** **Admin Area >** **{overview}** **Overview > Projects** dashboard on the **primary** node, find the
+1. Navigate to the **Admin Area >** **{overview}** **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)

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}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
+Navigate to the **Admin Area >** **{location-dot}** **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
@@ -135,8 +135,8 @@ This [content was moved to another location](background_verification.md).
 
 ### Notify users of scheduled maintenance
 
-On the **primary** node, navigate to **{admin}** **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
-message. You can check under **{admin}** **Admin Area >** **{location-dot}** **Geo** to estimate how long it
+On the **primary** node, navigate to **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
+message. You can check under **Admin Area >** **{location-dot}** **Geo** to estimate how long it
 will take to finish syncing. An example message would be:
 
 > A scheduled maintenance will take place at XX:XX UTC. We expect it to take
@@ -181,7 +181,7 @@ access to the **primary** node during the maintenance window.
    connection.
 
 1. Disable non-Geo periodic background jobs on the **primary** node by navigating
-   to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
+   to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
    and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
    This job will re-enable several other cron jobs that are essential for planned
    failover to complete successfully.
@@ -190,11 +190,11 @@ access to the **primary** node during the maintenance window.
 
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
-1. On the **primary** node, navigate to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **primary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
    and wait for all queues except those with `geo` in the name to drop to 0.
    These queues contain work that has been submitted by your users; failing over
    before it is completed will cause the work to be lost.
-1. On the **primary** node, navigate to **{admin}** **Admin Area >** **{location-dot}** **Geo** and wait for the
+1. On the **primary** node, navigate to **Admin Area >** **{location-dot}** **Geo** and wait for the
    following conditions to be true of the **secondary** node you are failing over to:
 
    - All replication meters to each 100% replicated, 0% failures.
@@ -202,7 +202,7 @@ access to the **primary** node during the maintenance window.
    - Database replication lag is 0ms.
    - The Geo log cursor is up to date (0 events behind).
 
-1. On the **secondary** node, navigate to **{admin}** **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **secondary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
 1. On the **secondary** node, use [these instructions](../../raketasks/check.md)
    to verify the integrity of CI artifacts, LFS objects, and uploads in file

doc/administration/geo/replication/configuration.md

@@ -191,7 +191,7 @@ keys must be manually replicated to the **secondary** node.
    gitlab-ctl reconfigure
    ```
 
-1. Visit the **primary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo**
+1. Visit the **primary** node's **Admin Area >** **{location-dot}** **Geo**
    (`/admin/geo/nodes`) in your browser.
 1. Click the **New node** button.
    ![Add secondary node](img/adding_a_secondary_node.png)
@@ -238,7 +238,7 @@ You can login to the **secondary** node with the same credentials as used for th
 Using Hashed Storage significantly improves Geo replication. Project and group
 renames no longer require synchronization between nodes.
 
-1. Visit the **primary** node's **{admin}** **Admin Area >** **{settings}** **Settings > Repository**
+1. Visit the **primary** node's **Admin Area >** **{settings}** **Settings > Repository**
    (`/admin/application_settings/repository`) in your browser.
 1. In the **Repository storage** section, check **Use hashed storage paths for newly created and renamed projects**.
 
@@ -255,7 +255,7 @@ on the **secondary** node.
 ### Step 6. Enable Git access over HTTP/HTTPS
 
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
-method to be enabled. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings**
+method to be enabled. Navigate to **Admin Area >** **{settings}** **Settings**
 (`/admin/application_settings/general`) on the **primary** node, and set
 `Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
 
@@ -264,7 +264,7 @@ method to be enabled. Navigate to **{admin}** **Admin Area >** **{settings}** **
 Your **secondary** node is now configured!
 
 You can login to the **secondary** node with the same credentials you used for the
-**primary** node. Visit the **secondary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo**
+**primary** node. Visit the **secondary** node's **Admin Area >** **{location-dot}** **Geo**
 (`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
 **secondary** Geo node and if Geo is enabled.
 

doc/administration/geo/replication/disable_geo.md

@@ -33,7 +33,7 @@ in order to do that.
 
 ## Remove the primary node from the UI
 
-1. Go to **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Go to **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
 1. Click the **Remove** button for the **primary** node.
 1. Confirm by clicking **Remove** when the prompt appears.
 

doc/administration/geo/replication/docker_registry.md

@@ -122,7 +122,7 @@ generate a short-lived JWT that is pull-only-capable to access the
 
 ### Verify replication
 
-To verify Container Registry replication is working, go to **{admin}** **Admin Area >** **{location-dot}** **Geo**
+To verify Container Registry replication is working, go to **Admin Area >** **{location-dot}** **Geo**
 (`/admin/geo/nodes`) on the **secondary** node.
 The initial replication, or "backfill", will probably still be in progress.
 You can monitor the synchronization process on each Geo node from the **primary** node's **Geo Nodes** dashboard in your browser.

doc/administration/geo/replication/object_storage.md

@@ -33,7 +33,7 @@ whether they are stored on the local filesystem or in object storage.
 
 To enable GitLab replication, you must:
 
-1. Go to **{admin}** **Admin Area >** **{location-dot}** **Geo**.
+1. Go to **Admin Area >** **{location-dot}** **Geo**.
 1. Press **Edit** on the **secondary** node.
 1. Enable the **Allow this secondary node to replicate content on Object Storage**
    checkbox.

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 admin page of the **primary** node. To remove a **secondary** node:
 
-1. Navigate to **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Navigate to **Admin Area >** **{location-dot}** **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/geo/replication/troubleshooting.md

@@ -26,7 +26,7 @@ Before attempting more advanced troubleshooting:
 
 ### Check the health of the **secondary** node
 
-Visit the **primary** node's **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`) in
+Visit the **primary** node's **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`) in
 your browser. We perform the following health checks on each **secondary** node
 to help identify if something is wrong:
 
@@ -132,8 +132,7 @@ Geo finds the current machine's Geo node name in `/etc/gitlab/gitlab.rb` by:
 - Using the `gitlab_rails['geo_node_name']` setting.
 - If that is not defined, using the `external_url` setting.
 
-This name is used to look up the node with the same **Name** in
-**{admin}** **Admin Area >** **{location-dot}** **Geo**.
+This name is used to look up the node with the same **Name** in **Admin Area >** **{location-dot}** **Geo**.
 
 To check if the current machine has a node name that matches a node in the
 database, run the check task:
@@ -840,7 +839,7 @@ If you are able to log in to the **primary** node, but you receive this error
 when attempting to log into a **secondary**, you should check that the Geo
 node's URL matches its external URL.
 
-1. On the primary, visit **{admin}** **Admin Area >** **{location-dot}** **Geo**.
+1. On the primary, visit **Admin Area >** **{location-dot}** **Geo**.
 1. Find the affected **secondary** and click **Edit**.
 1. Ensure the **URL** field matches the value found in `/etc/gitlab/gitlab.rb`
    in `external_url "https://gitlab.example.com"` on the frontend server(s) of

doc/administration/geo/replication/tuning.md

@@ -9,7 +9,7 @@ type: howto
 
 ## Changing the sync capacity values
 
-In the Geo admin page at **{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`),
+In the Geo admin page at **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`),
 there are several variables that can be tuned to improve performance of Geo:
 
 - Repository sync capacity.

doc/administration/geo/replication/version_specific_updates.md

@@ -214,7 +214,7 @@ Replicating over SSH has been deprecated, and support for this option will be
 removed in a future release.
 
 To switch to HTTP/HTTPS replication, log into the **primary** node as an admin and visit
-**{admin}** **Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`). For each **secondary** node listed,
+**Admin Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`). For each **secondary** node listed,
 press the "Edit" button, change the "Repository cloning" setting from
 "SSH (deprecated)" to "HTTP/HTTPS", and press "Save changes". This should take
 effect immediately.

doc/administration/integration/terminal.md

@@ -98,4 +98,4 @@ they will receive a `Connection failed` message.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413) in GitLab 8.17.
 
 Terminal sessions, by default, do not expire.
-You can limit terminal session lifetime in your GitLab instance. To do so, navigate to **{admin}** [**Admin Area > Settings > Web terminal**](../../user/admin_area/settings/index.md#general), and set a `max session time`.
+You can limit terminal session lifetime in your GitLab instance. To do so, navigate to [**Admin Area > Settings > Web terminal**](../../user/admin_area/settings/index.md#general), and set a `max session time`.

doc/administration/monitoring/performance/grafana_configuration.md

@@ -68,7 +68,7 @@ repository.
 After setting up Grafana, you can enable a link to access it easily from the
 GitLab sidebar:
 
-1. Navigate to the **{admin}** **Admin Area > Settings > Metrics and profiling**.
+1. Navigate 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**:
@@ -77,7 +77,7 @@ GitLab sidebar:
    - *Otherwise,* enter the full URL of the Grafana instance.
 1. Click **Save changes**.
 
-GitLab displays your link in the **{admin}** **Admin Area > Monitoring > Metrics Dashboard**.
+GitLab displays your link in the **Admin Area > Monitoring > Metrics Dashboard**.
 
 ## Security Update
 

doc/administration/monitoring/performance/performance_bar.md

@@ -72,7 +72,7 @@ Requests with warnings display `(!)` after their path in the **Request selector*
 The GitLab Performance Bar is disabled by default. To enable it for a given group:
 
 1. Sign in as a user with Administrator [permissions](../../../user/permissions.md).
-1. In the menu bar, click the **{admin}** **Admin Area** icon.
+1. In the menu bar, click **Admin Area**.
 1. Navigate to **{settings}** **Settings > Metrics and profiling**
    (`admin/application_settings/metrics_and_profiling`), and expand the section
    **Profiling - Performance bar**.

doc/administration/monitoring/performance/request_profiling.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 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}** **Admin area**.
+1. In the navigation bar, click **Admin area**.
 1. Navigate to **{monitor}** **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

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}** **Admin Area > Settings > Metrics and profiling**.
+1. Navigate 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/operations/extra_sidekiq_processes.md

@@ -82,7 +82,7 @@ To start multiple processes:
    ```
 
 After the extra Sidekiq processes are added, navigate to
-**{admin}** **Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
+**Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
 
 ![Multiple Sidekiq processes](img/sidekiq-cluster.png)
 

doc/administration/raketasks/project_import_export.md

@@ -46,6 +46,6 @@ Note the following:
   compatible as described in the [Version history](../../user/project/settings/import_export.md#version-history).
 - The project import option must be enabled in
   application settings (`/admin/application_settings/general`) under **Import sources**, which is available
-  under **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+  under **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
 - The exports are stored in a temporary [shared directory](../../development/shared_files.md)
   and are deleted every 24 hours by a specific worker.

doc/administration/raketasks/storage.md

@@ -100,7 +100,7 @@ to project IDs 50 to 100 in an Omnibus GitLab installation:
 sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 ```
 
-You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
+You can monitor the progress in the **Admin Area > Monitoring > Background Jobs** page.
 There is a specific queue you can watch to see how long it will take to finish:
 `hashed_storage:hashed_storage_project_migrate`.
 
@@ -150,7 +150,7 @@ to project IDs 50 to 100 in an Omnibus GitLab installation:
 sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
 ```
 
-You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
+You can monitor the progress in the **Admin Area > Monitoring > Background Jobs** page.
 On the **Queues** tab, you can watch the `hashed_storage:hashed_storage_project_rollback` queue to see how long the process will take to finish.
 
 After it reaches zero, you can confirm every project has been rolled back by running the commands bellow.

doc/ci/runners/README.md

@@ -376,7 +376,7 @@ different places.
 To view the IP address of a shared Runner you must have admin access to
 the GitLab instance. To determine this:
 
-1. Visit **{admin}** **Admin Area > Overview > Runners**.
+1. Visit **Admin Area > Overview > Runners**.
 1. Look for the Runner in the table and you should see a column for **IP Address**.
 
 ![shared Runner IP address](img/shared_runner_ip_address.png)

doc/development/integrations/jenkins.md

@@ -16,7 +16,7 @@ brew services start jenkins
 GitLab does not allow requests to localhost or the local network by default. When running Jenkins on your local machine, you need to enable local access.
 
 1. Log into your GitLab instance as an admin.
-1. Go to **{admin}** **Admin Area > Settings > Network**.
+1. Go to **Admin Area > Settings > Network**.
 1. Expand **Outbound requests** and check the following checkboxes:
 
    - **Allow requests to the local network from web hooks and services**

doc/subscriptions/index.md

@@ -254,7 +254,7 @@ The following table describes details of your subscription for groups:
 
 To view the status of your self-managed subscription, log in to the self-managed instance and go to the **License** page.
 
-  1. Go to **{admin}** **Admin Area**.
+  1. Go to **Admin Area**.
   1. From the left-hand menu, select **License**.
 
 ## Renew your subscription
@@ -386,8 +386,7 @@ You can view the exact JSON payload in the administration panel. To view the pay
 
 Seat Link is enabled by default.
 
-To disable this feature, go to
-**{admin}** **Admin Area > Settings > Metrics and profiling**, uncheck the **Enable Seat Link** checkbox > **Save changes**.
+To disable this feature, go to **Admin Area > Settings > Metrics and profiling**, uncheck the **Enable Seat Link** checkbox > **Save changes**.
 
 To disable Seat Link in an Omnibus GitLab installation, and prevent it from
 being configured in the future through the administration panel, set the following in
@@ -442,7 +441,7 @@ We recommend following these steps during renewal:
 1. Enter the number of [users over license](#users-over-license) in the second box for the user overage incurred in your previous subscription term.
 
    TIP: **Tip:**
-   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on **{admin}** (**Admin Area**) in the top bar, or going to `/admin`.
+   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or going to `/admin`.
 
    The following table describes details of your admin dashboard and renewal terms:
 

doc/topics/autodevops/index.md

@@ -130,7 +130,7 @@ any of the following places:
   [groups](../../user/group/clusters/index.md#base-domain)
 - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
 - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- or as an instance-wide fallback in **{admin}** **Admin Area > Settings** under the
+- or as an instance-wide fallback in **Admin Area > Settings** under the
   **Continuous Integration and Delivery** section
 
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
@@ -216,7 +216,7 @@ To enable or disable Auto DevOps at the group level:
 Even when disabled at the instance level, group owners and project maintainers can still enable
 Auto DevOps at the group and project level, respectively.
 
-1. Go to **{admin}** **Admin Area > Settings > Continuous Integration and Deployment**.
+1. Go to **Admin Area > Settings > Continuous Integration and Deployment**.
 1. Select **Default to Auto DevOps pipeline for all projects** to enable it.
 1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain),
    for Auto Deploy and Auto Review Apps to use.

doc/user/admin_area/abuse_reports.md

@@ -16,7 +16,7 @@ reports in the Admin Area.
 
 To receive notifications of new abuse reports by e-mail, follow these steps:
 
-1. Select **{admin}** **Admin Area > Settings >  Reporting**.
+1. Select **Admin Area > Settings >  Reporting**.
 1. Expand the **Abuse reports** section.
 1. Provide an email address.
 

doc/user/admin_area/index.md

@@ -65,7 +65,7 @@ The following topics document the **{overview}** **Overview** section of the Adm
 
 You can administer all projects in the GitLab instance from the Admin Area's Projects page.
 
-To access the Projects page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Projects**.
+To access the Projects page, go to **Admin Area >** **{overview}** **Overview > Projects**.
 
 Click the **All**, **Private**, **Internal**, or **Public** tab to list only projects of that
 criteria.
@@ -105,7 +105,7 @@ You can combine the filter options. For example, to list only public projects wi
 
 You can administer all users in the GitLab instance from the Admin Area's Users page.
 
-To access the Users page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Users**.
+To access the Users page, go to **Admin Area >** **{overview}** **Overview > Users**.
 
 To list users matching a specific criteria, click on one of the following tabs on the **Users** page:
 
@@ -157,7 +157,7 @@ reflected in the statistics.
 
 You can administer all groups in the GitLab instance from the Admin Area's Groups page.
 
-To access the Groups page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Groups**.
+To access the Groups page, go to **Admin Area >** **{overview}** **Overview > Groups**.
 
 For each group, the page displays their name, description, size, number of projects in the group,
 number of members, and whether the group is private, internal, or public. To edit a group, click
@@ -176,7 +176,7 @@ To [Create a new group](../group/index.md#create-a-new-group) click **New group*
 
 You can administer all jobs in the GitLab instance from the Admin Area's Jobs page.
 
-To access the Jobs page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Jobs**.
+To access the Jobs page, go to **Admin Area >** **{overview}** **Overview > Jobs**.
 
 All jobs are listed, in descending order of job ID.
 
@@ -201,7 +201,7 @@ For each job, the following details are listed:
 You can administer all Runners in the GitLab instance from the Admin Area's **Runners** page. See
 [GitLab Runner](https://docs.gitlab.com/runner/) for more information on Runner itself.
 
-To access the **Runners** page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Runners**.
+To access the **Runners** page, go to **Admin Area >** **{overview}** **Overview > Runners**.
 
 The **Runners** page features:
 
@@ -247,7 +247,7 @@ You can also edit, pause, or remove each Runner.
 You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers**
 page. For more details, see [Gitaly](../../administration/gitaly/index.md).
 
-To access the **Gitaly Servers** page, go to **{admin}** **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
+To access the **Gitaly Servers** page, go to **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
 
 For each Gitaly server, the following details are listed:
 

doc/user/admin_area/merge_requests_approvals.md

@@ -15,7 +15,7 @@ if they are enabled at an instance level.
 
 To enable merge request approval rules for an instance:
 
-1. Navigate to **{admin}** **Admin Area >** **{push-rules}** **Push Rules** and expand **Merge
+1. Navigate to **Admin Area >** **{push-rules}** **Push Rules** and expand **Merge
    requests approvals**.
 1. Set the required rule.
 1. Click **Save changes**.

doc/user/admin_area/settings/index.md

@@ -4,7 +4,7 @@ type: index
 
 # Admin Area settings **(CORE ONLY)**
 
-As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **{admin}** **Admin Area > Settings**.
+As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **Admin Area > Settings**.
 
 The admin area is not accessible on GitLab.com, and settings can only be changed by the
 GitLab.com administrators. See the [GitLab.com settings](../../gitlab_com/index.md)
@@ -12,8 +12,7 @@ documentation for all current settings and limits on the GitLab.com instance.
 
 ## General
 
-Access the default page for admin area settings by navigating to
-**{admin}** **Admin Area > Settings > General**:
+Access the default page for admin area settings by navigating to **Admin Area > Settings > General**:
 
 | Option | Description |
 | ------ | ----------- |
@@ -96,7 +95,7 @@ Access the default page for admin area settings by navigating to
 
 | Option | Description |
 | ------ | ----------- |
-| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **{admin}** **Admin Area >** **{location-dot}** **Geo >** **{settings}** **Settings**, and will no longer be available at **{admin}** **Admin Area >** **{settings}** **Settings >** **{location-dot}** **Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
+| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **Admin Area >** **{location-dot}** **Geo >** **{settings}** **Settings**, and will no longer be available at **Admin Area >** **{settings}** **Settings >** **{location-dot}** **Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
 
 ## Preferences
 

doc/user/group/settings/import_export.md

@@ -21,7 +21,7 @@ See also:
 
 To enable GitLab import/export:
 
-1. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+1. Navigate to **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
 1. Scroll to **Import sources**
 1. Enable desired **Import sources**
 

doc/user/project/clusters/add_eks_clusters.md

@@ -58,7 +58,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
    `Account ID` and `External ID` to use in the next step.

doc/user/project/clusters/add_gke_clusters.md

@@ -48,7 +48,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Under the **Create new cluster** tab, click **Google GKE**.
 1. Connect your Google account if you haven't done already by clicking the

doc/user/project/clusters/add_remove_clusters.md

@@ -142,7 +142,7 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Click the **Create new cluster** tab.
 1. Click either **Amazon EKS** or **Google GKE**, and follow the instructions for your desired service:
@@ -164,7 +164,7 @@ To add a Kubernetes cluster to your project, group, or instance:
 1. Navigate to your:
    1. Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    1. Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   1. **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   1. **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Click the **Add existing cluster** tab and fill in the details:
    1. **Kubernetes cluster name** (required) - The name you wish to give the cluster.
@@ -331,7 +331,7 @@ a new cluster or added an existing one. To disable Kubernetes cluster integratio
 1. Navigate to your:
    - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
    - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **{admin}** **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
+   - **Admin Area >** **{cloud-gear}** **Kubernetes** page, for an instance-level cluster.
 1. Click on the name of the cluster.
 1. Click the **GitLab Integration** toggle.
 1. Click **Save changes**.

doc/user/project/deploy_keys/index.md

@@ -121,7 +121,7 @@ repositories to secure, shared services, such as CI/CD.
 
 Instance administrators can add public deploy keys:
 
-1. Go to **Admin Area** (**{admin}**) **> Deploy Keys**.
+1. Go to **Admin Area > Deploy Keys**.
 1. Click on **New deploy key**.
 
    Make sure your new key has a meaningful title, as it is the primary way for project

doc/user/project/repository/branches/index.md

@@ -66,7 +66,7 @@ By default, when you create a new project in GitLab, the initial branch is calle
 For self-managed instances, a GitLab administrator can customize the initial branch name to something
 else. This way, every new project created from then on will start from the custom branch name rather than `master`. To do so:
 
-1. Go to the **{admin}** **Admin Area > Settings > Repository** and expand **Default initial
+1. Go to the **Admin Area > Settings > Repository** and expand **Default initial
    branch name**.
 1. Change the default initial branch to a custom name of your choice.
 1. **Save Changes**.

doc/user/project/settings/import_export.md

@@ -24,7 +24,7 @@ See also:
 
 To set up a project import/export:
 
-  1. Navigate to **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
+  1. Navigate to **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
   1. Scroll to **Import sources**
   1. Enable desired **Import sources**