remove graphql from dictionary (#25626)

dictionary.txt

@@ -900,7 +900,6 @@ GraphiQl
 GraphiQL
 graphiql-code-exporter
 graphiql-filesystem
-graphql
 GraphQL
 GraphQL-based
 graphql-compose

docs/blog/2017-10-01-migrating-my-blog-from-hexo-to-gatsby/index.md

@@ -343,8 +343,8 @@ be intuitive.
   global
 
 The error handling is pretty straightforward, if a bit verbose, as long as you
-know what graphql responses look like. In case you didn't know, if you get an
-error in a graphql query the response will contain the `errors` array. We check
+know what GraphQL responses look like. In case you didn't know, if you get an
+error in a GraphQL query the response will contain the `errors` array. We check
 for this array and handle it accordingly.
 
 Now let's looks specifically at where we render a link for each blog post:

docs/blog/2018-01-22-getting-started-gatsby-and-wordpress/index.md

@@ -113,7 +113,7 @@ _.each(result.data.allWordpressPost.edges, edge => {
 })
 ```
 
-The [docs define a Gatsby page](/docs/api-specification/#concepts) as "a site page with a pathname, a template component, and optional graphql query and layout component." See the docs on the [createPage bound action creator](/docs/actions/#createPage) and [guide on creating and modifying pages for more detail](/docs/creating-and-modifying-pages/).
+The [docs define a Gatsby page](/docs/api-specification/#concepts) as "a site page with a pathname, a template component, and optional GraphQL query and layout component." See the docs on the [createPage bound action creator](/docs/actions/#createPage) and [guide on creating and modifying pages for more detail](/docs/creating-and-modifying-pages/).
 
 ## ... Take a step back to "templates"
 
@@ -125,7 +125,7 @@ A template is a page component we can loop over to dynamically create pages base
 
 So a template is a page component that we can use to programmatically create pages. Then what's a page component?
 
-> Page Component — React.js component that renders a page and can optionally specify a layout component and a graphql query. ([Source](/docs/api-specification/#concepts)).
+> Page Component — React.js component that renders a page and can optionally specify a layout component and a GraphQL query. ([Source](/docs/api-specification/#concepts)).
 
 React components living in `src/pages` automatically become pages. The file name of a page maps to its site path. My site in its current state only has one good example of this — `src/pages/index.js` maps to [amberley.blog](https://amberley.blog/). If I had an 'about' page, it would live at `src/pages/about.js`, and map to [amberley.blog/about](https://amberley.blog/about). (Since that doesn't exist, it will actually end up hitting the only other page currently defined in my site, which is `src/pages/404.js` — ([read about 404 pages](/docs/add-404-page/)).
 

docs/blog/2019-02-27-reactiflux-q-and-a/index.md

@@ -139,7 +139,7 @@ While it's inevitable that bugs come with any platform you choose to build on, G
 
 **A:** Yeah — this is a top priority — we've been a bit overwhelmed post v2 launch handling issues/PRs but our we've thought a lot about this problem and next steps are a) [make it possible to export your schema and directly control it](https://github.com/gatsbyjs/gatsby/issues/4261).
 
-We're also very excited that more and more services are offering native GraphQL APIs which gets us out of having to dynamically create the schema. We added [support for stitching in graphql schemas](/blog/2018-09-25-announcing-graphql-stitching-support/) earlier this year and have a lot more plans to make schema stitching more powerful e.g. [add support for transforming data from 3rd party schemas](https://github.com/gatsbyjs/rfcs/pull/11).
+We're also very excited that more and more services are offering native GraphQL APIs which gets us out of having to dynamically create the schema. We added [support for stitching in GraphQL schemas](/blog/2018-09-25-announcing-graphql-stitching-support/) earlier this year and have a lot more plans to make schema stitching more powerful e.g. [add support for transforming data from 3rd party schemas](https://github.com/gatsbyjs/rfcs/pull/11).
 
 — kylemathews
 
@@ -189,7 +189,7 @@ A Gatsby email _application_. Contribute to DSchau/gatsby-mail development by cr
 
 **Q:** I have found developing plugins that create nodes or interact with the gatsby-api to be a big hassle in comparison to how pages and other content is developed. Is there any plans on making something like "hot-reload" nodes or generation during development without having to stop and start gatsby? — Everspace
 
-**A:** Source and transformer plugins can "hot reload" data during development. Support for this is baked into Gatsby's data layer. It's a bit complicated to explain in a Q&A but basically a source plugin can watch for data to change and re-emit nodes. Gatsby will then notice this and automatically re-run graphql queries for pages affected by the changing data. gatsby-source-filesystem is the most prominent example of this. It watches for file changes and re-emits File nodes as the data changes. [This is what drives Ludicrous Mode™️](https://twitter.com/gatsbyjs/status/974507205121617920?lang=en) You can see the code for this [here](https://github.com/gatsbyjs/gatsby/blob/d4d33467bcff60ad3c740244d7585227d7e117ee/packages/gatsby-source-filesystem/src/gatsby-node.js#L129-L136).
+**A:** Source and transformer plugins can "hot reload" data during development. Support for this is baked into Gatsby's data layer. It's a bit complicated to explain in a Q&A but basically a source plugin can watch for data to change and re-emit nodes. Gatsby will then notice this and automatically re-run GraphQL queries for pages affected by the changing data. gatsby-source-filesystem is the most prominent example of this. It watches for file changes and re-emits File nodes as the data changes. [This is what drives Ludicrous Mode™️](https://twitter.com/gatsbyjs/status/974507205121617920?lang=en) You can see the code for this [here](https://github.com/gatsbyjs/gatsby/blob/d4d33467bcff60ad3c740244d7585227d7e117ee/packages/gatsby-source-filesystem/src/gatsby-node.js#L129-L136).
 
 — kylemathews
 

docs/blog/2019-06-12-performance-improvements-for-large-sites/index.md

@@ -25,7 +25,7 @@ There were two main symptoms experienced by users of large Gatsby sites.
 The central problem was that Gatsby generates a file for each build called `pages-manifest.json` (also called `data.json`) that must be loaded by the browser before users can navigate to other pages. It contains metadata about every page on the site, including:
 
 - **componentChunkName**: The logical name of the React component for the page
-- **dataPath**: The path to the file that contains the page's graphql query result, and any other page context.
+- **dataPath**: The path to the file that contains the page's GraphQL query result, and any other page context.
 
 When a user clicks a link to another page, Gatsby first looks up the manifest for the page's component and query result file. Gatsby then downloads them (if they haven't already been prefetched), and then passes the loaded query results to the page's component and renders it. Since `pages-manifest` contains the list of all pages on the site, Gatsby can also immediately show a 404 if necessary if the page is not able to be located.
 
@@ -38,10 +38,10 @@ Even after the manifest had been loaded, the manifest had to be searched for the
 The solution seems abundantly obvious at this point. We needed to introduce a manifest file per page, instead of a global pages-manifest. We called this `page-data.json`. It includes:
 
 - **componentChunkName**: The logical name of the React component for the page
-- **result**: The full graphql query result and page context
+- **result**: The full GraphQL query result and page context
 - **webpackCompilationHash**: Unique hash output by webpack any time user's `src` code content changes
 
-This is very similar to each entry in the pages manifest. The major difference being that the graphql query result is inlined instead of being contained in a separate file.
+This is very similar to each entry in the pages manifest. The major difference being that the GraphQL query result is inlined instead of being contained in a separate file.
 
 Now, when a page navigation occurs, Gatsby makes a request directly to the server for the `page-data.json`, instead of checking the global manifest (which doesn't exist anymore).
 
@@ -70,7 +70,7 @@ However, this is only true if a page hasn't already been prefetched. We have som
 
 ### Netlify builds faster
 
-The old graphql static query results were content-hashed. Which meant that any change to any data resulted in a change to the pages-manifest. Hosting sites such as Netlify look at the changed files and use that to figure out what files can be shared between builds. Since the pages-manifest depends on all query result files, which are all content-hashed, then any data change resulted in a change to the pages-manifest, which could be 10+ MB in size.
+The old GraphQL static query results were content-hashed. Which meant that any change to any data resulted in a change to the pages-manifest. Hosting sites such as Netlify look at the changed files and use that to figure out what files can be shared between builds. Since the pages-manifest depends on all query result files, which are all content-hashed, then any data change resulted in a change to the pages-manifest, which could be 10+ MB in size.
 
 With the latest changes, if you only make a change one page's data, then Netlify will only have to copy that file when it rebuilds.
 

docs/blog/2019-07-23-google-sheets-gatsby-acroyoga-video-explorer/index.md

@@ -215,7 +215,7 @@ I did exactly the same for my instructors so I'll skip it here for brevity. As y
 
 As I mentioned at the beginning, I won't show the code for each and every component here. But I will explain the general process I used to create this UI. I first created the templates, which are single-tag.js, single-item.js, and single-instructor.js. These templates are used in gatsby-node.js when the createPage methods are called.
 
-My templates are fairly standard Gatsby templates with a React component at the top and a graphql query at the bottom. On the single-tag.js and single-instructor.js templates, I use filters in the query to get only the videos that match that tag. Here's how that query looks:
+My templates are fairly standard Gatsby templates with a React component at the top and a GraphQL query at the bottom. On the single-tag.js and single-instructor.js templates, I use filters in the query to get only the videos that match that tag. Here's how that query looks:
 
 ```javascript
 export const tagPageQuery = graphql`
@@ -238,7 +238,7 @@ export const tagPageQuery = graphql`
 
 This query uses $tag from React context (which was created in gatsby-node.js) to do the filtering. If $tag is found in the array of tags (for that row), then it returns that row (which is a video). This is how I can create separate instructor and tag pages that only show those relevant videos (the videos with those specific tags or instructors).
 
-At the top of my tag pages, I have a title that says “24 videos tagged with [the tag]”. To get the tag for that page, I need to pass pageContext as a prop to this template component. That allows me to access that \$tag variable within the template (instead of a graphql query). Now I can make the title with the following code:
+At the top of my tag pages, I have a title that says “24 videos tagged with [the tag]”. To get the tag for that page, I need to pass pageContext as a prop to this template component. That allows me to access that \$tag variable within the template (instead of a GraphQL query). Now I can make the title with the following code:
 
 ```jsx
 {itemsWithTag.length} {itemsWithTag.length > 1 ? 'videos' : 'video'} tagged with
@@ -305,7 +305,7 @@ Linking to the instructor and tags is done with this code:
 </CardContent>
 ```
 
-That's it. It's just `<Link to=` and the relative path, e.g. `<Link to="/some-resource/" />`. I don't need to worry about passing the right props or anything else. I know the page exists (because I built it using createPage in gatsby-node.js). I know the template will have the right data (because I setup the graphql query in that template file). I just need to Link to the right URL, and the pages will connect correctly. This creates a fast and intuitive user experience wherein the user can quickly click through the pages to find the right video.
+That's it. It's just `<Link to=` and the relative path, e.g. `<Link to="/some-resource/" />`. I don't need to worry about passing the right props or anything else. I know the page exists (because I built it using createPage in gatsby-node.js). I know the template will have the right data (because I setup the GraphQL query in that template file). I just need to Link to the right URL, and the pages will connect correctly. This creates a fast and intuitive user experience wherein the user can quickly click through the pages to find the right video.
 
 ## Creating a simple video player with React-Player
 

docs/contributing/gatsby-style-guide.md

@@ -219,7 +219,7 @@ Folder:
 
 The `.md` title or the folder title gets turned into the URL route automatically.
 
-Article titles should be short and reflect the main theme of the article to help readers quickly find relevant info. Many people use a search engine to find topics like "gatsby graphql", so the article title should ideally reflect common search terms.
+Article titles should be short and reflect the main theme of the article to help readers quickly find relevant info. Many people use a search engine to find topics like "gatsby GraphQL", so the article title should ideally reflect common search terms.
 
 Here are some title examples:
 

docs/docs/api-specification.md

@@ -61,7 +61,7 @@ Gatsby has multiple processes. The most prominent is the "bootstrap" process. It
 
 The bootstrap process is as follows:
 
-load site config -> load plugins -> source nodes -> transform nodes -> create graphql schema -> create pages -> compile component queries -> run queries -> fin
+load site config -> load plugins -> source nodes -> transform nodes -> create GraphQL schema -> create pages -> compile component queries -> run queries -> fin
 
 Once the initial bootstrap is finished, a `webpack-dev-server` and express server are started for serving files for the development workflow with live updates. For a production build, Gatsby skips the development server and instead builds the CSS, then JavaScript, then static HTML with webpack.
 

docs/docs/creating-a-transformer-plugin.md

@@ -55,7 +55,7 @@ module.exports = {
 }
 ```
 
-These are exposed in your graphql schema which you can query:
+These are exposed in your GraphQL schema which you can query:
 
 ```graphql
 query {

docs/docs/creating-dynamic-navigation.md

@@ -11,7 +11,7 @@ What this section will cover:
 - Pulling the data into a component using StaticQuery
 - Dynamically rendering your navigation
 
-You will be using `gatsby-config.js` to store the data for your links. `gatsby-config.js` is a file used for configuring Gatsby, located in the root path of every Gatsby project. A plain old JavaScript object is exported from this file; this object contains the `siteMetadata` object which you can query through graphql when generating your static pages.
+You will be using `gatsby-config.js` to store the data for your links. `gatsby-config.js` is a file used for configuring Gatsby, located in the root path of every Gatsby project. A plain old JavaScript object is exported from this file; this object contains the `siteMetadata` object which you can query through GraphQL when generating your static pages.
 
 This guide will use the Gatsby starter project `gatsby-starter-default`, which can be downloaded through the Gatsby command line interface tool using the command `gatsby new [project-name] https://github.com/gatsbyjs/gatsby-starter-default`.
 

docs/docs/gatsby-internals-terminology.md

@@ -105,7 +105,7 @@ Created as part of page, but currently unused.
 
 ### page.context
 
-This is [merged with the page itself](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/query/query-runner.ts#L79) and then is [passed to graphql](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/query/query-runner.ts#L36) queries as the `context` parameter.
+This is [merged with the page itself](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/query/query-runner.ts#L79) and then is [passed to GraphQL](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/query/query-runner.ts#L36) queries as the `context` parameter.
 
 ## Query
 

docs/docs/gatsby-repl.md

@@ -6,7 +6,7 @@ The Gatsby REPL ("read-eval-print loop") is available via the Gatsby CLI by runn
 
 This doc will give a brief description of each REPL command, expected output, and an example of what you can do with the command to digest the data. Examples are using the [Gatsby Starter Blog](/starters/gatsbyjs/gatsby-starter-blog/) as a demo environment, since it is currently the highest rated starter, and provides standard output for most of these commands.
 
-To get started, in your terminal, after running the initial site setup steps [here](/docs/quick-start), run the command `gatsby repl` to enter the interactive shell. If you are writing out a function, you can write that over multiple lines, as long as you do not use a semicolon or close a parenthesis or brace prematurely. This is helpful for running graphql queries and callback functions.
+To get started, in your terminal, after running the initial site setup steps [here](/docs/quick-start), run the command `gatsby repl` to enter the interactive shell. If you are writing out a function, you can write that over multiple lines, as long as you do not use a semicolon or close a parenthesis or brace prematurely. This is helpful for running GraphQL queries and callback functions.
 
 ## REPL Commands
 

docs/docs/migrating-from-v0-to-v1.md

@@ -285,7 +285,7 @@ export const pageQuery = graphql`
 `
 ```
 
-At the bottom of the file you'll notice the graphql query. This is how pages and
+At the bottom of the file you'll notice the GraphQL query. This is how pages and
 templates in Gatsby v1 get their data. In v0, wrapper components had little
 control over what data they got. In v1, templates and pages can query for
 exactly the data they need.

docs/docs/migrating-from-v1-to-v2.md

@@ -50,7 +50,7 @@ This documentation page covers the _how_ of migrating from v1 to v2. Various blo
 - [Resolving Deprecations](#resolving-deprecations)
 
   - [Import Link from Gatsby](#import-link-from-gatsby)
-  - [Import graphql from Gatsby](#import-graphql-from-gatsby)
+  - [Import GraphQL from Gatsby](#import-graphql-from-gatsby)
   - [Rename `boundActionCreators` to `actions`](#rename-boundactioncreators-to-actions)
   - [Rename `pathContext` to `pageContext`](#rename-pathcontext-to-pagecontext)
   - [Rename responsive image queries](#rename-responsive-image-queries)
@@ -812,7 +812,7 @@ Furthermore you can remove the package from the `package.json`.
 }
 ```
 
-### Import graphql from Gatsby
+### Import GraphQL from Gatsby
 
 The `graphql` tag function that Gatsby v1 auto-supports is deprecated in v2. Gatsby will throw deprecation warning unless you explicitly import it from the `gatsby` package.
 
@@ -1025,7 +1025,7 @@ The node `internal` object isn't meant for adding node data. While Gatsby v1 all
 
 ### Import `graphql` types from `gatsby/graphql`
 
-Import graphql types from `gatsby/graphql` to prevent `Schema must contain unique named types but contains multiple types named "<typename>"` errors. `gatsby/graphql` exports all builtin GraphQL types as well as `graphQLJSON` type.
+Import GraphQL types from `gatsby/graphql` to prevent `Schema must contain unique named types but contains multiple types named "<typename>"` errors. `gatsby/graphql` exports all builtin GraphQL types as well as `graphQLJSON` type.
 
 ```diff
 -const { GraphQLString } = require(`graphql`)