Seiten verändern auf datenschmutz.de

Textchas

Es ist überraschend, wie viele Spammer sich die Mühe machen, ihre Links in Wikis zu bekommen. Wir können gar nicht so viel aufräumen, wie die Seiten kaputt machen, und daher müsst ihr leider beim Editieren einer Seite immer "grummel" in das Feld über der Box schreiben. Der lästige Nerv tut uns leid, und wir sind jahrelang damit durchgekommen, Edits nur über https zuzulassen -- es ist ja ohnehin eine gute Idee, https zu verwenden --, aber leider sind die Spammer schlau genug geworden, um das auch zu bedienen.

Wenn ihr das Wort mal vergessen oder falsch eingegeben habt oder so: Euer Edit ist nicht weg, euer Browser hat ihn noch – geht einfach eine Seite zurück.

Ebenfalls wegen der Spammer (und weil es eigentlich keinen Grund gibt, sich hier einzuloggen – wir speichern eh keine IPs) haben wir das Anlegen von Accounts abgeschaltet. Es war nicht lustig, jeden Monat ein per Skript hunderte Fake-Accounts wegputzen zu müssen und nicht sicher zu sein, ob nicht doch irgendwer dabei war, der/die nachher sauer ist und meint, wir hätten ihn/sie „rausgeworfen”.

Extra-Features dieses Wikis

Doclinks

