Schreibstil

Alle öffentlichen Dokumentationsseiten sind Deutsch und duzen. Schreib konkret und nachvollziehbar. Keine Marketing-Superlative, keine Roadmap als fertiges Produkt.

Diese Regeln gelten für Grundlagen, Anleitungen, Widget und REST-API. Redaktionelle Vorlagen liegen unter Qualität und Prozess.

Sprache und Ton

Sprich die lesende Person mit du an.
Beschreibe, was die Oberfläche jetzt tut, nicht was sie einmal tun soll.
Halte Sätze kurz. Eine Aufgabe, ein nächster Schritt.
Vermeide „revolutionär“, „alles, was du brauchst“, „keine Komplikationen“.
Technische Bezeichner (booking.created, /b/{slug}/{courseId}, YOUR_API_KEY) bleiben unverändert.

UI-Bezeichnungen übernehmen

Verwende die deutschen Labels aus der Oberfläche. Übersetze sie nicht „schöner“ und mische sie nicht mit englischen Dashboard-Begriffen.

Korrekt (UI)	Nicht verwenden
Dein Kurs. / Deine Kursseite.	„Course page“, „dein Listing“
Entwurf, Veröffentlicht, Beendet, Abgesagt	draft/published als Fließtext ohne UI-Wort
Ausstehend, Bestätigt, Warteliste, Storniert, Abgelaufen	waitlisted, pending als alleinige Bezeichnung
Vor Ort, Online	Offline, remote
Filiale, Einzeladresse	Location, Venue im Fließtext
Trainer:in	Trainer, Member
Teilnehmerkonto	User-Account, Customer-Login
Arbeitsbereich / Workspace	Tenant, Org (außer in Klammern zur Erklärung)

Statuswerte der API darfst du in Klammern ergänzen, z. B. Veröffentlicht (published). Zuerst das UI-Wort, dann der technische Wert.

Glossar: Begriffe.

Beta, geplant, Roadmap

Kennzeichne den Funktionsstand am ersten relevanten Satz, nicht erst am Seitenende.

Kennzeichnung	Wann	Beispiel
Beta	Ausgeliefert, aber unvollständig oder im Ausbau	Stripe Connect, Widget, REST-API, ICS, Webhook `booking.created`
geplant oder Roadmap	In UI oder Marketing sichtbar, nicht nutzbar	Automatisierungen, Google-Sync, Zapier, PayPal, REST-Writes

Schreibe nicht „Integrationen sind verfügbar“, wenn du Zapier meinst.
Schreibe nicht „Zahlungen sind Roadmap“, wenn Stripe Connect in der Beta ausgeliefert ist.
Wenn Marketing und Produkt widersprechen, gilt das Produkt. Siehe Verfügbar und geplant.

Platzhalter statt Geheimnisse

In Beispielen nur diese Platzhalter:

Platzhalter	Einsatz
`YOUR_WIDGET_KEY`	Widget-Embed, Manifest, Client-Beispiele
`YOUR_API_KEY`	`Authorization: Bearer YOUR_API_KEY`

Weitere erlaubte Platzhalter, wenn nötig: YOUR_WORKSPACE_SLUG, YOUR_COURSE_ID, https://example.com.

Widget-Keys werden im Dashboard nur einmal vollständig angezeigt. In der Doku niemals ein „Beispiel-Key“ erfinden, das wie ein echtes Token aussieht.

Links und Informationsarchitektur

Produktaufgaben → /anleitungen/
Embed → /widget/
Lesende API, ICS, Webhooks → /rest-api/
Begriffe und Rollen → /grundlagen/

Setze relative Dokumentationspfade mit abschließendem Slash, z. B. /grundlagen/begriffe/.

Trenn die Zielgruppen. Eine Widget-Seite erklärt kein Owner-Onboarding. Eine Teilnehmerseite erklärt keine API-Keys. Zuordnung: Zielgruppen.

Beispiele und Befehle

Beispiele müssen mit dem beschriebenen Stand lauffähig oder klar als unvollständig markiert sein.
Preise in Euro mit Komma: 0,50 EUR, nicht $0.50.
Öffentliche URL immer als Muster: /b/{slug}/{courseId}.
Webhook-Namen exakt: booking.created.

Was du nicht dokumentierst als fertig

Diese Themen nicht als Anleitung mit Happy Path schreiben, solange sie nicht ausgeliefert sind:

Automatischer Nachrichtenversand
Persistierte Anwesenheit / Check-in
Mehrtermin-Kurs als ein Angebot
Google-Kalender-Synchronisation
Zapier
Schreibende REST-API
PayPal-Checkout

Du darfst sie in Verfügbar und geplant als geplant nennen.