Unterschiede zwischen den Revisionen 32 und 34 (über 2 Versionen hinweg)
Revision 32 vom 2018-05-11 14:50:44
Größe: 11967
Autor: LilaBlume
Kommentar:
Revision 34 vom 2019-11-30 13:47:58
Größe: 11831
Autor: LilaBlume
Kommentar:
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 8: Zeile 8:
Seite immer "grummel" in das Feld über der Box schreiben. Der lästige Seite immer "grummel" in das Feld über der Box schreiben. Der lästige
Zeile 41: Zeile 41:
{{{Doclink(2007-LfDBaWue-Bericht28.pdf, 28. TB LfD BaWü (2008))}}} wird {{{<<Doclink(2007-LfDBaWue-Bericht28.pdf, 28. TB LfD BaWü (2008))>>}}} wird
Zeile 61: Zeile 61:
 * Ratsdokument(nummer, lang=&quot;en&quot;) -- 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.  * 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.
Zeile 76: Zeile 76:
<<Ratsdokument(10827/1/11, &quot;de&quot;)>> (Ratsdokument mit Version, auf Deutsch) <<Ratsdokument(10827/1/11, "de")>> (Ratsdokument mit Version, auf Deutsch)
Zeile 98: Zeile 98:
<<Ratsdokument(10827/1/11, &quot;de&quot;)>> (Ratsdokument mit Version, auf Deutsch) <<Ratsdokument(10827/1/11, "de")>> (Ratsdokument mit Version, auf Deutsch)
Zeile 137: Zeile 137:
Leider hat Moinmoin selbst kein Markup für &quot;längeres Zitat&quot;. Weil längere Leider hat Moinmoin selbst kein Markup für "längeres Zitat". Weil längere
Zeile 172: Zeile 172:
Der Dateiname hat dabei immer die Form Jahr-beschreibung.ext, also etwa 2006-pruemStructure.jpg. &quot;titel und alt&quot; 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 &quot;Tooltip&quot; in grafischen Browsern. 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.
Zeile 214: Zeile 214:
  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 &quot;Erwartbarkeit&quot; aber hat damit nichts zu tun. Für sie ist relevant, dass der Anker-Text den Link möglichst genau beschreibt (&quot;NADIS-Bericht des Verfassungsschutzes (2005)&quot;, &quot;Bundestagsdrucksache 2348/17&quot;, &quot;Statement der Aktionsgruppe&quot;), 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.   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.
Zeile 220: Zeile 220:
Wenns geht, schreibt doch was in das &quot;Kommentar&quot;-Feld beim Abschicken einer Wenns geht, schreibt doch was in das "Kommentar"-Feld beim Abschicken einer
Zeile 225: Zeile 225:
generell sollte eine Entscheidung &quot;soll ich Inhalt X auf eine eigene Seite
ausgliedern&quot; immer mit einer Vorliebe für &quot;in der Seite bleiben&quot; fallen. Das
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

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

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:

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.

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:

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:

als:

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.