docs: Fix typos

docs/content/content/using-index-md.md

@@ -39,8 +39,8 @@ If this is confusing or you are unfamiliar with Hugo's template hierarchy, visit
 Now that you've got a handle on templates lets recap some Hugo basics to understand how to use an \_index.md file with a List page.
 
 1. Sections and Taxonomies are 'List' pages, NOT single pages.
-2. List pages are rendered using the template heirarchy found in the [Content - List Template](/templates/list/) docs.
-3. The Home page, though technically a List page, can have [it's own template](/templates/homepage/) at layouts/index.html rather than \_default/list.html. Many themes exploit this behaviour so you are likely to encounter this specific use case. 
+2. List pages are rendered using the template hierarchy found in the [Content - List Template](/templates/list/) docs.
+3. The Home page, though technically a List page, can have [its own template](/templates/homepage/) at layouts/index.html rather than \_default/list.html. Many themes exploit this behaviour so you are likely to encounter this specific use case. 
 4. Taxonomy terms pages are 'lists of metadata' not lists of content, so [have their own templates](/templates/terms/). 
 
 Let's put all this information together:

docs/content/extras/datafiles.md

@@ -21,7 +21,7 @@ Data Files can also be used in [themes](/themes/overview/), but note: If the sam
 
 ## The Data Folder
 
-The `data` folder is where you can store additional data for Hugo to use when generating your site. Data files aren't used to generate standalone pages - rather they're meant supplemental to the content files. This feature can extend the content in case your frontmatter would grow immensely. Or perhaps your want to show a larger dataset in a template (see example below). In both cases it's a good idea to outsource the data in their own file.  
+The `data` folder is where you can store additional data for Hugo to use when generating your site. Data files aren't used to generate standalone pages - rather they're meant supplemental to the content files. This feature can extend the content in case your frontmatter would grow immensely. Or perhaps you want to show a larger dataset in a template (see example below). In both cases it's a good idea to outsource the data in their own file.  
 
 These files must be YAML, JSON or TOML files (using either the `.yml`, `.yaml`, `.json` or `toml` extension) and the data will be accessible as a `map` in `.Site.Data`.
 

docs/content/tutorials/github-pages-blog.md

@@ -39,7 +39,7 @@ If that option isn't enabled, you likely haven't pushed your _docs_ folder yet.
 
 This is the simplest approach but requires the usage of a non-standard publish directory
 (GitHub Pages cannot be configured to use another directory than _docs_ currently).
-Also the presence of generated files on the master branch may not be to eveyone's taste.
+Also the presence of generated files on the master branch may not be to everyone's taste.
 
 ## Deployment via gh-pages branch
 

docs/content/tutorials/how-to-contribute-to-hugo.md

@@ -108,7 +108,7 @@ govendor get -v github.com/spf13/hugo
 
 ### Fork the repository
 
-If you're not fimiliar with this term, GitHub's [help pages](https://help.github.com/articles/fork-a-repo/) provide again a simple explanation:
+If you're not familiar with this term, GitHub's [help pages](https://help.github.com/articles/fork-a-repo/) provide again a simple explanation:
 
 > A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.
 
@@ -207,7 +207,7 @@ make check
 
 ### Formatting
 
-The Go code styleguide maybe is opiniated but it ensures that the codebase looks the same, regardless who wrote the code. Go comes with its own formatting tool. Let's apply the styleguide to our additions:
+The Go code styleguide maybe is opinionated but it ensures that the codebase looks the same, regardless who wrote the code. Go comes with its own formatting tool. Let's apply the styleguide to our additions:
 
 ```sh
 govendor fmt +local
@@ -309,7 +309,7 @@ Check the commit log if everything looks as expected. Should an error occur you
 
 ### Push commits
 
-To push our commits to the fork on GitHub we need to speficy a destination. A destination is defined by the remote and a branch name. Earlier, the defined that the remote url of our fork is the same as our GitHub handle, in my case `digitalcraftsman`. The branch should have the same as our local one. This makes it easy to identify corresponding branches.
+To push our commits to the fork on GitHub we need to specify a destination. A destination is defined by the remote and a branch name. Earlier, the defined that the remote url of our fork is the same as our GitHub handle, in my case `digitalcraftsman`. The branch should have the same as our local one. This makes it easy to identify corresponding branches.
 
 ```sh
 git push --set-upstream <YOUR-GITHUB-USERNAME> <BRANCHNAME>
@@ -324,7 +324,7 @@ If you modified your commit history in the last step GitHub will reject your try
 
 We made a lot of progress. Good work. In this step we finally open a pull request to submit our additions. Open the [Hugo master repository](https://github.com/spf13/hugo/) on GitHub in your browser.
 
-You should find a green button labeld with "New pull request". But GitHub is clever and probably suggests you a pull request like in the beige box below:
+You should find a green button labeled with "New pull request". But GitHub is clever and probably suggests you a pull request like in the beige box below:
 
 <img src="/img/tutorials/how-to-contribute-to-hugo/open-pull-request.png" alt="Open a pull request">
 

docs/content/tutorials/installing-on-mac.md

@@ -112,7 +112,7 @@ When installing from the tarball, you have to decide if you're going to install
 
 1. Install it in `/usr/local/bin` so that all the users on your system have access to it. This is a good idea because it's a fairly standard place for executables. The downside is that you may need elevated privileges to put software into that location. Also, if there are multiple users on your system, they will all run the same version. Sometimes this can be an issue if you want to try out a new release.
 
-2. Install it in `~/bin` so that only you can execute it. This is a good idea because it's easy to do, easy to maintain, and doesn't require elevated privileges. The downside is that only you can run Hugo. If there are other users on your site, they have to maintain their own copies. That can lead to people running different versions. of course, this does make it easier for you to experiment with different releases.
+2. Install it in `~/bin` so that only you can execute it. This is a good idea because it's easy to do, easy to maintain, and doesn't require elevated privileges. The downside is that only you can run Hugo. If there are other users on your site, they have to maintain their own copies. That can lead to people running different versions. Of course, this does make it easier for you to experiment with different releases.
 
 3. Install it in your `sites` directory. This is not a bad idea if you have only one site that you're building. It keeps every thing in a single place. If you want to try out new releases, you can just make a copy of the entire site, update the Hugo executable, and have it.