first pass at folder based versioning working with i10n

Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com>

Dockerfile

@@ -1,3 +1,3 @@
-FROM klakegg/hugo:0.78.2-asciidoctor
+FROM klakegg/hugo:0.81.0-ext-asciidoctor
 
 RUN apk add git

config.toml

@@ -99,21 +99,21 @@ privacy_policy = "https://policies.google.com/privacy"
 
 # Menu title if your navbar has a versions selector to access old versions of your site.
 # This menu appears only if you have at least one [params.versions] set.
-version_menu = "Releases"
+version_menu = "Versions"
 
 # Flag used in the "version-banner" partial to decide whether to display a 
 # banner on every page indicating that this is an archived version of the docs.
 # Set this flag to "true" if you want to display the banner.
-archived_version = false
+# archived_version = false
 
 # The version number for the version of the docs represented in this doc set.
 # Used in the "version-banner" partial to display a version number for the 
 # current doc set.
-version = "0.0"
+# version = "0.0"
 
 # A link to latest version of the docs. Used in the "version-banner" partial to
 # point people to the main doc site.
-url_latest_version = "https://example.com"
+# url_latest_version = "https://example.com"
 
 # Repository configuration (URLs for in-page links to opening issues and suggesting changes)
 github_repo = "https://github.com/google/docsy-example"
@@ -139,6 +139,11 @@ offlineSearch = false
 # Enable syntax highlighting and copy buttons on code blocks with Prism
 prism_syntax_highlighting = false
 
+# Versions (Folder-based)
+[params.versions]
+latest = "v0.1.0"
+all    = ["current", "v0.1.0", "v0.0.1"]
+
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.

content/en/docs/current/_index.md

@@ -0,0 +1,26 @@
+
+---
+title: "Documentation"
+linkTitle: "Documentation"
+weight: 20
+cascade:
+  version: current
+menu:
+  main:
+    weight: 20
+---
+
+{{% pageinfo %}}
+This is a placeholder page that shows you how to use this template site.
+{{% /pageinfo %}}
+
+
+This section is where the user documentation for your project lives - all the information your users need to understand and successfully use your project. 
+
+For large documentation sets we recommend adding content under the headings in this section, though if some or all of them don’t apply to your project feel free to remove them or add your own. You can see an example of a smaller Docsy documentation site in the [Docsy User Guide](https://docsy.dev/docs/), which lives in the [Docsy theme repo](https://github.com/google/docsy/tree/master/userguide) if you'd like to copy its docs section. 
+
+Other content such as marketing material, case studies, and community updates should live in the [About](/about/) and [Community](/community/) pages.
+
+Find out how to use the Docsy theme in the [Docsy User Guide](https://docsy.dev/docs/). You can learn more about how to organize your documentation (and how we organized this site) in [Organizing Your Content](https://docsy.dev/docs/best-practices/organizing-content/).
+
+

content/en/docs/v0.0.1/Concepts/_index.md

@@ -0,0 +1,17 @@
+---
+title: "Concepts"
+linkTitle: "Concepts"
+weight: 4
+description: >
+  What does your user need to understand about your project in order to use it - or potentially contribute to it? 
+---
+
+{{% pageinfo %}}
+This is a placeholder page that shows you how to use this template site.
+{{% /pageinfo %}}
+
+For many projects, users may not need much information beyond the information in the [Overview](/docs/overview/), so this section is **optional**. However if there are areas where your users will need a more detailed understanding of a given term or feature in order to do anything useful with your project (or to not make mistakes when using it) put that information in this section. For example, you may want to add some conceptual pages if you have a large project with many components and a complex architecture.
+
+Remember to focus on what the user needs to know, not just what you think is interesting about your project! If they don’t need to understand your original design decisions to use or contribute to the project, don’t put them in, or include your design docs in your repo and link to them. Similarly, most users will probably need to know more about how features work when in use rather than how they are implemented. Consider a separate architecture page for more detailed implementation and system design information that potential project contributors can consult.
+
+

content/en/docs/v0.0.1/Contribution guidelines/_index.md

@@ -0,0 +1,81 @@
+---
+title: "Contribution Guidelines"
+linkTitle: "Contribution Guidelines"
+weight: 10
+description: >
+  How to contribute to the docs
+---
+
+{{% pageinfo %}}
+These basic sample guidelines assume that your Docsy site is deployed using Netlify and your files are stored in GitHub. You can use the guidelines "as is" or adapt them with your own instructions: for example, other deployment options, information about your doc project's file structure, project-specific review guidelines, versioning guidelines, or any other information your users might find useful when updating your site. [Kubeflow](https://github.com/kubeflow/website/blob/master/README.md) has a great example.
+
+Don't forget to link to your own doc repo rather than our example site! Also make sure users can find these guidelines from your doc repo README: either add them there and link to them from this page, add them here and link to them from the README, or include them in both locations.
+{{% /pageinfo %}}
+
+We use [Hugo](https://gohugo.io/) to format and generate our website, the
+[Docsy](https://github.com/google/docsy) theme for styling and site structure, 
+and [Netlify](https://www.netlify.com/) to manage the deployment of the site. 
+Hugo is an open-source static site generator that provides us with templates, 
+content organisation in a standard directory structure, and a website generation 
+engine. You write the pages in Markdown (or HTML if you want), and Hugo wraps them up into a website.
+
+All submissions, including submissions by project members, require review. We
+use GitHub pull requests for this purpose. Consult
+[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
+information on using pull requests.
+
+## Quick start with Netlify
+
+Here's a quick guide to updating the docs. It assumes you're familiar with the
+GitHub workflow and you're happy to use the automated preview of your doc
+updates:
+
+1. Fork the [Goldydocs repo](https://github.com/google/docsy-example) on GitHub.
+1. Make your changes and send a pull request (PR).
+1. If you're not yet ready for a review, add "WIP" to the PR name to indicate 
+  it's a work in progress. (**Don't** add the Hugo property 
+  "draft = true" to the page front matter, because that prevents the 
+  auto-deployment of the content preview described in the next point.)
+1. Wait for the automated PR workflow to do some checks. When it's ready,
+  you should see a comment like this: **deploy/netlify — Deploy preview ready!**
+1. Click **Details** to the right of "Deploy preview ready" to see a preview
+  of your updates.
+1. Continue updating your doc and pushing your changes until you're happy with 
+  the content.
+1. When you're ready for a review, add a comment to the PR, and remove any
+  "WIP" markers.
+
+## Updating a single page
+
+If you've just spotted something you'd like to change while using the docs, Docsy has a shortcut for you:
+
+1. Click **Edit this page** in the top right hand corner of the page.
+1. If you don't already have an up to date fork of the project repo, you are prompted to get one - click **Fork this repository and propose changes** or **Update your Fork** to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
+1. Follow the rest of the [Quick start with Netlify](#quick-start-with-netlify) process above to make, preview, and propose your changes.
+
+## Previewing your changes locally
+
+If you want to run your own local Hugo server to preview your changes as you work:
+
+1. Follow the instructions in [Getting started](/docs/getting-started) to install Hugo and any other tools you need. You'll need at least **Hugo version 0.45** (we recommend using the most recent available version), and it must be the **extended** version, which supports SCSS.
+1. Fork the [Goldydocs repo](https://github.com/google/docsy-example) repo into your own project, then create a local copy using `git clone`. Don’t forget to use `--recurse-submodules` or you won’t pull down some of the code you need to generate a working site.
+
+    ```
+    git clone --recurse-submodules --depth 1 https://github.com/google/docsy-example.git
+    ```
+
+1. Run `hugo server` in the site root directory. By default your site will be available at http://localhost:1313/. Now that you're serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.
+1. Continue with the usual GitHub workflow to edit files, commit them, push the
+  changes up to your fork, and create a pull request.
+
+## Creating an issue
+
+If you've found a problem in the docs, but you're not sure how to fix it yourself, please create an issue in the [Goldydocs repo](https://github.com/google/docsy-example/issues). You can also create an issue about a specific page by clicking the **Create Issue** button in the top right hand corner of the page.
+
+## Useful resources
+
+* [Docsy user guide](https://www.docsy.dev/docs/): All about Docsy, including how it manages navigation, look and feel, and multi-language support.
+* [Hugo documentation](https://gohugo.io/documentation/): Comprehensive reference for Hugo.
+* [Github Hello World!](https://guides.github.com/activities/hello-world/): A basic introduction to GitHub concepts and workflow.
+
+

content/en/docs/v0.0.1/Examples/_index.md

@@ -0,0 +1,17 @@
+
+---
+title: "Examples"
+linkTitle: "Examples"
+weight: 3
+date: 2017-01-05
+description: >
+  See your project in action!
+---
+
+{{% pageinfo %}}
+This is a placeholder page that shows you how to use this template site.
+{{% /pageinfo %}}
+
+Do you have any example **applications** or **code** for your users in your repo or elsewhere? Link to your examples here.
+
+

content/en/docs/v0.0.1/Getting started/_index.md

@@ -0,0 +1,35 @@
+---
+title: "Getting Started"
+linkTitle: "Getting Started"
+weight: 2
+description: >
+  What does your user need to know to try your project?
+---
+
+{{% pageinfo %}}
+This is a placeholder page that shows you how to use this template site.
+{{% /pageinfo %}}
+
+Information in this section helps your user try your project themselves.
+
+* What do your users need to do to start using your project? This could include downloading/installation instructions, including any prerequisites or system requirements.
+
+* Introductory “Hello World” example, if appropriate. More complex tutorials should live in the Tutorials section.
+
+Consider using the headings below for your getting started page. You can delete any that are not applicable to your project.
+
+## Prerequisites
+
+Are there any system requirements for using your project? What languages are supported (if any)? Do users need to already have any software or tools installed?
+
+## Installation
+
+Where can your user find your project code? How can they install it (binaries, installable package, build from source)? Are there multiple options/versions they can install and how should they choose the right one for them?
+
+## Setup
+
+Is there any initial setup users need to do after installation to try your project?
+
+## Try it out!
+
+Can your users test their installation, for example by running a command or deploying a Hello World example?