docs: standardize multi-factor spelling and related string updates (#8752)

- **docs: s/Secondfactor/Second factor/**
- **docs: s/IDP/IdP/**
- **docs: s/Hardwaretokens/Hardware tokens/**
- **docs: standardize multi-factor vs multi factor vs multifactor**

# Which Problems Are Solved

 - English strings are improved

# How the Problems Are Solved

 - With better strings

---------

Co-authored-by: Fabi <fabienne@zitadel.com>

docs/docs/concepts/architecture/secrets.md

@@ -92,7 +92,7 @@ Some secrets cannot be hashed because they need to be used in their raw form. Th
 
 - Federation
   - Client Secrets of Identity Providers (IdPs)
-- Multi Factor Authentication
+- Multi-factor Authentication
   - TOTP Seed Values
 - Validation Secrets
   - Verifying contact information like eMail, Phonenumbers

docs/docs/guides/integrate/login-ui/_list-mfa-options.mdx

@@ -14,7 +14,7 @@ curl --request GET \
 ```
 
 Response Example:
-The relevant part for the list is the second factor and multi factor list.
+The relevant part for the list is the second factor and multi-factor list.
 
 ```bash
 {

docs/docs/guides/integrate/login-ui/mfa.mdx

@@ -30,7 +30,7 @@ ZITADEL supports different Methods:
 
 ### Start TOTP Registration
 
-The user has selected to setup Time-based One-Time-Password (TOTP).
+The user has selected to setup Time-based One-Time Password (TOTP).
 To show the user the QR to register TOTP with his Authenticator App like Google/Microsoft Authenticator or Authy you have to start the registration on the ZITADEL API.
 Generate the QR Code with the URI from the response.
 For users that do not have a QR Code reader make sure to also show the secret, to enable manual configuration.
@@ -485,7 +485,7 @@ You have successfully registered a new U2F to the user.
 
 ### Check User
 
-To be able to check the Universal-Second-Factor (U2F) you need a user check and a webAuthN challenge.
+To be able to check the Universal Second Factor (U2F) you need a user check and a webAuthN challenge.
 In the creat session request you can check for the user and directly initiate the webAuthN challenge.
 
 For U2F you can choose between "USER_VERIFICATION_REQUIREMENT_PREFERRED" and "USER_VERIFICATION_REQUIREMENT_DISCOURAGED" for the challenge.

docs/docs/guides/integrate/zitadel-apis/event-api.md

@@ -139,10 +139,10 @@ curl --request POST \
 
 The following example shows you how you could use the events search to find out the failed login attempts of your users.
 You have to include all the event types that tell you that a login attempt has failed.
-In this case this are the following events:
+In this case these are the following events:
 - Password verification failed
-- One-time-password (OTP) check failed (Authenticator Apps like Authy, Google Authenticator, etc)
-- Universal-Second-Factor (U2F) check failed (FaceID, WindowsHello, FingerPrint, etc)
+- One-time password (OTP) check failed (Authenticator Apps like Authy, Google Authenticator, etc)
+- Universal Second Factor (U2F) check failed (FaceID, WindowsHello, FingerPrint, etc)
 - Passwordless/Passkey check failed (FaceID, WindowsHello, FingerPrint, etc)
 
 ```bash

docs/docs/guides/manage/console/default-settings.mdx

@@ -178,10 +178,10 @@ Multifactors:
 
 - U2F (Universal Second Factor) with PIN, e.g FaceID, WindowsHello, Fingerprint, Hardwaretokens like Yubikey
 
-Secondfactors (2FA):
+Second factors (2FA):
 
 - Time-based One Time Password (TOTP), Authenticator Apps like Google/Microsoft Authenticator, Authy, etc.
-- Universal Second Factor (U2F), e.g FaceID, WindowsHello, Fingerprint, Hardwaretokens like Yubikey
+- Universal Second Factor (U2F), e.g FaceID, WindowsHello, Fingerprint, Hardware tokens like Yubikey
 - One Time Password with Email (Email OTP)
 - One Time Password with SMS (SMS OTP)
 
@@ -195,9 +195,9 @@ Configure the different lifetimes checks for the login process:
 
 - **Password Check Lifetime** specifies after which period a user has to reenter his password during the login process
 - **External Login Check Lifetime** specifies after which period a user will be redirected to the IDP during the login process
-- **Multifactor Init Lifetime** specifies after which period a user will be prompted to setup a 2-Factor / Multi Factor during the login process (value 0 will deactivate the prompt)
+- **Multi-factor Init Lifetime** specifies after which period a user will be prompted to setup a 2-Factor / Multi-factor during the login process (value 0 will deactivate the prompt)
 - **Second Factor Check Lifetime** specifies after which period a user has to revalidate the 2-Factor during the login process
-- **Multifactor Login Check Lifetime** specifies after which period a user has to revalidate the Multi Factor during the login process
+- **Multi-factor Login Check Lifetime** specifies after which period a user has to revalidate the Multi-factor during the login process
 
 ## Identity Providers
 

docs/docs/guides/migrate/sources/zitadel.md

@@ -16,7 +16,7 @@ The following scripts don't include:
 - Global policies
 - IAM members
 - Global IDPs
-- Global second/multi factors
+- Global second factor / multi-factors
 - Machine keys
 - Personal Access Tokens
 - Application keys

docs/docs/guides/migrate/users.md

@@ -173,7 +173,7 @@ In case the hashes can't be transferred directly, you always have the option to
 If your legacy system receives the passwords in clear text (eg, login form) you could also directly create users via ZITADEL API.
 We will explain this pattern in more detail in this guide.
 
-### One-time-passwords (OTP)
+### One-time passwords (OTP)
 
 You can pass the OTP secret when creating users: