Stil-Guide für die SocialOffice-Dokumentation

Dieser Leitfaden dient allen Autoren und Redakteuren, um eine einheitliche, professionelle und inklusive Dokumentation zu gewährleisten. Er definiert Regeln für Sprache, Formatierung, Struktur und visuelle Elemente.

Letzte Aktualisierung: 04. Mai 2026*

1. 🎯 Anrede & Sprache

Regel: Durchgehend "Sie"-Form

Die Dokumentation spricht den Nutzer höflich und professionell an.

✅ Richtig	❌ Falsch
"Wählen Sie das Modul aus"	"Wähle das Modul aus"
"Sie können Dateien anhängen"	"Du kannst Dateien anhängen"
"Öffnen Sie das Fenster"	"Öffne das Fenster"

Ausnahmen:

Technische Befehle/Commands bleiben in der Originalform (z. B. gpupdate /force)
Menüpunkte werden in Backticks geschrieben (z. B. Administration)

2. 👥 Gendergerechte Sprache

Ziel ist es, alle Geschlechter gleichermaßen anzusprechen und sichtbar zu machen, ohne den Lesefluss unnötig zu stören. Wir verwenden eine kombinierte Strategie aus Neutrale Formulierungen (Priorität 1) und geschlechtsneutralen Bezeichnungen (Priorität 2).

A. Priorität 1: Neutrale Formulierungen (Empfohlen)

Versuchen Sie, geschlechtsspezifische Begriffe durch neutrale Umschreibungen zu ersetzen. Dies ist oft flüssiger zu lesen.

Statt (geschlechtsspezifisch)	Nutzen (neutral)	Beispiel im Text
Der Benutzer	Der Nutzer / Die Person	"Der Nutzer kann..." statt "Der Benutzer kann..."
Der Administrator	Die Verwaltung / Die Admin-Person	"Die Verwaltung erstellt..."
Der Kunde	Die Klientin / Der Klient	Im Modul "Klienten" ist "Klient" bereits neutral, aber "Die Person" ist oft besser.
Die Mitarbeiter	Das Team / Die Mitarbeitenden	"Die Mitarbeitenden können..."
Der Leser	Die Leserin / Der Leser (nur wenn nötig)	Besser: "Wer dies liest..."

B. Priorität 2: Geschlechtsneutrale Bezeichnungen

Wenn eine neutrale Umschreibung nicht möglich ist oder der Begriff fest etabliert ist (z. B. in Datenbankfeldern), verwenden Sie geschlechtsneutrale Formen.

Empfohlene Form: Das Binnen-I oder Paarform (je nach Kontext).

Hinweis: Für technische Dokumentation (Software-UI) ist oft das Binnen-I oder die Pluralform am besten lesbar.*

Situation	Empfehlung	Beispiel
Allgemeine Ansprache	Plural (oft am elegantesten)	"Die Nutzer können..." statt "Der Nutzer/Die Nutzerin"
Einzelne Person	Binnen-I (nur bei feststehenden Begriffen)	"Der Benutzer" (wenn "Nutzer" nicht passt) Alternative: "Die Benutzende" (sehr inklusiv, aber oft schwer lesbar)
UI-Elemente / Felder	Original beibehalten	Wenn die Software "Benutzername" heißt, schreiben Sie "Benutzername".

❌ Vermeiden:

Schrägstriche (Benutzer/in) – stört den Lesefluss und Screenreader
Doppelpunkte (Benutzer:innen) – in technischen Anleitungen oft zu unterbrechend
Sternchen (Benutzer*innen) – kann in Code-Blöcken oder technischen Kontexten verwirrend wirken

C. Konkrete Anwendung im SocialOffice-Kontext

Begriff im System	Empfehlung in der Doku	Begründung
Benutzer	Nutzer oder Person	"Benutzer" klingt technisch; "Nutzer" ist menschlicher.
Mitarbeiter	Mitarbeitende	Inklusive aller Geschlechter.
Administrator	Admin-Person oder Verwaltung	Vermeidet "Der Administrator".
Klient	Klient (bleibt)	Der Begriff ist im Modul fest verankert und bereits relativ neutral.
Leser	Nutzer	Vermeidet "Leser/Leserin".

Beispiel-Satz (Vorher/Nachher):

❌ Vorher: "Der Administrator muss den Benutzer anlegen, damit der Benutzer sich anmelden kann."
✅ Nachher: "Die Verwaltung muss den Nutzer anlegen, damit sich die Person anmelden kann."
✅ Alternativ (Plural): "Die Verwaltung muss Nutzer anlegen, damit sich sie anmelden können."

3. 📑 Überschriften-Hierarchie

