Sag' es besser...

Eine komplett statische, trackerfreie Website mit 93 direkt verlinkbaren Einträgen zu ableistischer, sanistischer/saneistischer, misogyner, sexistischer, klassistischer und historisch belasteter Sprache.

Schnell starten

Den Inhalt des Ordners html/ auf einen normalen Webserver kopieren. Es gibt keine Datenbank, keinen Build-Zwang und keine externen Abhängigkeiten.

Für einen lokalen Test:

python3 -m http.server 8080 --directory html

Dann http://localhost:8080/ öffnen.

Alternativ ist eine kleine Nginx-Docker-Variante enthalten:

docker compose up -d

Sie stellt die Seite ebenfalls auf Port 8080 bereit.

Für Social Media und Suchmaschinen

Jeder Eintrag liegt als echte statische Seite unter html/wort/<slug>/index.html. Dadurch haben geteilte Begriffe eigene Titel und Beschreibungen, statt nur einen #hash auf der Startseite zu benutzen.

Die Seite html/grundlagen/ erklärt die Kategorien, Status-Badges und die Grenzen des Wörterbuchs. Sie wird beim Build automatisch mit erzeugt.

Wenn die endgültige Domain bekannt ist, einmal neu bauen:

./build.py --site-url https://deine-domain.example

Damit werden absolute Canonical-/Share-URLs sowie eine html/sitemap.xml erzeugt.

Inhalte bearbeiten

• data/words.json enthält alle Wörter, Alternativen, Erklärungen und Quellenzuordnungen.
• data/sources.json enthält die Quellen.
• Danach ./build.py ausführen.

Hinweis zu Git-Diffs

build.py erzeugt aus den Quelldateien ausschließlich unter html/ die Startseite, die Grundlagen-Seite und alle einzelnen Wortseiten neu. Die erzeugten HTML-Dateien werden als statischer Veröffentlichungsstand im Repository mitgeführt. Deshalb kann eine kleine Änderung in data/words.json, data/sources.json oder build.py in Git einen verhältnismäßig großen Diff auslösen: Die Änderung wird an mehreren generierten Seiten übernommen. Das ist erwartetes Verhalten und nicht automatisch ein Hinweis auf viele unabhängige inhaltliche Änderungen.

Mit „Quelldateien“ sind hier insbesondere gemeint:

• data/words.json für die Einträge, Alternativen, Erklärungen und Beispiele,
• data/sources.json für die zentral verwalteten Quellen,
• build.py für die HTML-Struktur und die Seitentemplates,
• styles.css für das Design und app.js für interaktive Funktionen.

Auch Dateien in assets/ gehören zum direkten Quellbestand, wenn Grafiken oder Icons geändert werden. Bearbeitet werden sollten grundsätzlich diese Dateien, nicht die daraus erzeugten index.html-Dateien unter html/wort/, html/grundlagen/ oder html/index.html. Anschließend werden die generierten Dateien mit ./build.py aktualisiert.

Entwicklung

Das Projekt liegt als Git-Repository auf Forgejo: https://devnoc.de/nocci/sag-es-besser

Für lokale Änderungen genügt ein einfacher Entwicklungsserver:

python3 -m http.server 8080 --directory html

Wenn Inhalte in data/ geändert wurden, aktualisiert ./build.py die Startseite und die einzelnen Seiten unter html/. Die erzeugten Dateien gehören zum statischen Veröffentlichungsstand und werden deshalb mitgeführt.

Für die laufende Entwicklung kann der Build automatisch mitlaufen:

./build.py --watch

Mit veröffentlichungsfertigem Output und Canonical-/Share-URLs:

./build.py --site-url https://deine-domain.example --watch

Direkter FTP-/FTPS-Upload

Für einen direkten Upload nach dem Build die FTP-Zugangsdaten lokal in .env eintragen. Die Datei ist in .gitignore ausgeschlossen; als Vorlage dient .env.example.

./build.py --site-url https://sag-es-besser.de --deploy

--deploy baut standardmäßig nach html/ und lädt anschließend alle erzeugten Dateien per FTPS auf FTP_REMOTE_DIR hoch. Ein anderes Ausgabeverzeichnis kann mit --output-dir angegeben werden. Der Upload legt fehlende Unterverzeichnisse an, löscht aber keine alten Dateien auf dem Server.

Der Watch-Modus benötigt keine zusätzlichen Pakete und endet mit Ctrl-C.

Datenschutz

Keine Cookies, keine Analytics, keine externen Fonts, kein CDN, keine externen JavaScript-Bibliotheken. Externe Verbindungen entstehen nur, wenn Besucher*innen bewusst einen Quellenlink öffnen.

Design

Absichtlich kein generischer Web-App-Look: kein Gradient, keine runden Dashboard-Karten, keine Stock-Illustrationen. Die Gestaltung orientiert sich eher an Wörterbuch, Flugblatt und kleinem Magazin. Semantisches HTML, Tastatursteuerung, prefers-reduced-motion und druckbares Layout sind eingebaut.