Fix some typos in docs

This commit is contained in:
Tobias 2015-10-16 23:57:56 +02:00 committed by Bjørn Erik Pedersen
parent 0c66ad8775
commit 4e9a5d8bd1
3 changed files with 5 additions and 5 deletions

View file

@ -194,7 +194,7 @@ of the content between the opening and closing shortcodes. If a closing
shortcode is required, you can check the length of `.Inner` and provide a warning
to the user.
A shortcode with `.Inner` content can be used wihout the inline content, and without the closing shortcode, by using the self-closing syntax:
A shortcode with `.Inner` content can be used without the inline content, and without the closing shortcode, by using the self-closing syntax:
{{</* innershortcode /*/>}}

View file

@ -385,7 +385,7 @@ e.g. `{{lower "BatMan"}}` → "batman"
### markdownify
Runs the string through the Markdown processesor. The result will be declared as "safe" so Go templates will not filter it.
Runs the string through the Markdown processor. The result will be declared as "safe" so Go templates will not filter it.
e.g. `{{ .Title | markdownify }}`
@ -678,7 +678,7 @@ In this version, we are now sorting the tags, converting them to links with "pos
### base64Encode and base64Decode
`base64Encode` and `base64Decode` let you easily decode content with a base64 enconding and vice versa through pipes. Let's take a look at an example:
`base64Encode` and `base64Decode` let you easily decode content with a base64 encoding and vice versa through pipes. Let's take a look at an example:
{{ "Hello world" | base64Encode }}

View file

@ -99,9 +99,9 @@ documentation, and if you still have questions
When installing from the tarball, you have to decide if you're going to install the binary in `/usr/local/bin` or in your home directory. There are three camps on this:
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 exectuables. 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.
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 becase 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.