Docs - Remove not inclusive words (#26294)

Co-authored-by: Lennart <lekoarts@gmail.com>
gatsbyjs · Aug 31, 2020 · 21b94df · 21b94df
1 parent 652af04
commit 21b94df
Show file tree

Hide file tree

Showing 20 changed files with 23 additions and 23 deletions.
diff --git a/docs/contributing/rfc-process.md b/docs/contributing/rfc-process.md
@@ -106,7 +106,7 @@ to the document.
 
 ## Implementing an RFC
 
-The author of an RFC is not obligated to implement it. Of course, the RFC
+The author of an RFC is not obligated to implement it. The RFC
 author (like any other developer) is welcome to post an implementation for
 review after the RFC has been accepted.
 

diff --git a/docs/docs/add-custom-webpack-config.md b/docs/docs/add-custom-webpack-config.md
@@ -61,7 +61,7 @@ exports.onCreateWebpackConfig = ({
 
 ### Absolute imports
 
-Instead of writing `import Header from '../../components/header'` over and over again you can just write `import Header from 'components/header'` with absolute imports:
+Instead of writing `import Header from '../../components/header'` over and over again you can write `import Header from 'components/header'` with absolute imports:
 
 ```js:title=gatsby-node.js
 exports.onCreateWebpackConfig = ({ stage, actions }) => {

diff --git a/docs/docs/adding-a-list-of-markdown-blog-posts.md b/docs/docs/adding-a-list-of-markdown-blog-posts.md
@@ -2,7 +2,7 @@
 title: Adding a List of Markdown Blog Posts
 ---
 
-Once you have added Markdown pages to your site, you are just one step away from being able to list your posts on a dedicated index page.
+Once you have added Markdown pages to your site, you are one step away from being able to list your posts on a dedicated index page.
 
 ## Creating posts
 

diff --git a/docs/docs/adding-search-with-algolia.md b/docs/docs/adding-search-with-algolia.md
@@ -24,7 +24,7 @@ To build the user interface for searching, this guide will use [React InstantSea
 
 ## Setting up the project
 
-This guide will set up a search based on the [Gatsby starter blog](/starters/gatsbyjs/gatsby-starter-blog/). You can of course base it on your own project instead, but that might require minor modifications to the code, depending on your page structure and the frameworks you use.
+This guide will set up a search based on the [Gatsby starter blog](/starters/gatsbyjs/gatsby-starter-blog/). You can base it on your own project instead, but that might require minor modifications to the code, depending on your page structure and the frameworks you use.
 
 Create a new site using
 

diff --git a/docs/docs/adding-tags-and-categories-to-blog-posts.md b/docs/docs/adding-tags-and-categories-to-blog-posts.md
@@ -231,7 +231,7 @@ Some notes:
 
 ## Make a tags index page (`/tags`) that renders a list of all tags
 
-Your `/tags` page will simply list out all tags, followed by the number of posts with that tag. You can get the data with the first query you wrote earlier, that groups posts by tags:
+Your `/tags` page will list out all tags, followed by the number of posts with that tag. You can get the data with the first query you wrote earlier, that groups posts by tags:
 
 ```jsx:title=src/pages/tags.js
 import React from "react"
@@ -308,4 +308,4 @@ export const pageQuery = graphql`
 
 ## _(optional)_ Render tags inline with your blog posts
 
-The home stretch! Anywhere else you'd like to render your tags, simply add them to the `frontmatter` section of your `graphql` query and access them in your component like any other prop.
+The home stretch! Anywhere else you'd like to render your tags, add them to the `frontmatter` section of your `graphql` query and access them in your component like any other prop.
diff --git a/docs/docs/build-caching.md b/docs/docs/build-caching.md
@@ -64,7 +64,7 @@ exports.onPostBuild = async function ({ cache, store, graphql }, { query }) {
 
 ## Clearing cache
 
-Since cache files are stored within the `.cache` directory, simply deleting it will clear all cache. You can also use [`gatsby clean`](/docs/gatsby-cli/#clean) to delete the `.cache` and `public` folders.
+Since cache files are stored within the `.cache` directory, deleting it will clear all cache. You can also use [`gatsby clean`](/docs/gatsby-cli/#clean) to delete the `.cache` and `public` folders.
 The cache is also invalidated by Gatsby in a few cases, specifically:
 
 - If `package.json` changes, for example a dependency is updated or added

diff --git a/docs/docs/creating-a-sitemap.md b/docs/docs/creating-a-sitemap.md
@@ -30,7 +30,7 @@ module.exports = {
 
 **Note:** The siteUrl property must be defined and not left empty.
 
-Next run a build (`npm run build`) since the sitemap generation will only happen for production builds. This is all that's required to get a working sitemap with Gatsby! By default, the generated sitemap path is /sitemap.xml and will include all of your site’s pages, but of course the plugin exposes options to configure this default functionality.
+Next run a build (`npm run build`) since the sitemap generation will only happen for production builds. This is all that's required to get a working sitemap with Gatsby! By default, the generated sitemap path is /sitemap.xml and will include all of your site’s pages, but the plugin exposes options to configure this default functionality.
 
 ### Additional modifications
 

diff --git a/docs/docs/creating-dynamic-navigation.md b/docs/docs/creating-dynamic-navigation.md
@@ -187,7 +187,7 @@ const Layout = ({ children }) => (
 
 ## Using the header component to display the navigation
 
-Locate the `header.js` file inside `src/components` and remove everything so only the functional component definition is left (everything else is just boilerplate code given to you when generating your project):
+Locate the `header.js` file inside `src/components` and remove everything so only the functional component definition is left (everything else is boilerplate code given to you when generating your project):
 
 ```jsx:title=src/components/header.js
 import React from "react"

diff --git a/docs/docs/deploying-to-azure.md b/docs/docs/deploying-to-azure.md
@@ -94,7 +94,7 @@ Next, add configuration details specific to your Gatsby project.
 
 The `App location` is the location of your front end app code. If you have a frontend app and an API in different directories but in the same repository, you will need to point out under which sub directory your front end app lives. You can leave this blank if you have a Gatsby project at the root.
 
-The default value for `Api location` is `/api`. As we don't have an API in an `/api` directory we can leave this blank and the Static Web App Service will ignore it during build. If you wish you can add an API at a later stage. Refer to the links at the bottom of this doc that describes how to do just that.
+The default value for `Api location` is `/api`. As we don't have an API in an `/api` directory we can leave this blank and the Static Web App Service will ignore it during build. If you wish you can add an API at a later stage. Refer to the links at the bottom of this doc that describes how to do that.
 
 The really important field to specify is the `App artifact location`, this should point to the folder where your Gatsby project is built, this would be `public` directory.
 

diff --git a/docs/docs/deploying-to-netlify.md b/docs/docs/deploying-to-netlify.md
@@ -23,7 +23,7 @@ There are two ways you can host your site:
 
 ### Git repository setup
 
-Netlify currently has built in support for [GitHub](https://github.com/), [GitLab](https://about.gitlab.com/) and [Bitbucket](https://bitbucket.org/). This approach allows you to roll back to past versions of the website whenever you want. You also gain the ability to redeploy the site simply by pushing the code to the respective repository, with no need to manually rebuild and upload every time you make changes. Your repository can be private or public.
+Netlify currently has built in support for [GitHub](https://github.com/), [GitLab](https://about.gitlab.com/) and [Bitbucket](https://bitbucket.org/). This approach allows you to roll back to past versions of the website whenever you want. You also gain the ability to redeploy the site by pushing the code to the respective repository, with no need to manually rebuild and upload every time you make changes. Your repository can be private or public.
 
 Now, login to Netlify and you will see a `New site from git` button at the top right corner of the screen. Click on it and connect with the same git provider that you used to host your website and authorize Netlify to use your account. Choose your website repository and it will take you to deploy settings with the below options.
 

diff --git a/docs/docs/end-to-end-testing.md b/docs/docs/end-to-end-testing.md
@@ -2,7 +2,7 @@
 title: End-to-End Testing
 ---
 
-[Cypress](https://www.cypress.io/) is one of the options when it comes to end-to-end (E2E) testing. Cypress is an all-in-one testing framework focused on E2E testing, meaning that you don't have to install 10 different things to get your test suite set up. You can write your first passing test in minutes without any configuration with the help of Cypress' API, which is easy to read and understand. It runs tests as fast as your browser can render content, which also makes test-driven development possible. You'll also profit from the time travel feature or the extensive debugging capabilities with Chrome DevTools. Of course, you can also use it with Gatsby, and this guide will explain how.
+[Cypress](https://www.cypress.io/) is one of the options when it comes to end-to-end (E2E) testing. Cypress is an all-in-one testing framework focused on E2E testing, meaning that you don't have to install 10 different things to get your test suite set up. You can write your first passing test in minutes without any configuration with the help of Cypress' API, which is easy to read and understand. It runs tests as fast as your browser can render content, which also makes test-driven development possible. You'll also profit from the time travel feature or the extensive debugging capabilities with Chrome DevTools. You can also use it with Gatsby, and this guide will explain how.
 
 To run Gatsby's development server and Cypress at the same time, you'll use the little helper [start-server-and-test](https://github.com/bahmutov/start-server-and-test). If you're already using [@testing-library/react](https://github.com/testing-library/react-testing-library) for [unit testing](/docs/unit-testing), you might want to install [@testing-library/cypress](https://github.com/testing-library/cypress-testing-library), too. This way you can use the same methods you used with `@testing-library/react` in your Cypress tests. Install the following packages to your `devDependencies`:
 

diff --git a/docs/docs/glossary/hydration.md b/docs/docs/glossary/hydration.md
@@ -36,7 +36,7 @@ With client-side rendering, most actions trigger local DOM updates instead of ne
 
 That's the drawback to client-side rendering: none of your site's content is visible or interactive until the client downloads JavaScript and builds the DOM. However, not all clients can construct a DOM. For example, client-side rendering can prevent search engine and social media crawlers from consuming and indexing your site's URLs. Browser users, on the other hand, may see a blank page or loading image while your JavaScript bundle downloads and executes.
 
-[Server-side rendering](/docs/glossary/server-side-rendering/) makes HTML available to the client _before_ JavaScript loads. Your site visitors can see and read your content even if it is not fully interactive. Server rendering eliminates the blank page problem. Rendered HTML also makes it easier for search engine and social media crawlers to consume your site. Of course, server-side rendering also has a drawback: every URL request requires another round trip to the server.
+[Server-side rendering](/docs/glossary/server-side-rendering/) makes HTML available to the client _before_ JavaScript loads. Your site visitors can see and read your content even if it is not fully interactive. Server rendering eliminates the blank page problem. Rendered HTML also makes it easier for search engine and social media crawlers to consume your site. Server-side rendering also has a drawback: every URL request requires another round trip to the server.
 
 Hydration lets us take a hybrid approach.
 

diff --git a/docs/docs/how-code-splitting-works.md b/docs/docs/how-code-splitting-works.md
@@ -32,7 +32,7 @@ Great! You've told webpack where you want to code split. But how will these be n
 [name]-[contenthash].js
 ```
 
-Content hash is simply a hash of the contents of the chunk that was code split. But what about `name`? You haven't told webpack the "name" of the chunk, other than the filename, which can't be a name since it has slashes in it. Normally, webpack would replace `[name]` with `[id]` (see [webpack docs](https://webpack.js.org/configuration/output/#output-chunkfilename)). But, it gives us the opportunity to specify the name instead as a comment in the `import block`. In the example above, that's what the `/* webpackChunkName: "component---src-blog-js" */` is doing.
+Content hash is a hash of the contents of the chunk that was code split. But what about `name`? You haven't told webpack the "name" of the chunk, other than the filename, which can't be a name since it has slashes in it. Normally, webpack would replace `[name]` with `[id]` (see [webpack docs](https://webpack.js.org/configuration/output/#output-chunkfilename)). But, it gives us the opportunity to specify the name instead as a comment in the `import block`. In the example above, that's what the `/* webpackChunkName: "component---src-blog-js" */` is doing.
 
 ## Primer on chunkGroups and chunks
 

diff --git a/docs/docs/html-generation.md b/docs/docs/html-generation.md
@@ -60,7 +60,7 @@ We create an `html` React component that will eventually be rendered to a file.
 
 ### 3. Load Page and Data
 
-The only input to `static-entry.js` is a path. So we must look up the page for that path in order to find its `componentChunkName` and `jsonName`. This is achieved by simply looking up the pages array contained in `data.json`. We can then load its data by looking it up in `dataPaths`.
+The only input to `static-entry.js` is a path. So we must look up the page for that path in order to find its `componentChunkName` and `jsonName`. This is achieved by looking up the pages array contained in `data.json`. We can then load its data by looking it up in `dataPaths`.
 
 ### 4. Create Page Component
 

diff --git a/docs/docs/local-https.md b/docs/docs/local-https.md
@@ -116,7 +116,7 @@ Your options are as follows:
 
 ## After `devcert` setup process
 
-You can open the development server at `https://localhost:8000` and enjoy the HTTPS goodness ✨. Of course, you may change the port according to your setup.
+You can open the development server at `https://localhost:8000` and enjoy the HTTPS goodness ✨. You may change the port according to your setup.
 
 Find out more about [how devcert works](https://github.com/davewasmer/devcert#how-it-works).
 

diff --git a/docs/docs/node-creation.md b/docs/docs/node-creation.md
@@ -51,7 +51,7 @@ Let's say you create the following node by passing it to `createNode`
 }
 ```
 
-The value for `baz` is itself an object. That value's parent is the top level object. In this case, Gatsby simply saves the top level node as is to redux. It doesn't attempt to extract `baz` into its own node. It does however track the subobject's root NodeID using [Node Tracking](/docs/node-tracking/)
+The value for `baz` is itself an object. That value's parent is the top level object. In this case, Gatsby saves the top level node as is to redux. It doesn't attempt to extract `baz` into its own node. It does however track the subobject's root NodeID using [Node Tracking](/docs/node-tracking/)
 
 During schema compilation, Gatsby will infer the sub object's type while [creating the gqlType](/docs/schema-inference#plain-object-or-value-field).
 

diff --git a/docs/docs/production-app.md b/docs/docs/production-app.md
@@ -136,7 +136,7 @@ Then, the app, webpack-runtime, component, shared libraries, and data JSON bundl
 
 The first thing your app does is run the [onClientEntry](/docs/browser-apis/#onClientEntry) browser API. This allows plugins to perform any operations before you hit the rest of the page loading logic. For example [gatsby-plugin-glamor](/packages/gatsby-plugin-glamor/) will call rehydrate.
 
-It's worth noting that the browser API runner is completely different to `api-runner-node` which is explained in [How APIs/Plugins Are Run](/docs/how-plugins-apis-are-run/). `api-runner-node` runs in Node.js and has to deal with complex server based execution paths. Whereas running APIs on the browser is simply a matter of iterating through the site's registered browser plugins and running them one after the other (see [api-runner-browser.js](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/cache-dir/api-runner-browser.js#L9)).
+It's worth noting that the browser API runner is completely different to `api-runner-node` which is explained in [How APIs/Plugins Are Run](/docs/how-plugins-apis-are-run/). `api-runner-node` runs in Node.js and has to deal with complex server based execution paths. Whereas running APIs on the browser is a matter of iterating through the site's registered browser plugins and running them one after the other (see [api-runner-browser.js](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/cache-dir/api-runner-browser.js#L9)).
 
 One thing to note is that it gets the list of plugins from `./cache/api-runner-browser-plugins.js`, which is generated [early in bootstrap](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bootstrap/index.js#L338).
 

diff --git a/docs/docs/schema-customization.md b/docs/docs/schema-customization.md
@@ -556,7 +556,7 @@ it is possible to define custom extensions as a way to add reusable functionalit
 to fields. Say you want to add a `fullName` field to `AuthorJson`
 and `ContributorJson`.
 
-You could of course write a `fullNameResolver`, and use it in two places:
+You could write a `fullNameResolver`, and use it in two places:
 
 ```js:title=gatsby-node.js
 const fullNameResolver = source => `${source.firstName} ${source.name}`
@@ -662,7 +662,7 @@ exports.createSchemaCustomization = ({ actions }) => {
 }
 ```
 
-It can then be used in any `createTypes` call by simply adding the directive/extension
+It can then be used in any `createTypes` call by adding the directive/extension
 to the field:
 
 ```js:title=gatsby-node.js
@@ -1143,7 +1143,7 @@ exports.createResolvers = ({
 You create a new `imageFile` field on the `CMS_Asset` type, which will create `File`
 nodes from every value on the `url` field. Since `File` nodes automatically have
 `childImageSharp` convenience fields available, you can then feed the images from the CMS
-into `gatsby-image` by simply querying:
+into `gatsby-image` by querying:
 
 ```graphql
 query {

diff --git a/docs/docs/tailwind-css.md b/docs/docs/tailwind-css.md
@@ -191,7 +191,7 @@ From v1.4.0 onwards PurgeCSS is built into Tailwind CSS, but the approaches need
 
 **1.4.0 and above**
 
-In 1.4.0 you can purge your CSS directly from your Tailwind config. You simply need to provide an array of strings telling it which files to process.
+In 1.4.0 you can purge your CSS directly from your Tailwind config. You need to provide an array of strings telling it which files to process.
 
 ```js:title=tailwind.config.js
 module.exports = {

diff --git a/docs/docs/use-static-query.md b/docs/docs/use-static-query.md
@@ -78,7 +78,7 @@ export const useSiteMetadata = () => {
 }
 ```
 
-Then just import your newly created hook, like so:
+Then import your newly created hook, like so:
 
 ```jsx:title=src/pages/index.js
 import React from "react"