Copyedit docs (#6275)

28 files changed, 111 insertions, 111 deletions

diff --git a/docs/content/doc/advanced/api-usage.en-us.md b/docs/content/doc/advanced/api-usage.en-us.md
index 0000465c49..d5a7b3a6ef 100644
--- a/docs/content/doc/advanced/api-usage.en-us.md
+++ b/docs/content/doc/advanced/api-usage.en-us.md
@@ -31,18 +31,18 @@ Gitea supports these methods of API authentication:
 - `access_token=...` parameter in URL query string
 - `Authorization: token ...` header in HTTP headers
 
-All of these methods accept the same apiKey token type.  You can
+All of these methods accept the same API key token type.  You can
 better understand this by looking at the code -- as of this writing,
 Gitea parses queries and headers to find the token in
 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47).
 
-You can create an apiKey token via your gitea install's web interface:
+You can create an API key token via your Gitea installation's web interface:
 `Settings | Applications | Generate New Token`.
 
 ### More on the `Authorization:` header
 
 For historical reasons, Gitea needs the word `token` included before
-the apiKey token in an authorization header, like this:
+the API key token in an authorization header, like this:
 
 ```
 Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
diff --git a/docs/content/doc/advanced/config-cheat-sheet.en-us.md b/docs/content/doc/advanced/config-cheat-sheet.en-us.md
index 40c96efa33..2fc78efcb3 100644
--- a/docs/content/doc/advanced/config-cheat-sheet.en-us.md
+++ b/docs/content/doc/advanced/config-cheat-sheet.en-us.md
@@ -44,7 +44,7 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
 
 - `ROOT`: **~/gitea-repositories/**: Root path for storing all repository data. It must be
    an absolute path.
-- `SCRIPT_TYPE`: **bash**: The script type this server supports, usually this is `bash`,
+- `SCRIPT_TYPE`: **bash**: The script type this server supports. Usually this is `bash`,
    but some users report that only `sh` is available.
 - `ANSI_CHARSET`: **\<empty\>**: The default charset for an unrecognized charset.
 - `FORCE_PRIVATE`: **false**: Force every new repository to be private.
diff --git a/docs/content/doc/advanced/customizing-gitea.en-us.md b/docs/content/doc/advanced/customizing-gitea.en-us.md
index fb61470fa7..983fe5f0c7 100644
--- a/docs/content/doc/advanced/customizing-gitea.en-us.md
+++ b/docs/content/doc/advanced/customizing-gitea.en-us.md
@@ -18,7 +18,7 @@ menu:
 Customizing Gitea is typically done using the `custom` folder. This is the central
 place to override configuration settings, templates, etc.
 
-If Gitea is deployed from binary, all default paths will be relative to the gitea
+If Gitea is deployed from binary, all default paths will be relative to the Gitea
 binary. If installed from a distribution, these paths will likely be modified to
 the Linux Filesystem Standard. Gitea will create required folders, including `custom/`.
 Application settings are configured in `custom/conf/app.ini`. Distributions may
diff --git a/docs/content/doc/advanced/external-renderers.en-us.md b/docs/content/doc/advanced/external-renderers.en-us.md
index 52374bc01d..e1d773725c 100644
--- a/docs/content/doc/advanced/external-renderers.en-us.md
+++ b/docs/content/doc/advanced/external-renderers.en-us.md
@@ -16,10 +16,10 @@ menu:
 # Custom files rendering configuration
 
 Gitea supports custom file renderings (i.e., Jupyter notebooks, asciidoc, etc.) through external binaries, 
-it is just matter of:
+it is just a matter of:
 * installing external binaries
 * add some configuration to your `app.ini` file
-* restart your gitea instance
+* restart your Gitea instance
 
 ## Installing external binaries
 
diff --git a/docs/content/doc/advanced/hacking-on-gitea.en-us.md b/docs/content/doc/advanced/hacking-on-gitea.en-us.md
index ee2dc00fd9..1fabc1a118 100644
--- a/docs/content/doc/advanced/hacking-on-gitea.en-us.md
+++ b/docs/content/doc/advanced/hacking-on-gitea.en-us.md
@@ -32,24 +32,24 @@ necessary. To be able to use these you must have the `"$GOPATH"/bin` directory
 on the executable path. If you don't add the go bin directory to the
 executable path you will have to manage this yourself.
 
-**Note 2**: Go version 1.9 or higher is required, however it is important
+**Note 2**: Go version 1.9 or higher is required; however, it is important
 to note that our continuous integration will check that the formatting of the
 source code is not changed by `gofmt` using `make fmt-check`. Unfortunately,
-the results of `gofmt` can differ by the version of `go` it is therefore
+the results of `gofmt` can differ by the version of `go`. It is therefore
 recommended to install the version of go that our continuous integration is
-running. At the time of writing this is Go version 1.11, however this can be
+running. At the time of writing this is Go version 1.12; however, this can be
 checked by looking at the
 [master `.drone.yml`](https://github.com/go-gitea/gitea/blob/master/.drone.yml)
 (At the time of writing
 [line 67](https://github.com/go-gitea/gitea/blob/8917d66571a95f3da232a0c27bc1300210d10fde/.drone.yml#L67)
-is the relevant line - however this may change.)
+is the relevant line - but this may change.)
 
 ## Downloading and cloning the Gitea source code
 
 Go is quite opinionated about where it expects its source code, and simply
 cloning the Gitea repository to an arbitrary path is likely to lead to
-problems - the fixing of which is out of scope for this document. Further some
-internal packages are referenced using their respective Github URL and at
+problems - the fixing of which is out of scope for this document. Further, some
+internal packages are referenced using their respective GitHub URL and at
 present we use `vendor/` directories.
 
 The recommended method of obtaining the source code is by using the `go get` command:
@@ -65,7 +65,7 @@ is not set `"$HOME/go/src/code.gitea.io/gitea"`.
 ## Forking Gitea
 
 As stated above, you cannot clone Gitea to an arbitrary path. Download the master Gitea source
-code as above. Then fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub,
+code as above. Then, fork the [Gitea repository](https://github.com/go-gitea/gitea) on GitHub,
 and either switch the git remote origin for your fork or add your fork as another remote:
 
 ```bash
