Move tutorial and docs into main repo (redwoodjs#4749)

If anything goes wrong it's @jtoar's fault

* mv over learn.redwoodjs.com

* Update Crowdin configuration file

* upgrade docusaurus

* deprecate and rm i18n

* mv over docs

* tidy up nav

* rm announcement bar

* rm swizzled comp doc page

* rework some of the docs and sidebar

* rename to docs

* wip

* use inter font

* annotate config for meeting

* add icons to sidebar

* [wip] fix broken links

* update readme

* fix broken links

* configure aloglia

* make sidebar closer to original

* update docs

* update tutorial

* update cookbooks

* update url

* update authentication

* update logo

* add index pages to sidebar

Co-authored-by: Claire Froelich <claire.froelich@gmail.com>
Co-authored-by: David Price <thedavid@thedavidprice.com>

crowdin.yml

@@ -0,0 +1,5 @@
+files:
+  - source: /learn.redwoodjs.com/docs/tutorial
+    translation: /learn.redwoodjs.com/i18n/%two_letters_code%/tutorial/%original_file_name%
+  - source: /learn.redwoodjs.com/docs/tutorial2
+    translation: /learn.redwoodjs.com/i18n/%two_letters_code%/tutorial2/%original_file_name%

docs/.gitignore

@@ -0,0 +1,15 @@
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*

docs/README.md

@@ -0,0 +1,33 @@
+# RedwoodJS Docs
+
+Deployment URL: https://redwoodjs.com/docs
+
+## Getting started
+
+Checkout this repo (redwoodjs/redwood), `cd` into this directory (`docs`)
+
+```
+yarn install
+
+yarn start
+```
+
+#### Internal linking
+
+For links to other docs inside the `tutorials` directory, USE RELATIVE LINKS!
+
+```
+In [previous section](./our-first-page) we....
+```
+
+## Contributing
+
+Open a PR against the repo on GitHub. That will build and launch a copy of the site that you can get from the `netlify/redwoodjs/deploy-preview` check (click "Details" to open it):
+
+![image](https://user-images.githubusercontent.com/300/76569613-c4421000-6470-11ea-8223-eb98504e6994.png)
+
+Double check that your changes look good!
+
+## Contributors
+
+Redwood is amazing thanks to a wonderful [community of contributors](https://github.com/redwoodjs/redwood/blob/main/README.md#contributors).

docs/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+}

docs/docs/a11y.md

@@ -0,0 +1,147 @@
+---
+slug: accessibility
+---
+
+# Accessibility (aka a11y)
+
+We built Redwood to make building websites more accessible (we write all the config so you don't have to), but Redwood's also built to help you make more accessible websites. Accessibility shouldn't be a nice-to-have. It should be a given from the start, a core feature that's built-in and well-supported.
+
+There's a lot of great tooling out there that'll not only help you build accessible websites, but also help you learn exactly what that means.
+
+> **With all this tooling, do I still have to manually test my application?**
+>
+> Unequivocally, yes. Even with all the tooling in the world, manual testing's still important, especially for accessibility.
+> The GDS Accessibility team found that [automated testing only catches ~30% of all the issues](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage).
+>
+> But just because the tools don't catch 'em all doesn't mean they're not valuable. It'd be much harder to learn what to look for without them.
+
+## Accessible Routing with Redwood Router
+
+For single-page applications (SPAs), accessibility starts with the Router. Without a full-page refresh, you just can't be sure that things like announcements and focus are being taken care of the way they're supposed to be. Here's a great example of [how disorienting SPAs can be to screen-reader users](https://www.youtube.com/watch?v=NKTdNv8JpuM). On navigation, nothing's announced. It's important not to understate the severity of this; the lack of an announcement isn't just buggy behavior, it's broken.
+
+Normally the onus would be on you as a developer to announce to screen-reader users that they've navigated somewhere new. That's a lot to ask, and hard to get right, especially when you're just trying to build your app. Luckily, if you're writing good content and marking it up semantically, there's nothing you have to do! Redwood automatically and always announces pages on navigation. Redwood looks for announcements in this order:
+
+1. `RouteAnnouncement`
+2. `h1`
+3. `document.title`
+4. `location.pathname`
+
+The reason for this is that announcements should be as specific as possible; more specific usually means more descriptive, and more descriptive usually means that users can not only orient themselves and navigate through the content, but also find it again.
+If you're not sure if your content is descriptive enough, see the [W3 guidelines](https://www.w3.org/WAI/WCAG21/Techniques/general/G88.html).
+
+Even though Redwood looks for a `RouteAnnouncement` first, you don't have to have one on every page—it's more than ok for the h1 to be what's announced. `RouteAnnouncement` is there for when the situation calls for a custom announcement.
+
+The API is simple: `RouteAnnouncement`'s children will be announced; note that this can be something on the page, or can be visually hidden using the `visuallyHidden` prop:
+
+```js
+// web/src/pages/HomePage.js
+
+import { RouteAnnouncement } from '@redwoodjs/router'
+
+const HomePage = () => {
+  return (
+    // this will still be visible
+    <RouteAnnouncement>
+      <h1>Welcome to my site!</h1>
+    </RouteAnnouncement>
+  )
+}
+
+export default HomePage
+```
+
+```js
+// web/src/pages/AboutPage.js
+
+import { RouteAnnouncement } from '@redwoodjs/router'
+
+const AboutPage = () => {
+  return (
+    <h1>Welcome to my site!</h1>
+    // this won't be visible
+    <RouteAnnouncement visuallyHidden>
+      All about me
+    </RouteAnnouncement>
+  )
+}
+
+export default AboutPage
+```
+
+Whenever possible, it's good to maintain parity between the visual and audible experience of your app. That's just to say that `visuallyHidden` shouldn't be the first thing you reach for. But it's there if you need it!
+
+<!-- Note that if you have more than one `RouteAnnouncement`, Redwood uses the most specific one, that way if you have multiple layouts, you can override as needed. -->
+
+## Focus
+
+On page change, Redwood Router resets focus to the top of the DOM so that users can navigate through the new page. While this is the expected behavior (and the behavior you usually want), for some apps, especially those with a lot of navigation, it can be cumbersome for users to have tab through all that nav before getting to the main point. (And that goes for every page change!)
+
+Right now, there's two ways to alleviate this in Redwood: with skip links and/or the `RouteFocus` component.
+
+### Skip links
+
+Since the main content isn't usually the first thing on the page, it's a good practice to provide a shortcut for keyboard and screen-reader users to skip to it. Skip links do just that, and if you generate a layout (`yarn rw g layout`) with the `--skipLink` flag, you'll get a layout with a skip link:
+
+```terminal
+yarn rw g layout main --skipLink
+```
+
+```js
+import { SkipNavLink, SkipNavContent } from '@redwoodjs/router'
+import '@reach/skip-nav/styles.css'
+
+const MainLayout = ({ children }) => {
+  return (
+    <>
+      <SkipNavLink />
+      <nav></nav>
+      <SkipNavContent />
+      <main>{children}</main>
+    </>
+  )
+}
+
+export default MainLayout
+```
+
+`SkipNavLink` renders a link that remains hidden till focused; `SkipNavContent` renders a div as the target for the link. For more on these components, see the [Reach UI](https://reach.tech/skip-nav/#reach-skip-nav) docs.
+
+Making sure your navs have skip links is a great practice that goes a long way. And it really doesn't cost you much!
+One thing you'll probably want to do is change the URL the skip link sends the user to when activated. You can do that by changing the `contentId` and `id` props of `SkipNavLink` and `SkipNavContent` respectively:
+
+```js
+<SkipNavLink contentId="main-content" />
+
+// ...
+
+<SkipNavContent id="main-content" />
+```
+
+If you'd prefer to implement your own skip link, [Ben Myers' blog](https://benmyers.dev/blog/skip-links/) is a great resource, and a great place to read about accessibility in general.
+
+### RouteFocus
+
+Sometimes you don't want to just skip the nav, but send a user somewhere. In this situation, you of course have the foresight that that place is where the user wants to be! So please use this at your discretion—sending a user to an unexpected location can be worse than sending them back the top.
+
+Having said that, if you know that on a particular page change a user's focus is better off being directed to a particular element, the `RouteFocus` component is what you want:
+
+```js
+import { RouteFocus } from '@redwoodjs/router'
+
+const ContactPage = () => (
+  <nav>
+    {/* way too much nav... */}
+  </nav>
+
+  // the contact form the user actually wants to interact with
+  <RouteFocus>
+    <TextField name="name" />
+  </RouteFocus>
+)
+
+export default ContactPage
+```
+
+`RouteFocus` tells the router to send focus to it's child on page change. In the example above, when the user navigates to the contact page, the name text field on the form gets focus—the first field of the form they're here to fill out.
+
+For a video example of using `RouteFocus`, see our [meetup on Redwood's accessibility features](https://youtu.be/T1zs77LU68w?t=3240).