Fix vale admin warnings

Update the word admin to administrator and
similar, as needed.

doc/administration/auditor_users.md

@@ -19,7 +19,7 @@ snippets, and create milestones on their groups, while also having read-only
 access to all projects on the server to which they haven't been explicitly
 [given access](../user/permissions.md).
-The Auditor role is _not_ a read-only version of the Admin role. Auditor users
+The `Auditor` access level is _not_ a read-only version of the `Admin` access level. Auditor users
 can't access the project or group settings pages, or the Admin Area.
 Assuming you have signed in as an Auditor user:
@@ -33,7 +33,7 @@ Assuming you have signed in as an Auditor user:
   have the same access as their given [permissions](../user/permissions.md).
   For example, if they were added as a Developer, they can push commits or
   comment on issues.
-- The Auditor can't view the Admin Area, or perform any admin actions.
+- The Auditor can't view the Admin Area, or perform any administration actions.
 For more information about what an Auditor can or can't do, see the
 [Permissions and restrictions of an Auditor user](#permissions-and-restrictions-of-an-auditor-user)
@@ -47,7 +47,7 @@ helpful:
 - Your compliance department wants to run tests against the entire GitLab base
   to ensure users are complying with password, credit card, and other sensitive
   data policies. With Auditor users, this can be achieved very without having
-  to give them user admin rights or using the API to add them to all projects.
+  to give them user administration rights or using the API to add them to all projects.
 - If particular users need visibility or access to most of all projects in
   your GitLab instance, instead of manually adding the user to all projects,
   you can create an Auditor user and then share the credentials with those users
@@ -83,7 +83,7 @@ instance, with the following permissions and restrictions:
 - Can read all files in a repository
 - Can read issues and MRs
 - Can read project snippets
-- Cannot be Admin and Auditor at the same time
+- Cannot be Administrator and Auditor at the same time
 - Cannot access the Admin Area
 - In a group or project they're not a member of:
   - Cannot access project settings

doc/administration/auth/ldap/index.md

@@ -647,8 +647,8 @@ like the following.
 NOTE:
 Administrators are not synced unless `group_base` is also
-specified alongside `admin_group`. Also, only specify the CN of the admin
-group, as opposed to the full DN.
+specified alongside `admin_group`. Also, only specify the CN of the `admin_group`,
+as opposed to the full DN.
 **Omnibus configuration**
@@ -698,7 +698,7 @@ When enabled, the following applies:
 To enable it you need to:
 1. [Enable LDAP](#configuration)
-1. Navigate to **(admin)** **Admin Area > Settings -> Visibility and access controls**.
+1. Navigate to **Admin Area > Settings -> Visibility and access controls**.
 1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
 ### Adjusting LDAP group sync schedule **(PREMIUM SELF)**

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

@@ -148,11 +148,11 @@ We have a workaround, based on toggling the access level of affected users:
 1. As an administrator, go to **Admin Area > Overview > Users**.
 1. Select the name of the affected user.
 1. In the user's administrative page, press **Edit** on the top right of the page.
-1. Change the user's access level from **Regular** to **Admin** (or vice versa),
+1. Change the user's access level from `Regular` to `Admin` (or vice versa),
    and press **Save changes** at the bottom of the page.
 1. Press **Edit** on the top right of the user's profile page
    again.
-1. Restore the user's original access level (**Regular** or **Admin**)
+1. Restore the user's original access level (`Regular` or `Admin`)
    and press **Save changes** again.
 The user should now be able to sign in.
@@ -191,7 +191,7 @@ have to be taken here:
   will associate this profile to the LDAP identity.
 The user can do either of these steps [in their
-profile](../../../user/profile/index.md#user-profile) or an admin can do it.
+profile](../../../user/profile/index.md#user-profile) or an administrator can do it.
 #### Debug LDAP user filter
@@ -358,17 +358,17 @@ the rails console.
    UIDs here should match the 'Identifier' from the LDAP identity checked earlier. If it doesn't,
    the user does not appear to be in the LDAP group.
-#### Admin privileges not granted
+#### Administrator privileges not granted
 When [Administrator sync](index.md#administrator-sync) has been configured
-but the configured users aren't granted the correct admin privileges, confirm
+but the configured users aren't granted the correct administrator privileges, confirm
 the following are true:
 - A [`group_base` is also configured](index.md#group-sync).
 - The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
 - This CN falls under the scope of the configured `group_base`.
 - The members of the `admin_group` have already signed into GitLab with their LDAP
-  credentials. GitLab will only grant this admin access to the users whose
+  credentials. GitLab will only grant this administrator access to the users whose
   accounts are already connected to LDAP.
 If all the above are true and the users are still not getting access, [run a manual
@@ -477,7 +477,7 @@ this line will indicate the sync is finished:
 Finished syncing admin users for 'ldapmain' provider
 ```
-If [admin sync](index.md#administrator-sync) is not configured, you'll see a message
+If [administrator sync](index.md#administrator-sync) is not configured, you'll see a message
 stating as such:
 ```shell

doc/administration/auth/okta.md

@@ -16,7 +16,7 @@ The following documentation enables Okta as a SAML provider.
 The following guidance is based on this Okta article, on adding a [SAML Application with an Okta Developer account](https://support.okta.com/help/s/article/Why-can-t-I-add-a-SAML-Application-with-an-Okta-Developer-account?language=en_US):
-1. On Okta admin section, make sure to select Classic UI view in the top left corner. From there, choose to **Add an App**.
+1. In the Okta admin section, make sure to select Classic UI view in the top left corner. From there, choose to **Add an App**.
 1. When the app screen comes up you see another button to **Create an App** and
    choose SAML 2.0 on the next screen.
 1. Optionally you can add a logo

doc/administration/compliance.md

@@ -18,12 +18,12 @@ relevant compliance standards.
 |**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab|Free+||Instance|
 |**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Free+|✓|Instance, Group, Project|
 |**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Free+||Instance|
-|**[Email all users of a project, group, or entire server](../tools/email.md)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Premium+||Instance|
+|**[Email all users of a project, group, or entire server](../tools/email.md)**<br>An administrator can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Premium+||Instance|
 |**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system.|Premium+||Instance|
 |**[Lock project membership to group](../user/group/index.md#member-lock)**<br>Group owners can prevent new members from being added to projects within a group.|Premium+|✓|Group|
-|**[LDAP group sync](auth/ldap/index.md#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Premium+||Instance|
+|**[LDAP group sync](auth/ldap/index.md#group-sync)**<br>GitLab Enterprise Edition gives administrators the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Premium+||Instance|
 |**[LDAP group sync filters](auth/ldap/index.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||Instance|
-|**[Audit events](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit events system, so you can control, analyze, and track every change.|Premium+|✓|Instance, Group, Project|
+|**[Audit events](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives administrators the ability to view any modifications made within the GitLab server in an advanced audit events system, so you can control, analyze, and track every change.|Premium+|✓|Instance, Group, Project|
 |**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||Instance|
 |**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. |Ultimate||Instance|
 |**Separation of Duties using [Protected branches](../user/project/protected_branches.md#protected-branches-approval-by-code-owners) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-cicd-configuration-path)**<br> GitLab Premium users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles.|Premium+|✓|Project|

doc/administration/geo/disaster_recovery/background_verification.md

@@ -146,8 +146,8 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
    **Edit** button:
    ![Projects dashboard](img/checksum-differences-admin-projects.png)
-1. On the project admin page get the **Gitaly storage name**, and **Gitaly relative path**:
-   ![Project admin page](img/checksum-differences-admin-project-page.png)
+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
    (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`

doc/administration/geo/replication/configuration.md

@@ -229,7 +229,7 @@ keys must be manually replicated to the **secondary** node.
    gitlab-rake gitlab:geo:check
    ```
-Once added to the admin panel and restarted, the **secondary** node will automatically start
+Once added to the Geo administration page and restarted, the **secondary** node will automatically start
 replicating missing data from the **primary** node in a process known as **backfill**.
 Meanwhile, the **primary** node will start to notify each **secondary** node of any changes, so
 that the **secondary** node can act on those notifications immediately.
@@ -299,7 +299,7 @@ Currently, this is what is synced:
 ## Selective synchronization
-Geo supports selective synchronization, which allows admins to choose
+Geo supports selective synchronization, which allows administrators to choose
 which projects should be synchronized by **secondary** nodes.
 A subset of projects can be chosen, either by group or by storage shard. The
 former is ideal for replicating data belonging to a subset of users, while the

doc/administration/geo/replication/datatypes.md

@@ -70,7 +70,7 @@ Communication is done via Gitaly's own gRPC API. There are three possible ways o
 - Using regular Git clone/fetch from one Geo node to another (with special authentication).
 - Using repository snapshots (for when the first method fails or repository is corrupt).
-- Manual trigger from the Admin UI (a combination of both of the above).
+- Manual trigger from the Admin Area (a combination of both of the above).
 Each project can have at most 3 different repositories:

doc/administration/geo/replication/remove_geo_node.md

@@ -7,13 +7,13 @@ type: howto
 # Removing secondary Geo nodes **(PREMIUM SELF)**
-**Secondary** nodes can be removed from the Geo cluster using the Geo admin page of the **primary** node. To remove a **secondary** node:
+**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. Click the **Remove** button for the **secondary** node you want to remove.
 1. Confirm by clicking **Remove** when the prompt appears.
-Once removed from the Geo admin page, you must stop and uninstall the **secondary** node:
+Once removed from the Geo administration page, you must stop and uninstall the **secondary** node:
 1. On the **secondary** node, stop GitLab:

doc/administration/geo/replication/security_review.md

@@ -78,7 +78,7 @@ from [owasp.org](https://owasp.org/).
 ### Who has administrative capabilities in the application?
 - Nothing Geo-specific. Any user where `admin: true` is set in the database is
-  considered an admin with super-user privileges.
+  considered an administrator with super-user privileges.
 - See also: [more granular access control](https://gitlab.com/gitlab-org/gitlab/-/issues/18242)
   (not Geo-specific).
 - Much of Geo’s integration (database replication, for instance) must be

doc/administration/geo/replication/troubleshooting.md

@@ -219,7 +219,7 @@ sudo gitlab-rake gitlab:geo:check
    ```
    - Ensure that you have added the secondary node in the Admin Area of the **primary** node.
-   - Ensure that you entered the `external_url` or `gitlab_rails['geo_node_name']` when adding the secondary node in the admin are of the **primary** node.
+   - Ensure that you entered the `external_url` or `gitlab_rails['geo_node_name']` when adding the secondary node in the Admin Area of the **primary** node.
    - Prior to GitLab 12.4, edit the secondary node in the Admin Area of the **primary** node and ensure that there is a trailing `/` in the `Name` field.
 1. Check returns `Exception: PG::UndefinedTable: ERROR:  relation "geo_nodes" does not exist`
@@ -780,7 +780,7 @@ node's URL matches its external URL.
 ## Fixing common errors
-This section documents common errors reported in the Admin UI and how to fix them.
+This section documents common errors reported in the Admin Area and how to fix them.
 ### Geo database configuration file is missing

doc/administration/geo/replication/tuning.md

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

doc/administration/index.md

@@ -170,7 +170,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 ## Continuous Integration settings
 - [Enable/disable GitLab CI/CD](../ci/enable_or_disable_ci.md#site-wide-admin-setting): Enable or disable GitLab CI/CD for your instance.
-- [GitLab CI/CD admin settings](../user/admin_area/settings/continuous_integration.md): Enable or disable Auto DevOps site-wide and define the artifacts' max size and expiration time.
+- [GitLab CI/CD administration settings](../user/admin_area/settings/continuous_integration.md): Enable or disable Auto DevOps site-wide and define the artifacts' max size and expiration time.
 - [External Pipeline Validation](external_pipeline_validation.md): Enable, disable and configure external pipeline validation.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job logs](job_logs.md): Information about the job logs.

doc/administration/job_artifacts.md

@@ -368,7 +368,7 @@ steps below.
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 If the `expire` directive is not set explicitly in your pipeline, artifacts expire per the
-default artifacts expiration setting, which you can find in the [CI/CD Admin settings](../user/admin_area/settings/continuous_integration.md).
+default artifacts expiration setting, which you can find in the [CI/CD Administration settings](../user/admin_area/settings/continuous_integration.md).
 ## Validation for dependencies

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -19,7 +19,7 @@ specifically created for visualizing and configuring the monitoring of your
 GitLab instance.
 All administrators at the time of creation of the project and group are
-added as maintainers of the group and project, and as an admin, you can
+added as maintainers of the group and project, and as an administrator, you can
 add new members to the group to give them maintainer access to the project.
 This project is used to self monitor your GitLab instance. The metrics dashboard
@@ -94,22 +94,22 @@ You can add custom metrics in the self monitoring project by:
 There is [a bug](https://gitlab.com/gitlab-org/gitlab/-/issues/208676) which causes
 project creation to fail with the following error (which appears in the log file)
-when the first admin user is an
+when the first administrator user is an
 [external user](../../../user/permissions.md#external-users):
 ```plaintext
 Could not create instance administrators group. Errors: ["You don’t have permission to create groups."]
 ```
-Run the following in a Rails console to check if the first admin user is an external user:
+Run the following in a Rails console to check if the first administrator user is an external user:
 ```ruby
 User.admins.active.first.external?
 ```
-If this returns true, the first admin user is an external user.
+If this returns true, the first administrator user is an external user.
 If you face this issue, you can temporarily
-[make the admin user a non-external user](../../../user/permissions.md#external-users)
+[make the administrator user a non-external user](../../../user/permissions.md#external-users)
 and then try to create the project.
-Once the project is created, the admin user can be changed back to an external user.
+Once the project is created, the administrator user can be changed back to an external user.

doc/administration/monitoring/performance/performance_bar.md

@@ -71,7 +71,7 @@ Requests with warnings display `(!)` after their path in the **Request selector*
 ![Request selector showing dropdown](img/performance_bar_request_selector_warning_expanded.png)
-## Enable the Performance Bar via the Admin panel
+## Enable the Performance Bar via the Admin Area
 The GitLab Performance Bar is disabled by default. To enable it for a given group:

doc/administration/operations/fast_ssh_key_lookup.md

@@ -224,5 +224,5 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 GitLab supports `authorized_keys` database lookups with [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux).
 Because the SELinux policy is static, GitLab doesn't support the ability to change
-internal Unicorn ports at the moment. Admins would have to create a special `.te`
+internal Unicorn ports at the moment. Administrators would have to create a special `.te`
 file for the environment, since it isn't generated dynamically.

doc/administration/read_only_gitlab.md

@@ -68,7 +68,7 @@ the database is read-only:
 1. Take a [GitLab backup](../raketasks/backup_restore.md#back-up-gitlab)
    in case things don't go as expected.
-1. Enter PostgreSQL on the console as an admin user:
+1. Enter PostgreSQL on the console as an administrator user:
     ```shell
     sudo \

doc/administration/repository_checks.md

@@ -12,8 +12,8 @@ type: reference
 Git has a built-in mechanism, [`git fsck`](https://git-scm.com/docs/git-fsck), to verify the
 integrity of all data committed to a repository. GitLab administrators
 can trigger such a check for a project via the project page under the
-admin panel. The checks run asynchronously so it may take a few minutes
-before the check result is visible on the project admin page. If the
+Admin Area. The checks run asynchronously so it may take a few minutes
+before the check result is visible on the project Admin Area. If the
 checks failed you can see their output on in the
 [`repocheck.log` file.](logs.md#repochecklog)
@@ -31,8 +31,7 @@ failures can be found at `/admin/projects?last_repository_check_failed=1`.
 ## Disabling periodic checks
-You can disable the periodic checks on the **Settings** page of the admin
-panel.
+You can disable the periodic checks on the **Settings** page of the Admin Area.
 ## What to do if a check failed

doc/administration/static_objects_external_storage.md

@@ -70,7 +70,7 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
    - `ORIGIN_HOSTNAME`: the hostname of your GitLab installation.
    - `STORAGE_TOKEN`: any arbitrary secure token. You can get a token by running
-     `pwgen -cn1 64` on a UNIX machine. Save this token for the admin panel, as
+     `pwgen -cn1 64` on a UNIX machine. Save this token for the Admin Area, as
      described in the [configuring](#configuring) section.
      ```javascript