Die Kotlin-Dokumentation verbindet Lernen, Sprachreferenz, Plattformen, API-Referenz und Migrationen.

Für den strukturellen Teil wurden DocLint-Regeln verwendet, die redaktionelle Bewertung erfolgte manuell anhand offizieller Quellen.

Untersuchungsumfang

Öffentlicher Stand vom 15. August 2026.

320

Markdown-Themen

2

.topic-Dateien

16

Tour-Lektionen

2.4.0

stabile Version

10

Kriterien

Kein einziges großes Handbuch

Lernen, Aufgaben, Konzepte, Referenz und Release-Inhalte sind getrennt.

NutzerzielZielErgebnis
AusprobierenTour und PlaygroundOhne IDE starten.
Projekt startenGet startedNach Plattform und Ziel.
Sprache verstehenLanguage guideKonzepte und Syntax.
API nachschlagenDokkaSeparate Referenz.
AktualisierenWhat’s new und MigrationVersionsbezogene Inhalte.
Bibliothek bauenKDoc und Author GuidelinesQualität öffentlicher APIs.

Technische Umsetzung

Reife Docs-as-Code-Architektur.

1

Markdown + Writerside

Inhalte und Navigation.

2

Mehrere Repositories

Externe Docs werden eingebunden.

3

CI

Ausführbare Beispiele werden geprüft.

4

Publikation

TeamCity baut und verarbeitet nach.

Redaktionelle Bewertung: 82/100

Sehr stark bei Einstieg, Beispielen und Engineering. Schwächer bei Lokalisierung und Troubleshooting.

Einstieg
9/10
Informationsarchitektur
9/10
Beispiele
10/10
Referenz
9/10
Versionen
9/10
Troubleshooting
7/10
Auffindbarkeit
8/10
Klarheit
8/10
Engineering
10/10
Lokalisierung
3/10

82/100

Besonders stark

Tour ohne Installation

[K3]

16 Browser-Lektionen.

Geprüfte Beispiele

[G4]

Runnable snippets werden in CI geprüft.

Navigation als Code

[G3]

kr.tree versioniert die Struktur.

Release-Dokumentation

[K10]

Dokumentationsänderungen werden mit Releases gepflegt.

Author Guidelines

[K7]

Personas, Fehlerfälle und API-Design.

AI-gestützte Wartung

[G7]

Das Repository enthält reproduzierbare Skills.

Starke und schwache Formulierungen

Gutes Engineering ersetzt kein Editing.

KriteriumFormulierungAnalyse
Gut“New to Kotlin? Take our tour…” [K2]Direkt und handlungsorientiert.
Gut“Begin the description of entry points…” [K7]Prüfbare Regel.
Überarbeiten“The Kotlin Standard Library provides…” [K5]Zu abstrakter Einstieg.
Korrigieren“Attempting to access properties…” [K4]Das folgende Beispiel zeigt einen Compile-Fehler.

Was fehlt

LückeWarum wichtig
Offizielle ÜbersetzungenDie Hauptdokumentation ist nur Englisch. [K9]
Einheitlicherer WegCore, KMP und API wirken als getrennte Räume. [K11]
Konstanteres TroubleshootingFehlerbehandlung ist nicht überall gleich tief. [G3]
Straffere ProsaEinige Grundlagen-Seiten sind zu lang. [K5]

Entwicklung

2.1.0

Grundlagenseiten wurden überarbeitet. [K10]

2.2.0

Intermediate Tour und separates KMP-Portal. [K11]

2.2.20

Mehr Web-, Coroutine- und Native-Dokumentation. [K12]

2.4.0

AI Skills, LSP, KSP und Lincheck. [K13]

Was man übernehmen sollte

PraxisÜbernehmen
Navigation als CodeInformationsarchitektur versionieren.
Geprüfte BeispieleCodebeispiele in CI testen.
Inhaltstypen trennenTutorial, Konzept und Referenz nicht vermischen.
Release DocsMigration zusammen mit dem Produkt aktualisieren.
Docs als DesigntestSchwieriges Onboarding kann auf schwierige API hinweisen.
AI mit SkillsAgenten konkrete, prüfbare Abläufe geben.

Primärquellen

Fazit

Kotlin ist vor allem als Produktionssystem für Dokumentation stark.

Der Leserweg trennt Lernen, Konzepte, Referenz und Migration sinnvoll.

Die größten Chancen liegen bei Lokalisierung, Troubleshooting und straffer Redaktion.

Kotlin zeigt eine reife Dokumentationsarchitektur mit geprüften Beispielen und automatisierbarer Wartung.