Minor corrections.

2.x/concept-overview.md

@@ -40,7 +40,7 @@ After installation, your Jetstream application will contain two "layouts". First
 
 #### The Guest / Authentication Layout
 
-In addition to the application layout, Jetstream creates a "guest" layout that is used to define the layout for Jetstream's authentication related pages, such as your application's login, registration, and password reset pages. When using the Livewire stack, this layout is defined at `resources/views/layouts/guest.blade.php` and rendered by the `App\View\Components\GuestLayout` class. When using the Inertia stack, this layout is defined at `resources/js/Layouts/GuestLayout.vue`.
+In addition to the application layout, Jetstream creates a "guest" layout that is used to define the layout for Jetstream's authentication-related pages, such as your application's login, registration, and password reset pages. When using the Livewire stack, this layout is defined at `resources/views/layouts/guest.blade.php` and rendered by the `App\View\Components\GuestLayout` class. When using the Inertia stack, this layout is defined at `resources/js/Layouts/GuestLayout.vue`.
 
 ### Dashboard
 

2.x/features/api.md

@@ -4,7 +4,7 @@
 
 ## Introduction
 
-Jetstream includes first-party integration with [Laravel Sanctum](https://laravel.com/docs/sanctum). Laravel Sanctum provides a featherweight authentication system for SPAs (single page applications), mobile applications, and simple, token based APIs. Sanctum allows each user of your application to generate multiple API tokens for their account. These tokens may be granted abilities / permissions which specify which actions the tokens are allowed to perform.
+Jetstream includes first-party integration with [Laravel Sanctum](https://laravel.com/docs/sanctum). Laravel Sanctum provides a featherweight authentication system for SPAs (single page applications), mobile applications, and simple, token-based APIs. Sanctum allows each user of your application to generate multiple API tokens for their account. These tokens may be granted abilities / permissions which specify which actions the tokens are allowed to perform.
 
 ![Screenshot of Laravel Jetstream API](./../../assets/img/api.png)
 
@@ -57,15 +57,15 @@ return $request->user()->id === $post->user_id &&
 
 ### First-Party UI Initiated Requests
 
-When a user makes a request to a route within your `routes/web.php` file, the request will typically be authenticated by Sanctum through a authenticated session cookie based guard. In most Laravel applications, this is the `web` guard.
+When a user makes a request to a route within your `routes/web.php` file, the request will typically be authenticated by Sanctum through an authenticated session cookie based guard. In most Laravel applications, this is the `web` guard.
 
-When the user is making a first-party request through the application UI, the `tokenCan` method will always return `true`. Remember, this does not necessarily mean that your application has to allow the user to perform the action. Typically, your policies will determine if the token has been granted the permission to perform the abilities **as well as check that the user instance itself should be allowed to perform the action**.
+When the user is making a first-party request through the application UI, the `tokenCan` method will always return `true`. Remember, this does not necessarily mean that your application has to allow the user to perform the action. Typically, your policies will determine if the token has been granted permission to perform the abilities **as well as check that the user instance itself should be allowed to perform the action**.
 
-For example, in the case of updating a blog post, this might mean checking that token is authorized to update posts **and** that the post belongs to the user:
+For example, in the case of updating a blog post, this might mean checking that the token is authorized to update posts **and** that the post belongs to the user:
 
 ```php
 return $request->user()->id === $post->user_id &&
        $request->user()->tokenCan('post:update')
 ```
 
-At first, allowing the `tokenCan` method to be called and always return `true` for first-party UI initiated requests may seem strange; however, it is convenient to be able to always assume an API token is available and can be inspected via the `tokenCan` method. This means that you may always call the `tokenCan` method within your application's authorizations policies without worrying about whether the request was triggered from your application's UI or was initiated by one of your API's third-party consumers.
+At first, allowing the `tokenCan` method to be called and always return `true` for first-party UI-initiated requests may seem strange; however, it is convenient to be able to always assume an API token is available and can be inspected via the `tokenCan` method. This means that you may always call the `tokenCan` method within your application's authorization policies without worrying about whether the request was triggered from your application's UI or was initiated by one of your API's third-party consumers.

2.x/features/authentication.md

@@ -18,7 +18,7 @@ Within the `fortify` configuration file, you can also disable entire features of
 
 ## Views / Pages
 
-When using the Livewire stack, the login view is displayed using the `resources/views/auth/login.blade.php` Blade template. When using the Inertia stack, this view is displayed using the `resources/js/Pages/Auth/Login.vue` template. The directories that contain these views also contain other authentication related views / pages for your application.
+When using the Livewire stack, the login view is displayed using the `resources/views/auth/login.blade.php` Blade template. When using the Inertia stack, this view is displayed using the `resources/js/Pages/Auth/Login.vue` template. The directories that contain these views also contain other authentication-related views / pages for your application.
 
 ### Customizing The Authentication Views
 

2.x/features/browser-sessions.md

@@ -6,7 +6,7 @@
 
 Laravel Jetstream's security features are accessed by the user using the top-right user profile navigation dropdown menu. Within this dashboard, Jetstream scaffolds views that allow the user to view the browser sessions associated with their account. In addition, the user may "logout" browser sessions other than the one being used by the device they are currently using.
 
-This feature utilizes Laravel's built-in `Illuminate\Session\Middleware\AuthenticateSession` middleware to safely logout other browser sessions that are authenticated as the current user.
+This feature utilizes Laravel's built-in `Illuminate\Session\Middleware\AuthenticateSession` middleware to safely log out other browser sessions that are authenticated as the current user.
 
 ![Screenshot of Browser Sessions](./../../assets/img/browser-sessions.png)
 
@@ -16,6 +16,6 @@ Most Jetstream features can be customized via action classes. However, for secur
 
 ## Views / Pages
 
-Typically, the browser session feature's corresponding views and pages should not require customization as they are already feature complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
+Typically, the browser session feature's corresponding views and pages should not require customization as they are already feature-complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
 
 When using the Livewire stack, the browser session management view is displayed using the `resources/views/profile/logout-other-browser-sessions-form.blade.php` Blade template. When using the Inertia stack, this view is displayed using the `resources/js/Pages/Profile/LogoutOtherBrowserSessionsForm.vue` template.

2.x/features/password-confirmation.md

@@ -50,7 +50,7 @@ That view that renders the Livewire stack's password confirmation screen is loca
 
 #### Ensuring The Password Has Been Confirmed
 
-Next, Livewire components that contains an action that should require password confirmation before being invoked should use the `Laravel\Jetstream\ConfirmsPasswords` trait.
+Next, Livewire components that contain an action that should require password confirmation before being invoked should use the `Laravel\Jetstream\ConfirmsPasswords` trait.
 
 After adding this trait to a component, you should call the `ensurePasswordIsConfirmed` method within any Livewire action that requires password confirmation. This should be done at the very beginning of the relevant action method:
 
@@ -70,7 +70,7 @@ public function enableAdminMode()
 
 :::warning Password Confirmation Expiration
 
-Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by the your application's `auth.password_timeout` configuration option have elapsed:
+Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by your application's `auth.password_timeout` configuration option has elapsed:
 :::
 
 ### Redirect Password Confirmation Via Inertia
@@ -93,7 +93,7 @@ That page that renders the Inertia's stack's password confirmation screen is loc
 
 :::warning Password Confirmation Expiration
 
-Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by the your application's `auth.password_timeout` configuration option have elapsed:
+Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by your application's `auth.password_timeout` configuration option has elapsed:
 :::
 
 ## Modal Password Confirmation
@@ -142,7 +142,7 @@ public function enableAdminMode()
 
 :::warning Password Confirmation Expiration
 
-Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by the your application's `auth.password_timeout` configuration option have elapsed:
+Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by your application's `auth.password_timeout` configuration option has elapsed:
 :::
 
 ### Modal Password Confirmation Via Inertia
@@ -184,12 +184,12 @@ Route::post('/admin-mode', function () {
 
 :::warning Password Confirmation Expiration
 
-Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by the your application's `auth.password_timeout` configuration option have elapsed:
+Once the user has confirmed their password, they will not be required to re-enter their password until the number of seconds defined by your application's `auth.password_timeout` configuration option has elapsed:
 :::
 
 ## Customizing How Passwords Are Confirmed
 
-Sometimes, you may wish to customize how the user's password is validated during confirmation. To do so, you may use the `Fortify::confirmPasswordsUsing` method. This method accepts a closure which receives the authenticated user instance and the `password` input field of the request. The closure should return `true` if the password is valid for the given user. Typically, this method should be called from the `boot` method of your `JetstreamServiceProvider`:
+Sometimes, you may wish to customize how the user's password is validated during confirmation. To do so, you may use the `Fortify::confirmPasswordsUsing` method. This method accepts a closure that receives the authenticated user instance and the `password` input field of the request. The closure should return `true` if the password is valid for the given user. Typically, this method should be called from the `boot` method of your `JetstreamServiceProvider`:
 
 ```php
 use Illuminate\Support\Facades\Hash;

2.x/features/password-update.md

@@ -14,7 +14,7 @@ Like most of Jetstream's features, the underlying logic used to implement the fe
 
 The `App\Actions\Fortify\UpdateUserPassword` class will be invoked when the user updates their password. This action is responsible for validating the input and updating the user's password.
 
-This action utilizes the `App\Actions\Fortify\PasswordValidationRules` trait to determine the validation rules that will be applied to the password. Customizing this trait will uniformly affect the validation rules applied to the password when the user registers, resets their password, or updates their password.
+This action utilizes the `App\Actions\Fortify\PasswordValidationRules` trait to determine the validation rules that will be applied to the password. Customizing this trait will uniformly affect the validation rules applied to the password when the user registers, resets or updates their password.
 
 ### Password Validation Rules
 
@@ -44,6 +44,6 @@ Of course, these methods may be chained to define the password validation rules
 
 ## Views / Pages
 
-Typically, the views and pages for these features should not require customization, as they are already feature complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
+Typically, the views and pages for these features should not require customization, as they are already feature-complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
 
 When using the Livewire stack, the password update view is displayed using the `resources/views/profile/update-password-form.blade.php` Blade template. When using the Inertia stack, this view is displayed using the `resources/js/Pages/Profile/UpdatePasswordForm.vue` template.

2.x/features/registration.md

@@ -84,7 +84,7 @@ Fortify::registerView(function () {
 
 ## Requiring Terms Of Service / Privacy Policy Approval
 
-Many application require users to accept their terms of service / privacy policy during registration. Jetstream allows you to easily enable this requirement for your own application, as well as provides a convenient way of writing these documents using Markdown.
+Many applications require users to accept their terms of service / privacy policy during registration. Jetstream allows you to easily enable this requirement for your own application, as well as provides a convenient way of writing these documents using Markdown.
 
 To get started, enable this feature in your application's `config/jetstream.php` configuration file:
 

2.x/features/teams.md

@@ -87,7 +87,7 @@ A user may switch their current team via the "team switcher" menu available with
 
 ### The Team Object
 
-The team object that is accessed via `$user->currentTeam` or Jetstream's other team related Eloquent queries provides a variety of useful methods for inspecting the team's attributes and relationships:
+The team object that is accessed via `$user->currentTeam` or Jetstream's other team-related Eloquent queries provides a variety of useful methods for inspecting the team's attributes and relationships:
 
 ```php
 // Access the team's owner...

2.x/features/two-factor-authentication.md

@@ -18,7 +18,7 @@ Most Jetstream features can be customized via action classes. However, for secur
 
 ## Views / Pages
 
-Typically, the two-factor authentication feature's corresponding views and pages should not require customization as they are already feature complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
+Typically, the two-factor authentication feature's corresponding views and pages should not require customization as they are already feature-complete. However, their locations are described below in case you need to make small presentation adjustments to these pages.
 
 When using the Livewire stack, the two-factor authentication management view is displayed using the `resources/views/profile/two-factor-authentication-form.blade.php` Blade template. When using the Inertia stack, this view is displayed using the `resources/js/Pages/Profile/TwoFactorAuthenticationForm.vue` template.