[FIX] Grammar and spelling

docs/features/core/admin_site.md

@@ -1,26 +1,26 @@
 # Admin Site
 
-The admin site allows administrators to configure, manage and trouble shoot Alliance Auth and all it's applications and services. E.g. you can create new groups and assign groups to users.
+The admin site allows administrators to configure, manage and troubleshoot Alliance Auth and all its applications and services. E.g., you can create new groups and assign groups to users.
 
-You can open the admin site by clicking on "Admin" in the drop down menu for a user that has access.
+You can open the admin site by clicking on "Admin" in the drop-down menu for a user that has access.
 
 ![Admin Site](/_static/images/features/core/admin_site.png)
 
 ## Setup for small to medium size installations
 
-For small to medium size alliances it is often sufficient to have no more then two superuser admins (admins that also are superusers). Having two admins usually makes sense, so you can have one primary and one backup.
+For small to medium size alliances, it is often sufficient to have no more than two superuser admins (admins that also are superusers). Having two admins usually makes sense, so you can have one primary and one backup.
 
 :::{warning}
-Superusers have read & write access to everything on your AA installation. Superusers also automatically have all permissions and therefore access to all features of your apps. Therefore we recommend to be very careful to whom you give superuser privileges.
+Superusers have read & write access to everything on your AA installation. Superuser also automatically have all permissions and therefore access to all features of your apps. Therefore, we recommend to be very careful to whom you give superuser privileges.
 :::
 
 ## Setup for large installations
 
-For large alliances and coalitions you may want to have a couple of administrators to be able to distribute and handle the work load. However, having a larger number of superusers may be a security concern.
+For large alliances and coalitions, you may want to have a couple of administrators to be able to distribute and handle the work load. However, having a larger number of superusers may be a security concern.
 
-As an alternative to superusers admins you can define staff admins. Staff admins can perform most of the daily admin work, but are not superusers and therefore can be restricted in what they can access.
+As an alternative to superusers admins, you can define staff admins. Staff admins can perform most of the daily admin work, but are not superusers and therefore can be restricted in what they can access.
 
-To create a staff admin you need to do two things:
+To create a staff admin, you need to do two things:
 
 1. Enable the `is_staff` property for a user
 1. Give the user permissions for admin tasks
@@ -28,21 +28,21 @@ To create a staff admin you need to do two things:
 :::{note}
 Note that staff admins have the following limitations:
 
-- Can not promote users to staff
-- Can not promote users to superuser
-- Can not add/remove permissions for users, groups and states
+- Cannot promote users to staff
+- Cannot promote users to superuser
+- Cannot add/remove permissions for users, groups and states
 
-These limitations exist to prevent staff admins to promote themselves to quasi superusers. Only superusers can perform these actions.
+These limitations exist to prevent staff admins from promoting themselves to quasi superusers. Only superusers can perform these actions.
 
 :::
 
 ### Staff property
 
-Access to the admin site is restricted. Users needs to have the `is_staff` property to be able to open the site at all. The superuser that is created during the installation
+Access to the admin site is restricted. Users need to have the `is_staff` property to be able to open the site at all. The superuser created during the installation
 process will automatically have access to the admin site.
 
 :::{hint}
-Without any permissions a "staff user" can open the admin site, but can neither view nor edit anything except for viewing the list of permissions.
+Without any permissions, a "staff user" can open the admin site, but can neither view nor edit anything except for viewing the list of permissions.
 :::
 
 ### Permissions for common admin tasks
@@ -91,4 +91,4 @@ Here is a list of permissions a staff admin would need to perform some common ad
 
 ### Permissions for other apps
 
-The permissions a staff admin needs to perform tasks for other applications depends on how the applications are configured. the default is to have four permissions (change, delete, edit view) for each model of the applications. The view permission is usually required to see the model list on the admin site and the other three permissions are required to perform the respective action to an object of that model. However, app developer can chose to define permissions differently.
+The permission a staff admin needs to perform tasks for other applications depends on how the applications are configured. The default is to have four permissions (change, delete, edit view) for each model of the applications. The view permission is usually required to see the model list on the admin site, and the other three permissions are required to perform the respective action to an object of that model. However, an app developer can choose to define permissions differently.

docs/features/core/analytics.md

@@ -6,7 +6,7 @@
 
 Before you proceed, please read through this page and/or raise any concerns on the Alliance Auth discord. This data helps us make AA better.
 
