Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/flow/selective

WikiSyntaxTextMod → Syntaxpolitur → Schritt 5

Schutzbereiche

In einem fünften Schritt werden weitere Bereiche gegen allgemeine Änderungen geschützt.

Das ist nicht immer erforderlich und wird nur umgesetzt, wenn es eine Notwendigkeit dafür gibt.

In den geschützten Bereichen wird nichts gesucht, erst recht nichts ersetzt.

Notwendigkeit des Schutzes

Es gibt zwei Stufen:

Verbergen vor der weiteren Analyse
Kommentare, nowiki und syntaxhighlight
Diese Bereiche beeinflussen die weitere Interpretation und Verarbeitung des Wikitextes.
Schutz vor benutzerdefinierten Änderungen und vor einigen intern ausgelösten Änderungen.

Im ersten Fall wird immer geschützt, während sonst schutzwürdige Bereiche nur dann abgetrennt und geschützt werden, wenn es späteren Bedarf dafür gibt.

Schutz von kodierten Abschnitten

Bereiche, in denen kodierte Informationen stehen, müssen übersprungen werden.

Reihenfolge und Identifizierung der Schutzbereiche
Beginn	Inhalt	Ende
`<!--` `<hiddentext>`	Kommentar	`-->` `</hiddentext>`
`<nowiki>`	Keine Wiki-Formatierung	`</nowiki>`
`<syntaxhighlight…>` `<source…>`	Syntaxhighlight	`</syntaxhighlight>` `</source>`
`<graph>` `<hiero>` `<imagemap>` `<inputbox>` `<math>` `<poem>` `<pre>` `<score>` `<templatedata>` `<timeline>`	Graph Hieroglyphen Verweissensitive Bilder Eingabefelder Math Poem festformatiert Notensatz TemplateData Zeitleisten	`</graph>` `</hiero>` `</imagemap>` `</inputbox>` `</math>` `</poem>` `</pre>` `</score>` `</templatedata>` `</timeline>`
Leerzeichen am Zeilenanfang	vorformatierter Text	Zeilenende (der letzten Zeile im Block)
`<code>`	Code	`</code>`
`<tt>`	Schreibmaschinenschrift	`</tt>`
`<dfn>` `<kbd>` `<samp>`	Code (bei `dfn` selten, aber denkbar)	`</dfn>` `</kbd>` `</samp>`

Im Zweifelsfall werden die Bereiche konservativ ausgelegt, also konservierend, bewahrend. Werden die Endmarkierungen nicht gefunden, weil der Text unzulässige Verschachtelungen (nesting) enthält, wird maximal ausgedehnt; notfalls bis zum Ende des gesamten Wikitextes.

Sortierschlüssel von Kategorien und der ganze Ausdruck SORTIERUNG sind immer gegen benutzerdefinierte Ersetzungen gesperrt.

Da im Ablauf zuerst die tags in standardisierte Form gebracht werden und erst anschließend die Schutzbereiche durch diese standardisierten tags gebildet werden, lassen sich abschreckende Beispiele für unübliche Code-Formatierungen von Wikisyntax oder gleichlautender ML nur mittels < bilden.^[1]

Schutz von Linkzielen

Beim Berichtigen von geänderten URL im Web und zum Anpassen von Wikilinks (jetzt auf BKL, umbenannte Lemmata) ist es sinnvoll, Linkziele im begründeten Einzelfall zu verändern. Diese Zeichenfolgen müssen aber vor Rechtschreibkorrekturen und typografischen Verfeinerungen geschützt werden.

Identifizierung der Linkzielbereiche
Beginn	Inhalt	Ende
nach `[[`	Wikilink (intern / extern) einschließlich `[[Datei:` (nur das Linkziel)	vor `\|` oder vor `]` oder Zeilenende
nach`[` bei `[//` `[http://` `[https://` `[ftp://`	URL	vor `]` oder vor Leerzeichen oder Zeilenende
`http://` `https://` `ftp://`	URL	eines von `< \| >` oder Leerzeichen oder Zeilenende^[2]
Zeilenbeginn oder Leerzeichen vor `Datei:` bzw. Dateiname	Innerhalb von `<gallery…>`	`\|` oder Zeilenende
nach `{{`	Vorlagen-Name	Letztes Nicht-Leerzeichen vor `\|` oder `}}` oder Zeilenende
Erstes Zeichen des Parameters nach `=`	Medienbezeichner in Vorlage^[3]	Letztes Zeichen der Datei-Extension vor `\|` oder `}}`

Die Syntaxelemente von Vorlageneinbindungen (Parameternamen mit | und =) sind meist ebenfalls gegen Veränderung geschützt, nicht aber die Parameterwerte.

Schutz von Text-Abschnitten

Vorstellbar wäre es, den Inhalt von Zitatvorlagen ähnlich der Linkziele gegen Rechtschreibkorrektur zu schützen.

Seit Sommer 2019 werden in der deutschsprachigen Wikipedia auch die Originaltexte in den Zitatvorlagen Vorlage:Zitat und Vorlage:" nebst der von ihnen abgeleiteten Varianten vor Veränderung geschützt.

Anmerkungen

↑ wie auch gerade eben beim Schreiben dieser Dokumentation erlebt
↑ Der Mediawiki-Parser interpretiert zurzeit ein Satzzeichen (wie .;),?) am Ende einer nicht in Klammern gesetzten URL als nicht zur URL gehörendes Satzzeichen, obwohl es sich nach HTTP um ein reguläres Zeichen als Bestandteil von URL handelt; dies müsste notfalls manuell aufgeklärt werden und ein Weblink gehört ohnedies in Klammern eingeschlossen. Die Weiterleitungsseite Faust. Der Tragödie zweiter Teil. endet mit Punkt, wird im Weblink vom Parser also nicht dem Lemma zugerechnet: https://de.wikipedia.org/wiki/Faust._Der_Trag%C3%B6die_zweiter_Teil. – es wird das Lemma direkt verlinkt.
↑ Parameterwerte, die auf eine „Datei-Extension“ (mit Punkt .) enden.
Dies sind zurzeit: avi css djvu doc flac gif jpeg jpg js mid mp3 odt og[agv] pdf png svg tiff? wav xcf xls xml (Groß- oder Kleinschreibung). Siehe auch wgFileExtensions.

[1] wie auch gerade eben beim Schreiben dieser Dokumentation erlebt

[2] Der Mediawiki-Parser interpretiert zurzeit ein Satzzeichen (wie .;),?) am Ende einer nicht in Klammern gesetzten URL als nicht zur URL gehörendes Satzzeichen, obwohl es sich nach HTTP um ein reguläres Zeichen als Bestandteil von URL handelt; dies müsste notfalls manuell aufgeklärt werden und ein Weblink gehört ohnedies in Klammern eingeschlossen. Die Weiterleitungsseite Faust. Der Tragödie zweiter Teil. endet mit Punkt, wird im Weblink vom Parser also nicht dem Lemma zugerechnet: https://de.wikipedia.org/wiki/Faust._Der_Trag%C3%B6die_zweiter_Teil. – es wird das Lemma direkt verlinkt.

[3] Parameterwerte, die auf eine „Datei-Extension“ (mit Punkt .) enden.
Dies sind zurzeit: avi css djvu doc flac gif jpeg jpg js mid mp3 odt og[agv] pdf png svg tiff? wav xcf xls xml (Groß- oder Kleinschreibung). Siehe auch wgFileExtensions.

[1]

[2]

[3]