Remove inline location-dot 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 Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
+Navigate 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 >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
+Navigate 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 >** **{location-dot}** **Geo** dashboard on the **primary** node, and
+Navigate 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:
 

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 >** **{location-dot}** **Geo** dashboard on the **secondary** node to
+Navigate 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
@@ -136,7 +136,7 @@ This [content was moved to another location](background_verification.md).
 ### Notify users of scheduled maintenance
 
 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
+message. You can check under **Admin Area > 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
@@ -194,7 +194,7 @@ access to the **primary** node during the maintenance window.
    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 Area >** **{location-dot}** **Geo** and wait for the
+1. On the **primary** node, navigate to **Admin Area > 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.

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 Area >** **{location-dot}** **Geo**
+1. Visit the **primary** node's **Admin Area > Geo**
    (`/admin/geo/nodes`) in your browser.
 1. Click the **New node** button.
    ![Add secondary node](img/adding_a_secondary_node.png)
@@ -264,7 +264,7 @@ method to be enabled. Navigate to **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 Area >** **{location-dot}** **Geo**
+**primary** node. Visit the **secondary** node's **Admin Area > 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 Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Go to **Admin Area > 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 Area >** **{location-dot}** **Geo**
+To verify Container Registry replication is working, go to **Admin Area > 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 Area >** **{location-dot}** **Geo**.
+1. Go to **Admin Area > 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 Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`).
+1. Navigate 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/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 Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`) in
+Visit the **primary** node's **Admin Area > 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,7 +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 Area >** **{location-dot}** **Geo**.
+This name is used to look up the node with the same **Name** in **Admin Area > Geo**.
 
 To check if the current machine has a node name that matches a node in the
 database, run the check task:
@@ -839,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 Area >** **{location-dot}** **Geo**.
+1. On the primary, visit **Admin Area > 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 Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`),
+In the Geo admin page at **Admin Area > 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 Area >** **{location-dot}** **Geo** (`/admin/geo/nodes`). For each **secondary** node listed,
+**Admin Area > 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/user/admin_area/settings/index.md

@@ -95,7 +95,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 
 | Option | Description |
 | ------ | ----------- |
-| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **Admin Area >** **{location-dot}** **Geo > Settings**, and will no longer be available at **Admin Area > 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 > Geo > Settings**, and will no longer be available at **Admin Area > Settings > Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
 
 ## Preferences