opral · flornkm · Sep 26, 2023 · Sep 13, 2023 · Sep 13, 2023 · Sep 13, 2023
diff --git a/.prettierrc.json b/.prettierrc.json
@@ -1,6 +1,5 @@
 {
 	"semi": false,
 	"useTabs": true,
-	"trailingComma": "all",
 	"printWidth": 100
 }
diff --git a/inlang/blog/git-as-sdk.md b/inlang/blog/git-as-sdk.md
@@ -1,10 +1,4 @@
----
-title: What if a Git SDK to build apps exists?
-href: /blog/git-as-sdk
-description: Git as a backend and content database might be superior to database driven solutions for apps like Figma, Google Docs, & Co.
----
-
-# {% $frontmatter.title %}
+# What if a Git SDK to build apps exists?
 
 While exploring how to design a developer-first localization solution (also known as i18n, aka offering software in different human languages), I realized that git as a backend might be superior to database driven solutions for applications like Figma, Google Docs, & Co. I refer to a cloud-based backend as a backend where users operate on documents that are stored in a database, opposed to documents in the form of files.
 

diff --git a/inlang/blog/inlang-refactor.md b/inlang/blog/inlang-refactor.md
@@ -1,10 +1,4 @@
----
-title: Refactoring Inlang
-href: /blog/refactoring-inlang
-description: Inlang got a major refactor which brings new capabilities to the ecosystem.
----
-
-# {% $frontmatter.title %}
+# Refactoring Inlang
 
 ![architecture inlang new](https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/architecture.jpg)
 