@@ -86,7 +86,7 @@ git fetch --all --prune
 ```
 
 To be able to create pull requests, the forked repository should be added as a remote
-to the Gitea sources, otherwise changes can't be pushed.
+to the Gitea sources. Otherwise, changes can't be pushed.
 
 ## Building Gitea (Basic)
 
@@ -141,10 +141,10 @@ make vet lint misspell-check
 To generate the stylsheets, you will need [Node.js](https://nodejs.org/) at version 8.0 or above.
 
 At present we use [less](http://lesscss.org/) and [postcss](https://postcss.org) to generate our stylesheets. Do
-**not** edit the files in `public/css/` directly as they are generated from
+**not** edit the files in `public/css/` directly, as they are generated from
 `lessc` from the files in `public/less/`.
 
-If you wish to work on the stylesheets you will need to install `lessc` the
+If you wish to work on the stylesheets, you will need to install `lessc` the
 less compiler and `postcss`. The recommended way to do this is using `npm install`:
 
 ```bash
@@ -163,17 +163,17 @@ PRs.
 
 ### Updating the API
 
-When creating new API routes or modifying existing API routes you **MUST**
+When creating new API routes or modifying existing API routes, you **MUST**
 update and/or create [Swagger](https://swagger.io/docs/specification/2-0/what-is-swagger/)
 documentation for these using [go-swagger](https://goswagger.io/) comments.
 The structure of these comments is described in the [specification](https://goswagger.io/use/spec.html#annotation-syntax).
-If you want more information about the Swagger structure you can look at the
+If you want more information about the Swagger structure, you can look at the
 [Swagger 2.0 Documentation](https://swagger.io/docs/specification/2-0/basic-structure/)
-or compare with a previous PR adding a new API endpoint e.g. [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20)
+or compare with a previous PR adding a new API endpoint, e.g. [PR #5483](https://github.com/go-gitea/gitea/pull/5843/files#diff-2e0a7b644cf31e1c8ef7d76b444fe3aaR20)
 
 You should be careful not to break the API for downstream users which depend
-on a stable API. In general this means additions are acceptable, but deletions
-or fundamental changes of API will be rejected.
+on a stable API. In general, this means additions are acceptable, but deletions
+or fundamental changes to the API will be rejected.
 
 Once you have created or changed an API endpoint, please regenerate the Swagger
 documentation using:
@@ -208,7 +208,7 @@ found in `docs/content/doc/advanced/config-cheat-sheet.en-us.md`
 
 ### Changing the logo
 
-When changing the Gitea logo svg. You will need to run and commit the results
+When changing the Gitea logo SVG, you will need to run and commit the results
 of:
 
 ```bash
@@ -220,7 +220,7 @@ This will create the necessary Gitea favicon and others.
 ### Database Migrations
 
 If you make breaking changes to any of the database persisted structs in the
-`models/` directory you will need to make a new migration. These can be found
+`models/` directory, you will need to make a new migration. These can be found
 in `models/migrations/`. You can ensure that your migrations work for the main
 database types using:
 
@@ -236,23 +236,23 @@ There are two types of test run by Gitea: Unit tests and Integration Tests.
 TAGS="bindata sqlite sqlite_unlock_notify" make test # Runs the unit tests
 ```
 
-Unit tests will not and cannot completely test Gitea alone. Therefore we
-have written integration tests, however, these are database dependent.
+Unit tests will not and cannot completely test Gitea alone. Therefore, we
+have written integration tests; however, these are database dependent.
 
 ```bash
 TAGS="bindata sqlite sqlite_unlock_notify" make generate build test-sqlite
 ```
 
-Will run the integration tests in an sqlite environment. Other database tests
-are available however may need adjustment for local environment. 
+will run the integration tests in an sqlite environment. Other database tests
+are available but may need adjustment to the local environment. 
 
 Look at
 [`integrations/README.md`](https://github.com/go-gitea/gitea/blob/master/integrations/README.md)
 for more information and how to run a single test.
 
 Our continuous integration will test the code passes its unit tests and that
-all supported databases will pass integration test in a docker environment.
-Migration from several recent versions of gitea will also be tested.
+all supported databases will pass integration test in a Docker environment.
+Migration from several recent versions of Gitea will also be tested.
 
 Please submit your PR with additional tests and integration tests as
 appropriate.
@@ -268,7 +268,7 @@ make trans-copy clean build
 ```
 
 You will require a copy of [Hugo](https://gohugo.io/) to run this task. Please
-note this may generate a number of untracked git objects which will need to
+note: this may generate a number of untracked git objects, which will need to
 be cleaned up.
 
 ## Visual Studio Code
diff --git a/docs/content/doc/advanced/specific-variables.en-us.md b/docs/content/doc/advanced/specific-variables.en-us.md
index b0f54c13a7..d9c6d3c3e3 100644
--- a/docs/content/doc/advanced/specific-variables.en-us.md
+++ b/docs/content/doc/advanced/specific-variables.en-us.md
@@ -59,7 +59,7 @@ For documentation about each of the variables available, refer to the
   * `HOST`: Host Macaron will listen on
   * `PORT`: Port Macaron will listen on
   * `MACARON_ENV`: global variable to provide special functionality for development environments
-     vs. production environments. If MACARON_ENV is set to "" or "development" then templates will
+     vs. production environments. If MACARON_ENV is set to "" or "development", then templates will
      be recompiled on every request. For more performance, set the MACARON_ENV environment variable
      to "production".
 
diff --git a/docs/content/doc/features/authentication.en-us.md b/docs/content/doc/features/authentication.en-us.md
index ba0ec7fedd..42424b50e4 100644
--- a/docs/content/doc/features/authentication.en-us.md
+++ b/docs/content/doc/features/authentication.en-us.md
@@ -91,7 +91,7 @@ Both the LDAP via BindDN and the simple auth LDAP share the following fields:
     name given on sign-in form.
   - Example: `(&(objectClass=posixAccount)(uid=%s))`
   - Example for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
-  - To substitute more than once `%[1]s` should be used instead, e.g. when
+  - To substitute more than once, `%[1]s` should be used instead, e.g. when
     matching supplied login name against multiple attributes such as user
     identifier, email or even phone number.
   - Example: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))`
@@ -181,7 +181,7 @@ configure this, set the fields below:
 
 ## FreeIPA
 
-- In order to log in to Gitea using FreeIPA credentials,a bind account needs to
+- In order to log in to Gitea using FreeIPA credentials, a bind account needs to
   be created for Gitea:
 
 - On the FreeIPA server, create a `gitea.ldif` file, replacing `dc=example,dc=com`
diff --git a/docs/content/doc/features/comparison.en-us.md b/docs/content/doc/features/comparison.en-us.md
index 2bd0b7cfc8..6f732307a2 100644
--- a/docs/content/doc/features/comparison.en-us.md
+++ b/docs/content/doc/features/comparison.en-us.md
@@ -15,9 +15,9 @@ menu:
 
 # Gitea compared to other Git hosting options
 
-To help decide if Gitea is suited for your needs here is how it compares to other Git self hosted options.
+To help decide if Gitea is suited for your needs, here is how it compares to other Git self hosted options.
 
-Be warned that we don't regularly check for feature changes in other products so this list can be outdated. If you find anything that needs to be updated in table below please report [issue on Github](https://github.com/go-gitea/gitea/issues).
+Be warned that we don't regularly check for feature changes in other products, so this list may be outdated. If you find anything that needs to be updated in the table below, please report it in an [issue on GitHub](https://github.com/go-gitea/gitea/issues).
 
 _Symbols used in table:_
 
@@ -118,7 +118,7 @@ _Symbols used in table:_
 | LDAP user synchronization | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ | ✓ |
 | OpenId Connect support | ✓ | ✘ | ✓ | ✓ | ✓ | ? | ✘ |
 | OAuth 2.0 integration (external authorization) | ✓ | ✘ | ⁄ | ✓ | ✓ | ? | ✓ |
-| Act as OAuth 2.0 provider | ✘ | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
+| Act as OAuth 2.0 provider | [✓](https://github.com/go-gitea/gitea/pull/5378) | ✘ | ✓ | ✓ | ✓ | ✓ | ✘ |
 | Two factor authentication (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ |
 | Mattermost/Slack integration | ✓ | ✓ | ⁄ | ✓ | ✓ | ⁄ | ✓ |
 | Discord integration | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
diff --git a/docs/content/doc/features/webhooks.en-us.md b/docs/content/doc/features/webhooks.en-us.md
index 2220c1ef29..628afb7356 100644
--- a/docs/content/doc/features/webhooks.en-us.md
+++ b/docs/content/doc/features/webhooks.en-us.md
@@ -15,8 +15,8 @@ menu:
 
 # Webhooks
 
-Gitea supports web hooks for repository events, this can be found in the settings
-page(`/:username/:reponame/settings/hooks`). All event pushes are POST requests.
+Gitea supports web hooks for repository events. This can be found in the settings
+page `/:username/:reponame/settings/hooks`. All event pushes are POST requests.
 The two methods currently supported are Gitea and Slack.
 
 ### Event information
@@ -26,8 +26,8 @@ a Payload URL:
 
 
 ```
-X-Github-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
-X-Github-Event: push
+X-GitHub-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
+X-GitHub-Event: push
 X-Gogs-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
 X-Gogs-Event: push
 X-Gitea-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
diff --git a/docs/content/doc/help/seek-help.en-us.md b/docs/content/doc/help/seek-help.en-us.md
index 69252a0956..36406b091f 100644
--- a/docs/content/doc/help/seek-help.en-us.md
+++ b/docs/content/doc/help/seek-help.en-us.md
@@ -20,7 +20,7 @@ menu:
 
 ## Bugs
 
-If you found a bug, please create an [issue on Github](https://github.com/go-gitea/gitea/issues).
+If you found a bug, please create an [issue on GitHub](https://github.com/go-gitea/gitea/issues).
 
 ## Chinese Support
 
diff --git a/docs/content/doc/help/troubleshooting.en-us.md b/docs/content/doc/help/troubleshooting.en-us.md
index 6eb440c612..664a51731e 100644
--- a/docs/content/doc/help/troubleshooting.en-us.md
+++ b/docs/content/doc/help/troubleshooting.en-us.md
@@ -19,7 +19,7 @@ This page contains some common seen issues and their solutions.
 
 ## SSH issues
 
-For issues reaching repositories over `ssh` while the gitea web front-end, but
+For issues reaching repositories over `ssh` while the Gitea web front-end, but
 `https` based git repository access works fine, consider looking into the following.
 
 ```
@@ -32,7 +32,7 @@ following things:
 
 * On the client:
   * Ensure the public and private ssh keys are added to the correct Gitea user.
-  * Make sure there are no issues in the remote url, ensure the name of the
+  * Make sure there are no issues in the remote url. In particular, ensure the name of the
     git user (before the `@`) is spelled correctly.
   * Ensure public and private ssh keys are correct on client machine.
   * Try to connect using ssh (ssh git@myremote.example) to ensure a connection
@@ -43,7 +43,7 @@ following things:
   * Verify that the correct public keys are added to `.ssh/authorized_keys`.
     Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
     Gitea admin panel.
-  * Read gitea logs.
+  * Read Gitea logs.
   * Read /var/log/auth (or similar).
   * Check permissions of repositories.
 
@@ -69,14 +69,14 @@ In this case, look into the following settings:
 
 ## Missing releases after migrating repository with tags
 
-To migrate an repository *with* all tags you need to do two things
+To migrate an repository *with* all tags, you need to do two things:
 
 * Push tags to the repository:
 ```
  git push --tags
  ```
  
- * (Re-)sync tags of all repositories within gitea:
+ * (Re-)sync tags of all repositories within Gitea:
  ```
  gitea admin repo-sync-releases
  ```
@@ -90,7 +90,7 @@ batch response: Authentication required: Authorization error: <GITEA_LFS_URL>/in
 Check that you have proper access to the repository
 error: failed to push some refs to '<GIT_REPO_URL>'
 ```
-Have you checked the value of `LFS_HTTP_AUTH_EXPIRY` in your `app.ini` file? By default your LFS token will expire after 20 minutes. If you have a slow connection or a large file (or both) it may not finish uploading within the time limit. 
+Have you checked the value of `LFS_HTTP_AUTH_EXPIRY` in your `app.ini` file? By default, your LFS token will expire after 20 minutes. If you have a slow connection or a large file (or both), it may not finish uploading within the time limit. 
 
 You may want to set this value to `60m` or `120m`.
 
diff --git a/docs/content/doc/installation/from-binary.en-us.md b/docs/content/doc/installation/from-binary.en-us.md
index 700642213c..8fa96bd96e 100644
--- a/docs/content/doc/installation/from-binary.en-us.md
+++ b/docs/content/doc/installation/from-binary.en-us.md
@@ -26,7 +26,7 @@ chmod +x gitea
 ```
 
 ## Verify GPG signature
-Gitea signs all binaries with a [GPG key](https://pgp.mit.edu/pks/lookup?op=vindex&fingerprint=on&search=0x2D9AE806EC1592E2) to prevent against unwanted modification of binaries. To validate the binary download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
+Gitea signs all binaries with a [GPG key](https://pgp.mit.edu/pks/lookup?op=vindex&fingerprint=on&search=0x2D9AE806EC1592E2) to prevent against unwanted modification of binaries. To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
 
 ```sh
 gpg --keyserver pgp.mit.edu --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
@@ -49,12 +49,12 @@ Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working
 
 ### Prepare environment
 
-Check that git is installed on the server, if it is not install it first.
+Check that Git is installed on the server. If it is not, install it first.
 ```sh
 git --version
 ```
 
-Create user to run gitea (ex. `git`)
+Create user to run Gitea (ex. `git`)
 ```sh
 adduser \
    --system \
@@ -77,7 +77,7 @@ chown root:git /etc/gitea
 chmod 770 /etc/gitea
 ```
 
-**NOTE:** `/etc/gitea` is temporary set with write rights for user `git` so that Web installer could write configuration file. After installation is done it is recommended to set rights to read-only using:
+**NOTE:** `/etc/gitea` is temporary set with write rights for user `git` so that Web installer could write configuration file. After installation is done, it is recommended to set rights to read-only using:
 ```
 chmod 750 /etc/gitea
 chmod 644 /etc/gitea/app.ini
@@ -90,7 +90,7 @@ chmod 644 /etc/gitea/app.ini
 export GITEA_WORK_DIR=/var/lib/gitea/
 ```
 
-### Copy gitea binary to global location
+### Copy Gitea binary to global location
 
 ```
 cp gitea /usr/local/bin/gitea
@@ -112,7 +112,7 @@ GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
 
 ## Updating to a new version
 
-You can update to a new version of gitea by stopping gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance. 
+You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance. 
 The binary file name should not be changed during the update to avoid problems 
 in existing repositories. 
 
@@ -122,7 +122,7 @@ If you have carried out the installation steps as described above, the binary sh
 have the generic name `gitea`. Do not change this, i.e. to include the version number. 
 
 See below for troubleshooting instructions to repair broken repositories after 
-an update of your gitea version.
+an update of your Gitea version.
 
 ## Troubleshooting
 
@@ -135,16 +135,16 @@ SQLite support in the binaries provided by dl.gitea.io. In this situation, it is
 possible to [install from source]({{< relref "from-source.en-us.md" >}}) without sqlite
 support.
 
-### Running gitea on another port
+### Running Gitea on another port
 
 For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
-bind: address already in use` gitea needs to be started on another free port. This
-is possible using `./gitea web -p $PORT`. It's possible another instance of gitea
+bind: address already in use` Gitea needs to be started on another free port. This
+is possible using `./gitea web -p $PORT`. It's possible another instance of Gitea
 is already running.
 
-### Git error after updating to a new version of gitea
+### Git error after updating to a new version of Gitea
 
-If the binary file name has been changed during the update to a new version of gitea, 
+If the binary file name has been changed during the update to a new version of Gitea, 
 git hooks in existing repositories will not work any more. In that case, a git 
 error will be displayed when pushing to the repository.
 
@@ -152,7 +152,7 @@ error will be displayed when pushing to the repository.
 remote: ./hooks/pre-receive.d/gitea: line 2: [...]: No such file or directory
 ```
 
-The `[...]` part of the error message will contain the path to your previous gitea 
+The `[...]` part of the error message will contain the path to your previous Gitea 
 binary.
 
 To solve this, go to the admin options and run the task `Resynchronize pre-receive, 
@@ -160,6 +160,6 @@ update and post-receive hooks of all repositories` to update all hooks to contai
 the new binary path. Please note that this overwrite all git hooks including ones
 with customizations made.
 
-If you aren't using the built-in to Gitea ssh server you will also need to re-write
+If you aren't using the built-in to Gitea SSH server you will also need to re-write
 the authorized key file by running the `Update the '.ssh/authorized_keys' file with
 Gitea SSH keys.` task in the admin options.
diff --git a/docs/content/doc/installation/from-package.en-us.md b/docs/content/doc/installation/from-package.en-us.md
index 2440d6bf73..eff1d70cfa 100644
--- a/docs/content/doc/installation/from-package.en-us.md
+++ b/docs/content/doc/installation/from-package.en-us.md
@@ -20,7 +20,7 @@ menu:
 Although there is a package of Gitea in Debian's [contrib](https://wiki.debian.org/SourcesList),
 it is not supported directly by us.
 
-Unfortunately the package is not maintained anymore and broken because of missing sources.
+Unfortunately, the package is not maintained anymore and broken because of missing sources.
 Please follow the [deployment from binary]({{< relref "from-binary.en-us.md" >}}) guide instead.
 
 Should the packages get updated and fixed, we will provide up-to-date installation instructions here.
diff --git a/docs/content/doc/installation/from-source.en-us.md b/docs/content/doc/installation/from-source.en-us.md
index 5806b0bfcc..9baeaac5a5 100644
--- a/docs/content/doc/installation/from-source.en-us.md
+++ b/docs/content/doc/installation/from-source.en-us.md
@@ -23,18 +23,18 @@ environment variable and to add the go bin directory or directories
 
 **Note**: When executing make tasks that require external tools, like
 `make misspell-check`, Gitea will automatically download and build these as
-necessary. To be able to use these you must have the `"$GOPATH/bin"` directory
+necessary. To be able to use these, you must have the `"$GOPATH/bin"` directory
 on the executable path. If you don't add the go bin directory to the
-executable path you will have to manage this yourself.
+executable path, you will have to manage this yourself.
 
-**Note 2**: Go version 1.9 or higher is required, however it is recommended to
+**Note 2**: Go version 1.9 or higher is required. However, it is recommended to
 obtain the same version as our continuous integration, see the advice given in
 <a href='{{ relref "docs/advanced/hacking-on-gitea.en-us.md" }}'>Hacking on
 Gitea</a>
 
 ## Download
 
-First retrieve the source code. The easiest way is to use the Go tool. Use the
+First, retrieve the source code. The easiest way is to use the Go tool. Use the
 following commands to fetch the source and switch into the source directory.
 Go is quite opinionated about where it expects its source code, and simply
 cloning the Gitea repository to an arbitrary path is likely to lead to
@@ -100,7 +100,7 @@ task e.g.:
 TAGS="bindata" make generate build
 ```
 
-In the default release build of our continuous integration system the build
+In the default release build of our continuous integration system, the build
 tags are: `TAGS="bindata sqlite sqlite_unlock_notify"`. The simplest
 recommended way to build from source is therefore:
 
@@ -110,7 +110,7 @@ TAGS="bindata sqlite sqlite_unlock_notify" make generate build
 
 ## Test
 
-After following the steps above a `gitea` binary will be available in the working directory.
+After following the steps above, a `gitea` binary will be available in the working directory.
 It can be tested from this directory or moved to a directory with test data. When Gitea is
 launched manually from command line, it can be killed by pressing `Ctrl + C`.
 
diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md b/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
index e004e3a0d3..d3b5df5b5a 100644
--- a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
+++ b/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
@@ -29,7 +29,7 @@ Uncomment any service that needs to be enabled on this host, such as MySQL.
 Change the user, home directory, and other required startup values. Change the
 PORT or remove the -p flag if default port is used.
 
-Enable and start gitea at boot:
+Enable and start Gitea at boot:
 ```
 sudo systemctl enable gitea
 sudo systemctl start gitea
@@ -45,7 +45,7 @@ sudo apt install supervisor
 
 Create a log dir for the supervisor logs:
 ```
-# assuming gitea is installed in /home/git/gitea/
+# assuming Gitea is installed in /home/git/gitea/
 mkdir /home/git/gitea/log/supervisor
 ```
 
@@ -57,7 +57,7 @@ sudo vim /etc/supervisor/supervisord.conf
 Append the configuration from the sample
 [supervisord config](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea).
 
-Change the user(git) and home(/home/git) settings to match the deployment
+Change the user (git) and home (/home/git) settings to match the deployment
 environment. Change the PORT or remove the -p flag if default port is used.
 
 Lastly enable and start supervisor at boot:
diff --git a/docs/content/doc/installation/windows-service.en-us.md b/docs/content/doc/installation/windows-service.en-us.md
index 9f2968ae02..6a4b33cb3f 100644
--- a/docs/content/doc/installation/windows-service.en-us.md
+++ b/docs/content/doc/installation/windows-service.en-us.md
@@ -46,7 +46,7 @@ sc create gitea start= auto binPath= ""C:\gitea\gitea.exe" web --config "C:\gite
 Do not forget to replace `C:\gitea` with the correct Gitea directory.
 
 Open "Windows Services", search for the service named "gitea", right-click it and click on
-"Run". If everything is OK Gitea will be reachable on `http://localhost:3000` (or the port
+"Run". If everything is OK, Gitea will be reachable on `http://localhost:3000` (or the port
 that was configured).
 
 ## Unregister as a service
diff --git a/docs/content/doc/installation/with-docker.en-us.md b/docs/content/doc/installation/with-docker.en-us.md
index 08e6e7c452..f2c32a9847 100644
--- a/docs/content/doc/installation/with-docker.en-us.md
+++ b/docs/content/doc/installation/with-docker.en-us.md
@@ -20,13 +20,13 @@ possible to always use the latest stable tag or to use another service that hand
 Docker images.
 
 This reference setup guides users through the setup based on `docker-compose`, but the installation
-of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself follow
+of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow
 the official [install instructions](https://docs.docker.com/compose/install/).
 
 ## Basics
 
 The most simple setup just creates a volume and a network and starts the `gitea/gitea:latest`
-image as a service. Since there is no database available one can be initialized using SQLite3.
+image as a service. Since there is no database available, one can be initialized using SQLite3.
 Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
 Note that the volume should be owned by the user/group with the UID/GID specified in the config file.
 If you don't give the volume correct permissions, the container may not start.
@@ -187,7 +187,7 @@ services:
 To use named volumes instead of host volumes, define and use the named volume
 within the `docker-compose.yml` configuration. This change will automatically
 create the required volume. You don't need to worry about permissions with
-named volumes, Docker will deal with that automatically.
+named volumes; Docker will deal with that automatically.
 
 ```diff
 version: "2"
@@ -230,10 +230,10 @@ Notice: if using a non-3000 port on http, change app.ini to match
 
 ## Install
 
-After starting the Docker setup via `docker-compose` Gitea should be available using a
+After starting the Docker setup via `docker-compose`, Gitea should be available using a
 favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the
 installation wizard. If the database was started with the `docker-compose` setup as
-documented above please note that `db` must be used as the database hostname.
+documented above, please note that `db` must be used as the database hostname.
 
 ## Environments variables
 
@@ -252,7 +252,7 @@ You can configure some of Gitea's settings via environment variables:
 * `DB_HOST`: **localhost:3306**: Database host address and port.
 * `DB_NAME`: **gitea**: Database name.
 * `DB_USER`: **root**: Database username.
-* `DB_PASSWD`: **"<empty>"**: Database user password. Use \`your password\` for quoting if you use special characters in the password.
+* `DB_PASSWD`: **"\<empty>"**: Database user password. Use \`your password\` for quoting if you use special characters in the password.
 * `INSTALL_LOCK`: **false**: Disallow access to the install page.
 * `SECRET_KEY`: **""**: Global secret key. This should be changed. If this has a value and `INSTALL_LOCK` is empty, `INSTALL_LOCK` will automatically set to `true`.
 * `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create accounts for users.
@@ -263,8 +263,8 @@ You can configure some of Gitea's settings via environment variables:
 # Customization
 
 Customization files described [here](https://docs.gitea.io/en-us/customizing-gitea/) should
-be placed in `/data/gitea` directory. If using host volumes it's quite easy to access these
-files; for named volumes this is done through another container or by direct access at
+be placed in `/data/gitea` directory. If using host volumes, it's quite easy to access these
+files; for named volumes, this is done through another container or by direct access at
 `/var/lib/docker/volumes/gitea_gitea/_data`. The configuration file will be saved at
 `/data/gitea/conf/app.ini` after the installation.
 
@@ -285,7 +285,7 @@ docker-compose up -d
 
 Since SSH is running inside the container, you'll have to pass SSH from the host to the
 container if you wish to use SSH support. If you wish to do this without running the container
-SSH on a non-standard port (or move your host port to a non-standard port) you can forward
+SSH on a non-standard port (or move your host port to a non-standard port), you can forward
 SSH connections destined for the container with a little extra setup.
 
 This guide assumes that you have created a user on the host called `git` which shares the same 
diff --git a/docs/content/doc/upgrade/from-gogs.en-us.md b/docs/content/doc/upgrade/from-gogs.en-us.md
index 37ca898d2d..e3a3aa89ea 100644
--- a/docs/content/doc/upgrade/from-gogs.en-us.md
+++ b/docs/content/doc/upgrade/from-gogs.en-us.md
@@ -70,7 +70,7 @@ There are some basic steps to follow. On a Linux system run as the Gogs user:
 
 ## Upgrading to most recent `gitea` version
 
-After successful migration from `gogs` to `gitea 1.0.x` it is possible to upgrade to the recent `gitea` version.
+After successful migration from `gogs` to `gitea 1.0.x`, it is possible to upgrade to the recent `gitea` version.
 Simply download the file matching the destination platform from the [downloads page](https://dl.gitea.io/gitea)
 and replace the binary.
 
diff --git a/docs/content/doc/usage/fail2ban-setup.md b/docs/content/doc/usage/fail2ban-setup.md
index 9fea9a640e..28c4874da2 100644
--- a/docs/content/doc/usage/fail2ban-setup.md
+++ b/docs/content/doc/usage/fail2ban-setup.md
@@ -19,7 +19,7 @@ menu:
 sure to test this before relying on it so you don't lock yourself out.**
 
 Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in 
-`app.ini`, then you should be able to go off of log/gitea.log, which gives you something like this 
+`app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this 
 on a bad authentication:
 
 ```log
@@ -52,8 +52,8 @@ action = iptables-allports
 Make sure and read up on fail2ban and configure it to your needs, this bans someone 
 for **15 minutes** (from all ports) when they fail authentication 10 times in an hour.
 
-If you run Gitea behind a reverse proxy with nginx (for example with docker), you need to add
-this to your nginx configuration so that IPs don't show up as 127.0.0.1: 
+If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add
+this to your Nginx configuration so that IPs don't show up as 127.0.0.1: 
 
 ```
 proxy_set_header X-Real-IP $remote_addr;
diff --git a/docs/content/doc/usage/https-support.md b/docs/content/doc/usage/https-support.md
index 25c9ab0164..531d835ff2 100644
--- a/docs/content/doc/usage/https-support.md
+++ b/docs/content/doc/usage/https-support.md
@@ -15,12 +15,12 @@ menu:
 
 # HTTPS setup to encrypt connections to Gitea
 
-## Using built-in server
+ ## Using the built-in server
 
-Before you enable HTTPS make sure that you have valid SSL/TLS certificates.
+Before you enable HTTPS, make sure that you have valid SSL/TLS certificates.
 You could use self-generated certificates for evaluation and testing. Please run `gitea cert --host [HOST]` to generate a self signed certificate.
 
-To use Gitea's built-in HTTPS support you must change your `app.ini` file:
+To use Gitea's built-in HTTPS support, you must change your `app.ini` file:
 
 ```ini
 [server]
@@ -33,7 +33,7 @@ KEY_FILE = key.pem
 
 To learn more about the config values, please checkout the [Config Cheat Sheet](../config-cheat-sheet#server).
 
-### Setting-up HTTP redirection
+### Setting up HTTP redirection
 
 The Gitea server is only able to listen to one port; to redirect HTTP requests to the HTTPS port, you will need to enable the HTTP redirection service:
 
@@ -48,9 +48,9 @@ If you are using Docker, make sure that this port is configured in your `docker-
 
 ## Using Let's Encrypt
 
-[Let's Encrypt](https://letsencrypt.org/) is a Certificate Authority that allows you to automatically request and renew SSL/TLS certificates. In addition to starting Gitea on your configured port, to request HTTPS certificates Gitea will also need to listed on port 80, and will set up an autoredirect to HTTPS for you. Let's Encrypt will need to be able to access Gitea via the Internet to verify your ownership of the domain.
+[Let's Encrypt](https://letsencrypt.org/) is a Certificate Authority that allows you to automatically request and renew SSL/TLS certificates. In addition to starting Gitea on your configured port, to request HTTPS certificates, Gitea will also need to listed on port 80, and will set up an autoredirect to HTTPS for you. Let's Encrypt will need to be able to access Gitea via the Internet to verify your ownership of the domain.
 
-By using Lets Encrypt **you must consent** to their [terms of service](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)
+By using Let's Encrypt **you must consent** to their [terms of service](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf).
 
 ```ini
 [server]
@@ -66,7 +66,7 @@ To learn more about the config values, please checkout the [Config Cheat Sheet](
 
 ## Using reverse proxy
 
-Setup up your reverse proxy like shown in the [reverse proxy guide](../reverse-proxies).
+Setup up your reverse proxy as shown in the [reverse proxy guide](../reverse-proxies).
 
 After that, enable HTTPS by following one of these guides:
 
@@ -74,5 +74,5 @@ After that, enable HTTPS by following one of these guides:
 * [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html)
 * [caddy](https://caddyserver.com/docs/tls)
 
-Note: Your connection between your reverse proxy and gitea might be unencrypted. To encrypt it too follow the [built-in server guide](#using-built-in-server) and change
+Note: Your connection between your reverse proxy and Gitea might be unencrypted. To encrypt it too, follow the [built-in server guide](#using-built-in-server) and change
 the proxy url to `https://[URL]`.
diff --git a/docs/content/doc/usage/issue-pull-request-templates.en-us.md b/docs/content/doc/usage/issue-pull-request-templates.en-us.md
index e7582f3208..a4fc51b81f 100644
--- a/docs/content/doc/usage/issue-pull-request-templates.en-us.md
+++ b/docs/content/doc/usage/issue-pull-request-templates.en-us.md
@@ -15,10 +15,10 @@ menu:
 
 # Issue and Pull Request Templates
 
-For some projects there are a standard list of questions that users need to be asked
-for creating an issue, or adding a pull request. Gitea supports adding templates to the
+Some projects have a standard list of questions that users need to answer
+when creating an issue or pull request. Gitea supports adding templates to the
 main branch of the repository so that they can autopopulate the form when users are 
-creating issues, and pull requests. This will cut down on the initial back and forth
+creating issues and pull requests. This will cut down on the initial back and forth
 of getting some clarifying details.
 
 Possible file names for issue templates:
diff --git a/docs/content/doc/usage/pull-request.en-us.md b/docs/content/doc/usage/pull-request.en-us.md
index 171c944ac0..39cff7f651 100644
--- a/docs/content/doc/usage/pull-request.en-us.md
+++ b/docs/content/doc/usage/pull-request.en-us.md
@@ -28,4 +28,4 @@ The first value of the list will be used in helpers.
 
 ## Pull Request Templates
 
-You can find more information about pull request templates in the dedicated page : [Issue and Pull Request templates](../issue-pull-request-templates)
+You can find more information about pull request templates at the page [Issue and Pull Request templates](../issue-pull-request-templates).
diff --git a/docs/content/doc/usage/reverse-proxies.en-us.md b/docs/content/doc/usage/reverse-proxies.en-us.md
index bd3945a405..d828d5b226 100644
--- a/docs/content/doc/usage/reverse-proxies.en-us.md
+++ b/docs/content/doc/usage/reverse-proxies.en-us.md
@@ -14,7 +14,7 @@ menu:
 ---
 
 ##  Using Nginx as a reverse proxy
-If you want Nginx to serve your Gitea instance you can the following `server` section inside the `http` section of `nginx.conf`:
+If you want Nginx to serve your Gitea instance, you can the following `server` section inside the `http` section of `nginx.conf`:
 
 ```
 server {
@@ -27,7 +27,7 @@ server {
 }
 ```
 
-## Using Nginx with a Sub-path as a reverse proxy
+## Using Nginx with a sub-path as a reverse proxy
 
 In case you already have a site, and you want Gitea to share the domain name, you can setup Nginx to serve Gitea under a sub-path by adding the following `server` section inside the `http` section of `nginx.conf`:
 
@@ -46,7 +46,7 @@ Then set `[server] ROOT_URL = http://git.example.com/git/` in your configuration
 
 ## Using Apache HTTPD as a reverse proxy
 
-If you want Apache HTTPD to serve your Gitea instance you can add the following to you Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu):
+If you want Apache HTTPD to serve your Gitea instance, you can add the following to your Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu):
 
 ```
 <VirtualHost *:80>
@@ -60,7 +60,7 @@ If you want Apache HTTPD to serve your Gitea instance you can add the following
 
 Note: The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`
 
-## Using Apache HTTPD with a Sub-path as a reverse proxy
+## Using Apache HTTPD with a sub-path as a reverse proxy
 
 In case you already have a site, and you want Gitea to share the domain name, you can setup Apache HTTPD to serve Gitea under a sub-path by adding the following to you Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu):
 
@@ -83,7 +83,7 @@ Note: The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`
 
 ## Using Caddy as a reverse proxy
 
-If you want Caddy to serve your Gitea instance you can add the following server block to your Caddyfile:
+If you want Caddy to serve your Gitea instance, you can add the following server block to your Caddyfile:
 
 ```
 git.example.com {
@@ -91,9 +91,9 @@ git.example.com {
 }
 ```
 
-## Using Caddy with a Sub-path as a reverse proxy
+## Using Caddy with a sub-path as a reverse proxy
 
-In case you already have a site, and you want Gitea to share the domain name, you can setup Caddy to serve Gitea under a sub-path by adding the following to you server block in your Caddyfile:
+In case you already have a site, and you want Gitea to share the domain name, you can setup Caddy to serve Gitea under a sub-path by adding the following to your server block in your Caddyfile:
 
 ```
 git.example.com {
diff --git a/docs/content/page/index.en-us.md b/docs/content/page/index.en-us.md
index da7486cda8..a9ccfce42c 100644
--- a/docs/content/page/index.en-us.md
+++ b/docs/content/page/index.en-us.md
@@ -10,7 +10,7 @@ draft: false
 
 # What is Gitea?
 
-Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket, and Gitlab.
+Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket, and GitLab.
 Gitea is a fork of [Gogs](http://gogs.io). See the [Gitea Announcement](https://blog.gitea.io/2016/12/welcome-to-gitea/)
 blog post to read about the justification for a fork.
 
@@ -254,7 +254,7 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
 - A Raspberry Pi 3 is powerful enough to run Gitea for small workloads.
 - 2 CPU cores and 1GB RAM is typically sufficient for small teams/projects.
 - Gitea should be run with a dedicated non-root system account on UNIX-type systems.
-   - Note: Gitea manages the `~/.ssh/authorized_keys` file. Running gitea as a regular user could break that user's ability to log in.
+   - Note: Gitea manages the `~/.ssh/authorized_keys` file. Running Gitea as a regular user could break that user's ability to log in.
 
 ## Browser Support
 
diff --git a/models/action.go b/models/action.go
index ca6bfaf666..2cd3616d63 100644
--- a/models/action.go
+++ b/models/action.go
@@ -53,7 +53,7 @@ const (
 )
 
 var (
-	// Same as Github. See
+	// Same as GitHub. See
 	// https://help.github.com/articles/closing-issues-via-commit-messages
 	issueCloseKeywords  = []string{"close", "closes", "closed", "fix", "fixes", "fixed", "resolve", "resolves", "resolved"}
 	issueReopenKeywords = []string{"reopen", "reopens", "reopened"}
diff --git a/models/issue_assignees.go b/models/issue_assignees.go
index 0fff2dfad5..1ac1e276cd 100644
--- a/models/issue_assignees.go
+++ b/models/issue_assignees.go
@@ -214,7 +214,7 @@ func (issue *Issue) changeAssignee(sess *xorm.Session, doer *User, assigneeID in
 }
 
 // UpdateAPIAssignee is a helper function to add or delete one or multiple issue assignee(s)
-// Deleting is done the Github way (quote from their api documentation):
+// Deleting is done the GitHub way (quote from their api documentation):
 // https://developer.github.com/v3/issues/#edit-an-issue
 // "assignees" (array): Logins for Users to assign to this issue.
 // Pass one or more user logins to replace the set of assignees on this Issue.
diff --git a/routers/api/v1/repo/issue.go b/routers/api/v1/repo/issue.go
index e63db4b6a4..27b3d93a75 100644
--- a/routers/api/v1/repo/issue.go
+++ b/routers/api/v1/repo/issue.go
@@ -316,7 +316,7 @@ func EditIssue(ctx *context.APIContext, form api.EditIssueOption) {
 
 	// Add/delete assignees
 
-	// Deleting is done the Github way (quote from their api documentation):
+	// Deleting is done the GitHub way (quote from their api documentation):
 	// https://developer.github.com/v3/issues/#edit-an-issue
 	// "assignees" (array): Logins for Users to assign to this issue.
 	// Pass one or more user logins to replace the set of assignees on this Issue.
diff --git a/routers/api/v1/repo/pull.go b/routers/api/v1/repo/pull.go
index e7c12b9038..9d3d9443f7 100644
--- a/routers/api/v1/repo/pull.go
+++ b/routers/api/v1/repo/pull.go
@@ -377,7 +377,7 @@ func EditPullRequest(ctx *context.APIContext, form api.EditPullRequestOption) {
 
 	// Add/delete assignees
 
-	// Deleting is done the Github way (quote from their api documentation):
+	// Deleting is done the GitHub way (quote from their api documentation):
 	// https://developer.github.com/v3/issues/#edit-an-issue
 	// "assignees" (array): Logins for Users to assign to this issue.
 	// Pass one or more user logins to replace the set of assignees on this Issue.