Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/flow/selective

WikiSyntaxTextModSyntaxpolitur → 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:

  1. Verbergen vor der weiteren Analyse
    Kommentare, nowiki und syntaxhighlight
    Diese Bereiche beeinflussen die weitere Interpretation und Verarbeitung des Wikitextes.
  2. 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
BeginnInhaltEnde
<!--
<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 Zeilenanfangvorformatierter TextZeilenende
(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 &lt; 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
BeginnInhaltEnde
nach
[[
Wikilink (intern / extern)
einschließlich [[Datei:
(nur das Linkziel)
vor |
oder vor ]
oder Zeilenende
nach[ bei
[//
[http://
[https://
[ftp://
URLvor ]
oder vor Leerzeichen
oder Zeilenende
http://
https://
ftp://
eines von < | >
oder Leerzeichen
oder Zeilenende[2]
Zeilenbeginn oder Leerzeichen
vor Datei: bzw. Dateiname
Innerhalb von
<gallery…>
|
oder Zeilenende
nach
{{
Vorlagen-NameLetztes 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

  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.