diff --git a/inlang/blog/notes-on-git-based-architecture.md b/inlang/blog/notes-on-git-based-architecture.md
@@ -1,10 +1,4 @@
----
-title: "March 2022: Does a git-based architecture make sense?"
-href: /blog/notes-on-git-based-architecture
-description: Internal notes from March 2022 on why a git-based architecture for localization and beyond seems to make sense.
----
-
-# {% $frontmatter.title %}
+# March 2022: Does a git-based architecture make sense?
 
 This document has been written by me, [@samuelstroschein](https://twitter.com/samuelstroschein), as a note to myself on why a git-based architecture makes sense.
 

diff --git a/inlang/blog/tableOfContents.json b/inlang/blog/tableOfContents.json
@@ -1,6 +1,26 @@
 [
-	"./inlang-refactor.md",
-	"./the-next-git.md",
-	"./git-as-sdk.md",
-	"./notes-on-git-based-architecture.md"
+	{
+		"path": "./inlang-refactor.md",
+		"slug": "inlang-refactor",
+		"title": "Refactoring Inlang",
+		"description": "Inlang got a major refactor which brings new capabilities to the ecosystem."
+	},
+	{
+		"path": "./the-next-git.md",
+		"slug": "the-next-git",
+		"title": "The next git",
+		"description": "Git, or more generalized version control, seems to be an appropriate backend for content heavy apps."
+	},
+	{
+		"path": "./git-as-sdk.md",
+		"slug": "git-as-sdk",
+		"title": "What if a Git SDK to build apps exists?",
+		"description": "Git as a backend and content database might be superior to database driven solutions for apps like Figma, Google Docs, & Co."
+	},
+	{
+		"path": "./notes-on-git-based-architecture.md",
+		"slug": "notes-on-git-based-architecture",
+		"title": "March 2022: Does a git-based architecture make sense?",
+		"description": "Internal notes from March 2022 on why a git-based architecture for localization and beyond seems to make sense."
+	}
 ]
diff --git a/inlang/blog/the-next-git.md b/inlang/blog/the-next-git.md
@@ -1,20 +1,9 @@
----
-title: The next git
-href: /blog/the-next-git
-description: Git, or more generalized version control, seems to be an appropriate backend for content heavy apps.
----
-
-# {% $frontmatter.title %}
+# The next git
 
 **Inlang might bring version control to domains outside of software engineering.**
 
-{% Figure
-
-    src="https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/what-if-1000-artists.jpeg"
-    alt="What if 1000s of artists are able to create a song together?"
-    caption="A slide from one of the first presentations about inlang being built on git, and the possibilities version control might open. The image has been taken from the iconic iPod campaign."
-
-/%}
+<display-figure src="https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/what-if-1000-artists.jpeg" alt="What if 1000s of artists are able to create a song together?" caption="What if 1000s of artists are able to create a song together?"
+    caption="A slide from one of the first presentations about inlang being built on git, and the possibilities version control might open. The image has been taken from the iconic iPod campaign."></display-figure>
 
 Inlang is git-based localization infrastructure and, simultaneously, a case study for version control-based applications. Git provides unprecedented (async) collaboration, automation, and simple review flows out of the box. Wouldn't version control be benefitial to domains outside of software engineering? What if artists could collaborate on a song in the way software engineers collaborate on open source software? What if open source mechanical engineering would be as common as open source software? What if... version control enables new workflows and apps with built-in version control are better than their counterparts?
 

diff --git a/inlang/documentation/concept/app.md b/inlang/documentation/concept/app.md
@@ -1,12 +1,6 @@
----
-title: App
-href: /documentation/app
-description: An inlang app provides a user interface for a project.
----
+# App
 
-# {% $frontmatter.title %}
-
-{% $frontmatter.description %} A wide variety of apps for many different use-cases exists. Go to the [marketplace](/marketplace) to find apps that fit your needs.
+An inlang app provides a user interface for a project. A wide variety of apps for many different use-cases exists. Go to the [marketplace](/marketplace) to find apps that fit your needs.
 
 ![inlang app concept](https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/app.jpg)
 

diff --git a/inlang/documentation/concept/language-tag.md b/inlang/documentation/concept/language-tag.md
@@ -1,10 +1,4 @@
----
-title: Language tag
-href: /documentation/language-tag
-description: TODO TODO TODO TODO TODO
----
-
-# {% $frontmatter.title %}
+# Language tag
 
 A language tag is a standardized code or tag that is used to identify human languages and regions.
 

diff --git a/inlang/documentation/concept/library.md b/inlang/documentation/concept/library.md
@@ -1,9 +1,3 @@
----
-title: Library
-href: /documentation/library
-description: Developers can use inlang libraries for their own software projects.
----
+# Library
 
-# {% $frontmatter.title %}
-
-{% $frontmatter.description %} A wide variety of libraries for different use-cases exists. Go to the [marketplace](/marketplace) to find a library that fit your needs.
+Developers can use inlang libraries for their own software projects. A wide variety of libraries for different use-cases exists. Go to the [marketplace](/marketplace) to find a library that fit your needs.
diff --git a/inlang/documentation/concept/lint-rule.md b/inlang/documentation/concept/lint-rule.md
@@ -1,12 +1,6 @@
----
-title: Lint rule
-href: /documentation/lint-rule
-description: Lint rules validate messages and other types of content in an inlang project.
----
+# Lint rule
 
-# {% $frontmatter.title %}
-
-{% $frontmatter.description %}
+Lint rules validate messages and other types of content in an inlang project.
 
 For example, the [missing translation lint rule](/marketplace/messageLintRule.inlang.missingTranslation) reports an issue if a message is missing a translation for a specified [language tag](/documentation/concepts/language-tag). Inlang applications use lint rules to validate content and report issues to the user.
 

diff --git a/inlang/documentation/concept/message.md b/inlang/documentation/concept/message.md
@@ -1,10 +1,4 @@
----
-title: Message
-href: /documentation/message
-description: TODO TODO TODO TODO TODO
----
-
-# {% $frontmatter.title %}
+# Message
 
 A message is a piece of text that is displayed to the user. Everything within an application, like the text on a button, is a message. A message itself is composed of variants. User preferences like language or region determine which variant is displayed. Inlang's message handling is based on the [ICU Message Format 2.0](https://github.com/unicode-org/message-format-wg/blob/main/spec/syntax.md).
 

diff --git a/inlang/documentation/concept/plugin.md b/inlang/documentation/concept/plugin.md
@@ -1,12 +1,6 @@
----
-title: Plugin
-href: /documentation/plugin
-description: An inlang plugin defines and extend how an inlang app should behave.
----
+# Plugin
 
-# {% $frontmatter.title %}
-
-{% $frontmatter.description %}
+An inlang plugin defines and extend how an inlang app should behave.
 
 For example, plugin A defines that [messages](/documentation/message) should be stored in a database, while plugin B defines that messages should be stored in a file. An [inlang app](/documentation/app) that uses plugin A will store messages in a database, while an inlang app that uses plugin B will store messages in a file.
 

diff --git a/inlang/documentation/concept/project.md b/inlang/documentation/concept/project.md
@@ -1,10 +1,4 @@
----
-title: Project
-href: /documentation/project
-description: TODO TODO TODO TODO TODO
----
-
-# {% $frontmatter.title %}
+# Project
 
 An inlang project is defined by a file that is named `project.inlang.json`. The file contains the settings for a project and is the entrypoint for all applications, plugins, and tools in the inlang ecosystem.
 

diff --git a/inlang/documentation/guide/develop-app.md b/inlang/documentation/guide/develop-app.md
@@ -1,10 +1,4 @@
----
-title: Develop an app
-href: /documentation/develop-app
-description: How to develop an inlang-based app.
----
-
-# {% $frontmatter.title %}
+# Develop an app
 
 There are many ways users interact with inlang. This documentation gives you information on how to develop your own inlang-based app.
 

diff --git a/inlang/documentation/guide/develop-lint-rule.md b/inlang/documentation/guide/develop-lint-rule.md
@@ -1,10 +1,4 @@
----
-title: Develop a lint rule
-href: /documentation/develop-lint-rule
-description: Create an own lint rule for inlang projects.
----
-
-# {% $frontmatter.title %}
+# Develop a lint rule
 
 This documentation provides step-by-step instructions on developing a lint rule for the inlang ecosystem. Lint rules are used to check for specific patterns or issues in translated messages to ensure high-quality translations. Follow the guide below to create your own custom lint rule.
 

diff --git a/inlang/documentation/guide/develop-plugin.md b/inlang/documentation/guide/develop-plugin.md
@@ -1,10 +1,4 @@
----
-title: Develop a plugin
-href: /documentation/develop-plugin
-description: Learn how easy it is to write your own plugin for inlang projects.
----
-
-# {% $frontmatter.title %}
+# Develop a plugin
 
 Plugins are a powerful way to extend the functionality of inlang applications. This documentation provides you with the information you need to develop your own plugin.
 

diff --git a/inlang/documentation/guide/publish-marketplace.md b/inlang/documentation/guide/publish-marketplace.md
@@ -1,10 +1,4 @@
----
-title: Publish to the marketplace
-href: /documentation/publish-marketplace
-description: Reach more of your target audience by publishing your app, plugin, or lint rule to the marketplace.
----
-
-# {% $frontmatter.title %}
+# Publish to the marketplace
 
 Publishing your own plugin or lint rule to the [marketplace](/marketplace) is straightforward, as the only thing you have to add to our item registry is the URL of your `marketplace-manifest.json`.
 

diff --git a/inlang/documentation/overview/architecture.md b/inlang/documentation/overview/architecture.md
@@ -1,10 +1,4 @@
----
-title: Architecture
-href: /documentation/architecture
-description: TODO TODO TODO TODO TODO
----
-
-# {% $frontmatter.title %}
+# Architecture
 
 Inlang's architecture consists of four main components:
 

diff --git a/inlang/documentation/overview/introduction.md b/inlang/documentation/overview/introduction.md
@@ -1,56 +1,24 @@
----
-title: Introduction
-href: /documentation
-description: Inlang is globalization infrastructure that powers an ecosystem of apps, plugins, and solutions that make globalization simple.
----
-
-# {% $frontmatter.title %}
+# Introduction
 
 ## What is inlang?
 
-{% $frontmatter.description %}
+Inlang is globalization infrastructure that powers an ecosystem of apps, plugins, and solutions that make globalization simple.
 
 ![inlang ecosystem](https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/ecosystem.jpg)
 
 ### Infrastructure approach
 
 For every use case, there is an app, a plugin, a lint rule, or a custom solution that can be built. Inlang's infrastructure powers an ecosystem of tools, applications, best practices, and automations for organizations to go global.
 
-{% Figure
-src="https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/project.jpg"
-alt="one config file to power all infrastructure tools"
-caption="Sketch about the concept of one configuration file that powers all tools, automation, and applications for globalization that developers build on top of."
-
-/%}
+<doc-figure src="https://cdn.jsdelivr.net/gh/inlang/monorepo/inlang/documentation/assets/project.jpg" alt="one config file to power all infrastructure tools" caption="Sketch about the concept of one configuration file that powers all tools, automation, and applications for globalization that developers build on top of."></doc-figure>
 
 ### Version control and automation via CI/CD
 
 Inlang apps are built on lix. Lix is a git-compatible version control backend for applications. Using lix provides inlang with CI/CD for globalization and collaboration between developers, translators, and designers on one common source of truth: your repository and your data.
 
-{% Figure
-
-    src="https://github.com/inlang/monorepo/assets/58360188/917cc987-669d-4203-a2ed-8184087fd070"
-
-    alt="lix-based globalization infrastructure"
-
-    caption="Lix repositories act as building blocks for tools, applications like the editor, and automation via CI/CD."
-
-/%}
-
-{% QuickLinks %}
-
-    {% QuickLink
-        title="Getting started"
-        icon="fast"
-        href="/documentation/manually-create-project"
-        description="Create a new project."
-    /%}
-
-    {% QuickLink
-        title="Marketplace"
-        icon="add-plugin"
-        href="/marketplace"
-        description="Find apps, plugins, and lint rules."
-    /%}
+<doc-figure src="https://github.com/inlang/monorepo/assets/58360188/917cc987-669d-4203-a2ed-8184087fd070" alt="lix-based globalization infrastructure" caption="Lix repositories act as building blocks for tools, applications like the editor, and automation via CI/CD."></doc-figure>
 
-{% /QuickLinks %}
+<doc-links>
+    <doc-link title="Getting started" icon="material-symbols:fast-forward-outline-rounded" href="/documentation/manually-create-project" description="Create a new project."></doc-link>
+    <doc-link title="Marketplace" icon="material-symbols:code-blocks-rounded" href="/marketplace" description="Find apps, plugins, and lint rules."></doc-link>
+</doc-links>
diff --git a/inlang/documentation/overview/manually-create-project.md b/inlang/documentation/overview/manually-create-project.md
@@ -1,10 +1,4 @@
----
-title: Manually creating a new project
-href: /documentation/manually-create-project
-description: You can manually create a new project if inlang.com/new is not working for you.
----
-
-# {% $frontmatter.title %}
+# Manually creating a new project
 
 You can manually create a new project via the CLI or by creating an inlang project file.
 

diff --git a/inlang/documentation/reference/comver.md b/inlang/documentation/reference/comver.md
@@ -1,10 +1,4 @@
----
-title: Backwards compatible versioning
-href: /documentation/comver
-description: You can manually create a new project if inlang.com/new is not working for you.
----
-
-# {% $frontmatter.title %}
+# Backwards compatible versioning
 
 > Is this update backwards compatible? 
 

diff --git a/inlang/documentation/reference/sdk.md b/inlang/documentation/reference/sdk.md
@@ -1,9 +1,3 @@
----
-title: SDK
-href: /documentation/sdk
-description: API reference for the inlang SDK. Developers can use the inlang SDK to build inlang applications.
----
-
-# {% $frontmatter.title %}
+# SDK
 
 The documentation for the inlang SDK is currently under construction and coming soon. In the meantime, please refer to the [inlang SDK on GitHub](https://github.com/inlang/monorepo/blob/main/inlang/source-code/sdk/src/index.ts) or [join our Discord](https://discord.gg/gdMPPWy57R) to get help from our team.
diff --git a/inlang/documentation/reference/tableOfContents.md b/inlang/documentation/reference/tableOfContents.md
@@ -0,0 +1,37 @@
+# Table of Contents
+
+inlang's website is using a custom structure for the table of contents. A real example of the structure can be found here: [tableOfContents.json](https://github.com/inlang/monorepo/blob/main/inlang/documentation/tableOfContents.json)
+
+## Structure
+
+### Variant 1
+
+This variant can be used for a flat table of contents.
+
+```json
+[
+	{
+		"path": "path-to-file.md",
+		"slug": "slug-of-url", // has to be unique
+		"title": "Title of the page",
+		"description": "Description of the page",
+	}
+]
+```
+
+### Variant 2
+
+This variant can be used for a table of contents with categories.
+
+```json
+{
+    "Category Name": [
+        {
+            "path": "path-to-file.md",
+            "slug": "slug-of-url", // has to be unique
+            "title": "Title of the page",
+            "description": "Description of the page",
+        }
+    ]
+}
+```