chore: spell check automation and spellcheck (#889)

* test spell check

* fix indenting

* test

* add something to test

* test spellcheck

* spelling improvements

* improve spelling and ignore list

* Update site/docs/start/00-quick-start.de.md

site/docs/administrate/01-console.en.md

@@ -6,7 +6,7 @@ title: Console
 
 Console is the ZITADEL Graphical User Interface.
 
-**Users** can manage some information by their own.
+**Users** can manage some information on their own.
 
 - profile information
 - credentials

site/docs/administrate/02-organisations.en.md

@@ -70,8 +70,7 @@ To start the domain verification click the domain name and a dialog will appear,
         <figcaption itemprop="caption description">Organisation Domain Verify</figcaption>
     </figure>
 </div>
-
-For example, create a TXT record with your DNS provider for the used domain an click verify. **ZITADEL** will then proceed an check your DNS.
+For example, create a TXT record with your DNS provider for the used domain and click verify. **ZITADEL** will then proceed an check your DNS.
 <div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
     <figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
         <a href="img/console_org_domain_verify_dns.png" itemprop="contentUrl" data-size="1920x1080">
@@ -81,7 +80,6 @@ For example, create a TXT record with your DNS provider for the used domain an c
     </figure>
 </div>
 
-
 > Do not delete the verification code **ZITADEL** will recheck the ownership from time to time
 
 When the verification is successful you have the option to activate the domain by clicking **Set as primary**
@@ -97,8 +95,7 @@ When the verification is successful you have the option to activate the domain b
 
 > This changes the **preferred loginnames** of your [users](administrate#Users) as indicated [here](administrate#How_ZITADEL_handles_usernames).
 
-Gratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
-
+Congratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
 <div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
     <figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
         <a href="img/console_user_personal_info.png" itemprop="contentUrl" data-size="1920x1080">

site/docs/administrate/03-projects.en.md

@@ -6,7 +6,7 @@ title: Projects
 
 The idea of projects is to have a vessel for all components who are closely related to each other.
 In ZITADEL all clients located in the same project share their roles, grants and authorizations.
-From a access management perspective you manage who has what role in the project and your application consume this information.
+From an access management perspective you manage who has what role in the project and your application consumes this information.
 A project belongs to exactly one organisation.
 The attribute project role assertion defines, if the roles should be integrated in the tokens without sending corresponding scope (urn:zitadel:iam:org:project:role:{rolename})
 With the project role check you can define if a user should have a requested role to be able to logon.
@@ -14,18 +14,18 @@ With the project role check you can define if a user should have a requested rol
 **Clients**
 
 Clients are described here [What are clients](administrate#What_are_clients)
-Basically these are you applications who initiate the authorization flow.
+Basically these are your applications who initiate the authorization flow.
 
 **Roles**
 
-[Roles (or Project Roles)](administrate#Roles) is a mean of managing users access rights for a certain project.
+[Roles (or Project Roles)](administrate#Roles) is a means of managing users access rights for a certain project.
 These [roles](administrate#Roles)  are opaque for ZITADEL and have no weight in relation to each other.
 So if a [user](administrate#Users) has two roles, admin and user in a certain project, the information will be treated additive.
 
 **Grants**
 
 With ZITADEL it is possible to give third parties (other organisations) the possibility to manage certain roles on their own.
-To achieve this the owner of a project can grant (some could say delegate) certain roles or all roles to a organisation.
+To achieve this the owner of a project can grant (some could say delegate) certain roles or all roles to an organisation.
 After granting that organisation it can manage on its own which user has what roles.
 This feature is especially useful for service providers, because they are able to establish a great self-service culture for their business customers.
 
@@ -34,7 +34,7 @@ This feature is especially useful for service providers, because they are able t
 #### Project vs. granted Project
 
 The simple difference of a project vs a granted project is that a project belongs to your organisation and the granted project belongs to a third party who did grant you some rights to manage certain roles of their project.
-To make it more easily to differentiate ZITADEL Console displays these both as separate menu in the project section.
+To make it more easier to differentiate, ZITADEL Console displays these both as separate menu in the project section.
 
 ### Manage a project
 
@@ -51,7 +51,7 @@ To create your project go to [https://console.zitadel.ch/projects](https://conso
     </figure>
 </div>
 
-Create a new project with name which explains what's the intended use of this project.
+Create a new project with a name which explains what's the intended use of this project.
 
 <div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
     <figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">

site/docs/administrate/04-clients.en.md

@@ -5,7 +5,7 @@ title: Clients
 ### What are clients
 
 Clients are applications who share the same security context and interface with an "authorization server".
-For example you could have a software project existing out of a web app and a mobile app, both of these application might consume the same roles because the end user might use both of them.
+For example you could have a software project existing out of a web app and a mobile app, both of these applications might consume the same roles because the end user might use both of them.
 
 ### Manage clients
 

site/docs/administrate/05-roles.en.md

@@ -4,11 +4,11 @@ title: Roles
 
 ### What are Roles
 
-With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access controle**.
+With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access control**.
 
-**Roles** can be consumed by the [clients](administrate#clients) which exist witing a specific [project](administrate#projects).
+**Roles** can be consumed by the [clients](administrate#clients) which exist within a specific [project](administrate#projects).
 
-For more information about how **roles** can be consumed have a look the the protocol specific information.
+For more information about how **roles** can be consumed, have a look the protocol specific information.
 
 - [OpenID Connect / OAuth](integrate#How_to_consume_authorizations_in_your_application_or_service)
 
@@ -22,13 +22,13 @@ Each **role** consist of three fields.
 | Display Name | A descriptive text for the purpose of the **Role**                           | User is the default role provided to each person |
 | Group        | The group field allows to group certain roles who belong in the same context | User and Admin in the group **default**          |
 
-### Grantig Roles
+### Granting Roles
 
 To give someone (or somewhat) access to a [projects](administrate#projects) resources and services **ZITADEL** provides to processes. **Roles** can be either granted to [users](administrate#Users) org to [organisations](administrate#Organisations).
 
 #### Grant Roles to Organisations
 
-The possibility to grant **roles** to an [organisation](administrate#Organisations) is intented as "delegation" so that a [org](administrate#Organisations) can on their own grant access to [users](administrate#Users).
+The possibility to grant **roles** to an [organisation](administrate#Organisations) is intended as "delegation" so that a [org](administrate#Organisations) can on their own grant access to [users](administrate#Users).
 
 For example a **service provider** could grant the **roles** user, and manager to an [org](administrate#Organisations) as soon as they purchases his service. This can be automated by utilising a [service user](administrate#Manage_Service_Users) in the **service providers** business process.
 
@@ -36,6 +36,6 @@ For example a **service provider** could grant the **roles** user, and manager t
 
 #### Grant Roles to Users
 
-By granting **roles** to [users](administrate#Users), be it [humanes or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) recieves the authorization to access resources from a service.
+By granting **roles** to [users](administrate#Users), be it [humans or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) receives the authorization to access resources from a service.
 
 > Screenshot here

site/docs/administrate/06-users.en.md

@@ -9,14 +9,14 @@ Nonetheless we treat them all the same in regard to [roles](administrate#Roles)
 
 #### Human vs. Service Users
 
-The major difference between humane vs. machine [users](administrate#Users) is the type of credentials who can be used.
-With machine [users](administrate#Users) there is only a non interactive login process possible. As such we utilize “JWT as Authorization Grant”.
+The major difference between human vs. machine [users](administrate#Users) is the type of credentials who can be used.
+With machine [users](administrate#Users) there is only a non interactive logon process possible. As such we utilize “JWT as Authorization Grant”.
 
 > TODO Link to “JWT as Authorization Grant” explanation.
 
 ### How ZITADEL handles usernames
 
-**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has it's own pool of usernames which include human and service [users](administrate#Users).
+**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has its own pool of usernames which include human and service [users](administrate#Users).
 For example a [user](administrate#Users) with the username `road.runner` can only exist once the [organisation](administrate#Organisations) `ACME`. **ZITADEL** will automatically generate a "logonname" for each [user](administrate#Users) consisting of `{username}@{domainname}.{zitadeldomain}`. Without verifying the domain name this would result in the logonname `road.runner@acme.zitadel.ch`. If you use a dedicated **ZITADEL** replace `zitadel.ch` with your domain name.
 
 If someone verifies a domain name within the organisation **ZITADEL** will generate additional logonames for each [user](administrate#Users) with that domain. For example if the domain is `acme.ch` the resulting logonname would be `road.runner@acme.ch` and as well the generated one `road.runner@acme.zitadel.ch`.

site/docs/administrate/07-policies.en.md

@@ -4,8 +4,8 @@ title: Policies
 
 ### What are policies
 
-Polices are a means of enforcing certain behavior of ZITADEL.
-ZITADEL defines a default policy on the system level. However a org. owner can change these aspects within his own org.
+Policies are a means of enforcing certain behaviour of ZITADEL.
+ZITADEL defines a default policy on the system level. However an organisation owner can change these aspects within his own organisation.
 
 Below is a list of available policies
 
@@ -24,7 +24,7 @@ This policy enforces passwords of users within the org. to be compliant.
 ### IAM Access Preference
 
 This policy enforces, when set to true, that usernames are suffixed with the organisations domain.
-Under normal operation this policy is only false on the `global` org. so that users can choose there email as username.
+Under normal operation this policy is only false on the `global` org. so that users can choose their email as their username.
 Only available for the `IAM Administrator`
 
 > Screenshot here

site/docs/administrate/08-providers.en.md

@@ -4,7 +4,7 @@ title: Identity Providers
 
 ### What are Identity Providers
 
-Identity providers or in short idp's are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
+Identity providers or in short idps are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
 Normally federation uses protocols like [OpenID Connect 1.0](https://openid.net/connect/), [OAuth 2.0](https://oauth.net/2/) and [SAML 2.0](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).
 
 Some examples include:
@@ -33,7 +33,7 @@ Some examples include:
 
 ### What is Identity Brokering
 
-ZITADEL supports the usage as identity broker, by linking multiple external idp's into one user.
+ZITADEL supports the usage as identity broker, by linking multiple external idps into one user.
 With identity brokering the client which relies on ZITADEL does not need to care about the linking of identity.
 
 ### Manage Identity Providers
@@ -54,13 +54,13 @@ SAML 2.0 will follow later on.
 > This is a work in progress.
 
 Storage federation is a means of integrating existing identity storage like [LDAP](https://tools.ietf.org/html/rfc4511) and [ADDS](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview).
-With this process **ZITADEL** can authenticate users with LDAP Binding and SPNNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
+With this process **ZITADEL** can authenticate users with LDAP Binding and SPNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
 
 #### Sync Settings
 
 Here we will document all the different sync options
 
-- Readonly
+- Read-only
 - Writeback
 - just-in-time sync
 - scheduled sync

site/docs/administrate/90-system.en.md

@@ -8,16 +8,16 @@ System describes the root of ZITADEL and includes all other elements like organi
 
 ### Default Policies
 
-When ZITADEL is setup for the first time we establish certain default polices for the whole system.
+When ZITADEL is set up for the first time we establish certain default policies for the whole system.
 
 > TODO Document default policy settings
 
 ### Manage Read Models
 
-Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consist of logonname and the password hash so that the login process can query that data.
+Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consists of logonname and the password hash so that the login process can query that data.
 
-All read models are eventual consistent by nature and sometimes an administrator would like to verify they are still up-to date.
-In the ZITADEL Console is a section called administration available where the admin can check all read models and there current state.
+All read models are eventually consistent by nature and sometimes an administrator would like to verify they are still up-to-date.
+In the ZITADEL Console is a section called administration available where the admin can check all read models and their current state.
 There is even a possibility to regenerate a read model.
 
 > When a read model is regenerated it might take up some time to be fully operational again
@@ -27,7 +27,7 @@ There is even a possibility to regenerate a read model.
 
 ### Secret Handling
 
-ZITADEL store secrets always encrypted or hashed in it's storage.
+ZITADEL stores secrets always encrypted or hashed in it's storage.
 Whenever feasible we try to utilize public / private key mechanics to handle secrets.
 
 **Encryption**
@@ -44,7 +44,7 @@ These keys are randomly generated within ZITADEL and are rotated on a regular ba
 > Signing keys are stored with AES256 encryption
 
 **TLS**
-Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handlings is out of context in this regard.
+Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handling are out of context in this regard.
 However ZITADEL can use TLS keys at runtime level.
 
 > TODO Document TLS config