Add latest changes from gitlab-org/gitlab@master

13 files changed, 19 insertions, 19 deletions

diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 63dca444dd4..11117e8a74c 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -13,7 +13,7 @@ GitLab supports authentication using smartcards.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33669) in GitLab 12.6.
 
-By default, existing users can continue to log in with a username and password when smartcard
+By default, existing users can continue to sign in with a username and password when smartcard
 authentication is enabled.
 
 To force existing users to use only smartcard authentication,
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 0ccde2c66e4..60101f5af8e 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -233,7 +233,7 @@ At this point, your **secondary** site contains an up-to-date copy of everything
 
 ## Promote the **secondary** site
 
-After the replication is finished, [promote the **secondary** site to a **primary** site](index.md). This process causes a brief outage on the **secondary** site, and users may need to log in again. If you follow the steps correctly, the old primary Geo site should still be disabled and user traffic should go to the newly-promoted site instead.
+After the replication is finished, [promote the **secondary** site to a **primary** site](index.md). This process causes a brief outage on the **secondary** site, and users may need to sign in again. If you follow the steps correctly, the old primary Geo site should still be disabled and user traffic should go to the newly-promoted site instead.
 
 When the promotion is completed, the maintenance window is over, and your new **primary** site now
 begins to diverge from the old one. If problems do arise at this point, failing
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
index 2eca24d7b74..8c18aaa944d 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
@@ -121,7 +121,7 @@ follow these steps to avoid unnecessary data loss:
       ```
 
       From this point, users are unable to view their data or make changes on the
-      **primary** site. They are also unable to log in to the **secondary** site.
+      **primary** site. They are also unable to sign in to the **secondary** site.
       However, existing sessions must work for the remainder of the maintenance period, and
       so public data is accessible throughout.
 
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
index 51926b11970..f9d99095951 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
@@ -106,7 +106,7 @@ follow these steps to avoid unnecessary data loss:
       ```
 
       From this point, users are unable to view their data or make changes on the
-      **primary** site. They are also unable to log in to the **secondary** site.
+      **primary** site. They are also unable to sign in to the **secondary** site.
       However, existing sessions need to work for the remainder of the maintenance period, and
       so public data is accessible throughout.
 
diff --git a/doc/administration/geo/replication/disable_geo.md b/doc/administration/geo/replication/disable_geo.md
index 3fa65b0183e..3230a92136f 100644
--- a/doc/administration/geo/replication/disable_geo.md
+++ b/doc/administration/geo/replication/disable_geo.md
@@ -63,7 +63,7 @@ Geo node in a PostgreSQL console (`sudo gitlab-psql`):
 
 ## Remove Geo-related configuration
 
-1. For each node on your primary Geo site, SSH into the node and log in as root:
+1. For each node on your primary Geo site, SSH into the node and sign in as root:
 
    ```shell
    sudo -i
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index f4adcccd384..81afcc19bb1 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -69,6 +69,6 @@ That's totally fine. We use HTTP(s) to fetch repository changes from the **prima
 
 Yes. See [Container Registry for a **secondary** site](container_registry.md).
 
-## Can you log in to a secondary site?
+## Can you sign in to a secondary site?
 
 Yes, but secondary sites receive all authentication data (like user accounts and logins) from the primary instance. This means you are re-directed to the primary for authentication and then routed back.
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index ca3ce28ea4b..5be7d40890c 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -53,7 +53,7 @@ you already have a working GitLab instance that is in-use, it can be used as a
 
 The second GitLab site serves as the Geo **secondary** site. Again, use the
 [GitLab reference architectures documentation](../../reference_architectures/index.md) to set this up.
-It's a good idea to log in and test it. However, be aware that its data is
+It's a good idea to sign in and test it. However, be aware that its data is
 wiped out as part of the process of replicating from the **primary** site.
 
 ## Configure a GitLab site to be the Geo **primary** site
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index ef4df800126..c794b8ef219 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -16,14 +16,14 @@ You must use a [GitLab Premium](https://about.gitlab.com/pricing/) license or hi
 but you only need one license for all the sites.
 
 WARNING:
-The steps below should be followed in the order they appear. **Make sure the GitLab version is the same on all sites. Do not create an account or log in to the new secondary.**
+The steps below should be followed in the order they appear. **Make sure the GitLab version is the same on all sites. Do not create an account or sign in to the new secondary.**
 
 ## Using Omnibus GitLab
 
 If you installed GitLab using the Omnibus packages (highly recommended):
 
 1. Confirm the [requirements for running Geo](../index.md#requirements-for-running-geo) are met.
-1. [Install GitLab Enterprise Edition](https://about.gitlab.com/install/) on the nodes that serve as the **secondary** site. **Do not create an account or log in** to the new **secondary** site. The **GitLab version must match** across primary and secondary sites.
+1. [Install GitLab Enterprise Edition](https://about.gitlab.com/install/) on the nodes that serve as the **secondary** site. **Do not create an account or sign in** to the new **secondary** site. The **GitLab version must match** across primary and secondary sites.
 1. [Add the GitLab License](../../../user/admin_area/license.md) on the **primary** site to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
 1. [Confirm network connectivity](../index.md#firewall-rules) between the **primary** and **secondary** site.
 1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
diff --git a/doc/administration/integration/kroki.md b/doc/administration/integration/kroki.md
index 6355d1a8c22..aa029be90e7 100644
--- a/doc/administration/integration/kroki.md
+++ b/doc/administration/integration/kroki.md
@@ -54,7 +54,7 @@ read the [Kroki installation](https://docs.kroki.io/kroki/setup/install/#_images
 ## Enable Kroki in GitLab
 
 You need to enable Kroki integration from Settings under Admin Area.
-To do that, log in with an administrator account and follow these steps:
+To do that, sign in with an administrator account and follow these steps:
 
 1. On the top bar, select **Main menu > Admin**.
 1. Go to **Settings > General**.
diff --git a/doc/administration/maintenance_mode/index.md b/doc/administration/maintenance_mode/index.md
index ccba5da3a15..12f3c4c1cc3 100644
--- a/doc/administration/maintenance_mode/index.md
+++ b/doc/administration/maintenance_mode/index.md
@@ -82,7 +82,7 @@ them to disable Maintenance Mode after it's been enabled.
 
 ### Authentication
 
-All users can log in and out of the GitLab instance but no new users can be created.
+All users can sign in and out of the GitLab instance but no new users can be created.
 
 If there are [LDAP syncs](../auth/ldap/index.md) scheduled for that time, they fail since user creation is disabled. Similarly, [user creations based on SAML](../../integration/saml.md#general-setup) fail.
 
@@ -113,9 +113,9 @@ For most JSON requests, `POST`, `PUT`, `PATCH`, and `DELETE` are blocked, and th
 |:----:|:--------------------------------------:|:----:|
 | `POST` | `/admin/application_settings/general` | To allow updating application settings in the administrator UI |
 | `PUT`  | `/api/v4/application/settings` | To allow updating application settings with the API |
-| `POST` | `/users/sign_in` | To allow users to log in. |
-| `POST` | `/users/sign_out`| To allow users to log out. |
-| `POST` | `/oauth/token` | To allow users to log in to a Geo secondary for the first time. |
+| `POST` | `/users/sign_in` | To allow users to sign in. |
+| `POST` | `/users/sign_out`| To allow users to sign out. |
+| `POST` | `/oauth/token` | To allow users to sign in to a Geo secondary for the first time. |
 | `POST` | `/admin/session`, `/admin/session/destroy` | To allow [Admin Mode for GitLab administrators](https://gitlab.com/groups/gitlab-org/-/epics/2158) |
 | `POST` | Paths ending with `/compare`| Git revision routes. |
 | `POST` | `.git/git-upload-pack` | To allow Git pull/clone. |
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 8d3ec0af479..a003a3f25bc 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -81,7 +81,7 @@ GitLab displays your link in the **Main menu > Admin > Monitoring > Metrics Dash
 When setting up Grafana through the process above, no scope shows in the screen at
 **Main menu > Admin > Applications > GitLab Grafana**. However, the `read_user` scope is
 required and is provided to the application automatically. Setting any scope other than
-`read_user` without also including `read_user` leads to this error when you try to log in using
+`read_user` without also including `read_user` leads to this error when you try to sign in using
 GitLab as the OAuth provider:
 
 ```plaintext
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index cd32ef6cb99..401451d58b4 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -74,7 +74,7 @@ $ ssh-add -L | grep cert | ssh-keygen -L -f -
 ```
 
 Technically that's not strictly true, for example, it could be
-`prod-aearnfjord` if it's a SSH certificate you'd normally log in to
+`prod-aearnfjord` if it's a SSH certificate you'd normally sign in to
 servers as the `prod-aearnfjord` user, but then you must specify your
 own `AuthorizedPrincipalsCommand` to do that mapping instead of using
 our provided default.
@@ -108,7 +108,7 @@ Where `{KEY_ID}` is the `%i` argument passed to the script
 
 You need to customize the `sshUsers` part of that. It should be
 some principal that's guaranteed to be part of the key for all users
-who can log in to GitLab, or you must provide a list of principals,
+who can sign in to GitLab, or you must provide a list of principals,
 one of which is present for the user, for example:
 
 ```plaintext
@@ -123,7 +123,7 @@ into multiple lines of `authorized_keys` output, as described in the
 `AuthorizedPrincipalsFile` documentation in `sshd_config(5)`.
 
 Normally when using the `AuthorizedKeysCommand` with OpenSSH the
-principal is some "group" that's allowed to log into that
+principal is some "group" that's allowed to sign in to that
 server. However with GitLab it's only used to appease OpenSSH's
 requirement for it, we effectively only care about the "key ID" being
 correct. Once that's extracted GitLab enforces its own ACLs for
diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md
index 3fd8cb29fa6..b0dc995c684 100644
--- a/doc/administration/timezone.md
+++ b/doc/administration/timezone.md
@@ -27,7 +27,7 @@ This Rake task does not list time zones in TZInfo format required by Omnibus Git
 
 GitLab defaults its time zone to UTC. It has a global time zone configuration parameter in `/etc/gitlab/gitlab.rb`.
 
-To obtain a list of time zones, log in to your GitLab application server and run a command that generates a list of time zones in TZInfo format for the server. For example, install `timedatectl` and run `timedatectl list-timezones`.
+To obtain a list of time zones, sign in to your GitLab application server and run a command that generates a list of time zones in TZInfo format for the server. For example, install `timedatectl` and run `timedatectl list-timezones`.
 
 To update, add the time zone that best applies to your location. For example: