Website: fixing typos

.gitignore

@@ -33,3 +33,6 @@ Session.vim
 
 # GNU Screen
 .screenrc
+
+# Hugo build lock
+.hugo_build.lock

site/content/blog/on-release-versions.md

@@ -29,7 +29,7 @@ Since I really want to keep Mage as backwards compatible as possible (CI runs
 tests with versions as far back as 1.7)... I didn't want this headache.  I also
 didn't want everyone to have to make their import statements say /v2. Mage's
 libraries are and always will be backwards compatible.  The tags on the repo
-previosuly were not intended to be semantic versions.  In fact, I had intended
+previously were not intended to be semantic versions.  In fact, I had intended
 to simply make each new release a major version specifically to make it clear
 that these aren't semantic versions (just like Chrome is on v70 right now).
 However, I wasn't very careful, and some of my tags were in semantic version

site/content/blog/release-v1.3.0.md

@@ -18,13 +18,13 @@ As you may or may not know (it hasn't been well advertised), it's now extremely
 easy to run multiple go versions side by side.  You can `go get
 golang.org/dl/go1.xx` for any version of go from 1.8 and up.  It'll drop a
 binary on your system that you can then run `go1.xx download` and it'll download
-and set up a new go environment for that verison of go.  From then on, you can
+and set up a new go environment for that version of go.  From then on, you can
 `go1.xx build` etc just like you do with the "go" binary.   
 
 This makes it super easy to work on different projects with different required
 versions of go support.  I used to work at Canonical, and we were restricted to
 the versions of Go that shipped in the latest Ubuntu release, because our code
-was going to shiop with that release, too, and it needed to buid with the
+was going to ship with that release, too, and it needed to build with the
 built-in go compiler.  This meant that we were almost always behind the latest
 go version.  Of course, go is backwards compatible, so you can build 1.6
 compatible code with go 1.11.... but you can also accidentally introduce

site/content/dependencies/_index.en.md

@@ -46,7 +46,7 @@ there are two calls to mg.F(compile, "server"), then compile("server") will only
 ## Parallelism
 
 If run with `mg.Deps` or `mg.CtxDeps`, dependencies are run in their own
-goroutines, so they are parellelized as much as possible given the dependency
+goroutines, so they are parallelized as much as possible given the dependency
 tree ordering restrictions.  If run with `mg.SerialDeps` or `mg.SerialCtxDeps`,
 the dependencies are run serially, though each dependency or sub-dependency will
 still only ever be run once. 

site/content/index.md

@@ -31,7 +31,7 @@ go run bootstrap.go
 ```
 
 This will download the code into your GOPATH, and then run the bootstrap script
-to build mage with version infomation embedded in it.  A normal `go get`
+to build mage with version information embedded in it.  A normal `go get`
 (without -d) will build the binary correctly, but no version info will be
 embedded.  If you've done this, no worries, just go to
 `$GOPATH/src/github.com/magefile/mage` and run `mage install` or `go run