Konsistente Ebenen

= Haupttitel (Seitentitel) =
== Hauptkapitel ==
=== Unterkapitel ===
==== Detail (nur bei Bedarf) ====

Beispiel:

= Klienten =
== Aufbau ==
== Verlaufsdokumentation ==
=== Beispiel von Einträgen ===

Vermeiden:

Überspringen von Ebenen (nicht von = direkt zu ===)
Zu viele Ebenen (max. 4)
"Inhaltsverzeichnis" als Überschrift (MediaWiki generiert das automatisch)

4. 💻 Code & Technische Begriffe

Formatierung nach Typ

Typ	Formatierung	Beispiel
Menüpunkte	`Backticks`	`Administration`, `Weiteres`
Befehle/Commands	`Code-Block`	`gpupdate /force`
Dateinamen	`Backticks`	`policies.json`
URLs	Markdown-Link	<https://example.com>
IDs/Keys	`Code-Block`	`keacgmkcjipbdcpfoobecgkhfhffodhi`
Schlüsselwörter	Fett	Administrator, Berechtigungen

Code-Blöcke verwenden für:

Shell-Befehle
JSON-Inhalte
Konfigurationswerte
Pfadangaben

<syntaxhighlight lang="json"> {

 "installation_mode": "force_installed",
 "update_url": "https://clients2.google.com/service/update2/crx"

} </syntaxhighlight>

5. 🖼️ Bilder & Screenshots

Platzierung

Logo ganz oben (alle Seiten haben Datei:Logo.png)
Screenshots direkt nach der Beschreibung, die sie illustrieren
Nicht am Ende der Seite sammeln

Bildbeschriftung

[[File:xxx.png|thumb|Beschreibung]]

Regel: Jede Bild-Referenz sollte im Text erwähnt werden, bevor das Bild erscheint.

Größe

Standard: 300px-500px Breite
Größere Bilder nur bei komplexen Diagrammen

6. 🔗 Interne Verweise

Konsistente Verlinkung

[[Seitentitel|Anzeigetext]]

Beispiel:

Wählen Sie das Hauptmodul [[Klienten]] über die [[Seitenaufbau|Navigation]] aus.

Vermeidung von "Rot-Links"

Vor dem Veröffentlichen prüfen:

Existiert die verlinkte Seite?
Ist der Titel korrekt geschrieben?

Fehlende Seiten (aktuell):

7. 📋 Tabellen

Wann verwenden?

Vergleich von Optionen
Konfigurationswerte
Schritt-für-Schritt-Anleitungen

Format

Feld	Wert	Beschreibung
ID	`abc123`	Eindeutige Kennung
URL	`https://...`	Update-Server

Tipp: Fettmarkierung in der ersten Spalte für bessere Lesbarkeit.

8. 🎨 Terminologie

Einheitliche Begriffe

Begriff	Verwenden	Nicht verwenden
Benutzer	Nutzer / Person	User, Account, Benutzer (technisch)
Klienten	Klienten	Kunden, Fälle
Eintrag	Eintrag	Datensatz, Record
Modul	Modul	Feature, Komponente
Administration	Administration	Admin-Bereich, Settings
Mitarbeiter	Mitarbeitende	Mitarbeiter, Personal
Toolbar	Toolbar	Werkzeugleiste
Navigation	Navigation	Menü, Sidebar

9. ⚠️ Warnhinweise & Hinweise

Konsistente Boxen

Typ	Format	Beispiel
Wichtig	Fett	Wichtig: Dieses Plugin ist nur für Outlook Classic
Hinweis	Normal	Hinweis: Die Tabelle wird nur bis gestern geführt
Achtung	Kursiv	Achtung: Neue Version nicht kompatibel mit alter Software

10. 📄 Checkliste vor Veröffentlichung

Bevor eine Seite online geht:

[ ] Anrede durchgehend "Sie"
[ ] Gendergerechte Sprache: "Nutzer" statt "Benutzer", "Mitarbeitende" statt "Mitarbeiter"?
[ ] Überschriften-Hierarchie korrekt (= → == → ===)
[ ] Alle Bilder haben Alt-Text
[ ] Interne Links funktionieren (keine Rot-Links)
[ ] Code/Commands in Backticks oder Code-Blöcken
[ ] Keine Tippfehler in Menüpunkten
[ ] Bilder sinnvoll platziert (nicht alle am Ende)
[ ] Keine doppelten Inhalte mit anderen Seiten
[ ] Logo nur einmal oben

Dieser Stil-Guide ist verbindlich für alle neuen und überarbeiteten Seiten der SocialOffice-Dokumentation.*