-To Opt-Out, modify our pre-loaded token using the Admin dashboard */admin/analytics/analyticstokens/1/change/
+To opt out, modify our preloaded token using the Admin dashboard */admin/analytics/analyticstokens/1/change/
 
 Each of the three features Daily Stats, Celery Events and Page Views can be enabled/Disabled independently.
 
@@ -20,13 +20,13 @@ ANALYTICS_DISABLED = True
 
 ## What
 
-Alliance Auth has taken great care to anonymize the data sent. In order to identify _unique_ installs we generate a UUIDv4, a random mathematical construct which does not contain any identifying information [UUID - UUID Objects](https://docs.python.org/3/library/uuid.html#uuid.uuid4)
+Alliance Auth has taken great care to anonymize the data sent. To identify _unique_ installs, we generate a UUIDv4, a random mathematical construct which does not contain any identifying information [UUID - UUID Objects](https://docs.python.org/3/library/uuid.html#uuid.uuid4)
 
-Analytics comes pre-loaded with our Google Analytics Token, and the Three Types of task can be opted out independently. Analytics can also be loaded with your _own_ GA token and the analytics module will act any/all tokens loaded.
+Analytics comes preloaded with our Google Analytics token, and the three types of tasks can be opted out independently. Analytics can also be loaded with your _own_ GA token, and the analytics module will act any/all tokens loaded.
 
 Our Daily Stats contain the following:
 
-- A phone-in task to identify a servers existence
+- A phone-in task to identify a server's existence
 - A task to send the Number of User models
 - A task to send the Number of Token Models
 - A task to send the Number of Installed Apps
@@ -36,7 +36,7 @@ Our Daily Stats contain the following:
 Our Celery Events contain the following:
 
 - Unique Identifier (The UUID)
-- Celery Namespace of the task eg allianceauth.eveonline
+- Celery Namespace of the task e.g., allianceauth.eveonline
 - Celery Task
 - Task Success or Exception
 - A context number for bulk tasks or sometimes a binary True/False
@@ -47,18 +47,18 @@ Our Page Views contain the following:
 - Page Path
 - Page Title
 - The locale of the users browser
-- The User-Agent of the users browser
+- The User-Agent of the user's browser
 - The Alliance Auth Version
 
 ## Why
 
-This data allows Alliance Auth development to gather accurate statistics on our install base, as well as how those installs are used.
+This data allows Alliance Auth development to gather accurate statistics on our installation base, as well as how those installations are used.
 
 This allows us to better target our development time to commonly used modules and features and test them at the scales in use.
 
 ## Where
 
-This data is stored in a Team Google Analytics Dashboard. The Maintainers all have Management permissions here, and if you have contributed to the Alliance Auth project or third party applications feel free to ask in the Alliance Auth discord for access.
+This data is stored in a Team Google Analytics Dashboard. The Maintainers all have Management permissions here, and if you have contributed to the Alliance Auth project or third party applications, feel free to ask in the Alliance Auth discord for access.
 
 ## Using Analytics in my App
 

docs/features/core/dashboard.md

@@ -1,10 +1,10 @@
 # Dashboard
 
-The dashboard is the main page of the **Alliance Auth** website and the first page every logged in user will see.
+The dashboard is the main page of the **Alliance Auth** website, and the first page every logged-in user will see.
 
-The content of the dashboard is specific to the logged in user. It has a sidebar, which will display the list of apps a user currently as access to based on his permissions. And it also shows which character the user has registered and to which group he belongs.
+The content of the dashboard is specific to the logged-in user. It has a sidebar, which will display the list of apps a user currently as access to based on his permissions. And it also shows which character the user has registered and to which group he belongs.
 
-For admin users the dashboard shows additional technical information about the  AA instance.
+For admin users, the dashboard shows additional technical information about the AA instance.
 
 ![dashboard](/_static/images/features/core/dashboard/dashboard.png)
 

docs/features/core/groups.md

@@ -14,7 +14,7 @@ Here you have several options:
 
 ### Internal
 
-Users cannot see, join or request to join this group. This is primarily used for Auth's internally managed groups, though can be useful if you want to prevent users from managing their membership of this group themselves. This option will override the Hidden, Open and Public options when enabled.
+Users cannot see, join or request to join this group. This is primarily used for Auth's internally managed groups, though it can be useful if you want to prevent users from managing their membership of this group themselves. This option will override the Hidden, Open and Public options when enabled.
 
 By default, every new group created will be an internal group.
 
@@ -36,11 +36,11 @@ Group is accessible to any registered user, even when they do not have permissio
 
 The key difference is that the group is completely unmanaged by Auth. **Once a member joins they will not be removed unless they leave manually, you remove them manually, or their account is deliberately set inactive or deleted.**
 
-Most people won't have a use for public groups, though it can be useful if you wish to allow public access to some services. You can grant service permissions on a public group to allow this behavior.
+Most people won't have a use for public groups, though it can be useful if you wish to allow public access to some services. You can grant service permissions to a public group to allow this behavior.
 
 ### Restricted
 
-When a group is restricted only superuser admins can directly add or remove them to/from users. The purpose of this property is prevent staff admins from assigning themselves to groups that are security sensitive. The "restricted" property can be combined with all the other properties.
+When a group is restricted, only superuser admins can directly add or remove them to/from users. The purpose of this property is to prevent staff admins from assigning themselves to groups that are security sensitive. The "restricted" property can be combined with all the other properties.
 
 ```{eval-rst}
 .. _ref-reserved-group-names:
@@ -48,15 +48,15 @@ When a group is restricted only superuser admins can directly add or remove them
 
 ## Reserved group names
 
-When using Alliance Auth to manage external services like Discord, Auth will automatically duplicate groups on those services. E.g. on Discord Auth will create roles of the same name as groups. However, there may be cases where you want to manage groups on external services by yourself or by another bot. For those cases you can define a list of reserved group names. Auth will ensure that you can not create groups with a reserved name. You will find this list on the admin site under groupmanagement.
+When using Alliance Auth to manage external services like Discord, Auth will automatically duplicate groups on those services. E.g., on Discord Auth will create roles of the same name as groups. However, there may be cases where you want to manage groups on external services by yourself or by another bot. For those cases, you can define a list of reserved group names. Auth will ensure that you cannot create groups with a reserved name. You will find this list on the admin site under groupmanagement.
 
 :::{note}
-While this feature can help to avoid naming conflicts with groups on external services, the respective service component in Alliance Auth also needs to be build in such a way that it knows how to prevent these conflicts. Currently only the Discord and Teamspeak3 services have this ability.
+While this feature can help to avoid naming conflicts with groups on external services, the respective service component in Alliance Auth also needs to be built in such a way that it knows how to prevent these conflicts. Currently only the Discord and Teamspeak3 services have this ability.
 :::
 
 ## Managing groups
 
-In order to access group management, users need to be either a superuser, granted the `auth | user | group_management ( Access to add members to groups within the alliance )` permission or a group leader (discussed later).
+To access group management, users need to be either a superuser, granted the `auth | user | group_management ( Access to add members to groups within the alliance )` permission or a group leader (discussed later).
 
 ### Group Requests
 
@@ -64,7 +64,7 @@ When a user joins or leaves a group which is not marked as "Open", their group r
 
 ### Group Membership
 
-The group membership tab gives an overview of all of the non-internal groups.
+The group membership tab gives an overview of all the non-internal groups.
 
 ![Group overview](/_static/images/features/core/groupmanagement/group-membership.png)
 
@@ -89,7 +89,7 @@ Group leaders have the same abilities as users with the `group_management` permi
 - Approve requests for groups they are a leader of.
 - View the Group Membership and Group Members of groups they are leaders of.
 
-This allows you to more finely control who has access to manage which groups.
+This allows you to more fine control who has access to manage which groups.
 
 ### Auto Leave
 
@@ -121,7 +121,7 @@ Note that all settings are optional and the app will use the documented default
 
 ## Permissions
 
-In order to join a group other than a public group, the permission `groupmanagement.request_groups` (`Can request non-public groups` in the admin panel) must be active on their account, either via a group or directly applied to their User account.
+To join a group other than a public group, the permission `groupmanagement.request_groups` (`Can request non-public groups` in the admin panel) must be active on their account, either via a group or directly applied to their User account.
 
 When a user loses this permission, they will be removed from all groups _except_ Public groups.
 

docs/features/core/index.md

@@ -1,6 +1,6 @@
 # Core Features
 
-Managing access to applications and services is one of the core functions of **Alliance Auth**. The related key concepts and functionalities are describes in this section.
+Managing access to applications and services is one of the core functions of **Alliance Auth**. The related key concepts and functionalities are described in this section.
 
 :::{toctree}
 :maxdepth: 1

docs/features/core/notifications.md

@@ -1,14 +1,14 @@
 # Notifications
 
-Alliance Auth has a build in notification system. The purpose of the notification system is to provide an easy and quick way to send messages to users of Auth. For example some apps are using it to inform users about results after long running tasks have completed and admins will automatically get notifications about system errors.
+Alliance Auth has a build in notification system. The purpose of the notification system is to provide an easy and quick way to send messages to users of Auth. For example, some apps are using it to inform users about results after long-running tasks have been completed, and admins will automatically get notifications about system errors.
 
-The number of unread notifications is shown to the user in the top menu. And the user can click on the notification count to open the notifications app.
+The number of unread notifications is shown to the user in the top menu. And the user can click on the notification count to open the Notifications app.
 
 ![notification app](/_static/images/features/core/notifications.png)
 
 ## Settings
 
-The notifications app can be configured through settings.
+The Notifications app can be configured through settings.
 
-- `NOTIFICATIONS_REFRESH_TIME`: The unread count in the top menu is automatically refreshed to keep the user informed about new notifications. This setting allows to set the time between each refresh in seconds. You can also set it to `0` to turn off automatic refreshing. Default: `30`
-- `NOTIFICATIONS_MAX_PER_USER`: Maximum number of notifications that are stored per user. Older notifications are replaced by newer once. Default: `50`
+- `NOTIFICATIONS_REFRESH_TIME`: The unread count in the top menu is automatically refreshed to keep the user informed about new notifications. This setting allows setting the time between each refresh in seconds. You can also set it to `0` to turn off automatic refreshing. Default: `30`
+- `NOTIFICATIONS_MAX_PER_USER`: Maximum number of notifications that are stored per user. Newer replace older notifications. Default: `50`

docs/features/core/states.md

@@ -1,10 +1,10 @@
 # States
 
-States define the basic role of a user based on his affiliation with your organization. A user that has a character in your organization (e.g. alliance) will usually have the `Member` state. And a user, that has no characters in your organization will usually have the `Guest` state.
+States define the basic role of a user based on his affiliation with your organization. A user that has a character in your organization (e.g., alliance) will usually have the `Member` state. And a user, that has no characters in your organization will usually have the `Guest` state.
 
-States are assigned and updated automatically. So a user which character just left your organization will automatically loose his `Member` state and get the `Guest` state instead.
+States are assigned and updated automatically. So a user which character just left your organization will automatically lose his `Member` state and get the `Guest` state instead.
 
-The main purpose of states like `Member` is to have one place where you can assign all permissions that should apply to all users with that particular state. For example if all your members should have access to the SRP app you would add the permission that gives access to the SRP app to the `Member` state.
+The main purpose of states like `Member` is to have one place where you can assign all permissions that should apply to all users with that particular state. For example, if all your members should have access to the SRP app, you would add the permission that gives access to the SRP app to the `Member` state.
 
 ## Creating a State
 
@@ -14,7 +14,7 @@ A number of fields are available and are described below.
 
 ### Name
 
-This is the displayed name of a state. Should be self-explanatory.
+This is the displayed name of a state. It should be self-explanatory.
 
 ### Permissions
 
@@ -50,9 +50,9 @@ This lets you select which factions the state is available to. Factions can be a
 
 States are mutually exclusive, meaning a user can only be in one at a time.
 
-Membership is determined based on a user's main character. States are tested in order of descending priority - the first one which allows membership to the main character is assigned to the user.
+Membership is determined based on a user's main character. States are tested in order of descending priority - the first one, which allows membership to the main character, is assigned to the user.
 
-States are automatically assigned when a user registers to the site, their main character changes, they are activated or deactivated, or states are edited. Note that editing states triggers lots of state checks so it can be a very slow process.
+States are automatically assigned when a user registers to the site, their main character changes, they are activated or deactivated, or states are edited. Note that editing states triggers lots of state checks, so it can be a very slow process.
 
 Assigned states are visible in the `Users` section of the `Authentication` admin site.
 
@@ -60,4 +60,4 @@ Assigned states are visible in the `Users` section of the `Authentication` admin
 
 If no states are available to a user's main character, or their account has been deactivated, they are assigned to a catch-all `Guest` state. This state cannot be deleted nor can its name be changed.
 
-The `Guest` state allows permissions to be granted to users who would otherwise not get any. For example access to public services can be granted by giving the `Guest` state a service access permission.
+The `Guest` state allows permissions to be granted to users who would otherwise not get any. For example, access to public services can be granted by giving the `Guest` state a service access permission.