Fix punctuation and grammar issues in guides (#4811)

* Fixup grammar and punctuations issues

* Apply PR suggestions

guides/authentication/mix_phx_gen_auth.md

@@ -10,7 +10,7 @@ Let's start by running the following command from the root of our app (or `apps/
 $ mix phx.gen.auth Accounts User users
 ```
 
-This creates an `Accounts` context with an `Accounts.User` schema module. The final argument is the plural version of the schema module which is used for generating database table names and route helpers. The `mix phx.gen.auth` generator is similar to `mix phx.gen.html` except it does not accept a list of additional fields to add to the schema and it generates many more context functions.
+This creates an `Accounts` context with an `Accounts.User` schema module. The final argument is the plural version of the schema module, which is used for generating database table names and route helpers. The `mix phx.gen.auth` generator is similar to `mix phx.gen.html` except it does not accept a list of additional fields to add to the schema, and it generates many more context functions.
 
 Since this generator installed additional dependencies in `mix.exs`, let's fetch those:
 
@@ -38,7 +38,7 @@ $ mix phx.server
 
 ## Developer responsibilities
 
-Since Phoenix generates this code into your application instead of building these modules into Phoenix itself, you now have complete freedom to modify the authentication system so it works best with your use case. The one caveat with using a generated authentication system is it will not be updated after it's been generated. Therefore as improvements are made to the output of `mix phx.gen.auth`, it becomes your responsibility to determine if these changes need to be ported into your application. Security-related and other important improvements will be explicitly and clearly marked in the `CHANGELOG.md` file and upgrade notes.
+Since Phoenix generates this code into your application instead of building these modules into Phoenix itself, you now have complete freedom to modify the authentication system, so it works best with your use case. The one caveat with using a generated authentication system is it will not be updated after it's been generated. Therefore, as improvements are made to the output of `mix phx.gen.auth`, it becomes your responsibility to determine if these changes need to be ported into your application. Security-related and other important improvements will be explicitly and clearly marked in the `CHANGELOG.md` file and upgrade notes.
 
 ## Generated code
 
@@ -72,13 +72,13 @@ The generated functionality ships with an account confirmation mechanism, where
 
 ### Notifiers
 
-The generated code is not integrated with any system to send SMSs or emails for confirming accounts, resetting passwords, etc. Instead it simply logs a message to the terminal. It is your responsibility to integrate with the proper system after generation.
+The generated code is not integrated with any system to send SMSes or emails for confirming accounts, resetting passwords, etc. Instead, it simply logs a message to the terminal. It is your responsibility to integrate with the proper system after generation.
 
 ### Tracking sessions
 
 All sessions and tokens are tracked in a separate table. This allows you to track how many sessions are active for each account. You could even expose this information to users if desired.
 
-Note that whenever the password changes (either via reset password or directly), all tokens are deleted and the user has to log in again on all devices.
+Note that whenever the password changes (either via reset password or directly), all tokens are deleted, and the user has to log in again on all devices.
 
 ### User Enumeration attacks
 
@@ -90,17 +90,17 @@ Furthermore, if you are concerned about enumeration attacks, beware of timing at
 
 ### Case sensitiveness
 
-The email lookup is made to be case insensitive. Case insensitive lookups are the default in MySQL and MSSQL. In SQLite3 we use [`COLLATE NOCASE`](https://www.sqlite.org/datatype3.html#collating_sequences) in the column definition to support it. In PostgreSQL we use the [`citext` extension](https://www.postgresql.org/docs/current/citext.html).
+The email lookup is made to be case-insensitive. Case-insensitive lookups are the default in MySQL and MSSQL. In SQLite3 we use [`COLLATE NOCASE`](https://www.sqlite.org/datatype3.html#collating_sequences) in the column definition to support it. In PostgreSQL, we use the [`citext` extension](https://www.postgresql.org/docs/current/citext.html).
 
-Note `citext` is part of PostgreSQL itself and is bundled with it in most operating systems and package managers. `mix phx.gen.auth` takes care of creating the extension and no extra work is necessary in the majority of cases. If by any chance your package manager splits `citext` into a separate package, you will get an error while migrating and you can most likely solve it by installing the `postgres-contrib` package.
+Note `citext` is part of PostgreSQL itself and is bundled with it in most operating systems and package managers. `mix phx.gen.auth` takes care of creating the extension and no extra work is necessary in the majority of cases. If by any chance your package manager splits `citext` into a separate package, you will get an error while migrating, and you can most likely solve it by installing the `postgres-contrib` package.
 
 ### Concurrent tests
 
 The generated tests run concurrently if you are using a database that supports concurrent tests, which is the case of PostgreSQL.
 
 ## More about `mix phx.gen.auth`
 
-Check out `mix phx.gen.auth` for more details, such as using different password hashing library, customizing the web module namespace, generating binary id type, configuring the default options, and using custom table names.
+Check out `mix phx.gen.auth` for more details, such as using a different password hashing library, customizing the web module namespace, generating binary id type, configuring the default options, and using custom table names.
 
 ## Additional resources
 

guides/controllers.md

@@ -367,7 +367,7 @@ When we reload our [welcome page], we see that we've been redirected to `/redire
 
 If we care to, we can open up our developer tools, click on the network tab, and visit our root route again. We see two main requests for this page - a get to `/` with a status of `302`, and a get to `/redirect_test` with a status of `200`.
 
-Notice that the redirect function takes `conn` as well as a string representing a relative path within our application. For security reasons, the `:to` helper can only redirect for paths within your application. If you want to redirect to a fully-qualified path or an external URL, you should use `:external` instead:
+Notice that the redirect function takes `conn` as well as a string representing a relative path within our application. For security reasons, the `:to` helper can only redirect to paths within your application. If you want to redirect to a fully-qualified path or an external URL, you should use `:external` instead:
 
 ```elixir
 def index(conn, _params) do
@@ -425,7 +425,7 @@ Phoenix does not enforce which keys are stored in the flash. As long as we are i
 
 ## Action fallback
 
-Action fallback allows us to centralize error handling code in plugs which are called when a controller action fails to return a [`%Plug.Conn{}`](`t:Plug.Conn.t/0`) struct. These plugs receive both the `conn` which was originally passed to the controller action along with the return value of the action.
+Action fallback allows us to centralize error handling code in plugs, which are called when a controller action fails to return a [`%Plug.Conn{}`](`t:Plug.Conn.t/0`) struct. These plugs receive both the `conn` which was originally passed to the controller action along with the return value of the action.
 
 Let's say we have a `show` action which uses [`with`](`with/1`) to fetch a blog post and then authorize the current user to view that blog post. In this example we might expect `fetch_post/1` to return `{:error, :not_found}` if the post is not found and `authorize_user/3` might return `{:error, :unauthorized}` if the user is unauthorized. We could use `ErrorView` which is generated by Phoenix for every new application to handle these error paths accordingly:
 

guides/deployment/deployment.md

@@ -108,7 +108,7 @@ $ MIX_ENV=prod mix ecto.migrate
 $ PORT=4001 MIX_ENV=prod mix phx.server
 ```
 
-And that's it. Next you can use one of our official guides to deploy:
+And that's it. Next, you can use one of our official guides to deploy:
 
   * [with Elixir's releases](releases.html)
   * [to Gigalixir](gigalixir.html), an Elixir-centric Platform as a Service (PaaS)

guides/deployment/fly.md

@@ -16,7 +16,7 @@ The main goal for this guide is to get a Phoenix application running on [Fly.io]
 
 ## Sections
 
-Let's separate this process into a few steps so we can keep track of where we are.
+Let's separate this process into a few steps, so we can keep track of where we are.
 
 - Install the Fly.io CLI
 - Sign up for Fly.io
@@ -36,7 +36,7 @@ We can [sign up for an account](https://fly.io/docs/getting-started/login-to-fly
 $ fly auth signup
 ```
 
-Or signin.
+Or sign in.
 
 ```console
 $ flyctl auth login
@@ -67,7 +67,7 @@ The `fly launch` command also created a `fly.toml` file for you. This is where y
 
 ### Storing secrets on Fly.io
 
-You may also have some secrets you'd like set on your app.
+You may also have some secrets you'd like to set on your app.
 
 Use [`fly secrets`](https://fly.io/docs/reference/secrets/#setting-secrets) to configure those.
 
@@ -83,7 +83,7 @@ When you want to deploy changes to your application, use `fly deploy`.
 $ fly deploy
 ```
 
-Note: On Apple Silicon (M1) computers, docker runs cross platform builds using qemu which might not always work. If you get a segmentation fault error like the following:
+Note: On Apple Silicon (M1) computers, docker runs cross-platform builds using qemu which might not always work. If you get a segmentation fault error like the following:
 
 ```
  => [build  7/17] RUN mix deps.get --only
@@ -259,7 +259,7 @@ $ fly scale count 2
 Count changed to 2
 ```
 
-Checking the status we can see what happened.
+Checking the status, we can see what happened.
 
 ```console
 $ fly status
@@ -299,7 +299,7 @@ The IEx prompt is included to help show the IP address of the node we are connec
 
 Fly makes it easy to deploy instances closer to your users. Through the magic of DNS, users are directed to the nearest region where your application is located. You can read more about [Fly.io regions here](https://fly.io/docs/reference/regions/).
 
-Starting back from our baseline of a single instance running in `sea` which is Seattle, Washington (US), Let's add the region `ewr` which is Parsippany, NJ (US). This puts an instance on both coasts of the US.
+Starting back from our baseline of a single instance running in `sea` which is Seattle, Washington (US), let's add the region `ewr` which is Parsippany, NJ (US). This puts an instance on both coasts of the US.
 
 ```console
 $ fly regions add ewr

guides/deployment/gigalixir.md

@@ -10,7 +10,7 @@ Our main goal for this guide is to get a Phoenix application running on Gigalixi
 
 ## Steps
 
-Let's separate this process into a few steps so we can keep track of where we are.
+Let's separate this process into a few steps, so we can keep track of where we are.
 
 - Initialize Git repository
 - Install the Gigalixir CLI
@@ -23,7 +23,7 @@ Let's separate this process into a few steps so we can keep track of where we ar
 
 ## Initializing Git repository
 
-If you haven't already, we'll need to commit our files git. We can do so by running the following commands in our project directory:
+If you haven't already, we'll need to commit our files to git. We can do so by running the following commands in our project directory:
 
 ```console
 $ git init
@@ -93,7 +93,7 @@ $ echo 'erlang_version=22.3' >> elixir_buildpack.config
 $ echo 'node_version=12.16.3' > phoenix_static_buildpack.config
 ```
 
-Phoenix v1.6 uses `esbuild` to compile your assets but all Gigalixir images come with `npm`, so we will configure `npm` directly to deploy our assets. Add a `assets/package.json` file if you don't have any with the following:
+Phoenix v1.6 uses `esbuild` to compile your assets, but all Gigalixir images come with `npm`, so we will configure `npm` directly to deploy our assets. Add a `assets/package.json` file if you don't have any with the following:
 
 ```json
 {
@@ -103,7 +103,7 @@ Phoenix v1.6 uses `esbuild` to compile your assets but all Gigalixir images come
 }
 ```
 
-Finally don't forget to commit:
+Finally, don't forget to commit:
 
 ```console
 $ git add elixir_buildpack.config phoenix_static_buildpack.config assets/package.json

guides/deployment/heroku.md

@@ -24,13 +24,13 @@ Heroku is a great platform and Elixir performs well on it. However, you may run
 - [The built-in observer](https://elixir-lang.org/getting-started/debugging.html#observer) can't be used with Heroku.
   - Heroku does allow for connection into your dyno, but you won't be able to use the observer to watch the state of your dyno.
 
-If you are just getting started or you don't expect to use the features above, Heroku should be enough for your needs. For instance, if you are migrating an existing application running on Heroku to Phoenix, keeping a similar set of features, Elixir will perform just as well or even better than your current stack.
+If you are just getting started, or you don't expect to use the features above, Heroku should be enough for your needs. For instance, if you are migrating an existing application running on Heroku to Phoenix, keeping a similar set of features, Elixir will perform just as well or even better than your current stack.
 
 If you want a platform-as-a-service without these limitations, try [Gigalixir](gigalixir.html). If you would rather deploy to a cloud platform, such as EC2, Google Cloud, etc, consider using `mix release`.
 
 ## Steps
 
-Let's separate this process into a few steps so we can keep track of where we are.
+Let's separate this process into a few steps, so we can keep track of where we are.
 
 - Initialize Git repository
 - Sign up for Heroku
@@ -44,7 +44,7 @@ Let's separate this process into a few steps so we can keep track of where we ar
 
 [Git](https://git-scm.com/) is a popular decentralized revision control system and is also used to deploy apps to Heroku.
 
-Before we can push to Heroku we'll need to initialize a local Git repository and commit our files to it. We can do so by running the following commands in our project directory:
+Before we can push to Heroku, we'll need to initialize a local Git repository and commit our files to it. We can do so by running the following commands in our project directory:
 
 ```console
 $ git init
@@ -70,7 +70,7 @@ The Heroku CLI, part of the Toolbelt, is useful to create Heroku applications, l
 
 ## Create and Set Up Heroku Application
 
-There are two different ways to deploy a Phoenix app on Heroku. We could use Heroku buildpacks or their container stack. The difference between these two approaches is in how we tell Heroku to treat our build. In buildpack case, we need to update our apps configuration on Heroku to use Phoenix/Elixir specific buildpacks. On container approach, we have more control on how we want to set up our app and we can define our container image using `Dockerfile` and `heroku.yml`. This section will explore the buildpack approach. In order to use Dockerfile, it is often recommended to convert our app to use releases, which we will describe later on.
+There are two different ways to deploy a Phoenix app on Heroku. We could use Heroku buildpacks or their container stack. The difference between these two approaches is in how we tell Heroku to treat our build. In buildpack case, we need to update our apps configuration on Heroku to use Phoenix/Elixir specific buildpacks. On container approach, we have more control on how we want to set up our app, and we can define our container image using `Dockerfile` and `heroku.yml`. This section will explore the buildpack approach. In order to use Dockerfile, it is often recommended to convert our app to use releases, which we will describe later on.
 
 ### Create Application
 
@@ -93,7 +93,7 @@ https://mysterious-meadow-6277.herokuapp.com/ | https://git.heroku.com/mysteriou
 
 > Note: if we hadn't initialized our Git repository before we ran the `heroku create` command, we wouldn't have our Heroku remote repository properly set up at this point. We can set that up manually by running: `heroku git:remote -a [our-app-name].`
 
-The buildpack uses a predefined Elixir and Erlang version but to avoid surprises when deploying, it is best to explicitly list the Elixir and Erlang version we want in production to be the same we are using during development or in your continuous integration servers. This is done by creating a config file named `elixir_buildpack.config` in the root directory of your project with your target version of Elixir and Erlang:
+The buildpack uses a predefined Elixir and Erlang version, but to avoid surprises when deploying, it is best to explicitly list the Elixir and Erlang version we want in production to be the same we are using during development or in your continuous integration servers. This is done by creating a config file named `elixir_buildpack.config` in the root directory of your project with your target version of Elixir and Erlang:
 
 ```
 # Elixir version
@@ -137,7 +137,7 @@ When using this buildpack, you want to delegate all asset bundling to `npm`. So
 }
 ```
 
-The Phoenix Static buildpack uses a predefined Node.js version but to avoid surprises when deploying, it is best to explicitly list the Node.js version we want in production to be the same we are using during development or in your continuous integration servers. This is done by creating a config file named `phoenix_static_buildpack.config` in the root directory of your project with your target version of Node.js:
+The Phoenix Static buildpack uses a predefined Node.js version, but to avoid surprises when deploying, it is best to explicitly list the Node.js version we want in production to be the same we are using during development or in your continuous integration servers. This is done by creating a config file named `phoenix_static_buildpack.config` in the root directory of your project with your target version of Node.js:
 
 ```
 # Node.js version