Merge remote-tracking branch 'refs/remotes/origin/master' into feature/documentation

content/blog/hello-lektor/contents.lr

@@ -43,14 +43,14 @@ There the hacker's favorite projects like
 [Pelican](https://github.com/getpelican/pelican) or
 [Jekyll](https://jekyllrb.com/) which support generating websites out of static
 files that are tracked through version control and there are CMS systems like
-[Statamic](http://statamic.com/) which store all of it's data in flat files
+[Statamic](http://statamic.com/) which store all of its data in flat files
 — but as mentioned — needs PHP.
 
 None of those were what I was looking for.  Static file generators like Jekyll
 are nice in a way but not just end user unfriendly, but also very limited in
 what you can do with them.  They are more suited for building blogs than
-more complex sites.  I have tried a bunch of them and build different things
+more complex sites.  I tried a bunch of them and built different things
-with them, but ultimately always felt like somethign is missing.
+with them, but ultimately always felt like something was missing.
 
 After about two years of frustration with that situation I finally sat down
 and spend some time working on a system to solve this problem.  May I
@@ -59,7 +59,7 @@ introduce: Lektor.
 ## What is Lektor?
 
 Lektor combines the experience of using a content management system like
-Workdpress with a static website generator like Jekyll and has some of the
+Wordpress with a static website generator like Jekyll and has some of the
 flexibility of a web development framework like Django.  It can run locally
 on your computer and deploy to remote servers.  All source assets are stored
 either in version control or Dropbox and when you are satisfied with the end

content/contents.lr

@@ -117,7 +117,7 @@ text:
 
 ## Open Source
 
-Lektor at it's core is a three clause [BSD licensed
+Lektor at its core is a three clause [BSD licensed
 ](https://raw.githubusercontent.com/lektor/lektor/master/LICENSE) Open Source
 project written in Python and Node.js.
 ----

content/docs/api/db/types/flow/contents.lr

@@ -20,7 +20,7 @@ For configuration you can define which blocks are allowed by setting the
 that are allowed.  If not defined, all flow blocks become available.
 
 The text format for flow blocks in the `contents.lr` file looks a bit more
-complex because of it's nested nature, but in essence it's this:
+complex because of its nested nature, but in essence it's this:
 
 ```
 #### name-of-flow-block ####

content/docs/api/project/contents.lr

@@ -9,7 +9,7 @@ summary: Provides access to a project file.
 body:
 
 The project class is one of the most basic classes that Lektor uses to
-implement it's building process.  It's generated very early on when the
+implement its building process.  It's generated very early on when the
 application needs to interact with the project file on disk.  This
 class is mostly useful for building scripts that use the Lektor API and
 not so much in other situations as it's not directly playing a role in

content/docs/api/templates/filters/url/contents.lr

@@ -4,7 +4,7 @@ type: filter
 ---
 summary: Generates a relative URL from the current page to another.
 ---
-signature: alt=None
+signature: alt=None, absolute=None, external=None
 ---
 body:
 

content/docs/content/flow/contents.lr

@@ -7,7 +7,7 @@ body:
 Flow is a system in Lektor that allows you to have higher flexibility when
 creating pages.  The [Flow Type :ref](../../api/db/types/flow/) field type
 that allows you to store multiple different formats of data within the same
-field each with it's own template.
+field each with its own template.
 
 This allows you to build complex pages made from individual components.
 

content/docs/content/urls/contents.lr

@@ -15,7 +15,7 @@ URL which can be customized.  They are roughly speaking something like a
 file name.  For instance `foo-bar` can be a slug in `/foo-bar/`.  The default
 slug of a page is the ID of the page.  So if you have a page called
 `/foo/bar/contents.lr` then the default slug is `bar`.  As you can see the
-full URL is comprised of it's own slug concatenated with all the slugs of
+full URL is comprised of its own slug concatenated with all the slugs of
 all parents.
 
 Can a slug contain slashes?  Yes indeed it can.  A slug is free to contain

content/docs/guides/blog/contents.lr

@@ -90,7 +90,7 @@ instead of `this.children` which will return only the items for the intended
 page.
 
 ```html+jinja
-{% extends "blog_layout.html" %}
+{% extends "layout.html" %}
 {% from "macros/pagination.html" import render_pagination %}
 {% block title %}My Blog{% endblock %}
   <h1>My Blog</h1>

content/docs/guides/disqus/contents.lr

@@ -5,7 +5,7 @@ summary: Enabling disqus comments in one minute.
 body:
 
 The `disqus-comments` plugin adds support for Disqus comments to Lektor and
-with it's help you can have comments on your pages in no time.  Once the plugin
+with its help you can have comments on your pages in no time.  Once the plugin
 is enabled a `render_disqus_comments` function is available for templates which
 can render a disqus comment box.  All you need to do for this is to create your
 own Disqus community at [Disqus Engage :ext](https://publishers.disqus.com/engage).

content/docs/models/contents.lr

@@ -86,7 +86,7 @@ Models have the following options that can customize the model itself:
 - `hidden`: a boolean value that indicates if the model should be hidden from
   the UI or not.  If set to `yes` then new pages cannot select this model.
   This is very useful for models that are implied through configuration.
-- `protected`: if a model is set to protected then all of it's instances
+- `protected`: if a model is set to protected then all of its instances
   cannot be deleted once created.
 - `inherits`: if you want to inherit all fields from another model then this
   can be set to the name of another model.

content/docs/plugins/howto/contents.lr

@@ -1,6 +1,6 @@
 title: Howto
 ---
-summary: Covers the most common thigns plugins would do and how to implement it.
+summary: Covers the most common things plugins would do and how to implement it.
 ---
 sort_key: 30
 ---

templates/blog-archive/index.html

@@ -1,4 +1,4 @@
-{% extends "blog_layout.html" %}
+{% extends "blog-layout.html" %}
 {% block title %}Archive | The Transcript{% endblock %}
 {% block blog_body %}
   <h1>The Transcript Archive</h1>

templates/blog-archive/month.html

@@ -1,4 +1,4 @@
-{% extends "blog_layout.html" %}
+{% extends "blog-layout.html" %}
 {% block title %}{{ this.date|dateformat('MMMM yyyy') }} Archive | The Transcript{% endblock %}
 {% block blog_body %}
   <h1>The Transcript, {{ this.date|dateformat('MMMM yyyy') }}</h1>

templates/blog-archive/year.html

@@ -1,4 +1,4 @@
-{% extends "blog_layout.html" %}
+{% extends "blog-layout.html" %}
 {% block title %}{{ this.year }} Archive | The Transcript{% endblock %}
 {% block blog_body %}
   <h1>The Transcript in {{ this.year }}</h1>

templates/blog.html

@@ -1,4 +1,4 @@
-{% extends "blog_layout.html" %}
+{% extends "blog-layout.html" %}
 {% from "macros/pagination.html" import render_pagination %}
 {% block title %}The Transcript{% endblock %}
   {% block blog_body %}