Grammar fixes for docs

Fixes to spelling and punctuation for consistency and readability.

docs/Acceptable-Formulae.md

@@ -38,7 +38,7 @@ There are exceptions:
 | emacs, vim         | [Too popular to move to dupes](https://github.com/Homebrew/homebrew/pull/21594#issuecomment-21968819) |
 | subversion         | Originally added for 10.5, but people want the latest version                                         |
 | libcurl            | Some formulae require a newer version than macOS provides                                             |
-| openssl            | macOS's openssl is deprecated & outdated.                                                             |
+| openssl            | macOS's openssl is deprecated & outdated                                                              |
 | libxml2            | Historically, macOS's libxml2 has been buggy                                                          |
 
 We also maintain [a tap](https://github.com/Homebrew/homebrew-dupes) that
@@ -74,7 +74,7 @@ due to upstream changes and we can’t provide [bottles](Bottles.md) for them.
 ### Bindings
 First check that there is not already a binding available via
 [`gem`](https://rubygems.org/) or [`pip`](http://www.pip-installer.org/)
-etc..
+etc.
 
 If not, then put bindings in the formula they bind to. This is more
 useful to people. Just install the stuff! Having to faff around with

docs/Brew-Test-Bot.md

@@ -3,7 +3,7 @@
 `brew test-bot` is the name for the automated review and testing system funded
 by [our Kickstarter in 2013](https://www.kickstarter.com/projects/homebrew/brew-test-bot).
 
-It comprises of four Mac Minis running in a data centre in England which host
+It comprises four Mac Minis running in a data centre in England which host
 [a Jenkins instance at https://bot.brew.sh](https://bot.brew.sh) and run the
 [`brew test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb)
 Ruby script to perform automated testing of commits to the master branch, pull
@@ -15,7 +15,7 @@ The bot automatically builds pull requests and updates their status depending
 on the result of the job.
 
 For example, a job which has been queued but not yet started will have a
-section in the pull-request that looks like this:
+section in the pull request that looks like this:
 
 
 ![Triggered Pull Request](images/brew-test-bot-triggered-pr.png)

docs/Formula-Cookbook.md

@@ -288,13 +288,13 @@ Name the formula like the project markets the product. So it’s `pkg-config`, n
 
 The only exception is stuff like “Apache Ant”. Apache sticks “Apache” in front of everything, but we use the formula name `ant`. We only include the prefix in cases like *GNUplot* (because it’s part of the name) and *GNU Go* (because everyone calls it “GNU go”—nobody just calls it “Go”). The word “Go” is too common and there are too many implementations of it.
 
-If you’re not sure about the name check the homepage, and check the Wikipedia page and [what Debian call it](https://www.debian.org/distrib/packages).
+If you’re not sure about the name check the homepage, and check the Wikipedia page and [what Debian calls it](https://www.debian.org/distrib/packages).
 
-Where Homebrew already has a formula called `foo` we typically do not accept requests to replace that formula with something else also named `foo`. This is to avoid both confusing and surprising users’ expectation.
+Where Homebrew already has a formula called `foo` we typically do not accept requests to replace that formula with something else also named `foo`. This is to avoid both confusing and surprising users’ expectations.
 
 When two formulae share an upstream name, e.g. [`AESCrypt`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/aescrypt.rb) and [`AESCrypt`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/aescrypt-packetizer.rb) the newer formula must typically adapt the name to avoid conflict with the current formula.
 
-If you’re *still* not sure, just commit. We’ll apply some arbitrary rule and make a decision :wink:.
+If you’re *still* not sure, just commit. We’ll apply some arbitrary rule and make a decision 😉.
 
 When importing classes, Homebrew will require the formula and then create an instance of the class. It does this by assuming the formula name can be directly converted to the class name using a `regexp`. The rules are simple:
 

docs/Gems,-Eggs-and-Perl-Modules.md

@@ -81,7 +81,7 @@ or use this:
 
 **However all versions of RubyGems before 1.3.6 are buggy** and ignore
 the above setting. Sadly a fresh install of Snow Leopard comes with
-1.3.5. Currently the only known way to get round this is to upgrade
+1.3.5. Currently the only known way to get around this is to upgrade
 rubygems as root:
 
 `sudo gem update --system`

docs/How-To-Open-a-Homebrew-Pull-Request.md

@@ -25,7 +25,7 @@ Depending on the change you want to make, you need to send the pull request to t
 3. Add your pushable forked repository with `git remote add <YOUR_USERNAME> https://github.com/<YOUR_USERNAME>/homebrew-core.git`
  * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
 
-For formulae in central taps other than `homebrew/core`, such as `homebrew/science` or `homebrew/games`, substitute that tap's name for `homebrew/core` in each step, and alter the GitHub repository URLs as necessary.
+For formulae in central taps other than `homebrew/core`, such as `homebrew/science` or `homebrew/nginx`, substitute that tap's name for `homebrew/core` in each step, and alter the GitHub repository URLs as necessary.
 
 ## Create your pull request from a new branch
 

docs/Node-for-Formula-Authors.md

@@ -14,9 +14,9 @@ where `libexec` is the destination prefix (usually the `libexec` variable).
 
 # Download URL
 
-If the Node module is also available on the npm registry, we prefer npm hosted release tarballs over GitHub (or elsewhere) hosted source tarballs. The advantages of these tarballs are that they doesn't include the files from the `.npmignore` (such as tests) resulting in a smaller download size and that a possibly transpilation step is already done (e.g. no need to compile CoffeeScript files as a build step).
+If the Node module is also available on the npm registry, we prefer npm hosted release tarballs over GitHub (or elsewhere) hosted source tarballs. The advantages of these tarballs are that they don't include the files from the `.npmignore` (such as tests) resulting in a smaller download size and that any possible transpilation step is already done (e.g. no need to compile CoffeeScript files as a build step).
 
-The npm registry URLs have usually the format of:
+The npm registry URLs usually have the format of:
 
 ```
 https://registry.npmjs.org/<name>/-/<name>-<version>.tgz
@@ -26,33 +26,33 @@ Alternatively you could curl the JSON at `https://registry.npmjs.org/<name>` and
 
 # Dependencies
 
-Node modules, which are compatible with the latest Node version should declare a dependencies on the `node` formula.
+Node modules which are compatible with the latest Node version should declare a dependency on the `node` formula.
 
 ```ruby
 depends_on "node"
 ```
 
-If your formula requires to be executed with an older Node version you must vendor this older Node version as done in the [`kibana` formula](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb).
+If your formula requires being executed with an older Node version you must vendor this older Node version as done in the [`kibana` formula](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb).
 
 ### Special requirements for native addons
 
-If your node module is a native addon or has a native addon somewhere in it's dependency tree you have to declare an additional dependency. Since the compilation of the native addon results in a invocation of `node-gyp` we need an additional build time dependency on `:python` (because gyp depends on Python 2.7).
+If your node module is a native addon or has a native addon somewhere in its dependency tree you have to declare an additional dependency. Since the compilation of the native addon results in a invocation of `node-gyp` we need an additional build time dependency on `:python` (because gyp depends on Python 2.7).
 
 ```ruby
 depends_on :python => :build
 ```
 
-Please also note, that such a formula would only be compatible with the same Node major version it originally was compiled with. This means that we need to revision every formula with a Node native addon with every major version bump of the `node` formula. To make sure we don't overlook your formula on a Node major version bump, write a meaningful test which would fail in such a case (invoked with an ABI incompatible Node version).
+Please also note that such a formula would only be compatible with the same Node major version it originally was compiled with. This means that we need to revision every formula with a Node native addon with every major version bump of the `node` formula. To make sure we don't overlook your formula on a Node major version bump, write a meaningful test which would fail in such a case (invoked with an ABI incompatible Node version).
 
 # Installation
 
 Node modules should be installed to `libexec`. This prevents the Node modules from contaminating the global `node_modules`, which is important so that npm doesn't try to manage Homebrew-installed Node modules.
 
-In the following we distinguish between 2 type of Node module using formulae:
+In the following we distinguish between two types of Node modules using formulae:
 * formulae for standard Node modules compatible with npm's global module format which should use [`std_npm_install_args`](#installing-global-style-modules-with-std_npm_install_args-to-libexec) (like [`azure-cli`](https://github.com/Homebrew/homebrew-core/blob/d93fe9ba3bcc9071b699c8da4e7d733518d3337e/Formula/azure-cli.rb) or [`autocode`](https://github.com/Homebrew/homebrew-core/blob/1a670a6269e1e07f86683c2d164977c9bd8a3fb6/Formula/autocode.rb)) and
-* formulae were the `npm install` step is only one of multiple not exclusively Node related install steps (not compatible with npm's global module format) which have to use [`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args) (like [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb) or [`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb))
+* formulae where the `npm install` step is only one of multiple not exclusively Node related install steps (not compatible with npm's global module format) which have to use [`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args) (like [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb) or [`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb))
 
-Both methods have in common, that they are setting the correct environment for using npm inside Homebrew up and returning the arguments for invoking `npm install` for their specific use cases. This includes fixing an important edge case with the npm cache (Caused by Homebrew's redirection of `$HOME` during the build and test process) by using our own custom `npm_cache` inside `HOMEBREW_CACHE`, which would otherwise result in very long build times and high disk space usage.
+Both methods have in common that they are setting the correct environment for using npm inside Homebrew and are returning the arguments for invoking `npm install` for their specific use cases. This includes fixing an important edge case with the npm cache (caused by Homebrew's redirection of `$HOME` during the build and test process) by using our own custom `npm_cache` inside `HOMEBREW_CACHE`, which would otherwise result in very long build times and high disk space usage.
 
 To use them you have to require the Node language module at the beginning of your formula file with:
 
@@ -62,13 +62,13 @@ require "language/node"
 
 ### Installing global style modules with `std_npm_install_args` to libexec
 
-In your formula's `install` method, simply cd to the top level of your Node module if necessary and than use `system` to invoke `npm install` with `Language::Node.std_npm_install_args` like:
+In your formula's `install` method, simply cd to the top level of your Node module if necessary and then use `system` to invoke `npm install` with `Language::Node.std_npm_install_args` like:
 
 ```ruby
 system "npm", "install", *Language::Node.std_npm_install_args(libexec)
 ```
 
-This will install your Node module in npm's global module style with a custom prefix to `libexec`. All your modules executable will be automatically resolved by npm into `libexec/"bin"` for you, which is not symlinked into Homebrew's prefix. We need to make sure these are installed. Do this with we need to symlink all executables to `bin` with:
+This will install your Node module in npm's global module style with a custom prefix to `libexec`. All your modules' executables will be automatically resolved by npm into `libexec/"bin"` for you, which is not symlinked into Homebrew's prefix. We need to make sure these are installed. To do this we need to symlink all executables to `bin` with:
 
 ```ruby
 bin.install_symlink Dir["#{libexec}/bin/*"]
@@ -76,13 +76,13 @@ bin.install_symlink Dir["#{libexec}/bin/*"]
 
 ### Installing module dependencies locally with `local_npm_install_args`
 
-In your formula's `install` method, do any installation steps which need to be done before the `npm install` step and than cd to the top level of the included Node module. Then, use `system` with `Language::Node.local_npm_install_args` to invoke `npm install` like:
+In your formula's `install` method, do any installation steps which need to be done before the `npm install` step and then cd to the top level of the included Node module. Then, use `system` with `Language::Node.local_npm_install_args` to invoke `npm install` like:
 
 ```ruby
 system "npm", "install", *Language::Node.local_npm_install_args
 ```
 
-This will install all of your Node modules dependencies to your local build path. You can now continue with your build steps and take care of the installation into the Homebrew `prefix` by your own, following the [general Homebrew formula instructions](https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md).
+This will install all of your Node modules dependencies to your local build path. You can now continue with your build steps and take care of the installation into the Homebrew `prefix` on your own, following the [general Homebrew formula instructions](https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md).
 
 # Example
 

docs/Prose-Style-Guidelines.md

@@ -44,8 +44,8 @@ We prefer:
 * More generally, parallel list item structure
 * Capitalize all list items if you want, even if they're not complete sentences; just be consistent within each list, and preferably, throughout the whole page
 * Use a subordinate list item instead of dropping a multi-sentence paragraph-long item into a list of sentence fragments
-* Prefer Markdown over other markup formats unless their specific features are needed.
-* GitHub flavored Markdown. GitHub's implementation is the standard, period.
+* Prefer Markdown over other markup formats unless their specific features are needed
+ * GitHub Flavored Markdown. GitHub's implementation is the standard, period.
 
 ### Typographical conventions
 

docs/Python-for-Formula-Authors.md

@@ -4,7 +4,7 @@ This document explains how to successfully use Python in a Homebrew formula.
 
 Homebrew draws a distinction between Python **applications** and Python **libraries**. The difference is that users generally do not care that applications are written in Python; it is unusual that a user would expect to be able to `import foo` after installing an application. Examples of applications are `ansible` and `jrnl`.
 
-Python libraries exist to be imported from other Python modules; they are often dependencies of Python applications. They are usually no more than incidentally useful from a Terminal.app command line. Examples of libraries are `py2cairo` and the bindings that are installed by `protobuf --with-python`.
+Python libraries exist to be imported by other Python modules; they are often dependencies of Python applications. They are usually no more than incidentally useful from a Terminal.app command line. Examples of libraries are `py2cairo` and the bindings that are installed by `protobuf --with-python`.
 
 Bindings are a special case of libraries that allow Python code to interact with a library or application implemented in another language.
 
@@ -22,7 +22,7 @@ where `prefix` is the destination prefix (usually `libexec` or `prefix`).
 
 # Python module dependencies
 
-In general, applications should unconditionally bundle all of their dependencies and libraries should install any unsatisfied dependencies; these strategies are discussed in depth in the following sections.
+In general, applications should unconditionally bundle all of their dependencies and libraries and should install any unsatisfied dependencies; these strategies are discussed in depth in the following sections.
 
 In the rare instance that this proves impractical, you can specify a Python module as an external dependency using the syntax:
 
@@ -49,9 +49,9 @@ Applications that are compatible with Python 2 **should** use the Apple-provided
 ```ruby
 depends_on :python if MacOS.version <= :snow_leopard
 ```
-No explicit Python dependency is needed on recent OS versions since /usr/bin is always in `PATH` for Homebrew formulæ; on Leopard and older, the python in `PATH` is used if it's at least version 2.7, or else Homebrew's python is installed.
+No explicit Python dependency is needed on recent OS versions since /usr/bin is always in `PATH` for Homebrew formulae; on Leopard and older, the python in `PATH` is used if it's at least version 2.7, or else Homebrew's python is installed.
 
-Formulæ for apps that require Python 3 **should** declare an unconditional dependency on `:python3`, which will cause the formula to use the first python3 discovered in `PATH` at install time (or install Homebrew's if there isn't one). These apps **must** work with the current Homebrew python3 formula.
+Formulae for apps that require Python 3 **should** declare an unconditional dependency on `:python3`, which will cause the formula to use the first python3 discovered in `PATH` at install time (or install Homebrew's if there isn't one). These apps **must** work with the current Homebrew python3 formula.
 
 ## Installing
 
@@ -183,7 +183,7 @@ Sometimes we have to `inreplace` a `Makefile` to use our prefix for the python b
 
 Libraries **should** declare a dependency on `:python` or `:python3` as appropriate, which will respectively cause the formula to use the first python or python3 discovered in `PATH` at install time. If a library supports both Python 2.x and Python 3.x, the `:python` dependency **should** be `:recommended` (i.e. built by default) and the :python3 dependency should be `:optional`. Python 2.x libraries **must** function when they are installed against either the system Python or Homebrew Python.
 
-Formulæ that declare a dependency on `:python` will always be bottled against Homebrew's python, since we cannot in general build binary packages that can be imported from both Pythons. Users can add `--build-from-source` after `brew install` to compile against whichever python is in `PATH`.
+Formulae that declare a dependency on `:python` will always be bottled against Homebrew's python, since we cannot in general build binary packages that can be imported from both Pythons. Users can add `--build-from-source` after `brew install` to compile against whichever python is in `PATH`.
 
 ## Installing
 

docs/Querying-Brew.md

@@ -31,9 +31,9 @@ The schema itself is not currently documented outside of the code that generates
 
 ## Examples
 
-_The top-level element of the JSON is always an array, so the `map` operator is used to act on the data._
+_The top-level element of the JSON output is always an array, so the `map` operator is used to act on the data._
 
-### Prety-print a single formula's info
+### Pretty-print a single formula's info
 
 `brew info --json=v1 tig | jq .`
 
@@ -63,6 +63,6 @@ To find the names of normal (not keg-only) formulae that are installed, but not
 
 ## Concluding remarks
 
-Using the JSON output, queries can be made against Homebrew with less risk of being broken due to Homebrew code changes, and without needing to understand Homebrew's ruby internals.
+Using the JSON output, queries can be made against Homebrew with less risk of being broken due to Homebrew code changes, and without needing to understand Homebrew's Ruby internals.
 
-If the JSON does not provide some information that it ought to, please submit request, preferably with a patch to add the desired information.
+If the JSON output does not provide some information that it ought to, please submit a request, preferably with a patch to add the desired information.

docs/Tips-N'-Tricks.md

@@ -5,7 +5,7 @@
 The supported method of installing specific versions of
 some formulae is to see if there is a versions formula like e.g. `gcc@6` available. If the version you’re looking for isn’t available, consider [opening a pull request](How-To-Open-a-Homebrew-Pull-Request.md)!
 
-### Installing directly from pull-requests
+### Installing directly from pull requests
 You can [browse pull requests](https://github.com/Homebrew/homebrew-core/pulls)
 and install through the direct link. For example Python 3.3.0 pull request [Homebrew/homebrew#15199](https://github.com/Homebrew/homebrew/pull/15199)
 

docs/Versions.md

 # Versions
 
-Now that [Homebrew/versions](https://github.com/homebrew/homebrew-versions) has been deprecated [Homebrew/core](https://github.com/homebrew/homebrew-core) supports multiple versions of formulae with a new naming format.
+Now that [Homebrew/versions](https://github.com/homebrew/homebrew-versions) has been deprecated, [Homebrew/core](https://github.com/homebrew/homebrew-core) supports multiple versions of formulae with a new naming format.
 
 In [Homebrew/versions](https://github.com/homebrew/homebrew-versions) the formula for GCC 6 was named `gcc6.rb` and began `class Gcc6 < Formula`. In [Homebrew/core](https://github.com/homebrew/homebrew-core) this same formula is named `gcc@6.rb` and begins `class GccAT6 < Formula`.
 

docs/brew-tap.md

@@ -73,7 +73,7 @@ If you need a formula to be installed from a particular tap, you can use fully
 qualified names to refer to them.
 
 For example, you can create a tap for an alternative `vim` formula. Without
-pinning it, the behavior will be
+pinning it, the behaviour will be
 
 ```bash
 brew install vim                     # installs from homebrew/core