Fix casing of JavaScript in all docs (#6115)

* Renamed `Javascript` to `JavaScript` for all relevant occurences

docs/blog/2017-09-18-gatsby-modern-static-generation/index.md

@@ -53,7 +53,7 @@ need to maintain a runtime, a database, application code, or complex optimized
 web servers.
 
 But the downside is you have to keep separate template files that will
-eventually rendered as HTML on the browser, and Javascript file that will
+eventually rendered as HTML on the browser, and JavaScript file that will
 eventually manipulate that HTML again on the browser (and CSS assets too).
 
 ## Enter the new world order
@@ -86,7 +86,7 @@ On your end, the development flow looks:
 - During development, write code like a boss (hot reloading, modularized code,
   webpack plugins, etc...)
 - Use React.js Server Side Rendering API to convert this code to static HTML
-  content, and Javascript code, on your server
+  content, and JavaScript code, on your server
 
 It’s really that easy? Well, sort of.
 

docs/blog/2017-12-06-gatsby-plus-contentful-plus-netlify/index.md

@@ -157,7 +157,7 @@ features. I haven’t heard any complaints from my co-workers.
 Another “problem” with static sites is the lack of out-of-the-box site search.
 Most search implementations occur between the server and the database. As a doc
 site, users typically expect solid search functionality. There are a few
-frontend only javascript search libraries (like [lunr.js](https://lunrjs.com/))
+frontend only JavaScript search libraries (like [lunr.js](https://lunrjs.com/))
 that take a search query and parse a pre-built JSON index of your content.
 
 I could have created this index by tying into the `onPostBuild` Gatsby API. This

docs/blog/2018-02-16-bright-future-for-the-web/index.md

@@ -10,7 +10,7 @@ _This article was originally published on
 [Medium](https://medium.com/@ryanwiemer/gatsby-and-the-jam-stack-91e31508f364)
 on January 31, 2018._
 
-Recently I relaunched my wife’s photography portfolio, [KNW Photography](https://www.knw.io/), using a combination of Gatsby, [Contentful](https://www.contentful.com/) and [Netlify](https://www.netlify.com/). This particular group of tools represents a new and exciting web development architecture known as the [JAMstack](https://jamstack.org/) (Javascript, APIs and Markup). In this post I will be sharing my personal thoughts on each of these new tools and why together they represent the “holy grail” of the static website world.
+Recently I relaunched my wife’s photography portfolio, [KNW Photography](https://www.knw.io/), using a combination of Gatsby, [Contentful](https://www.contentful.com/) and [Netlify](https://www.netlify.com/). This particular group of tools represents a new and exciting web development architecture known as the [JAMstack](https://jamstack.org/) (JavaScript, APIs and Markup). In this post I will be sharing my personal thoughts on each of these new tools and why together they represent the “holy grail” of the static website world.
 
 ## Why Other Static Site Generators Didn’t Work For Me
 

docs/blog/2018-03-29-migration-from-wordpress-to-gatsby/index.md

@@ -32,9 +32,9 @@ Long story short, I decided to get rid of WordPress and replace it with a much m
 
 JAM is an acronym for **J**avascript **A**PI **M**arkup. What does it mean though? It is not a framework or a specific technology. It is more of an architectural approach. A modern way web content is built, managed and distributed.
 
-Back in the day, the web was just static HTML pages, maybe with some CSS and Javascript on the top. Perfect for static content. However, usually, you need your data to be more dynamic. Instead of static HTML sitting on the server served directly, HTML pages were built on-the-fly when a client requested them. The data dynamically provided from a database. While this is very flexible, it comes at a cost. It's slow. Way slower than just a static site. The application server executes code on demand, needs to contact a database, usually on a different machine, build the page and send it back. The scalability is hard and expensive. When the traffic rises, its more complicated to scale the solution. We're talking load balancing, session replication, distributed caching not to mention difficult RDS scalability. And it's vulnerable. With so many moving parts, the attack surface is extensive. Ranging from Cross-Site-Scripting, SQL Injection to exploiting [security vulnerabilities in your libraries](https://www.vojtechruzicka.com/snyk-detecting-dependencies-with-known-vulnerabilities/).
+Back in the day, the web was just static HTML pages, maybe with some CSS and JavaScript on the top. Perfect for static content. However, usually, you need your data to be more dynamic. Instead of static HTML sitting on the server served directly, HTML pages were built on-the-fly when a client requested them. The data dynamically provided from a database. While this is very flexible, it comes at a cost. It's slow. Way slower than just a static site. The application server executes code on demand, needs to contact a database, usually on a different machine, build the page and send it back. The scalability is hard and expensive. When the traffic rises, its more complicated to scale the solution. We're talking load balancing, session replication, distributed caching not to mention difficult RDS scalability. And it's vulnerable. With so many moving parts, the attack surface is extensive. Ranging from Cross-Site-Scripting, SQL Injection to exploiting [security vulnerabilities in your libraries](https://www.vojtechruzicka.com/snyk-detecting-dependencies-with-known-vulnerabilities/).
 
-When you just have static HTML, CSS and Javascript files, it's much harder to compromise your site unless someone gains complete access to your server. Since the content does not change, it is easy to cache. Instead of having just one central server or just a few of them in an expensive and complicated solution, you can use Content Delivery Network to distribute your site. This way you'll have your availability covered and CDN redistributing your files across the globe. Users from New York will be served as fast as users from Tokyo. And if your traffic skyrockets, it is still not a problem. Scalability is easy and cheap if you don't have to manage synchronization of state.
+When you just have static HTML, CSS and JavaScript files, it's much harder to compromise your site unless someone gains complete access to your server. Since the content does not change, it is easy to cache. Instead of having just one central server or just a few of them in an expensive and complicated solution, you can use Content Delivery Network to distribute your site. This way you'll have your availability covered and CDN redistributing your files across the globe. Users from New York will be served as fast as users from Tokyo. And if your traffic skyrockets, it is still not a problem. Scalability is easy and cheap if you don't have to manage synchronization of state.
 
 ![jam stack](./jamstack.png)
 

docs/blog/2018-04-04-gatsby-contentful-starter-tutorial/index.md

@@ -116,6 +116,6 @@ Contentful ensures your website and its users can access your content quickly an
 
 That’s a quick overview of how to get your website up and running from scratch using Contentful and GatsbyJS.
 
-Contentful's platform offers speed, flexibility, and ease of integration with your code, supporting any stack you use with SDKs for common languages like [Javascript](https://www.contentful.com/developers/docs/javascript/sdks/), [Python](https://www.contentful.com/developers/docs/python/sdks/), and [PHP](https://www.contentful.com/developers/docs/php/sdks/). Unlike a CMS, Contentful provides you with separation between content and presentation, allowing you to focus on developing your website and leave content delivery to Contentful.
+Contentful's platform offers speed, flexibility, and ease of integration with your code, supporting any stack you use with SDKs for common languages like [JavaScript](https://www.contentful.com/developers/docs/javascript/sdks/), [Python](https://www.contentful.com/developers/docs/python/sdks/), and [PHP](https://www.contentful.com/developers/docs/php/sdks/). Unlike a CMS, Contentful provides you with separation between content and presentation, allowing you to focus on developing your website and leave content delivery to Contentful.
 
 If you're curious to learn more about Contentful, you can check out the Contentful [Developer Center](https://www.contentful.com/developers/docs/) to learn more on how the technology works, or head over to the [Guides and tutorials](https://www.contentful.com/guides/) section.

docs/blog/2018-2-27-why-i-upgraded-my-website-to-gatsbyjs-from-jekyll/index.md

@@ -28,11 +28,11 @@ When delivering content to users on mobile devices, it is important to optimize
 
 However, it would be a pain to have to manually convert images into different sized thumbnails for a post. I wanted an automated image processing pipeline to automatically resize the images extracted from the markdown documents, and then automatically populate the `srcset` attribute on the images in the output HTML document. I found the [Jekyll Responsive Image Plugin](https://github.com/wildlyinaccurate/jekyll-responsive-image) great for this. It allows me to create templates which will be used by Jekyll when rendering the markdown and automatically does the image resizing.
 
-Even so, when I tried to do more complicated workflows like adding CSS preprocessing with dependence on the JavaScript ecosystem with the [Node Package Manager (npm)](https://www.npmjs.com/), it became a lot more convoluted. Looking at a few recipes I’ve found, I would have to dive down the road of writing [Gulp](https://gulpjs.com/) workflows and somehow connect them to Jekyll commands. I also chanced upon the [Jekyll Asset Pipeline](https://github.com/matthodan/jekyll-asset-pipeline) which seems what I could use. I didn’t dive too deep into it, but from brief glances it seems like I would have to come up with a lot of custom scripting to interface with Javascript libraries on my own.
+Even so, when I tried to do more complicated workflows like adding CSS preprocessing with dependence on the JavaScript ecosystem with the [Node Package Manager (npm)](https://www.npmjs.com/), it became a lot more convoluted. Looking at a few recipes I’ve found, I would have to dive down the road of writing [Gulp](https://gulpjs.com/) workflows and somehow connect them to Jekyll commands. I also chanced upon the [Jekyll Asset Pipeline](https://github.com/matthodan/jekyll-asset-pipeline) which seems what I could use. I didn’t dive too deep into it, but from brief glances it seems like I would have to come up with a lot of custom scripting to interface with JavaScript libraries on my own.
 
-I guess having used [webpack](https://webpack.js.org/) at work, I was pampered by this open source community where there are loaders and documented recipes for doing almost anything, granted that someone was willing to wade into the world of "Javascript fatigue". Around the same time, [@yangshun](https://github.com/yangshun) introduced me to [Gatsby](https://www.gatsbyjs.org/), a React static site generator which seemed really fascinating. It also seemed a good opportunity for me to get my hands dirty with frontend development again.
+I guess having used [webpack](https://webpack.js.org/) at work, I was pampered by this open source community where there are loaders and documented recipes for doing almost anything, granted that someone was willing to wade into the world of "JavaScript fatigue". Around the same time, [@yangshun](https://github.com/yangshun) introduced me to [Gatsby](https://www.gatsbyjs.org/), a React static site generator which seemed really fascinating. It also seemed a good opportunity for me to get my hands dirty with frontend development again.
 
-As I had some free time on my hands, why not rewrite everything again and keep myself updated with the ever-changing Javascript ecosystem? Seems like a lot of fun!
+As I had some free time on my hands, why not rewrite everything again and keep myself updated with the ever-changing JavaScript ecosystem? Seems like a lot of fun!
 
 ## Final Form — Gatsby
 
@@ -85,9 +85,9 @@ export const pageQuery = graphql`
 
 When the `<PostTemplate />` component needs to be rendered into a page, the accompanying exported `pageQuery`, a GraphQL query is made, and the results are passed in as props into the component.
 
-The real magic happens when the website is compiled into a production bundle. Running `gatsby build` will tell Gatsby to perform all the GraphQL queries defined and render all the React components into a HTML document, using a technique known as server-side rendering. This means that everything “React” is serialized and compiled to static HTML, ready to be viewed without Javascript. Visitors to the site will then be able to quickly load and interact with the static version of the page.
+The real magic happens when the website is compiled into a production bundle. Running `gatsby build` will tell Gatsby to perform all the GraphQL queries defined and render all the React components into a HTML document, using a technique known as server-side rendering. This means that everything “React” is serialized and compiled to static HTML, ready to be viewed without JavaScript. Visitors to the site will then be able to quickly load and interact with the static version of the page.
 
-Not only that, within the HTML document, there are instructions to load the Javascript bundle of your application asynchronously. When it has been loaded, the content displayed in the browser will be dynamically replaced by the React application, gaining interactivity. This also happens with the other pages of your site — Gatsby will ensure that they are asynchronously loaded so that when you click on a link, the data is already cached on the browser for React to swap out the DOM elements that need to be changed. Everything is done to give the illusion of speed to the viewer while asynchronously loading everything in the background.
+Not only that, within the HTML document, there are instructions to load the JavaScript bundle of your application asynchronously. When it has been loaded, the content displayed in the browser will be dynamically replaced by the React application, gaining interactivity. This also happens with the other pages of your site — Gatsby will ensure that they are asynchronously loaded so that when you click on a link, the data is already cached on the browser for React to swap out the DOM elements that need to be changed. Everything is done to give the illusion of speed to the viewer while asynchronously loading everything in the background.
 
 ### Plugins
 

docs/blog/2018-2-6-choosing-a-back-end/index.md

@@ -15,7 +15,7 @@ The only thing as abundant than Headless CMS options is Static Site Generator op
 
 Gatsby pitches as a “Blazing-fast static site generator for React”. So if I can build sites, but also encompass some React knowledge, all the better right? And I’m always looking for side-projects and sites for others, so if I can get a JAMstack sorted quicker and easier than my previous WordPress stack, then all the better going forward! I thought it was best to start with my own site, to test the viability.
 
-> **What-stack?** JAM stands for Javascript, API, Markup. There are lots of benefits to this type of site, but the one I’m interested in is that your CMS is detached from your site - no hefty WordPress build for your tiny blog site.
+> **What-stack?** JAM stands for JavaScript, API, Markup. There are lots of benefits to this type of site, but the one I’m interested in is that your CMS is detached from your site - no hefty WordPress build for your tiny blog site.
 > [You can read more on the JAMstack website](https://jamstack.org/).
 
 I found Gatsby a real pleasure. You can find tutorials on their site for setup and once you see the code it’s fairly simple. I can personally recommend [Scott Tolinski’s series - available on Youtube](https://www.youtube.com/watch?v=b2H7fWhQcdE&list=PLLnpHn493BHHfoINKLELxDch3uJlSapxg). Gatsby nicely wraps up React and React Router with a nice folder structure, webkit, ES6, SASS support and - importantly - GraphQL.

docs/docs/querying-with-graphql.md

@@ -208,7 +208,7 @@ See also the following blog posts:
 
 Notice that in the above example for [querying images](#images), we used `...GatsbyImageSharpFixed`, which is a GraphQL Fragment, a reusable set of fields for query composition. You can read more about them [here](http://graphql.org/learn/queries/#fragments).
 
-If you wish to define your own fragments for use in your application, you can use named exports to export them in any Javascript file, and they will be automatically processed by Gatsby for use in your GraphQL queries.
+If you wish to define your own fragments for use in your application, you can use named exports to export them in any JavaScript file, and they will be automatically processed by Gatsby for use in your GraphQL queries.
 
 For example if I put a fragment in a helper component, I can use that fragment in any other query:
 

docs/features/gatsby-specs.csv

@@ -56,7 +56,7 @@ Developer Experience,Maintenance & Extensibility,Serverless,3,3,2,2,"<p>Serverle
 
 <p>Gatsby provides asset pipelining out of the box through its build system on top of Webpack and Babel. Wordpress and Jekyll don't provide this, although you could set up your own. Squarespace has a limited and tightly controlled development environment (no local development) that doesn't allow for creating an asset pipeline.</p>"
 ,,CSS Extensions (eg Sass),3,3,1,1,"Languages such as Sass and Less compile to CSS while offering support for variables, functions, hierarchal class definitions; libraries like glamor and aphrodite allow css to be colocated with JS and HTML in React. This solves problems in vanilla CSS like global namespacing, non-determinatism, dead code elimination and minification"
-,,Advanced Javascript syntax,3,1,1,0,"Javascript has become more powerful as a language in the last several years, making it easier to write code. These include:
+,,Advanced JavaScript syntax,3,1,1,0,"JavaScript has become more powerful as a language in the last several years, making it easier to write code. These include:
 <ul>
 <li><b>Syntactic sugar</b>: arrow functions, destructuring, template strings, dynamic object property names.</li>
 <li><b>Language features</b>: Classes, static variables, generators, async control flows like promises & async / await</lI>

docs/sites.yml

@@ -723,7 +723,7 @@
     and design into engineering and visa versa. I take a pragmatic,
     product-oriented approach to development, allowing me to see the big picture
     and ensuring quality products are completed on time. I have a passion for
-    modern front end javascript frameworks such as React and Vue, and I have
+    modern front end JavaScript frameworks such as React and Vue, and I have
     substantial experience on the back end with an interest in Node and
     container based deployment with Docker and AWS.
   categories: