Fix links (#200)

* using/legal: fix links

* Test

* Test

* Test

* Fix broken link

* Test

* Test

* Test

* Fix exercise implementation link

* Fix v3 reference doc links

* Test

* Fix invalid link

* More fixes

* More fixes

* Fix link

* More fixes

* More fixes

* More fixes

* More fixes

* More fixes

* More fixes

* More fixes

* More fixes

Author: ErikSchierboom

building/config.json

@@ -519,6 +519,13 @@
     "title": "Analyzers",
     "blurb": ""
   },
+  {
+    "uuid": "48775c5f-b449-4c91-b792-b81a8ef4ec04",
+    "slug": "tooling/analyzers/feedback-guidelines",
+    "path": "building/tooling/analyzers/feedback-guidelines.md",
+    "title": "Feedback Guidelines",
+    "blurb": ""
+  },
   {
     "uuid": "787e4243-b97a-4b55-9038-7667e5c3788a",
     "slug": "tooling/analyzers/comments",

building/configlet/README.md

@@ -4,28 +4,28 @@
 
 ## Linting
 
-The primary function of configlet is to do _linting_: checking if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism. The full list of rules that are checked by the linter can be found [here](./lint).
+The primary function of configlet is to do _linting_: checking if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism. The full list of rules that are checked by the linter can be found [here](/docs/building/configlet/lint).
 
 ## Generating documents
 
 The secondary function of configlet is to generate documents. There are two types of documents that configlet can generate:
 
-1. A Concept Exercise's [`introduction.md` file](./generating-documents#document-concept-exercises-introductionmd-file).
-1. A Practice Exercise's [`instructions.md` file](./generating-documents#document-practice-exercises-instructionsmd-file).
+1. A Concept Exercise's [`introduction.md` file](/docs/building/configlet/generating-documents#document-concept-exercises-introductionmd-file).
+1. A Practice Exercise's [`instructions.md` file](/docs/building/configlet/generating-documents#document-practice-exercises-instructionsmd-file).
 
-How these documents are generated can be found [here](./generating-documents).
+How these documents are generated can be found [here](/docs/building/configlet/generating-documents).
 
 ## Syncing test data
 
-The tertiary function of configlet is to sync test data. Each implemented [Practice Exercise](./tracks/practice-exercises) for which test data exists in the [problem-specifications repo](https://github.com/exercism/problem-specifications) _must_ contain a `.meta/tests.toml` file. The goal of this file is to keep track of which tests are implemented by the exercise. Tests in this file are identified by their UUID and each test has a boolean value that indicates if it is implemented by that exercise.
+The tertiary function of configlet is to sync test data. Each implemented [Practice Exercise](/docs/building/tracks/practice-exercises) for which test data exists in the [problem-specifications repo](https://github.com/exercism/problem-specifications) _must_ contain a `.meta/tests.toml` file. The goal of this file is to keep track of which tests are implemented by the exercise. Tests in this file are identified by their UUID and each test has a boolean value that indicates if it is implemented by that exercise.
 
-How to sync the contents of the `.meta/tests.toml` can be found [here](./sync)
+How to sync the contents of the `.meta/tests.toml` can be found [here](/docs/building/configlet/sync)
 
 ## Generating UUIDs
 
 Exercises, tracks and concepts are identified by a UUID.
 
-How to generate UUIDs can be found [here](./uuid).
+How to generate UUIDs can be found [here](/docs/building/configlet/uuid).
 
 ## Usage
 

building/configlet/generating-documents.md

@@ -1,6 +1,6 @@
 # Configlet generating documents
 
-The secondary use of [configlet](../) is generating documents.
+The secondary use of [configlet](/docs/building/configlet) is generating documents.
 
 ## Usage
 
@@ -12,11 +12,11 @@ These are the documents that configlet can generate.
 
 ### Document: Concept Exercise's introduction.md file
 
-Each [Concept Exercise](../concept-exercises.md) has an [`introduction.md` file](../concept-exercises.md#docsintroductionmd). Each exercise can have an optional [`introduction.md.tpl` file](../concept-exercises.md#docsintroductionmdtploptional).
+Each [Concept Exercise](/docs/building/tracks/concept-exercises) has an [`introduction.md` file](/docs/building/tracks/concept-exercises#docsintroductionmd). Each exercise can have an optional [`introduction.md.tpl` file](/docs/building/tracks/concept-exercises#docsintroductionmdtploptional).
 
 The template file should be treated like a regular Markdown file but with one addition: the ability to specify placeholders. The following placeholders are supported:
 
-- `%{concept:<slug>}`: refers to the concept's [`introduction.md` document](../concepts.md#fileintroductionmd)
+- `%{concept:<slug>}`: refers to the concept's [`introduction.md` document](/docs/building/tracks/concepts#fileintroductionmd)
 
 When configlet detects that a Concept Exercise has an `introduction.md.tpl` file, it will generate a `introduction.md` file from it. The generated introduction will have the same contents as the template, expect for the placeholders, which will be replaced with the contents of the documents they refer to.
 

building/configlet/lint.md

@@ -1,6 +1,6 @@
 # Linting
 
-The primary use of [configlet](./) is linting: checking if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism.
+The primary use of [configlet](/docs/building/configlet) is linting: checking if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism.
 
 ## Usage
 
@@ -184,15 +184,15 @@ The `config.json` file should have the following checks:
 - The `"key_features"` key is optional
 - The `"key_features"` value must be an array with length = 6
 - The `"key_features[].icon"` key is required
-- The `"key_features[].icon"` value must use one of the [pre-defined icon values](../tracks/config-json#keyfeatures)
+- The `"key_features[].icon"` value must use one of the [pre-defined icon values](/docs/building/tracks/config-json#keyfeatures)
 - The `"key_features[].title"` key is required
 - The `"key_features[].title"` value must be a non-blank string¹ with length <= 25
 - The `"key_features[].content"` key is required
 - The `"key_features[].content"` value must be a non-blank string¹ with length <= 100
 - The `"tags"` key is required
 - The `"tags"` value must be an array of strings
 - The `"tags"` values must not have duplicates
-- The `"tags"` values must use one of the [pre-defined tag values](../tracks/config-json.md#tags)
+- The `"tags"` values must use one of the [pre-defined tag values](/docs/building/tracks/config-json#tags)
 
 ### Rule: exercises/concept/&lt;slug&gt;/.meta/config.json is valid
 
@@ -244,24 +244,24 @@ The `config.json` file should have the following checks:
 
 ### Rule: exercises/concept/&lt;slug&gt;/.docs/hints.md is valid
 
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - All headings must be either `## General` or `## X. <task>` where `X` matches the task number heading in the `instructions.md`
 - All hints must be specified as Markdown list items
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: exercises/concept/&lt;slug&gt;/.docs/instructions.md is valid
 
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - All tasks must start with a level two heading that starts with a number followed by a dot: `## 1. Do X`
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: exercises/concept/&lt;slug&gt;/.docs/instructions.md.tpl is valid (if present)
 
-- Each [concept placeholders](../tracks/concept-exercises.md#file-docsintroductionmdtpl)'s concept must match the `"concepts.slug"` property of one of the concepts in the track's `config.json`.
+- Each [concept placeholders](/docs/building/tracks/concept-exercises#file-docsintroductionmdtpl)'s concept must match the `"concepts.slug"` property of one of the concepts in the track's `config.json`.
 
 ### Rule: exercises/concept/&lt;slug&gt;/.docs/introduction.md is valid
 
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: exercises/practice/&lt;slug&gt;/.meta/config.json is valid
@@ -310,29 +310,29 @@ The `config.json` file should have the following checks:
 ### Rule: exercises/shared/.docs/debug.md is valid
 
 - The file's presence is optional
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: exercises/shared/.docs/help.md is valid
 
 - The file's presence is required
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: exercises/shared/.docs/tests.md is valid
 
 - The file's presence is required
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: concepts/&lt;slug&gt;/about.md is valid
 
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: concepts/&lt;slug&gt;/introduction.md is valid
 
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: concept/&lt;slug&gt;/links.json is valid
@@ -368,28 +368,28 @@ The `config.json` file should have the following checks:
 
 - The file's presence is required
 - The file's contents must be non-blank
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: docs/INSTALLATION.md is valid
 
 - The file's presence is required
 - The file's contents must be non-blank
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: docs/LEARNING.md is valid
 
 - The file's presence is required
 - The file's contents must be non-blank
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: docs/RESOURCES.md is valid
 
 - The file's presence is required
 - The file's contents must be non-blank
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ### Rule: docs/SNIPPET.txt is valid
@@ -401,7 +401,7 @@ The `config.json` file should have the following checks:
 
 - The file's presence is required
 - The file's contents must be non-blank
-- The Markdown must conform to the [Markdown standards](../markdown/markdown.md)
+- The Markdown must conform to the [Markdown standards](/docs/building/markdown/markdown)
 - Links must be absolute (relative links are not allowed)
 
 ## Glossary

building/configlet/uuid.md

@@ -1,6 +1,6 @@
 # Generating UUIDs
 
-Exercises, tracks and concepts are identified by a UUID. [configlet](./) can generate new, valid UUIDs.
+Exercises, tracks and concepts are identified by a UUID. [configlet](/docs/building/configlet) can generate new, valid UUIDs.
 
 ## Usage
 

building/markdown/README.md

@@ -0,0 +1,6 @@
+# Markdown
+
+- [Internal Linking](/docs/building/markdown/internal-linking)
+- [Markdown Specification](/docs/building/markdown/markdown)
+- [Exercism's Style Guide](/docs/building/markdown/style-guide)
+- [Widgets](/docs/building/markdown/widgets)

building/markdown/internal-linking.md

@@ -4,7 +4,7 @@ Links rendered via Exercism's Markdown parser are checked to see if they are int
 
 A tooltip for a concept might look like this:
 
-<img src="../../.imgs/concept-tooltip.png" height="200">
+<img src="https://raw.githubusercontent.com/exercism/docs/main/.imgs/concept-tooltip.png" height="200">
 
 ## Usage
 
@@ -21,4 +21,4 @@ We do not currently support relative URLs (e.g. those beginning with `./` or `..
 Rather than using normal links, you might like to render Widgets.
 These are generally used at the end of a document to suggest extra reading or good exercises to learn something from.
 
-See [the Widgets documentation](./widgets.md) for more details.
+See [the Widgets documentation](/docs/building/markdown/widgets) for more details.

building/markdown/widgets.md

@@ -3,16 +3,16 @@
 Concept and Exercise Widgets are used frequently throughout the site.
 They look like this:
 
-<img src="../../.imgs/concept-widget.png" height="100">
-<img src="../../.imgs/exercise-widget.png" height="100">
+<img src="https://raw.githubusercontent.com/exercism/docs/main/.imgs/concept-widget.png" height="100">
+<img src="https://raw.githubusercontent.com/exercism/docs/main/.imgs/exercise-widget.png" height="100">
 
 They also have user-contextual tooltips such as this:
 
-<img src="../../.imgs/concept-tooltip.png" height="200">
+<img src="https://raw.githubusercontent.com/exercism/docs/main/.imgs/concept-tooltip.png" height="200">
 
 You may like to render these widgets yourself in Markdown documents, for example at the end of a document to suggest extra reading or good exercises to learn something from.
 
-**Note:** You can also use normal links for inline text, which will have the tooltips added. See [the Internal Linking documentation](./internal-linking.md) for more details.
+**Note:** You can also use normal links for inline text, which will have the tooltips added. See [the Internal Linking documentation](/docs/building/markdown/internal-linking) for more details.
 
 ## Usage
 

building/tooling/README.md

@@ -9,6 +9,6 @@ All tooling is deployed using the same Docker workflow.
 
 There are currently three pieces of tooling:
 
-- **[Test Runners](./test-runners)**
-- **[Representers](./representers)**
-- **[Analyzers](./analyzers)**
+- **[Test Runners](/docs/building/tooling/test-runners)**
+- **[Representers](/docs/building/tooling/representers)**
+- **[Analyzers](/docs/building/tooling/analyzers)**

building/tooling/analyzers/README.md

@@ -11,10 +11,10 @@ Each Analyzer lives in the Exercism GitHub organization in a repository named `$
 You can explore the different Analyzers [here](https://github.com/exercism?q=-analyzer).
 
 If you would like to get involved in helping with an existing Analyzer, please open an issue in its repository asking if there is somewhere you can help.
-If you would like to create an Analyzer for a language that currently does not have one, please follow the [creating a Analyzer](creating-from-scratch.md) instructions.
+If you would like to create an Analyzer for a language that currently does not have one, please follow the [creating a Analyzer](/docs/building/tooling/analyzers/creating-from-scratch) instructions.
 
-This directory contains the following information:
+You can use the following documents to learn more about building an analyzer:
 
-- **[`creating-from-scratch.md`](./creating-from-scratch.md):** Information on creating a Analyzer from scratch.
-- **[`interface.md`](./interface.md):** The Analyzer interface.
-- **[`docker.md`](./docker.md):** How to build a Docker image with Docker for local testing and deployment.
+- [Creating a Analyzer from scratch](/docs/building/tooling/analyzers/creating-from-scratch)
+- [The Analyzer interface.](/docs/building/tooling/analyzers/interface)
+- [How to build a Docker image with Docker for local testing and deployment](/docs/building/tooling/analyzers/docker)

building/tooling/analyzers/comments.md

@@ -5,7 +5,7 @@
 # Comment Copy Guidelines
 
 This document sets guidelines for the comments produced by the analyzer. The
-[Feedback guidelines][git-feedback-guidelines] talk about _when_ to comment and
+[Feedback guidelines](/docs/building/tooling/analyzers/feedback-guidelines) talk about _when_ to comment and
 _what_ to comment. This document talks mostly about _how_ to comment.
 
 ## Working directory for contents
@@ -138,4 +138,3 @@ custom errors might be interesting.
 [git-website-copy]: https://github.com/exercism/website-copy/tree/main/automated-comments
 [issue-ci-comments]: https://github.com/exercism/automated-mentoring-support/issues/51
 [git-website-copy-label]: https://github.com/exercism/website-copy/pulls?q=is%3Aopen+is%3Apr+label%3Atype%2Fanalyzer-comments
-[git-feedback-guidelines]: https://github.com/exercism/automated-mentoring-support/blob/main/docs/guidelines.md#idiomatic-rules--language-features--stylistic-choices

building/tooling/analyzers/creating-from-scratch.md

@@ -5,7 +5,7 @@ Firstly, thank you for your interest in creating an Analyzer!
 These are the steps to get going:
 
 1. Check [our repository list for an existing `...-analyzer`](https://github.com/exercism?q=-analyzer) to ensure that one doesn't already exist.
-2. Scan the [contents of this directory](./) to ensure you are comfortable with the idea of creating an Analyzer.
+2. Scan the [contents of this directory](/docs/building/tooling/analyzers) to ensure you are comfortable with the idea of creating an Analyzer.
 3. Open an issue at [exercism/exercism][exercism-repo] introducing yourself and telling us which language you'd like to create a Analyzer for.
 
 We have an incredibly friendly and supportive community who will be happy to help you as you work through this! If you get stuck, please speak to us on Slack or create new issues at [exercism/exercism][exercism-repo] as needed 🙂

building/tooling/analyzers/docker.md

@@ -2,12 +2,12 @@
 
 Our Analyzers are deployed as Docker images.
 
-Please read the [general Tooling docker information](../docker.md) to familiarize yourself with how these work.
+Please read the [general Tooling docker information](/docs/building/tooling/analyzers/docker) to familiarize yourself with how these work.
 
 When we run the Analyzer's container we execute a `run.sh` script.
 To ensure this works properly the following rules must be following:
 
 - The working directory should be `/opt/analyzer`.
 - There should be a `/opt/analyzer/bin/run.sh` script that can be called with 3 parameters:
   the `exercise slug`, the path to the `solution folder`, and the path to the `output folder`.
-  For more information see [The Interface](./interface.md).
+  For more information see [The Interface](/docs/building/tooling/analyzers/interface).