Die Erfahrung vieler Jahre zeigt, dass externe Ressourcen auch und gerade bei eher gesetzten Behörden wie etwa Datenschutzbeauftragten verschwinden oder jedenfalls ihre Lage ändern. Deshalb spiegeln wir einige Dokumente (Liste. Das sind entweder Dokumente, die häufig zitiert werden (bei denen Änderungen der URLs wirklich viel Arbeit wären) oder Dokumente, die vermutlich bald verschwinden werden.

Um sie aus dem Wiki-Text zu zitieren, gibt es das Doclink-Makro, das im ersten Argument den Dateinamen hat, im zweiten den Ankertext (als das, was im Text steht). Beispiel:

<<Doclink(2007-LfDBaWue-Bericht28.pdf, 28. TB LfD BaWü (2008))>> wird zu 28. TB LfD BaWü (2008).

Wer Dokumente gespiegelt haben will, möge sie einfach hier eintragen, jemand mit Schreibrecht sollte das in absehbarer Zeit sehen:

• Beispiel-Dokument: http://sample.url/somewhere (für eine Beispielseite)

Links auf Regierungsdokumentation

Wir vermuten stark, dass Parlamentsdoku und ähnliches noch lange im Netz verfügbar sein wird. Daher spiegeln wir sowas in der Regel nicht hier.

Allerdings werden sich die Links zu diesen Geschichten dann und wann ändern. Daher sollten Links auf EU-Ratsdokumente und Bundestags-Drucksachen über die entsprechenden Makros gemacht werden (und beschwert euch, wenn die nicht richtig funktionieren; wir haben nur geraten, wie das geht, eine richtige API zu diesen Dingen ist uns nicht bekannt):

• Ratsdokument(nummer, lang="en") -- Gibt einen PDF-Link auf EU-Dokumentation. Das betrifft inzwischen auch Beschlüsse und Kommissionsmitteilungen, der Name ist also nicht mehr ganz toll. Die Beispiele unten sollten immer dokumentieren, was gerade geht. Optional kann hinten noch eine Sprache als ISO-Ländercode angegeben werden, Default ist Englisch, weil es das wohl für alle Drucksachen gibt. Aber Vorsicht: Beim Rat ist viel Geheim. Bereits geleakte Geheimdokumente würden wir ggf. spiegeln.
• BtDS(drucksachennummer) -- Gibt einen PDF-Link auf eine Bundestags-Drucksache zurück. Bundestagsdrucksachen haben immer die Form (legislaturperiode)/(dokumentnummer). Wahrscheinlich geht das noch nicht für ältere Drucksachen. Wenns das mal braucht, bauen wir das noch ein.

Beispiel:

<<BtDS(17/4833)>>

<<Ratsdokument(EU 2016/679)>> (verabschiedete Richtlinie)

<<Ratsdokument(EU 2016/680V)>> (verabschiedete Verordnung – unsere Maschine
braucht das V manuell angegeben, der Link bricht, wenn es für eine Verordnung fehlt)

<<Ratsdokument(10827/1/11)>>  (Ratsdokument mit Version)

<<Ratsdokument(10827/1/11, "de")>> (Ratsdokument mit Version, auf Deutsch)

<<Ratsdokument(15870/09)>> (Ratsdokument ohne Version)

<<Ratsdokument(2009/315/JI)>> (Parlamentsbeschluss)

<<Ratsdokument(2009/315/OJ)>> (Veröffentlichung im Official Journal)

<<Ratsdokument(COM(2012) 735)>> (Kommissionsmitteilung)

wird zu

Bundestags-Drucksache 17/4833

Richtlinie 2016/679 (verabschiedete Richtlinie)

Verordnung 2016/680 (verabschiedete Verordnung)

Ratsdokument 10827/1/11 (Ratsdokument mit Version)

Ratsdokument 10827/1/11 (Ratsdokument mit Version, auf Deutsch)

Ratsdokument 15870/09 (Ratsdokument ohne Version)

2009/315/JI (Parlamentsbeschluss)

2009/315/OJ (Veröffentlichung im Official Journal)

Kommissionsmitteilung COM(2012) 735 (Kommissionsmitteilung)

Die dann und wann gesehene Form COM/2012/735 für Ratsmitteilungen finden wir doof, und drum geht sie hier nicht.

Rellinks

Einige Features von datenschmutz.de liegen außerhalb des Wikis (Auskunftsgenerator, Get connected-Archiv). Da die Seite mit http, https und als hidden service erreichbar ist, will mensch relative Links dorthin setzen, was aber mit der üblichen Moin-Syntax nicht geht. Stattdessen haben wir Rellinks, die ziemlich direkt in Anker-Elemente übersetzt werden und in jedem Fall für Links auf get connect-Artikel verwendet werden sollten. Beispiel:

Ein <<Rellink(gc/html/burger.html,Artikel zu schlechten Argumenten im bürgerlichen Datenschutz)>>
erschien in RHZ 3/14.

wird zu:

Ein Artikel zu schlechten Argumenten im bürgerlichen Datenschutz erschien in RHZ 3/14.

Blockquotes

Leider hat Moinmoin selbst kein Markup für "längeres Zitat". Weil längere Zitatblöcke hier länger vorkommen, haben wir eine eigene Erweiterung dafür gemacht, den blockquote-Parser. Das sieht so aus:

{{{#!blockquote
Dieses ist ein Zitat, das zeigen ''soll'', dass innerhalb von 
Blockquotes Wiki-Syntax erlaubt ist.  Insofern gehen auch die

 #. nicht nur in der EU
 #. durchaus beliebten
 #. Aufzählungen.
}}}

Gerendert wird das derzeit so (besseres CSS dafür ist willkommen):

Dieses ist ein Zitat, das zeigen soll, dass innerhalb von Blockquotes Wiki-Syntax erlaubt ist. Insofern gehen auch die

1. nicht nur in der EU
2. durchaus beliebten
3. Aufzählungen.

Iimages

Das Iimage-Makro sollte für alle Bilder auf diesem Wiki verwendet werden (zur Verwendung von Bildern allgemein vgl. unten, da erklären wir auch, warum wir Links zu externen Bildern nicht gerne sehen). Es hat die Form

Iimage(Dateiname,titel und alt)

Der Dateiname hat dabei immer die Form Jahr-beschreibung.ext, also etwa 2006-pruemStructure.jpg. "titel und alt" bezeichnet hier ein paar Worte zu dem, was auf dem Bild zu sehen ist. Dieser Text wird gezeigt, wenn das Bild nicht geladen werden kann oder soll sowie z.B. als "Tooltip" in grafischen Browsern.

Bild-Dateien einrichten können nur die Server-Betreiber. Wenn ihr ein Bild hier drin aben wollt, schreibt eine Bestellung hierhin:

• Beispiel-Bild: http://von.irgendwoh.er/bild.gif, soll 2011-beispielbild.jpg heißen.

Irgendwer sollte sich dann relativ schnell drum kümmern. Wenn ihr das Iimage-Makro verwendet habt, wird zunächst der Ersatztext gezeigt, danach, wenn wir das Bild verarztet haben, automatisch das Bild.

Stil-Wünsche

Natürlich sind uns Beiträge in jedem Stil willkommen, die Erfahrung einiger Jahre (oder Präferenzen der Datenschutzgruppe) führen allerdings zu folgenden Wünschen:

Quellenangaben inline

Wenns geht, haben wir Quellenangaben und Verweise lieber inline:

• Laut 23. Bericht Verschwörungsbeauftragten aus Absurdistan werden seit 2011 Melderegister und ZEVIS mit Reisedaten der Bahn und Payback zusammengeführt.

als:

• Inzwischen werden Melderegister und ZEVIS mit Reisedaten der Bahn und Payback zusammengeführt.

  Quelle: 23. Bericht Verschwörungsbeauftragten aus Absurdistan

Das erste Format ist robuster gegenüber Edits, entspricht besser den Gepflogenheiten des Web und verbindet Aussage und Beleg enger. Ähnliches gilt für das Footnote-Makro -- in Hypertexten haben Fußnoten eigentlich nicht viel verloren, und in der Regel ist es auch angenehmer, gleich im Text zu sehen, woher eine Information kommt. Ausnahmen bestätigen natürlich die Regel.

Aufzählungen von Quellen sind recht als genau das, Aufzählungen von vermischten oder noch nicht wirklich ausgewerteten Quellen. Auch dann ist ein kurzer Kommentar für spätere Nutzer_innen hilfreich:

• http://some.url/?doc=xy -- Herstellerdokumentation zum Streaming von Videoüberwachungsdaten in Datenbanktabellen.

Diskussion dazu

Pro: Ich halte nicht alle Wikipedia-Dogmen für sinnig. Aber Footnotes erlauben die genauere Referenzierung und ermöglichen es erstmal zu überlegen, ob mensch den Link anklickt oder nicht, wogegen bei allen möglichen Links nicht klar ist, ob ich jetzt eine Webseite von Polizei oder Verfassungsschutz anklicke. D.h. durch Footnites ist es sehr genau möglich zu beschreiben worum es sich handelt, im Fließtext dagegen nicht.

• Es gibt fraglos Fälle, in denen eine Inline-Quellenangabe nicht sinnvoll ist, etwa, wenn die Quelle nur entfernt was mit dem diskutierten Inhalt zu tun hat. Die Frage der "Erwartbarkeit" aber hat damit nichts zu tun. Für sie ist relevant, dass der Anker-Text den Link möglichst genau beschreibt ("NADIS-Bericht des Verfassungsschutzes (2005)", "Bundestagsdrucksache 2348/17", "Statement der Aktionsgruppe"), was in Hypertexten ohnehin stark anzustreben ist, unabhängig davon, ob der Link in einer Fußnote steht oder nicht. Und dann sollte der Browser die Ziel-URL natürlich auch an geeigneter Stelle einblenden, klar.

Footnotes erschweren die Lesbarkeit des Quelltextes, auch wenn sie vielleicht ein schönerer Stil sind.

Commit-Kommentare

Wenns geht, schreibt doch was in das "Kommentar"-Feld beim Abschicken einer Änderung. Sowas macht die Anzeige von AktuelleÄnderungen viel informativer...

Lieber weniger Seiten

Es gibt natürlich viel zu lange Seiten (Europol ist ein Beispiel), aber generell sollte eine Entscheidung "soll ich Inhalt X auf eine eigene Seite ausgliedern" immer mit einer Vorliebe für "in der Seite bleiben" fallen. Das Wiki ist erstmal schon unübersichtlich genug, und es ist einfacher, auf einer Seite hoch- und runterzuscrollen als zwischen vielen Seiten zu navigieren. Außerdem geht auch nicht so leicht verloren, dass ein Thema schon behandelt ist.

Bei der Gelegenheit: Wir haben hier das Unterseiten-Feature von moin (Seite/Unterseite) viel zu wenig genutzt. Es wäre z.B. gewiss ein Gewinn, die Teildatenbanken von INPOL unter INPOL (oder, wahrscheinlich besser, unter Datenbanken BKA) zu gruppieren. Wer möchte, dann das gerne besser machen.

Bilder lieber nicht

Bitte fügt Bilder nur ein, wenn sie wirklich was bringen, nicht aus nur ästhetischen Gründen.

Grundsätzlich wollen wir alle Bilder, die aus unserem Wiki referenziert werden, auch bei uns speichern, schon, um externen Log-Einträgen vorzubeugen. Seht also bitte, dass wir dafür keinen Ärger kriegen, die Rechte auf Bildern abzuklären würde uns ziemlich nerven.

Die Alternative, nämlich Attachments erlauben, klingt immer noch zu gruselig.

Vgl. auch oben zum Iimage-Makro.

Allgemeine Hilfe zum Editieren

Eine allgemeine Hilfe zum Editieren gibt es unter HilfeZumEditieren, wer erstmal spielen will, kann das in der WikiSandBox tun.