Content > Proofreading

pages/02.content/01.content-pages/docs.md

@@ -26,9 +26,9 @@ When you download and install the **Core Grav** package, you are greeted by a st
 
 ![Listing Page](content-listing.jpg?classes=shadow)
 
-This is really an extension of a regular Page. This is a page that has a reference to a collection of pages.
+This is an extension of a regular Page. This is a page that has a reference to a collection of pages.
 
-The simplest approach to setting this up is to create **child-pages** below the Listing Page. An example of this would be a **blog listing page**, where you would display a summary list of blog posts that exist as child-pages.
+The most straightforward approach to setting this up is to create **child-pages** below the Listing Page. An example of this would be a **blog listing page**, where you would display a summary list of blog posts that exist as child-pages.
 
 There is also some configuration settings to **control the order** of the listing as well as a **limit on the number of items**, and whether or not **pagination** should be enabled.
 
@@ -38,7 +38,7 @@ There is also some configuration settings to **control the order** of the listin
 
 ![Modular Page](content-modular.jpg?classes=shadow)
 
-A Modular Page is a special type of listing page because it actually builds a **single page** from its **child-pages**. This allows for the ability to build very complex **one-page layouts** from Modules. This is accomplished by constructing the **Modular Page** from multiple **Module-folders** found in the page's primary folder.
+A Modular Page is a special type of listing page because it builds a **single page** from its **child-pages**. This allows for the ability to build very complex **one-page layouts** from Modules. This is accomplished by constructing the **Modular Page** from multiple **Module-folders** found in the page's primary folder.
 
 !! A sample **One-Page Skeleton** using a **Modular Page** can be found in the [Grav Downloads](https://getgrav.org/downloads/skeletons).
 
@@ -50,15 +50,15 @@ Each of these page types follows the same basic structure, so before we can get
 
 All content pages are located in the `/user/pages` folder. Each **Page** should be placed in its own folder.
 
-!! Folder names should also be valid **slugs**. Slugs are entirely lowercase, with accented characters replaced by letters from the Latin alphabet and whitespace characters replaced by a dash or an underscore, in order to avoid being encoded.
+!! Folder names should also be valid **slugs**. Slugs are entirely lowercase, with accented characters replaced by letters from the Latin alphabet and whitespace characters replaced by a dash or an underscore, to avoid being encoded.
 
-Grav understands that any integer value followed by a period will be solely for the purpose of ordering, and is removed internally in the system. For example, if you have a folder named `01.home`, Grav will treat this folder as `home`, but will ensure that with default ordering, it comes before `02.blog`.
+Grav understands that any integer value followed by a period will be solely for ordering, and is removed internally in the system. For example, if you have a folder named `01.home`, Grav will treat this folder as `home`, but will ensure that with default ordering, it comes before `02.blog`.
 
 ![Grav Folder Example](page-folders.png)
 
 Your site must have an entry-point so that it knows where to go when you point your browser to the root of your site. For example if you were to enter `http://yoursite.com` in your browser, by default Grav expects an alias `home/`, but you can override the home-location by changing the `home.alias` option in the [Grav configuration file](/basics/grav-configuration).
 
-**Module-folders** are identified by an underscore (`_`) before the folder name. This is a special folder type that is intended to be used only with **modular content**.  These are **not routable** and **not visible** in the navigation. An example of a Module-folder would be a folder such as `user/pages/01.home/_header`. Home is actually configured as a **modular page** and would be constructed from the `_header`, `_features`, and `_body` Modules.
+**Module-folders** are identified by an underscore (`_`) before the folder name. This is a special folder type that is intended to be used only with **modular content**.  These are **not routable** and **not visible** in the navigation. An example of a Module-folder would be a folder such as `user/pages/01.home/_header`. Home is configured as a **modular page** and would be constructed from the `_header`, `_features`, and `_body` Modules.
 
 The textual name of each folder defaults to the _slug_ that the system uses as part of the URL. For example if you have a folder such as `/user/pages/02.blog`, the slug for this page would default to `blog`, and the full URL would be `http://yoursite.com/blog`. A blog item page, located in `/user/pages/02.blog/blog-item-5` would be accessible via `http://yoursite.com/blog/blog-item-5`.
 
@@ -82,7 +82,7 @@ When dealing with collections, there are several options available to control ho
 | **manual**   | The order based on the `order_manual` variable                                                                                                       |
 | **random**   | The order is randomized                                                                                                                              |
 
-You can specifically define a manual order by providing a list of options to the `content.order.custom` configuration setting. This will work in conjunction with the `content.order.by` because it first tries to manually order the pages, but any pages not specified in the manual order, will fall through and be ordered by the ordering provided.
+You can specifically define a manual order by providing a list of options to the `content.order.custom` configuration setting. This will work in conjunction with the `content.order.by` because it first tries to order the pages manually, but any pages not specified in the manual order, will fall through and be ordered by the ordering provided.
 
 !! You can override the **default behavior** for folder ordering and the direction in which the ordering occurs by setting the `pages.order.dir` and the `pages.order.by` options in the [Grav system configuration file](/basics/grav-configuration).
 
@@ -92,7 +92,7 @@ Within the page-folder, we create the actual page-file. The filename should end
 
 The important thing to understand is the name of the file directly references the name of the theme's template file that will be used to render. The standard name for the main template file is **default**, so the file would be named `default.md`.
 
-You, can of course, name your file whatever you like, for example: `document.md`, which would make Grav look for a template file in the theme that matches, such as the **document.html.twig** Twig-template.
+You can, of course, name your file whatever you like, for example: `document.md`, which would make Grav look for a template file in the theme that matches, such as the **document.html.twig** Twig-template.
 
 !! This behavior can be overridden in the page by setting the [template parameter](/content/headers#template) in the headers.
 
@@ -168,7 +168,7 @@ This allows you to perform a wide variety of functionality from any page on your
 ```
 {% endverbatim %}
 
-In the next section we will continue to dig into the specifics of a Page in detail.
+In the next section, we will continue to dig into the specifics of a Page in detail.
 
 ### contentMeta
 

pages/02.content/02.headers/docs.md

@@ -20,7 +20,7 @@ If you have no headers at all, you will not have any control over the title of t
 title: Title of my Page
 ```
 
-If the `title` variable is not set, Grav has a fall back solution, and will try to use the capitalized `slug` variable:
+If the `title` variable is not set, Grav has a fallback solution, and will try to use the capitalized `slug` variable:
 
 ### Slug
 
@@ -435,11 +435,11 @@ sitemap:
 
 The significance of these headers is that Grav does not use them by default. They are only read by the **sitemap plugin** to determine how often this particular page is modified and what its priority should be.
 
-Any page header such as this should be documented, and generally there will be some default value that will be used if the page does not provide it.
+Any page header such as this should be documented, and generally, there will be some default value that will be used if the page does not provide it.
 
 Another example would be to store page-specific data that could then be used by Twig in the content of the page.
 
-For example you might have want to associate some author reference for the page. If you added these YAML settings to the page header:
+For example, you might have want to associate some author reference for the page. If you added these YAML settings to the page header:
 
 ```ruby
 author:

pages/02.content/03.collections/docs.md

@@ -4,11 +4,11 @@ taxonomy:
     category: docs
 ---
 
-Collections have grown considerably since the early betas of Grav. We started off with a very limited set of page-based collections, but with the help of our community we have increased these capabilities to make them even more powerful!  So much so that they now have their own section in the documentation.
+Collections have grown considerably since the early betas of Grav. We started off with a very limited set of page-based collections, but with the help of our community, we have increased these capabilities to make them even more powerful!  So much so that they now have their own section in the documentation.
 
 ## Basics of Grav Collections
 
-In Grav, the most common type of collection is a list of pages that can be defined either in the page's frontmatter or in the twig itself. The most common is to define a collection in the frontmatter. With a collection defined, it is available in the Twig of the page to do with as you wish. By using page collection methods or looping through each [page object](https://learn.getgrav.org/themes/theme-vars#page-object) and using the page methods or properties you can do powerful things. Common examples of this include displaying a list of blog posts, or displaying modular sub-pages to render a complex page design.
+In Grav, the most common type of collection is a list of pages that can be defined either in the page's frontmatter or in the twig itself. The most common is to define a collection in the frontmatter. With a collection defined, it is available in the Twig of the page to do with as you wish. By using page collection methods or looping through each [page object](https://learn.getgrav.org/themes/theme-vars#page-object) and using the page methods or properties you can do powerful things. Common examples of this include displaying a list of blog posts or displaying modular sub-pages to render a complex page design.
 
 ## Collection Object
 

pages/02.content/04.markdown/docs.md

@@ -10,7 +10,7 @@ Let's face it: Writing content for the Web is tiresome. WYSIWYG editors help all
 
 Some of the key benefits are:
 
-1. Markdown is simple to learn, with minimal extra characters so it's also quicker to write content.
+1. Markdown is simple to learn, with minimal extra characters, so it's also quicker to write content.
 2. Less chance of errors when writing in markdown.
 3. Produces valid XHTML output.
 4. Keeps the content and the visual display separate, so you cannot mess up the look of your site.
@@ -23,7 +23,7 @@ John Gruber, the author of Markdown, puts it like this:
 > -- <cite>John Gruber</cite>
 
 
-Grav ships with built-in support for [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](https://michelf.ca/projects/php-markdown/extra/). You must enable **Markdown Extra** in your `system.yaml` configuration file
+Grav ships with built-in support for [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](https://michelf.ca/projects/php-markdown/extra/). You must enable **Markdown Extra** in your `system.yaml` configuration file.
 
 Without further delay, let us go over the main elements of Markdown and what the resulting HTML looks like:
 

pages/02.content/05.linking/docs.md

@@ -28,9 +28,9 @@ To get us started, here is a quick look at some of the common components of a Gr
 
 Grav doesn't just limit your internal links to specific names within your file/directory structure. It can also pull slugs assigned both in the header of the file, as well as the fallback directory name. This makes creating quick links easy as you don't have to remember the specific file name, but an easily remembered (and relevant) slug.
 
-Grav's templating engine uses file names to determine which template to apply to them. For example, a blog might use the common file name `item.md` for each blog post. The blog post itself can be assigned a slug that makes more sense, such as `grass` or `grass-is-green`.
+Grav's templating engine uses file names to determine which template to apply to them. For example, a blog might use the standard file name `item.md` for each blog post. The blog post itself can be assigned a slug that makes more sense, such as `grass` or `grass-is-green`.
 
-Directory names also have numbers assigned which helps with ordering. You don't have to include these numbers with slug-relative links. Grav ignores them when creating the slug, so your site's URL structure is more clean.
+Directory names also have numbers assigned which helps with ordering. You don't have to include these numbers with slug-relative links. Grav ignores them when creating the slug, so your site's URL structure is cleaner.
 
 Here are a few examples of slug-relative links.
 

pages/02.content/06.image-linking/docs.md

@@ -4,19 +4,19 @@ taxonomy:
     category: docs
 ---
 
-Grav has a variety of flexible linking options that allow you to link images from one page to another, and even from remote sources. If you have ever linked files using HTML or worked with a file system using a command line, a lot of this should be very easy to pick up.
+Grav has a variety of flexible linking options that allow you to link images from one page to another, and even from remote sources. If you have ever linked files using HTML or worked with a file system using a command line, a lot of this should be elementary to pick up.
 
 We will run to some easy examples using this very basic, trimmed down model of what a Grav site's **Pages** directory might look like.
 
 ![Pages Directory](pages.png)
 
-Using this directory structure as an example, we will take a look at the different types of links you can use to display media files in your content. We have image files in every folder, including one image for each blog post, and three images in a special `/images` directory which acts as a page, but contains only media files.
+Using this directory structure as an example, we will take a look at the different types of links you can use to display media files in your content. We have image files in every folder, including one image for each blog post, and three images in a special `/images` directory which acts as a page but contains only media files.
 
-The use of the `/images` folder serves as an example of how you can maintain a simple centralized image directory to store files that are frequently used by multiple pages. This simplifies the linking process in these cases.
+The use of the `/images` folder serves as an example of how you can maintain a simple, centralized image directory to store files that are frequently used by multiple pages. This simplifies the linking process in these cases.
 
-!!!! If you decide to use a centralized image directory, be advised that this directory should exist within the `/pages` folder as this folder is intended for front end content.
+!!!! If you decide to use a centralized image directory, be advised that this directory should exist within the `/pages` folder as this folder is intended for front-end content.
 
-To get us started, here is a quick look at some of the common components of a Grav markdown-based image tag.
+To get us started, here is a quick look at some of the standard components of a Grav markdown-based image tag.
 
 ```
 ![Alt Text](../path/image.ext)
@@ -37,7 +37,7 @@ To get us started, here is a quick look at some of the common components of a Gr
 
 With relative links, the location of the source file is every bit as important as that of the destination. If either file in the mix is moved, changing the path between them, the link can be broken.
 
-The advantage of this type of linking structure is that you can easily switch between a local development server and a live server with a different domain name and as long as the file structure remains consistent, the links should work without a problem.
+The advantage of this type of linking structure is that you can quickly switch between a local development server and a live server with a different domain name and as long as the file structure remains consistent, the links should work without a problem.
 
 A file link points to a particular file by name, rather than its directory or slug. If you were creating an image link in `pages/01.blog/test-post-1/item.md` to `/pages/01.blog/test-post-3/test_image_3.jpg` you would use the following command.