docs: fix grammar and spelling [ci skip]

guides/source/5_0_release_notes.md

@@ -254,7 +254,7 @@ Please refer to the [Changelog][railties] for detailed changes.
     using the environment variable `RAILS_LOG_TO_STDOUT`.
     ([Pull Request](https://github.com/rails/rails/pull/23734))
 
-*   Enable HSTS with IncludeSudomains header for new applications.
+*   Enable HSTS with IncludeSubdomains header for new applications.
     ([Pull Request](https://github.com/rails/rails/pull/23852))
 
 *   The application generator writes a new file `config/spring.rb`, which tells

guides/source/plugins.md

@@ -61,7 +61,7 @@ You should see:
   1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
 ```
 
-This will tell you that everything got generated properly and you are ready to start adding functionality.
+This will tell you that everything got generated properly, and you are ready to start adding functionality.
 
 Extending Core Classes
 ----------------------
@@ -430,7 +430,7 @@ class ApplicationRecord < ActiveRecord::Base
 end
 ```
 
-Run `bin/test` one final time and you should see:
+Run `bin/test` one final time, and you should see:
 
 ```
   6 runs, 6 assertions, 0 failures, 0 errors, 0 skips
@@ -482,7 +482,7 @@ For more information about publishing gems to RubyGems, see: [Publishing your ge
 RDoc Documentation
 ------------------
 
-Once your plugin is stable and you are ready to deploy, do everyone else a favor and document it! Luckily, writing documentation for your plugin is easy.
+Once your plugin is stable, and you are ready to deploy, do everyone else a favor and document it! Luckily, writing documentation for your plugin is easy.
 
 The first step is to update the README file with detailed information about how to use your plugin. A few key things to include are:
 
@@ -491,7 +491,7 @@ The first step is to update the README file with detailed information about how
 * How to add the functionality to the app (several examples of common use cases)
 * Warnings, gotchas or tips that might help users and save them time
 
-Once your README is solid, go through and add rdoc comments to all of the methods that developers will use. It's also customary to add `#:nodoc:` comments to those parts of the code that are not included in the public API.
+Once your README is solid, go through and add rdoc comments to all the methods that developers will use. It's also customary to add `#:nodoc:` comments to those parts of the code that are not included in the public API.
 
 Once your comments are good to go, navigate to your plugin directory and run:
 

guides/source/webpacker.md

@@ -93,7 +93,7 @@ Usage
 
 With Webpacker installed, by default any JavaScript file in the `app/javascripts/packs` directory will get compiled to its own pack file.
 
-So if you have a file called `app/javascript/packs/application.js`, Webpacker will create a pack called `application`, and you can add it to your Rails application with the code `<%= javascript_pack_tag "application" %>`. With that in place, in development, Rails will re-compile the `application.js` file every time it changes and you load a page that uses that pack. Typically, the file in the actual `packs` directory will be a manifest that mostly loads other files, but it can also have arbitrary JavaScript code.
+So if you have a file called `app/javascript/packs/application.js`, Webpacker will create a pack called `application`, and you can add it to your Rails application with the code `<%= javascript_pack_tag "application" %>`. With that in place, in development, Rails will re-compile the `application.js` file every time it changes, and you load a page that uses that pack. Typically, the file in the actual `packs` directory will be a manifest that mostly loads other files, but it can also have arbitrary JavaScript code.
 
 The default pack created for you by Webpacker will link to Rails default JavaScript packages if they have been included in the project:
 
@@ -126,7 +126,7 @@ app/javascript:
       └── logo.svg
 ```
 
-Typically the pack file itself is largely a manifest that uses `import` or `require` to load the necessary files and may also do some initialization.
+Typically, the pack file itself is largely a manifest that uses `import` or `require` to load the necessary files and may also do some initialization.
 
 If you want to change these directories, you can adjust the `source_path` (default `app/javascript`) and `source_entry_path` (default `packs`) in the `configuration/webpacker.yml` file.
 
@@ -174,7 +174,7 @@ The Webpacker ActionView helpers for static assets correspond to asset pipeline
 |favicon_link_tag  |favicon_pack_tag  |
 |image_tag         |image_pack_tag    |
 
-Also the generic helper `asset_pack_path` takes the local location of a file and returns its webpacker location for use in Rails views.
+Also, the generic helper `asset_pack_path` takes the local location of a file and returns its webpacker location for use in Rails views.
 
 You can also access the image by directly referencing the file from a CSS file in `app/javascript`.
 
@@ -186,7 +186,7 @@ Gem authors of Rails engines who wish to support consumers using Webpacker are e
 
 ### Hot Module Replacement (HMR)
 
-Webpacker out-of-the-box supports HMR with webpack-dev-server and you can toggle it by setting dev_server/hmr option inside webpacker.yml.
+Webpacker out-of-the-box supports HMR with webpack-dev-server, and you can toggle it by setting dev_server/hmr option inside webpacker.yml.
 
 Check out [webpack's documentation on DevServer](https://webpack.js.org/configuration/dev-server/#devserver-hot) for more information.
 

guides/source/working_with_javascript_in_rails.md

@@ -262,7 +262,7 @@ this generates
 </form>
 ```
 
-Since it's just a `<form>`, all of the information on `form_with` also applies.
+Since it's just a `<form>`, all the information on `form_with` also applies.
 
 ### Customize Remote Elements
 
@@ -394,7 +394,7 @@ The `ajax:before` event can manipulate form data before serialization and the
 
 If you stop the `ajax:aborted:file` event, the default behavior of allowing the
 browser to submit the form via normal means (i.e. non-Ajax submission) will be
-canceled and the form will not be submitted at all. This is useful for
+canceled, and the form will not be submitted at all. This is useful for
 implementing your own Ajax file upload workaround.
 
 Note, you should use `return false` to prevent an event for `jquery-ujs` and
@@ -551,7 +551,7 @@ You can then submit this token as a `X-CSRF-Token` header for your
 Ajax request. You do not need to add a CSRF token for GET requests,
 only non-GET ones.
 
-You can read more about about Cross-Site Request Forgery in the [Security guide](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf).
+You can read more about Cross-Site Request Forgery in the [Security guide](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf).
 
 Other Resources
 ---------------