Help:CirrusSearch/de

Aus MediaWiki
Zur Navigation springen Zur Suche springen
Diese Seite ist eine übersetzte Version der Seite Help:CirrusSearch und die Übersetzung ist zu 100 % abgeschlossen sowie aktuell.

Sprachen:
Bahasa Indonesia • ‎Basa Sunda • ‎Deutsch • ‎English • ‎Lëtzebuergesch • ‎Nederlands • ‎Tiếng Việt • ‎Türkçe • ‎Zazaki • ‎català • ‎español • ‎français • ‎italiano • ‎magyar • ‎occitan • ‎polski • ‎português • ‎português do Brasil • ‎shqip • ‎suomi • ‎svenska • ‎čeština • ‎Ελληνικά • ‎македонски • ‎русский • ‎українська • ‎ייִדיש • ‎עברית • ‎ئۇيغۇرچە • ‎العربية • ‎فارسی • ‎لۊری شومالی • ‎پښتو • ‎বাংলা • ‎தமிழ் • ‎తెలుగు • ‎ไทย • ‎中文 • ‎日本語 • ‎한국어

Der schnellste Weg, etwas in Wikimedia-Projekten zu finden, ist, gezielt danach zu suchen. Auf jeder Seite befindet sich dazu ein Suchfeld mit einem Lupensymbol.

CirrusSearch ist eine MediaWiki-Erweiterung, die die Elasticsearch nutzt, um verbesserte Suchfunktionalitäten gegenüber der Standard-MediaWiki-Suche zur Verfügung zu stellen. Die Wikimedia Foundation nutzt CirrusSearch für alle Wikimedia-Projekte. Sie weist wesentliche Verbesserungen gegenüber der alten Suchmaschine LuceneSearch auf. Diese Seite beschreibt die Funktionen von CirrusSearch. Falls deine Frage hier nicht beantwortet wird, stelle sie auf der Diskussionsseite. Jemand wird dir dann darauf antworten.

Für Informationen zur MediaWiki-Erweiterung siehe Extension:CirrusSearch.

Wie die Suche funktioniert

Man gibt Schlüsselwörter und Ausdrücke in das Suchfeld ein und drückt Enter oder Return oder klickt – je nachdem, was vorhanden ist – auf das Lupensymbol, die Such- oder die „Los“-Schaltfläche. Wenn eine Seite denselben Titel hat wie der Suchbegriff, wird man direkt auf diese Seite geführt. In den anderen Fällen werden alle Seiten des Wikis durchsucht, und es erscheint eine Liste mit den Artikeln, die zum Suchbegriff passen, oder eine Mitteilung, dass keine Seite den Suchbegriff enthält.

Wenn man die Schaltfläche für die Suche drückt, ohne etwas in das Suchfeld eingetragen zu haben, öffnet sich die Seite Special:Search (oder ein lokalisierte Version wie Spezial:Suche), die erweiterte Suchmöglichkeiten bietet (diese sind auch in jeder Liste mit Suchergebnissen verfügbar).

Es kann sinnvoll sein, die Suche auf Seiten innerhalb eines bestimmten Namensraumes zu beschränken, z. B. um nur auf Benutzerseiten zu suchen. Überprüfe die Namensräume, die für deine Suche benötigt werden.

Standardmäßig werden nur die Namensräume durchsucht, die in deinen Einstellungen aktiviert sind. Angemeldete Benutzer können ihre Einstellungen ändern, um die Namensräume, die standardmäßig durchsucht werden, nach ihren Wünschen zu ändern. Das ist möglich durch Aus- oder Abwählen der Checkboxen im Abschnitt Suche der Benutzereinstellungen.

Das Hinzufügen zusätzlicher Standard-Namensräume hat den Nebeneffekt, dass der Autovervollständigungs-Algorithmus vom Standardverhalten in einen etwas strengeren Modus geändert wird.

Was wurde verbessert?

Die neue Suchmaschine weist drei wesentliche Verbesserungen gegenüber der alten Suchmaschine auf, namentlich:

  • Bessere Unterstützung für Suchanfragen in unterschiedlichen Sprachen.
  • Schnellere Aktualisierungen für den Suchindex, d. h. Änderungen an Artikeln werden viel schneller in den Suchergebnissen sichtbar.
  • Expandieren von Vorlagen, d. h. der gesamte Vorlageninhalt von Artikeln wird in den Suchergebnissen angezeigt.

Wie oft wird der Suchindex aktualisiert?

Der Suchindex wird nahezu in Echtzeit aktualisiert. Seitenänderungen sollten unverzüglich in den Suchergebnissen erscheinen. Veränderungen an Vorlagen sollten in den Artikeln, die sie enthalten, innerhalb von Minuten wirksam werden. Da Veränderungen an Vorlagen in einer Warteliste abgearbeitet werden, kann die Performance variieren. Ein Null-Edit an dem Artikel wird die Veränderung erzwingen, dies sollte aber nicht nötig sein, solange alles normal verläuft.

Suchvorschläge

Die Vorschläge, die man in einem Dropdown-Menü erhält, wenn man etwas in das Suchfeld eingibt, sind grob nach Artikelqualität sortiert. Dazu werden die Zahl enthaltener Wikilinks auf jeder Seite, ihre Größe, die Menge an externen Links, die Anzahl der Überschriften und die Zahl der Weiterleitungen einbezogen. Suchvorschläge können übersprungen werden, Anfragen werden dann direkt zu den Suchergebnissen weitergeleitet. Dazu setzt man eine Tilde ~ vor die Suchanfrage. Beispiel ~Frida Kahlo. Die Suchvorschläge werden trotzdem noch erscheinen, aber durch Drücken der Eingabetaste kommt man wieder auf die Ergebnisseite. ASCII/Akzente/Diakritika sind für englische Texte aktiviert, doch es gibt beim Ergebnis ein paar Formatierungsprobleme. Siehe task T54656 in Phabricator.

Volltextsuche

Eine Volltextsuche ist eine indexbasierte Suche. Alle Seiten werden in der Wiki-Datenbank gespeichert und alle darin enthaltenen Wörter werden in der Datenbank der Suche gespeichert, die ein Index zum Volltext des Wikis ist. Jedes sichtbare Wort wird in der Liste der Seiten indiziert, in denen es gefunden wurde, daher ist die Suche nach einem Wort so schnell wie das Nachschlagen eines einzelnen Eintrags.[1] Weiterhin wird der Suchindex binnen Sekunden aktualisiert, falls Formulierungen geändert wurden.

Es gibt viele Indexe zum Volltext eines Wikis, um die vielen benötigten Arten von Suchen zu erleichtern. Der gesamte Wikitext wird mehrmals zu vielen speziellen Indexen indiziert, während jeder davon den Wikitext so ausliest, wie es gerade optimal ist. Beispiel-Indexe beinhalten:

  • Hilfstext, einschließlich Notizen, Unterschriften, Inhaltsverzeichnissen und alle Wikitexte, die mit dem HTML-Attribut class=searchaux versehen wurden.
  • Einleitungstext, der Wikitext zwischen dem Anfang der Seite und der ersten Überschrift.
  • Der Kategorientext indiziert die Auflistungen im unteren Bereich.
  • Vorlagen werden indiziert. Wenn sich auf Seiten einbezogene Worte einer Vorlage ändern, dann werden alle Seiten aktualisiert, die diese einbeziehen. (Das kann eine lange Zeit in Anspruch nehmen, abhängig von der Warteschleife.) Wenn die Untervorlagen von einer Vorlagenänderung betroffen sind, wird der Index aktualisiert.
  • Dokumenteninhalte, die im Datei-/Medien-Namensraum gespeichert sind, werden jetzt indiziert. Tausende von Formaten werden erkannt.

Es existiert Unterstützung für Dutzende Sprachen, aber erwünscht sind alle. Es gibt eine Liste der momentan unterstützten Sprachen unter elasticsearch.org; siehe Dokumentation für Unterstützer, um Anfragen oder Patches beizutragen.

CirrusSearch optimiert die Suchanfrage und führt sie aus. Die ausgegebenen Titel, jedes Mal 20 auf einmal, werden für die Suchergebnisseite nach Relevanz sortiert und stark nachbearbeitet. Beispielsweise werden Beispielausschnitte aus dem Artikel gesammelt und Suchbegriffe werden in Fettschrift hervorgehoben.

Suchergebnisse werden oft von verschiedenen einleitenden Mitteilungen begleitet. Diese können beinhalten: „Meinten Sie“ (Rechtschreibkorrektur), und, falls sonst keine Ergebnisse gefunden werden wurden, lautet die Ausgabe „Zeige Ergebnisse für“ (Korrektur der Anfrage) und „Suche stattdessen nach“ (deine Anfrage).

Suchmerkmale beinhalten auch:

  • Sortieren von Navigationsvorschlägen nach Anzahl der eintreffenden Links.
  • Beginnen mit dem Tilde-Zeichen ~, um Navigation und Vorschläge so zu deaktivieren, dass der Seitenrang beibehalten wird.
  • Smart-Matching von Zeichen durch Normalisierung (oder „Folding“) von Nicht-Keyboard-Zeichen zu Keyboard-Zeichen.
  • Wörter und Ausdrücke, die zutreffen, werden auf der Seite der Suchergebnisse in Fett hervorgehoben. Die Hervorhebung ist ein Analyse-Werkzeug nur für die Darstellung, zusätzlich zum Analyse-Werkzeug Suchindex, das die Seite eigentlich findet. Es kann sein, dass die Hervorhebung nicht immer zu 100% mit dem Suchbegriff übereinstimmt, vor allem für RegEx-Suchen. Die Hervorhebung kann genauer oder ungenauer sein als der Indexer.

Wörter, Ausdrücke und Modifikatoren

Der grundlegende Suchbegriff ist ein Wort oder ein "Ausdruck in Anführungszeichen" (Phrase). Die Suche erkennt ein Wort als:

  • ein Ziffernfolge.
  • eine Buchstabenfolge.
  • Unterwörter zwischen Übergängen von Buchstaben/Ziffern, wie z. B. in txt2regex.
  • Unterwörter innerhalb eines compoundName mithilfe von camelCase.

Ein Stoppwort ist ein Wort, das ignoriert wird (weil es häufig auftritt oder aus anderen Gründen).[2] Ein gegebener Suchbegriff stimmt mit dem „Inhalt“ überein (der auf der Seite angezeigt wird). Um stattdessen nach Übereinstimmungen mit dem Wikitext zu suchen, wird der Suchparameter insource benötigt (Siehe Abschnitt unten). Jeder Suchparameter hat seinen eigenen Index und interpretiert den gegebenen Begriff auf seine eigene Art.[3]

Abstände zwischen Wörtern, Ausdrücken, Parametern und Eingaben zu Parametern können großzügige Mengen an Leerzeichen und „Grauraum-Zeichen“ (greyspace characters) enthalten. Grauraum-/Greyspace-Zeichen sind alle nicht-alphanumerischen Zeichen ~!@#$%^&*()_+-={}|[]\:";'<>?,./. Eine gemischte Folge von Greyspace-Zeichen und Leerzeichen ist „Greyspace“ und wird wie eine große Wortgrenze behandelt. Indexe werden mit Greyspace gebildet und Anfragen werden interpretiert.[4]

Zwei Ausnahmen sind erstens, wo ein embedded:colon ein Wort ist (wenn es als Buchstabe behandelt wird), und zweitens, wo ein eingebettetes Komma , so wie in 1,2,3, wie eine Zahl behandelt wird. Greyspace-Zeichen werden sonst ignoriert, außer sie können aufgrund der Syntax einer Anfrage als modifizierende Zeichen interpretiert werden.

Die Modifikatoren sind ~ * \? - " ! . Je nach Platzierung in der Syntax können sie auf einen Begriff zutreffen, auf einen Parameter oder eine gesamte Anfrage. Wort- und Ausdrucksmodifikatoren sind Wildcard-, Verwandtschafts- und ungenaue Suchen. Jeder Parameter kann seine eigenen Modifikatoren haben, aber allgemein gilt:

  • Eine ungenaue Wort- oder Ausdrucksuche kann mit einem angehängten Tildezeichen ~ (und einer Zahl als Angabe des Grades) erfolgen.
  • Ein Tildezeichen ~, das einer Anfrage als Präfix vorangestellt wird, garantiert Suchergebnisse anstatt einer möglichen Navigation.
  • Ein Wildcard-Zeichen innerhalb eines Wortes kann ein (maskiertes) Fragezeichen \? sein für ein Zeichen oder ein Stern * für mehrere.
  • Die Wahrheitslogik kann AND und OR interpretieren, Parameter können das jedoch nicht.
  • Die Wahrheitslogik versteht - oder ! als Präfixe für einen Begriff, um die gewöhnliche Bedeutung des Begriffes von „Übereinstimmung“ zu „Ausschließen“ umzukehren.
Wörter, die mit - oder ! beginnen wie die englischen Beispiele -in-law oder !Kung, können exakt auf Titel oder Weiterleitungen passen, werden aber auch auf jede Seite passen, die das negierte Wort nicht enthält, was im Normalfall auf fast alle Seiten zutreffen sollte. Um nach solchen Begriffen zu suchen, nutze den Suchparameter insource (siehe entsprechenden Abschnitt unten).
  • Anführungszeichen kennzeichnen die Suche nach einem „genauen Ausdruck“. Bei Parametern werden sie auch benötigt, um Eingaben mit mehreren Wörtern zu abzugrenzen.
  • Stemming ist automatisch, kann aber durch die Benutzung eines „genauen Ausdrucks“ ausgeschaltet werden.
Die beiden Wildcard-Zeichen sind der Stern und das (maskierte) Fragezeichen und beide können in der Mitte oder am Ende eines Suchwortes stehen. Das maskierte Fragezeichen \? steht für ein Zeichen und der Stern * steht für eine beliebige Anzahl von Zeichen. Da viele Benutzer einfach eine Frage stellen, statt eine Suchanfrage zu verfassen, wird jedes Fragezeichen ignoriert, es sei denn, es wurde mit Absicht als \? maskiert in die Wildcard-Bedeutung gesetzt.

Eine Phrasensuche kann durch verschiedene Hinweise an die Suchmaschine ausgelöst werden. Jede Hinweismethode hat einen Nebeneffekt dahingehend, wie tolerant die Suche hinsichtlich Übereinstimmung mit der Wortsequenz sein wird. Bei greyspace, camelCase oder txt2number sind die Hinweise wie folgt:

  • Bei Eingabe von „words-joined_by_greyspace(characters)“ oder „wordsJoinedByCamelCaseCharacters“ wird „words joined bycharacters“ gefunden, in reiner Form oder in Form von Greyspace.
  • zu „txt2number“ wird eine Übereinstimmung mit „txt 2 number“ oder „txt-2.number“ gefunden.
  • Stoppwörter werden für Grenzen eines grey_space- oder camelCase-Ausdrucks aktiviert (an seinem Rand). Ein Beispiel im Englischen mit den Stoppwörtern the, of, und a ist die Übereinstimmung von „the_invisible_hand_of_a“ mit meetings invisible hand shake.

Die Mitteilung „Suche stattdessen nach“ wird ausgelöst, wenn ein allgemein unbekanntes Wort in einem Ausdruck ignoriert wird.

Jede der folgenden Arten des Ausdrucksabgleichs enthält und erweitert die Toleranzen der vorherigen:

  • Ein „genauer Ausdruck“ (exact phrase) "in Anführungszeichen" toleriert Greyspace (passt auf jedes Greyspace-Zeichen). Über "exact_phrase" oder "exact phrase" wird eine Übereinstimmung mit "exact]phrase" gefunden.
  • Ein Greyspace-Ausdruck (greyspace_phrase) initiiert Stemming und die Prüfung auf Stoppwörter.
  • Bei Eingabe von CamelCase wird zusätzlich camelcase gefunden (alles kleingeschrieben), weil CirrusSearch bei dieser Suche keinen Wert auf Groß- und Kleinschreibung legt.

Das Seitenbewertungssystem erlaubt es, bei einer Zweiwortsuche auf die Anführungszeichen zu verzichten. Ohne Anführungszeichen wird ein Wortpaarindex für die Ermittlung des Seitenrangs verwendet, zusätzlich werden die Wörter gefunden, wenn sie verteilt irgendwo auf einer Seite stehen.

Einige Parameter interpretieren Greyspace-Ausdrücke, dagegen interpretieren andere Parameter wie insource lediglich den normalen Ausdruck in Anführungszeichen.

In der Such-Terminologie bedeutet die Unterstützung von „Stemming“, dass eine Suche nach „schwimm“ auch „schwimmen“ und „schwimmt“ einschließt, aber nicht „schwamm“.
Suchausdruck parserfunction parserFunction parser function parser-function parser:function parSer:funcTion
parserfunction N N N N
"parser function" N N N N
parser_function N N N
parserFunction N N
"parser:function" N N N N
"parser_function" N N N N
"parSer_funcTion" N N N N
parSer_FuncTion N N

Bitte beachte, dass Groß- und Kleinschreibung bei Stemming keine Rolle spielt.

Beachte, wie die Suche nach einem „genauen Ausdruck“ (in Anführungszeichen) das embedded:colon-Zeichen (:) als Buchstabe interpretiert hat, aber nicht das embedded_underscore-Zeichen (_). Ein ähnlicher Fall tritt auf bei einem Komma innerhalb einer Zahl (,).

Bei Eingabe von in:this:word findet CirrusSearch im Kontext eines genauen Ausdrucks (der den Kontext des „insource“-Parameters beinhaltet) keine Übereinstimmung mit in, this oder word, sondern nur eine mit in:this:word.

Andernfalls sei daran erinnert, dass für CirrusSearch Wörter aus Buchstaben, Zahlen oder einer Kombination von beidem bestehen und Groß- und Kleinschreibung keine Rolle spielen.

Die normale Wortsuche benutzt Leerzeichen und ist agressiv mit Stemming, und wenn die gleichen Wörter mit Greyspace-Zeichen oder camelCase verbunden werden, sind sie agressiv mit Ausdrücken und Unterwörtern.

Wenn häufige Wörter wie „von“ oder „der“ in einem Greyspace-Ausdruck vorkommen, werden sie ignoriert, um eine bessere Übereinstimmung zu finden.

Ein wörtlicher Ausdruck mit greyspace, camelCase- oder txt2number-Begriff stimmt mit den angegebenen Wörtern gleichermaßen überein. Man kann jede dieser drei Formen benutzen.[5] Nun passt camelcase auch auf camelCase, weil die Suche nicht auf Groß- und Kleinschreibung achtet, aber camelCase passt auf camelcase, weil camelCase agressiver ist. Wie der Rest der Suche wird die Groß- und Kleinschreibung bei „Unterwörtern“ nicht beachtet. Im Vergleich dazu orientiert sich der „genaue Ausdruck“ am Greyspace und ignoriert Übergänge von Zahlen oder Buchstaben und Stemming. Ausdrücke mit Anführungszeichen achten nicht auf Groß- und Kleinschreibung.

Aus der Tabelle können wir annehmen, dass die grundlegende Suche parser_function -"parser function" die Summe aus den grundlegenden Suchen parserFunction und parser<stems> function<stems> darstellt.

Wenn man Anfragen mit Zahlen machen würde, käme es zu folgenden Ergebnissen:

  • Plan9 oder Plan_9 passt zu: plan9, plans 9, planned 9th, (planned) 9.2, "plans" (9:24)
  • "plan9" passt nur zu plan9 (ungeachtet von Groß- und Kleinschreibung)
  • Plan*9 passt zu plan9 oder planet4589.

Der Stern-Platzhalter * findet Abfolgen von Buchstaben und Ziffern innerhalb eines ausgegebenen Wortes, aber nie das Anfangszeichen. Ein oder mehr Zeichen, ein Teil des Wortes, muss vor dem *-Zeichen stehen.

  • Wenn der Teil zu Beginn nur aus Buchstaben besteht, wird der Abgleich auf eine Folge von (null oder mehr) Buchstaben begrenzt.
  • Wenn es sich nur um Zahlen handelt, wird der Abgleich auf eine Sequenz von (null oder mehr) Zahlen begrenzt, einschließlich Ordinalbuchstaben (st, nd, rd), Großbuchstaben, oder Zeitabkürzungen (am oder pm); und wird nur mit der Gesamtheit (beider Seiten) von Dezimalzahlen übereinstimmen.
  • Andernfalls wird das Komma als Teil einer Zahl gesehen, doch der Dezimalpunkt wird als Greyspace-Zeichen gesehen und trennt zwei Zahlen voneinander.
  • Innerhalb eines „genauen Ausdrucks“ stimmt er überein mit Stemming plus Komposita.

Die Wildcard \? stellt einen Buchstaben oder eine Zahl dar; *\? wird auch akzeptiert, aber \?* wird nicht erkannt.

Die Wildcards können für grundlegende Wort-, Ausdrucks- und Insource-Suchen genutzt werden und können auch eine Alternative zu (einigen) fortgeschrittenen Regex-Suchen sein (werden später noch behandelt).

Das Setzen einer Tilde ~ hinter ein Wort oder einen Ausdruck aktiviert eine ungenaue Suche.

  • Bei einem Ausdruck wird das als „Näherungssuche“ bezeichnet, weil benachbarte Wörter bis zu einer bestimmten Entfernung toleriert werden anders als bei einem „genauen Ausdruck“.
  • Beispielsweise stimmt "exact one two phrase"~2 überein mit exact phrase.
  • Bei einem Wort bedeutet das zusätzliche Buchstaben oder veränderte Buchstaben.
  • Bei einem Ausdruck verlangt eine ungenaue Suche eine ganze Zahl, die aussagt, wie viele zusätzliche Wörter hineinpassen dürfen, doch bei einem Wort kann eine ungenaue Suche eine gebrochen Zahl enthalten; der Standard ist word~0.5 (word~.5), mit dem in den meisten Fällen zwei Buchstaben gefunden werden können, die vertauscht, verändert oder hinzugefügt wurden, doch niemals die ersten beiden Buchstaben.
  • Bei einer Näherungssuche mit einem Ausdruck kann eine große Zahl benutzt werden, doch das ist eine „teure“ (langsame) Suche.
  • Bei einem Wort ist word~2 am ungenauesten (mit einer Bearbeitungsdistanz von 2, das ist der Standard) und word~1 ist am wenigsten ungenau; word~0 ist überhaupt nicht ungenau.
flowers algernon Flowers for Algernon flowers are for Algernon Flowers a1 2b 3c 4f 5j 6l 7j 8p q9 z10 for Algernon
"flowers algernon" Yes N N N
"flowers algernon"~0 Yes N N N
"flowers algernon"~1 Yes Yes N N
"flowers algernon"~2 Yes Yes Yes N
"flowers algernon"~11 Yes Yes Yes Yes
"algernon flowers"~1 N N N N
"algernon flowers"~2 Yes N N N
"algernon flowers"~3 Yes Yes N N
"algernon flowers"~4 Yes Yes Yes N
"algernon flowers"~13 Yes Yes Yes Yes

Damit der benötigte Näherungswert in umgekehrter Reihenfolge (von rechts nach links) übereinstimmt, zähle und verwerfe alle zusätzlichen Wörter, addiere dann zweimal die Summe der restlichen Wörter minus eins. (Mit anderen Worten, addiere das Doppelte der Anzahl der Segmente). Für den vollständigen Näherungsalgorithmus siehe Elasticsearch slop. Ein explizites AND wird zwischen zwei Ausdrücken benötigt, weil die beiden „inneren“ Anführungszeichen sonst verwechselt werden. Die Verwendung von Anführungszeichen deaktiviert Stemming, das Anhängen der Tilde ("but appending"~) reaktiviert Stemming.

flowers flower Flowers for Algernon flower for Algernon
flowers Yes Yes Yes Yes Stemming ist im Einsatz.
"flowers" Yes N Yes N Eine Näherungssuche deaktiviert Stemming.
"flowers"~ Yes Yes Yes Yes Näherung plus Stemming durch Anhängen einer Tilde.
"flowers for algernon" N N Yes N Eine Näherungssuche deaktiviert Stemming.
flowers for algernon"~ N N Yes Yes Näherung plus Stemming durch Anhängen einer Tilde.
"flowers algernon"~1 N N Yes N Eine Näherungssuche deaktiviert Stemming.
"flowers algernon"~1~ N N Yes Yes Näherung plus Stemming durch Anhängen einer Tilde.

Insource

1.24
Gerrit change 137733

Insource-Suchen können verwendet werden, um jedes „Wort“ zu finden, das auf einer Seite dargestellt wird, aber sie sind dafür entwickelt worden, jeden Ausdruck zu finden, den man finden möchte, – inklusive MediaWiki-Auszeichnungen. Dieser Ausdruck ignoriert vollkommen Greyspace: insource: "state state autocollapse" passt zu |state={{{state|autocollapse}}}.

insource: word
insource: "word1 word2"

Greyspace-Zeichen werden ignoriert, genau wie es bei Wortsuchen und Suchen nach genauen Ausdrücken geschieht.

insource:/regexp/
insource:/regexp/i

Dies sind reguläre Ausdrücke. Da sie nicht effizient sind, können nur einige wenige zeitgleich auf dem Such-Cluster erlaubt werden, trotzdem sind sie mächtig. Die Version mit dem Modifikator i ignoriert Groß-/Kleinschreibung im Ausdruck und ist sogar noch ineffizienter.

Insource ergänzt sich selbst. Auf der einen Seite ist es eine Volltextsuche, um sofort jedes Wort im Wikitext zu finden. Auf der anderen Seite kann es eine RegEx-Suche nach jeder Zeichenfolge ausführen.[6] RegEx/RegExp (regular expressions, reguläre Ausdrücke) scannen alle Textzeichen in einer vorgegebenen Seitenliste; sie besitzen keinen Wortindex, der die Suchgeschwindigkeit erhöhen würde, und der Prozess wird abgebrochen, wenn er länger als 20 Sekunden benötigt. RegEx laufen als letztes; um daher eine unnötige Zeichenebenen-Überprüfung einzuschränken, übergibt man ihnen eine Seitenliste (eine Suchdomain), die zuvor durch eine indexbasierte Suche ausgewählt wurde, welche als „Klausel“ (weitere Bedingung) zur Suche hinzugefügt wurde, und das macht man bei jeder einzelnen RegEx-Suche.[7]. Insource kann beides, und die bessere Variante anstelle von insource:/arg/ ist oft insource: arg, wobei arg bei beiden dasselbe ist.

Die Syntax für die RegEx-Suche ist insource: und dann /regexp/ ohne Leerzeichen dazwischen. (Kein anderer Parameter untersagt ein Leerzeichen. Alle Parameter außer insource:/regexp/ akzeptieren generös Leerzeichen nach ihrem Doppelpunkt.)

Die beiden Funktionen der Insource-Suche, indexbasierte und Regex-Suche, sind in vielerlei Hinsicht ähnlich:

  • Beide durchsuchen ausschließlich Wikitext.
  • Keine von beiden findet Ausdrücke, die durch Transklusion in den Text gelangt sind.
  • Keine macht Suchen mit Stemming, ungenaue und Näherungssuchen.
  • Beide wollen die wenigstens Ergebnisse, und beide arbeiten schneller, wenn man ihnen eine Suchbedingung hinzufügt.

Aber alle indexbasierten Suchen ignorieren Greyspace, und Wildcard-Suchen finden keinen Greyspace; daher sind RegEx-Suchen der einzige Weg, eine exakte Folge aller möglichen Zeichen zu finden, beispielsweise zwei aufeinander folgende Leerzeichen. RegEx sind eine völlig eigenständige Klasse eines Suchwerkzeugs, die die Suche nach einer einfachen Zeichenfolge (Zeichenliteral) grundsätzlich einfach macht (grundlegende, einfache Verwendung) und die Suche mit Ausdrücken, die Metazeichen enthalten, auf dem Wiki ermöglichen (fortgeschrittene Verwendung). Siehe dazu unter Suche mit regulären Ausdrücken.

Der Parameter insource behandelt Wörter mit eingebettetem Doppelpunkt als ein Wort. Das wirkt sich aus bei Suchen nach Vorlagen, Parserfunktionen, URL, Wikilinks, HTML-Tags und Kommentaren.
Soweit möglich, sollte eine reine RegEx-Suche vermieden werden. Dazu, wie das immer möglich ist, siehe unten in Suche mit regulären Ausdrücken.
Um nach Wörtern zu suchen, die mit - oder ! beginnen wie wie die englischen Beispiele -in-law oder !Kung, nutze eine Suche mit insource gemeinsam mit einer einfachen Suche nach dem „blanken“ Begriff ohne Negierung (um eine reine Regex-Suche zu vermeiden), zum Beispiel "in-law" insource:/-in-law/i oder "kung" insource:/!kung/i.

Prefix und Namensraum

Ein Namensraum-Ausdruck dient der Suche, den anfänglichen Suchbereich anzugeben. Der Standard ist statt einer Suche im gesamten Wiki der Hauptnamensraum (in Wikipedias der Artikelnamensraum).

Nur ein Namensraum kann im einfachen Suchfeld angegeben werden. Das muss entweder der erste Ausdruck sein oder der letzte zusammen mit dem Parameter prefix.

Zwei oder mehr Namensräume können über den Abschnitt „Erweitert“ in der vollständigen Suchleiste gesucht werden, die auf jeder Seite mit Suchergebnissen oder über Special:Search (oder eine lokalisierte Version wie Spezial:Suche) verfügbar ist. Dein Suchbereich kann dort als Namensraum-Profil gespeichert werden, ohne in die Nutzereinstellungen zu gehen. Die Liste der Namensräume ist dann bei jeder zukünftigen Suche auf der ersten Seite zu finden, um den Suchbereich der Ergebnisse anzuzeigen. Um das wieder zurückzustellen, wähle den Standardnamensraum aus (angezeigt in runden Klammern), aktiviere „Auswahl für zukünftige Suchanfragen merken“ und führe eine Suche durch.

Die Suchleiste setzt einen Suchbereich und zeigt sie grafisch an. „Inhaltsseiten“ (Hauptnamensraum), „Multimedia“ (Dateien), „Alles“ (all: und file:), „Übersetzungen“ usw. sind Hyperlinks, die den jeweiligen Suchbereich aktivieren und dies anzeigen, indem sie inaktiv werden (Schrift wechselt Farbe). Einträge im Suchfeld überschreiben jedoch die Einstellungen der Suchleiste. Wenn ein Namensraum oder prefix: explizit angegeben ist, können die Angaben aus der Suchleiste irreführend sein. Die Suchleiste und das Suchfeld stellen daher nicht komplementäre (sich gegenseitig ausschließende) Methoden dar, den Suchbereich einzustellen.

Ein Namensraumausdruck überschreibt die Suchleiste, und ein prefix-Ausdruck überschreibt eine Namensraumangabe.

Gib einen Namensraum ein oder all: für alle Namensräume oder : für den Hauptnamensraum. „Alles“ beinhaltet nicht den Dateinamensraum. „Multimedia“ schließt Medieninhalte ein, die in Commons gespeichert sind, wie PDF, die alle indiziert und durchsuchbar sind. Im Dateinamensraum zeigt der Namensraummodifikator local: Wirkung, sonst wird er ignoriert. Namensraumaliasse werden akzeptiert.

talk: "Wind clock" Findet Seiten im Namensraum Talk (Diskussion), deren Titel oder Text den Ausdruck „wind clock“ enthält.
file: "Wind clock" Findet Seiten im Namensraum File (Datei), deren Titel, Text oder Medieninhalt den Ausdruck „wind clock“ enthält.
file: local: "Wind clock" Filtert Ergebnisse von Commons heraus (nur Ergebnisse aus dem lokalen Wiki werden angezeigt).
local: "Wind clock" Ignoriert. Durchsucht den Hauptnamensraum. local: wird ignoriert, wenn der Dateinamensraum nicht involviert ist.

Wie alle Suchparameter müssen local: und all: in Kleinbuchstaben geschrieben werden. Für die Namensraumbezeichnungen ist es dagegen egal.

Der Parameter prefix: passt auf jede Zahl von Startzeichen aller Seiten eines Namensraumes.[8] Wenn die ersten Zeichen auf einen Namensraum und einen Doppelpunkt passen, dann wird der Suchbereich geändert. Ist allein ein Namensraum angegeben, wird prefix auf alle seine Seitennamen passen. Ist nur ein Zeichen angegeben, darf es kein Bindestrich -, einfaches Anführungszeichen ' oder doppeltes Anführungszeichen " sein. Das letzte Zeichen darf kein Doppelpunkt sein. Bei Seitennamen, die passen, passen per Definition auch die Titel ihrer Unterseiten. Der Parameter prefix: erlaubt kein Leerzeichen vor einer Namensraumangabe, aber Leerraum vor einem Seitennamen.

prefix:cow Findet Seiten im Hauptnamensraum, deren Titel mit den drei Buchstaben „c o w“ beginnt.
domestic   prefix:cow Findet Seiten im Hauptnamensraum, deren Titel mit den drei Buchstaben „c o w“ beginnt und die das Wort „domestic“ enthalten.
domestic   prefix:cow/ Listet alle vorhandenen Unterseiten von „Cow“ auf, aber nur, wenn sie das Wort „domestic“ enthalten. Das ist eine sehr häufige Suchart, und sie erfolgt regelmäßig unter Verwendung des speziellen URL-Parameters prefix=.
domestic   prefix:Talk:cow/ Listet alle Unterseiten von „Talk:cow“ auf, aber nur, wenn sie das Wort „domestic“ enthalten.
1967   prefix:Pink Floyd/ Listet alle Unterseiten von „Pink Floyd“ auf, aber nur, wenn sie die Folge „1967“ enthalten.

Der Parameter prefix steht am Ende, damit die Zeichen für die Seitennamen doppelte Anführungszeichen " enthalten können.

Die Erweiterung Extension:Translate erschafft eine Art von „Sprachnamensraum“ für übersetzte Versionen einer Seite (wie dieser hier). Aber anders als die Angabe von Namensraum oder prefix, die den anfänglichen Suchbereich erzeugen, ist der Parameter inlanguage ein Filter dafür (siehe nächsten Abschnitt).

Inhalt aus dem Suchindex ausschließen

Inhalt kann aus dem Suchindex ausgeschlossen werden, indem man in einen DIV-Bereich mit der Klasse class="navigation-not-searchable" einschließt. das weist CirrusSearch an, diesen Inhalt nicht in den Suchindex aufzunehmen (siehe task T162905 für weiteren Kontext).

Zusätzlich kann Inhalt als Zusatzinformation markiert werden, indem man die Klasse class="searchaux" verwendet. Das weist CirrusSearch an, den Inhalt vom Haupttext in ein Hilfsfeld zu verschieben, das geringere Wichtung für Suche und Markierung in Suchausschnitten besitzt. Diese Textauszeichnung wird verwendet für Elemente wie Beschreibungen von Vorschaubildern, Siehe-auch-Abschnitten usw.

Filter

Ein Filter darf mehrmals auftreten, auch negiert; er darf auch allein auftreten, um einen Suchbereich zu filtern. Eine Suche wird aus Begriffen gebildet, die einen Suchbereich filtern. Ein Namensraum- oder prefix-Ausdruck ist kein Filter, denn ein Namensraum allein wird keine Ergebnisse liefern und prefix kann nicht negiert werden.

Das Hinzufügen eines zusätzlichen Wortes, Ausdrucks oder Parameters bewirkt eine weitere Filterung. Ein hochpräzises Suchergebnis kann sehr viele Positiv-/Negativfilter enthalten, wenn jede relevante Seite in den Ergebnissen aufgeführt wird (in diesem Fall ist das Ranking stark irrelevant). Die Filterung reagiert empfindlich auf die Ergänzung von RegEx-Ausdrücken; man sollte möglichst wenige Seiten übrig haben, bevor RegEx angewendet wird (denn dieses kann auf keinen vorbereiteten Index für seine Suche zurückgreifen).

Die folgenden Suchparameter sind Filter.

Insource (oben behandelt) ist ebenfalls ein Filter, aber insource:/regexp/ ist es nicht. Filter und alle anderen Suchparameter müssen in Kleinbuchstaben angegeben werden (mit Ausnahme von Namensraumangaben; bei ihnen ist das egal).

Intitle und incategory

Wort und Ausdruckssuche passen auf Seitentitel und auf die Kategorien, die am unteren Ende der Seite eingetragen sind. Mit diesen Parametern aber kann man ausschließlich nach Seitentiteln suchen oder eine Kategoriesuche allein durchführen.

  • cow*
    • Finde Artikel, deren Titel oder Text Wörter enthält, die mit „cow“ beginnen.
  • intitle:foo
    • Findet Artikel, deren Titel „foo“ enthält. Stemming für „foo“ ist aktiviert (auch „food“ und „fool“ werden gefunden).
  • intitle:"fine line"
    • Findet Artikel, deren Titel „fine line“ enthält. Stemming ist deaktiviert („fine lines“ wird nicht gefunden).
  • intitle:foo bar
    • Findet Artikel, deren Titel „foo“ enthält und deren Titel oder Text „bar“ enthält.
  • -intitle:foo bar
    • Findet Artikel, deren Titel nicht „foo“ enthält und deren Titel oder Text „bar“ enthält.
  • incategory:Music
    • Findet Artikel aus „Category:Music“ („Category“ eventuell lokalisiert zu „Kategorie“).
  • incategory:"music history"
    • Findet Artikel aus „Category:Music_history“.
  • incategory:"musicals" incategory:"1920"
    • Findet Artikel, die sich sowohl in „Category:Musicals“ als auch in „Category:1920“ befinden.
  • -incategory:"musicals" incategory:"1920"
    • Findet Artikel, die nicht in „Category:Musicals“ enthalten sind, aber in „Category:1920“.

intitle und incategory sind alte Suchparameter. Incategory führt keine automatische Suche in einer Unterkategorie mehr durch, man kann dafür aber vielfach weitere Kategorienamen manuell hinzufügen.

Deepcategory

Eine tiefe Kategoriesuche erlaubt es, eine Kategorie und ihre Unterkategorien zu durchsuchen. Die Tiefe des Baumes ist momentan begrenzt auf 5 Ebenen (konfigurierbar), und die Anzahl an Kategorien ist begrenzt auf 256 (konfigurierbar). Die Tiefensuche verwendet den SPARQL-Kategorienservice von WDQS. Die Filter-Schlüsselwörter heißen deepcategory oder deepcat. Beispiel:

  • deepcat:"musicals"
    • Finde Artikel, die sich in „Category:Musicals“ oder einer der Unterkategorien befinden („Category“ eventuell lokalisiert zu „Kategorie“).

Schon früher wurde der Filter mit Hilfe eines Gadgets (Helferleines) implementiert: Um Zugriff auf den Suchparameter „deepcat“ zu erhalten und so automatisch bis zu 70 Unterkategorien bei incategory zu ergänzen (in der Form „incategory:category1|category2|...|category70“), kann man eine Zeile in sein Benutzerscript eintragen (siehe auch de:Hilfe:Suche/Deepcat).[9]

Linksto

Linksto findet Wikilinks zu einem vorgegebenen Namen, nicht Inhalt. Der vollständige Seitenname muss eingegeben werden, auf Groß- und Kleinschreibung ist zu achten; die Eingabe muss auf den gesamten Titel der Seite passen ohne Anzeige-Modifikationen, wie sie durch {{DISPLAYTITLE:…}} (lokalisiert {{SEITENTITEL:…}}) erfolgen können (sie muss auf {{FULLPAGENAME}} passen, für die aktuelle Seite wäre das „Help:CirrusSearch/de“).

linksto findet keine Weiterleitungen (Redirects). Es findet nur [[Wikilinks]], selbst wenn diese durch eine Vorlage erzeugt wurden. Es findet keine Links, die durch einen URL erzeugt wurden, selbst wenn es ein Link zu einer internen Wikimedia-Seite ist.

Eingaben, um alle Links auf eine Seite Help:Cirrus Search zu finden, wenn Help:Searching und H:S Weiterleitungen auf diese Seite sind:

  1. linksto: "Help:Cirrus Search"
  2. linksto: Help:Searching
  3. linksto: H:S

CirrusSearch -linksto: Help:CirrusSearch findet Artikel, die „CirrusSearch“ erwähnen, aber nicht in einem Wikilink.

Hastemplate

Die Einbindung von Vorlagen kann mit hastemplate: template herausgefunden werden. Die Eingabe des kanonischen Namens findet alle Vorkommen, die Eingabe des Namens einer Weiterleitung findet jedoch nur diese Variante. Namensraumaliasse sind erlaubt, Groß- und Kleinschreibung spielt keine Rolle und Weiterleitungen werden gefunden. (Zum Vergleich: boost-template – kein Standardnamensraum; linksto – keine Namensraumaliasse, beachtet Groß-/Kleinschreibung, keine Weiterleitungen; intitle – keine Weiterleitungen.)

Hastemplate findet auch sekundäre Verwendungen auf einer Seite (Meta-Verwendung): Es durchsucht die Seiten nach vollständiger Ersetzung. Dahinter steht dieselbe Philosophie wie, Wörter und Ausdrücke aus einer Vorlage zu erhalten, aber hier steht es für „Vorlage in Vorlage“. Die Seite wird in den Inhaltsergebnissen aufgelistet, obwohl der Inhalt (die Vorlage) im Wikitext nicht zu sehen ist.

  • hastemplate: "quality image" findet die Verwendung von „Template:Quality image“ („Template“ eventuell lokalisiert zu „Vorlage“) im Standardsuchbereich (voreingestellte Namensräume).
  • : hastemplate: portal:contents/tocnavbar findet Hauptnamensraum-Verwendungen des aus dem Portal-Namensraum stammenden „Contents/TOCnavbar“.

Wenn die Erweiterung Extension:Translate installiert ist, werden hastemplate-Suchen negativ beeinflusst, wann immer die Vorlage Template:Translatable template name (oder eine ihrer Kurzformen) den Vorlagennamen einer übersetzbaren Vorlage lokalisiert. Für diese Fälle muss man die Suche mit insource einsetzen.

Inlanguage

Wenn die Erweiterung Extension:Translate installiert ist, ist der Parameter inlanguage wichtig, um hochpräzise Suchergebnisse zu erhalten.

inlanguage: Sprachencode

wird nur Suchergebnisse in dieser Sprache anzeigen.

Beispiele:

  • um alle japanischen Seiten in einem Wiki zu zählen:
all: inlanguage: ja
  • um deutsche und spanische Seiten aus dem Hilfe-Namensraum herauszufiltern (nicht anzuzeigen):
help: -inlanguage: de -inlanguage: es
  • um Übersetzungen zu ignorieren, wenn Englisch die grundlegende Sprache auf dem Wiki ist:
inlanguage:en

Contentmodel

Der Filter contentmodel: erlaubt es, die Suche auf Seiten mit spezifischem Inhalt (englischer Begriff Content Model) zu begrenzen. Für mögliche Werte vgl. Content handlers/de. Zum Beispiel:

  • Um ausschließlich JSON-Seiten zu finden:
contentmodel:json

subpageof

Um Unterseiten zu finden.

subpageof: Elternseite

Zum Beispiel:

  • Alle Unterseiten von „CirrusSearch“ finden.
subpageof:CirrusSearch
  • Verwende doppelte Anführungszeichen, wenn die übergeordnete Seite Leerzeichen enthält.
subpageof:"Requests for comment"

Beachte: Anders als bei prefix: darf in die Sucheingabe hinter dem Schlüsselwort der Namensraum der Seite nicht eingefügt werden. Wenn die Suche nach Unterseiten auf einen bestimmten Namensraum eingeschränkt werden soll, dann nutze den Namensraumfilter.

Seitengewichtung

Die Gewichtung ermittelt Ausschnitt, Vorschläge und Seitenrelevanz. Das normale Gewicht ist 1. Zusätzliche Gewichtung erfolgt durch Multiplikatoren.

Wenn die Suche nur aus Wörtern besteht, erhalten Seiten, die darauf passen, eine höhere Bewertung. Fügt man explizit irgendeinen Ausdruck zur Suche hinzu (in Anführungszeichen "), wird ebenso wie bei bestimmten anderen Ergänzungen dieses Verhalten „bevorzuge den Ausdruck“ nicht angewendet.

Morelike

  • morelike:page name 1|page name 2|...|page name n
    • Findet Artikel, deren Text dem der angegebenen Artikel am ähnlichsten ist.
  • morelike:wasp|bee|ant
    • Findet Artikel über stechende Insekten („wasp”: Wespe; „bee“: Biene; „ant“: Ameise).
  • morelike:template:search|template:regex|template:usage
    • Findet Templates/Vorlagen über die RegEx-Suche nach Vorlagenverwendungen im Wiki.

Die morelike:-Suche arbeitet in der Weise, dass ein Set an Wörtern der vorgegebenen Artikel ausgewählt wird und dann eine Suche mit dieser Wortauswahl durchgeführt wird. Man kann die Funktionsweise beeinflussen, indem man zum URL der Suchergebnisse (nur dort) folgende Parameter hinzufügt:

  • cirrusMltMinDocFreq – Minimalanzahl an Dokumenten, die einen Suchbegriff enthalten müssen, damit er berücksichtigt wird.
  • cirrusMltMaxDocFreq – Maximalanzahl an Dokumenten, die einen Suchbegriff enthalten müssen, damit er berücksichtigt wird.
  • cirrusMltMaxQueryTerms – Maximalzahl an Begriffen, die berücksichtigt werden.
  • cirrusMltMinTermFreq – Angabe, wie häufig ein Begriff mindestens in den vorgegebenen Artikeln vorkommen muss, damit er berücksichtigt wird. Bei kleinen Feldern (title) sollte der Wert 1 sein.
  • cirrusMltMinWordLength – Minimale Wortlänge eines Begriffs, damit er berücksichtigt wird. Der Standard ist 0.
  • cirrusMltMaxWordLength – Maximale Wortlänge, über der Wörter ignoriert werden, standardmäßig 0 (unbegrenzt).
  • cirrusMltFields - Die Felder, die verwendet werden können, als kommaseparierte Werteliste. Erlaubt sind title, text, auxiliary_text, opening_text, headings und all.
  • cirrusMltUseFieldstrue: Nutze ausschließlich die Felddaten. Standard ist false: Das System extrahiert den Inhalt des Feldes text, um die Suche zusammenzustellen.
  • cirrusMltPercentTermsToMatch – Der Prozentwert an Begriffen, die passen müssen. Der Standard ist 0.3 (30 %).
  • Beispiel: &cirrusMtlUseFields=yes&cirrusMltFields=title&cirrusMltMinTermFreq=1&cirrusMltMinDocFreq=1&cirrusMltMinWordLength=2

Diese Einstellungen können dauerhaft gespeichert werden durch Überschreiben von cirrussearch-morelikethis-settings in den Systemmitteilungen.

Prefer-recent

Wird irgendwo in der Suchanfrage prefer-recent: eingefügt, werden jüngst bearbeitete Artikel etwas höher bewertet, als es die Regeln für die Seitenrangermittlung sonst vorgeben.

Standardmäßig wird die Bewertung um 60 % in einem 160-Tage-Fenster erhöht, was in das Suchfeld als prefer-recent:0.6,160. eingegeben werden könnte. Dieser Wert passt gut zu anderen Regeln für die Seitenbewertung und ist für die meisten Suchen gedacht.

Die Regeln kann man manipulieren mit prefer-recent:boost,recent. Technisch gesehen ist boost der Anteil der Bewertung, um den sie erhöht werden soll, und recent ist die Halbwertszeit in Tagen. boost ist mehr als ein gewöhnlicher Multiplikand, die Verstärkung ist exponentiell. Der Faktor, der im Exponenten verwendet wird, ist die Zeit seit der letzten Bearbeitung.

Zum Beispiel:

prefer-recent:,7

Seiten, die älter als 7 Tage sind, werden nur halb so hoch bewertet, und Seiten, die älter als 14 Tage sind, noch einmal halb so hoch usw.

Für eine simple Sortierung nach Datum in hochpräzisen Suchergebnissen, in denen Seitenrang und Höhe der Bewertung relativ unwichtig sind, erhöhe einfach die gesamte Bewertung:

  • prefer-recent:1,7 (weeks)
  • prefer-recent:1,1 (days)
  • prefer-recent:1,0.0007 (minutes)
  • prefer-recent:1,0.0001 (8.64 seconds)
  • prefer-recent:1,0.00001 (seconds)

Boost-templates

Man kann Seiten darauf basierend höher bewerten lassen, welche Vorlagen sie enthalten. Das kann direkt in der Sucheingabe erfolgen mit boost-templates:"" oder durch den System­mitteilungs­parameter MediaWiki:cirrussearch-boost-templates. Eine Suche mit boost-templates:"" überschreibt die Inhalte von cirrussearch-boost-templates. Die Syntax ist ein wenig ungewöhnlich, wurde aber so gewählt, damit sie möglichst einfach ist. Einige Beispiele:

File:boost-templates:"Template:Quality Image|200%" incategory:china
Findet Dateien in der Kategorie „China“, und Qualitätsbilder werden dabei an den Anfang einsortiert.
File:boost-templates:"Template:Quality Image|200% Template:Low Quality|50%" incategory:china
Findet Dateien in der Kategorie „China“, wobei Qualitätsbilder an den Anfang und Bilder in schlechter Qualität an das Ende einsortiert werden.
File:boost-templates:"Template:Quality Image|200% Template:Low Quality|50%" popcorn
Findet Dateien über Popcorn, wobei Qualitätsbilder an den Anfang und Bilder in schlechter Qualität an das Ende einsortiert werden. Bei Nutzung der Systemnachricht cirrussearch-boost-templates könnte die Eingabe im Suchfeld auf popcorn allein reduziert werden.

Keine Dezimalpunkte (oder Kommata) bei den Prozentangaben einfügen. Sie sind wirkungslos und der Bewertungsprozess des Suchsystems funktioniert so, dass es unwahrscheinlich ist, dass solche Angaben auf irgendetwas passen.

Eine Warnung zu cirrussearch-boost-templates: Werden sehr, wirklich sehr große oder kleine Prozentwerte verwendet, schwächen sie massiv das gesamte Bewertungssystem. Wenn beispielsweise im Enwiki Qualitätsartikel mit 1 Mio. Prozent Verstärkung bewertet würden, würden bei einer Suche nach Begriffen, die zufällig in Qualitätsartikeln vorkommen, diese vor allen Suchergebnissen einsortiert werden, deren Titel exakt auf die Suchbegriffe passen. Die Suche nach Ausdrücken wäre genauso betroffen, eine Suche nach brave new world würde daher eher einen Qualitätsartikel finden, in dem die drei Wörter verteilt einzeln vorkommen, als das exakte Ergebnis Brave New World.

Suche mit regulären Ausdrücken

Eine einfache indexbasierte Suche findet Wörter, die sichtbar auf einer Seite dargestellt werden. Silbentrennung, Satzzeichen und Klammern, Schrägstriche und andere mathematische oder Computersymbole stellen für Wörter nur Wortgrenzen dar. Es ist nicht möglich, sie in eine indexbasierte Suche einzufügen.

Man findet sie sehr viel schneller, wenn man eine RegEx-Suche an eine indexbasierte Suche anfügt.

Warnung: Keine reine Regex-Suche insource:/regexp/ durchführen. Sie wird wahrscheinlich nach 20 Sekunden abgebrochen werden, währenddessen sie die Suche anderer, verantwortungsbewusster Nutzer blockiert.

Eine RegEx-Suche nach einer exakten Folge ist eine einfache Suche; man setzt einfach den gesamten regulären Ausdruck in Anführungszeichen oder maskiert alle nicht-alphanumerischen Zeichen mit einem Backslash \. Alle RegEx-Suchen benötigen einen Suchbereich, der vom Nutzer mit einem einfachen Filter vorgegeben werden muss:

  • insource:"debian.reproducible.net" insource:/debian\.reproducible\.net/
  • insource:"c:\program files (x86)" insource:/C\:\\Program Files \(x86\)/i
  • insource:"<tag>{{template}}<tag>" insource:/"<tag>{{template}}<\/tag>"/
  • insource:"[[title|link label]]'s" insource:/"[[title|link label]]'s"/
  • insource:/regexp/ prefix:{{FULLPAGENAME}}

Das letzte Beispiel funktioniert von einem Link aus (zum Beispiel in der Bearbeitungsvorschau), aber wegen {{FULLPAGENAME}} nicht im Suchfeld.

Zum Beispiel: [[Special:Search/insource:/regex/ prefix:{{FULLPAGENAME}}]] findet den Begriff regex auf der aktuellen Seite, und zwar nur in Kleinschreibung.

Eine Suche ohne Angabe von Namensraum oder prefix durchsucht den Standardsuchbereich (einstellbar auf jeder Suchergebnisseite, d. h. in Special:Search oder einer lokalisierten Version wie de:Spezial:Suche). Manche Nutzer verwenden als Standard „Alle Namensräume“, also das gesamte Wiki. In einem großen Wiki wird das bei einer reinen Regex-Suche vermutlich fehlschlagen, da es zu einem HTML-Timeout führt, bevor die Suche abgeschlossen ist.

Eine RegEx-Suche durchsucht buchstäblich Zeichen für Zeichen auf jeder Seite des aktiven Suchbereichs. Eine indexbasierte Suche dagegen sucht in Wirklichkeit nur einige Einträge in einer Datenbank (dem Index), die getrennt ist von der Wiki-Datenbank, was nahezu Echtzeitergebnisse ermöglicht. Wird also eine Suche mit insource:// (irgendein RegExp) durchgeführt, so sollte eine weitere Suchfolge ergänzt werden, die den Bereich der RegEx-Suche so weit wie möglich eingrenzt. Es gibt mehrere Suchparameter, die einen Index benutzen und deshalb sofort einen genaueren Suchbereich für /regexp/ ermöglichen. das sind in Reihenfolge absteigender Effektivität:

  • insource:"" mit Anführungszeichen; den regulären Ausdruck ohne Maskierungszeichen zu wiederholen ist ideal.
  • intitle:, incategory: und linksto: sind exzellente Filter.
  • hastemplate: ist ein sehr guter Filter.
  • "Wort1 Wort2 Wort3", mit Anführungszeichen oder ohne, sind gut.
  • <Namensraum>: ist praktisch nutzlos, kann aber bewirken, dass eine langsame RegEx-Suche abgeschlossen wird.

Um eine reine RegEx-Suchfolge zu testen, kann man eine (Benutzer-)Seite anlegen mit Testmustern und dann diese Seite zusätzlich in der Suche mit dem Parameter prefix vollständig angeben. Die Zeichenfolge, die auf den Ausdrck passt, wird im Suchergebnis hervorgehoben. Es werden diese Seite (in der Datenbank) und ihre Unterseiten durchsucht, sofern vorhanden.

Suchparameter, die die Effizienz einer RegEx-Suche nicht erhöhen, sind die Operatoren, die die Bewertung einer Seite beeinflussen: morelike, boost-template und prefer-recent.

Metazeichen

Dieser Abschnitt behandelt, wie man Metazeichen (meta characters) maskiert, die in RegEx-Suchen Verwendung finden. Dazu, welche spezielle Bedeutung die Metazeichen besitzen, siehe in Regular expression syntax (englisch) oder in Hilfe:Suche/insource, RegExp – regulärer Ausdruck (Hilfe in der deutschen Wikipedia). [10]

Die Verwendung einer exakten Folge verlangt einen RegEx, aber der RegEx-Suchausdruck bringt die Suche dazu, sich selbst zu beschränken (Abbruch nach 20 Sekunden). Einen RegEx-Suchausdruck immer hinzufügen, niemals eine reine RegEx-Suche durchführen. Zuvor eine einfache Suche durchführen und die Anzahl der Suchergebnisse beachten, bevor ein exakter Suchausdruck eingegeben wird. Die Suche mit einem exakten Ausdruck erfordert einen gefilterten Suchbereich.

Zum Beispiel:

  • Um einen Namensraum zu durchsuchen, misst man die Anzahl der Seiten mit einem einzelnen Suchbegriff, der aus dem Namensraum besteht. Das wird die Zahl der Seiten in diesem Namensraum auflisten.
  • Um wiederzufinden, was man eventuell gesehen hat, wie etwa „Wiki-Link“ oder „(Trans[In]klusion)“, mit einem Namensraum und insource-Filtern beginnen.

Präzisierung mit einem exakten Suchausdruck

  • Um den laufenden Suchprozess zu verfeinern, damit man das findet, was man eigentlich sehen will, wie „2 + 2 = 4“ oder „"site".org“, sind RegEx-Ausdrücke gewöhnlich das Beste, denn man kann sie als einen einzelnen RegEx-Suchausdruck hinzufügen, die begrenzte Zahl an Seiten, die das Suchsystem durchsuchen muss, kann gesehen werden.

Man kann eine Suche nach einer exakten Zeichenfolge starten, sollte aber immer daran denken:

  • Die Suche mit RegEx durchsucht nur Wikitext, nicht den Text, wie er angezeigt wird, daher sind ein paar Unterschiede in Bezug auf die Textauszeichnung zu beachten, sogar die Zahl der Leerzeichen muss in der Suchanfrage genau übereinstimmen.
  • Die Angabe eines begleitenden Filters ist verpflichtend.
  • Man muss wissen, wie man RegEx-Metazeichen maskiert.

Es gibt zwei Möglichkeiten, Metazeichen zu maskieren. Beide haben ihre Berechtigung und können gelegentlich gemeinsam eingesetzt werden.

  • Ein Backslash \ maskiert ein einzelnes Zeichen. Die RegEx-Suche nutzt Schrägstriche, um den RegEx-Ausdruck zu begrenzen (insource:/regexp/). Eine Eingabe von /reg/exp/ ist mehrdeutig, deshalb muss man dies als /reg\/exp/ schreiben.
  • Eine ganze Zeichenfolge kann in doppelte Anführungszeichen gesetzt werden ("regexp"). Die Maskierung eines Zeichens tut nicht weh, deshalb kann man darin jedes Zeichen maskieren gemeinsam mit jedem potentiellen Metazeichen. Die Maskierung mit Anführungszeichen ist sauberer (besser zu lesen).
  • Man kann nicht beide Methoden vermischen, aber sie zugleich nebeneinander einsetzen.

Die Maskierung mit doppelten Anführungszeichen (insource:/"regexp"/) ist eine einfache Möglichkeit, nach vielen Arten von Folgen zu suchen, aber innerhalb des Ausdruck kann keine Maskierung mit Backslash erfolgen.

  • /"[[page/name|{{temp-late"/ anstelle von /\[\[page\/name\|\{\{temp\-late/.
  • /"literal back\slash"/ ist genau so gut wie /literal back\/slash/.
  • Aber das funktioniert nie: /"This \" fails"/.
  • Und das hängt davon ab, was bezweckt war: /"This \/ depends"/. Es findet \/, wenn es genau so im Wikitext steht, was in den wenigsten Fällen das Ziel sein dürfte, sondern eher eine Suche nach /.

Die Backslash-Maskierung (insource:/regexp/) erlaubt die Maskierung von " und /, macht es aber nötig, die anderen Metazeichen gleichfalls zu maskieren:

  • Um einen Schrägstrich / zu finden, verwende \/.
  • Um das doppelte (ASCII-)Anführungszeichen " zu finden, verwende \".
  • Die maskierten Metazeichen sind: \~\@\#\&\*\(\)\-\+\{\}\[\]\|\<\>\?\.\\.
  • Der äquivalente Ausdruck mit Maskierung durch doppelte Anführungszeichen ist "~@#&*()-+{}[]|\<>?.\".

Der einfachste Algorithmus, einen grundlegenden RegEx-Suchausdruck insource:/"regexp"/ zu erzeugen, bei dem man die anderen Metazeichen nicht beachten muss, sondern nur " und /:

  1. Schreibe die Folge auf: the/str"ing (die äußere Begrenzung /"…"/ nicht vergessen, sie wird hier nur nicht dargestellt, weil sie auf keinen Fall geändert werden darf).
  2. Ersetze " mit "\"" (Maskierung des Anführungszeichens mit Backslash, Anführungszeichen drumherum).
  3. Ersetze / mit "\/" (Maskierung des Schrägstrichs mit Backslash, Anführungszeichen drumherum).
  4. Man erhält folgenden Ausdruck (jetzt mit äußerer Begrenzung): insource:/"the"\/"str"\""ing"/, was die gemeinsame Verwendung beider Maskierungsmethoden nebeneinander zeigt (drei Teilfolgen in Anführungszeichen, dazwischen zwei mit Backslash maskierte Einzelzeichen).
Während der Verfeinerung der Suche beachten, dass der Wikitext des Ausschnitts auf der Seite der Suchergebnisse eine geänderte Leerraumdarstellung besitzt. RegEx reagieren empfindlich auf geänderten Leerraum, daher ist es gefährlich, Text von diesen Ausschnitten zu kopieren.

Die Notation in eckigen Klammern, um eigene Zeichenklassen zu erzeugen, maskiert Metazeichen darin ebenfalls. Soll eine schließende eckige Klammer selbst gefunden werden, muss sie darin aber mit Backslash maskiert werden, sonst würde sie als Abschluss der Zeichenklasse interpretiert werden. Die einzige Ausnahme ist, wenn sie als erstes Zeichen nach der öffnenden Klammer steht. Innerhalb der Begrenzung der Zeichenklasse durch die eckigen Klammern hat der einfache Strich - eine besondere Bedeutung (Angabe eines Intervalls), es sei denn, er wird (wie die schließende eckige Klammer) als erstes nach der öffnenden Klammer gesetzt oder mit Backslash maskiert. Zum Beispiel suchen beide folgenden Suchmuster nach einem Zeichen, das entweder ein Strich, eine schließende eckige Klammer oder ein Punkt ist: [-.\]] oder [].\-].

Allgemeine Beispiele mit Metazeichen:

  • insource:"2+2=4" insource:/"2+2=4"/ passt auf „2+2=4“, ohne Leerraum zwischen den Zeichen.
  • insource:"2 + 2 = 4" insource:/2 ?\+ ?2 ?= ?4\./passt auf kein oder ein Leerzeichen dazwischen. Das Gleichheitszeichen = ist kein Metazeichen, aber das Pluszeichen + ist eines.

Es sind einige Unterschiede zu beachten im Vergleich zu Standard-RegEx-Metazeichen:

\n und \r\n sind nicht dafür reserviert, auf einen Zeilenumbruch zu passen.

  • Der Punkt . steht für jedes Zeichen inklusive dem Zeichen für einen Zeilenumbruch (newline character), weshalb .* über Zeilenumbrüche hinweg passt.
  • Das Nummernzeichen # hat eine Bedeutung und muss maskiert werden.
  • ^ und $ werden nicht benötigt. So wie grep eine globale Suche je Zeile mit einem regulären Ausdruck und Anzeige der passenden Zeilen darstellt (global per line, regular expression, print each line), ist insource:/…/ eine globale Suche je Seite mit einem regulären Ausdruck und Anzeige der passenden Seiten in einer Ergebnisauflistung.
  • < und > bieten die Möglichkeit, einen mehrstelligen Zahlenbereich zu suchen, wie es auch mit [0-9] möglich ist, aber ohne auf die Zahl der Stellen zu achten oder auf den Intervall an jeder Position, daher funktioniert <9-10> und sogar <1-111>.

Ein fortgeschrittenes Beispiel

Will man beispielsweise unter Nutzung von Metazeichen die Verwendung einer Vorlage „Val“ ermitteln, die einen unbenannten Parameter besitzt mit einer drei- bis vierstelligen Zahl, die eventuell mit Leerzeichen von anderen Parametern abgetrennt ist, und auf derselben Seite in einem Vorkommen derselben Vorlage „Val“ ein benannter Parameter mit Wert fmt=commas vorkommt, ebenfalls eventuell mit Leerzeichen von anderen Zeichen abgetrennt (es kann, aber muss nicht, dasselbe Vorkommen der Vorlage auf der Seite sein):

hastemplate:val insource:"fmt commas" insource:/\{\{val\|[^}]*fmt *= *commas/ insource:/\{val\| *[-+]?[0-9]{3,4} *[|}]/

Beachte, dass das Gleichheitszeichen in insource:"fmt commas" nicht benötigt wird, es hinzufügen aber auch keine anderen Suchergebnisse hervorrufen würde. Die Suche ist schnell, denn sie verwendet zwei indexbasierte Filter, so dass jede Seite, die per RegEx durchsucht wird, bereits das höchstmögliche Potential besitzt.

Geosuche

Eingrenzung

Die Suche kann auf Seiten eingegrenzt werden, für die identifiziert wurde, dass sie (ihr Inhalt) sich in der Nähe von bestimmten angegebenen Geokoordinaten befinden. Die Koordinaten können entweder als Paar <lat>,<lon> (<lat> für die Breite, <lon> für die Länge) angegebene werden oder durch Angabe des Titels einer Seite, auf der die Koordinaten zu finden sind. Eine Entfernung kann zur Begrenzung der Suche vorangestellt werden. Beispiele:

  • neartitle:"San Francisco"
  • neartitle:"100km,San Francisco"
  • nearcoord:37.77666667,-122.39
  • nearcoord:42km,37.77666667,-122.39

Höhere Bewertung

Alternativ kann die Gewichtung von Seiten innerhalb des festgelegten geografischen Gebiets erhöht werden. Die Syntax ist dieselbe wie für die Suche zur Eingrenzung, nur dass dem Schlüsselwort ein boost- vorangestellt wird. Das bewirkt eine Verdopplung des Wertes für die Gewichtung der Seiten, die sich im Suchbereich befinden, was die Chance erhöht, dass sich Seiten aus der Nähe unter den ersten Suchergebnissen befinden.

  • boost-neartitle:"San Francisco"
  • boost-neartitle:"100km,San Francisco"
  • boost-nearcoord:37.77666667,-122.39
  • boost-nearcoord:42km,37.77666667,-122.39

Suche nach Dateieigenschaften

1.28
Gerrit change 311061

Seit MediaWiki 1.28 unterstützt CirrusSearch das Indizieren und die Suche nach einigen Dateieigenschaften im entsprechenden Namensraum File:. Das beinhaltet:

  • Dateityp
  • MIME-Typ
  • Größe
  • Breite und Höhe
  • Auflösung
  • Bittiefe für Dateien, die das unterstützen
Diese Eigenschaften sind zwar nur sinnvoll im Zusammenhang mit Dateien, ihre Verwendung allein schränkt aber die Suche nicht auf den Dateinamensraum ein. Es ist bei Nutzung dieser Parameter zu empfehlen, diesen Namensraum in der Suche hinzufügen oder die Suche gar auf ihn zu beschränken.

filetype

Die Suche nach Dateitypen erlaubt es, Dateien entsprechend ihrer Klassifikation (wie etwa Bürodokumente, Videos, Rasterbilder, Vektorbilder usw.) zu finden. Folgende Typen sind zur Zeit vorhanden:

  • UNKNOWN
  • BITMAP
  • DRAWING
  • AUDIO
  • VIDEO
  • MULTIMEDIA
  • OFFICE
  • TEXT
  • EXECUTABLE
  • ARCHIVE

Diese Liste kann in Zukunft eventuell erweitert werden. Siehe auch MEDIATYPE_*-Konstanten in Defines.php.

Die Syntax für die Suche ist filetype:{type} mit {type} als einem der verfügbaren Typen. Ein Beispiel:

filetype:video sucht nach allen Videos.

Für die Suche nach Dateitypen spielt Groß- oder Kleinschreibung keine Rolle.

filemime

Passt auf den MIME-Typen. Die Syntax ist:

filemime:{MIMEtype} – sucht nach allen Dateien des MIME-Typs {MIMEtype}.

Das Argument kann in Anführungszeichen " gesetzt werden, um eine exakte Suche durchzuführen. Ohne Anführungszeichen können auch Teilfolgen von MIME-Typen eingegeben werden.

Beispiele:

filemime:"image/png" sucht nach allen Dateien mit exakt dem MIME-Typen image/png (PNG-Dateien).

filemime:pdf sucht nach allen Dateien, deren MIME-Typ „pdf“ enthält (PDF-Dokumente).

Für die Suche nach MIME-Typen spielt Groß- oder Kleinschreibung keine Rolle.

filesize

Sucht nach Dateien der angegebenen Größe, wobei der Zahlenwert in Kibibyte anzugeben ist (1 Kibibyte [KiB] = 1024 Byte). Die Syntax mit {number} als dem Zahlenwert ist:

filesize:{number} oder filesize:>{number} – sucht nach Dateien, die mindestens die angegebene Größe besitzen.

filesize:<{number} – sucht nach Dateien, die höchstens die angegebene Größe besitzen.

filesize:{number},{number} – sucht nach Dateien, die eine Größe zwischen den angebenenen Werten besitzen.

Beispiele:

filesize:>20 oder filesize:20 sucht nach Dateien, die mindestens 20 KiB groß sind.

filesize:<1024 sucht nach Dateien, die kleiner als 1 MiB sind (1 MiB [Mebibyte] = 1024 KiB = 1024 × 1024 Byte = 1.048.576 Byte).

filesize:100,500 sucht nach Dateien mit einer Größe zwischen 100 KiB und 500 KiB.

Dateimaße

Es ist möglich, nach bestimmten Dateimaßen zu suchen: Breite, Höhe, Auflösung (die als Quadratwurzel des Produkts aus Höhe × Breite definiert ist) und Bittiefe. Nicht alle Dateien haben notwendigerweise alle dieser Maße. Die Syntax ist (mit {measure} als einem der Maßparameter und {number} als einem Zahlenwert):

{measure}:{number} – die Datei besitzt ein Maß, das dem angegebenen Zahlenwert gleicht.

{measure}:>{number} – die Datei besitzt ein Maß, das mindestens die angegebene Größe besitzt.

{measure}:<{number} – die Datei besitzt ein Maß, das nicht größer ist als der angegebene Zahlenwert.

{measure}:{number},{number} – die Datei besitzt ein Maß mit einem Wert zwischen den angegebenen Größen.

Als measure kann verwendet werden:

filew oder filewidth – Dateibreite

fileh oder fileheight – Dateilänge

fileres – Dateiauflösung (siehe oben)

filebits – Datei-Bitrate

Beispiele:

filew:>800 fileh:>600 sucht nach Dateien, die größer als 800x600 Pixel sind.

filebits:16 sucht nach Dateien mit 16-Bit-Farbtiefe.

fileheight:100,500 sucht nach Dateien, die zwischen 100 und 500 Pixeln hoch sind.

Suche mit Wikibase

Die Wikibase-Erweiterung definiert einige Schlüsselwörter für die Suche, um es einfacher zu machen, nach bestimmten Wikibase-Elementen zu suchen. Zur Zeit ist sie nur auf Wikidata-Seiten von Nutzen.

haswbstatement

haswbstatement liefert die Elemente zurück, die in einer Aussage mit einer bestimmten Eigenschaft einen bestimmten Wert haben. Funktioniert für alle Eigenschaften mit den Datentypen „externer Identifikator“ (“external identifier”), „Zeichenkette“ (“string”), „Datenobjekt“ (“item”), „Eigenschaft“ (“property”), „Lexeme“ (“lexeme”), „Form“ (“form”) und „Zweck“ (“sense”). Davon ausgenommen sind momentan aus Performanzgründen die Eigenschaften veröffentlicht in (P1433) und zitiert (P2860).

Ein Beispiel: Für ein Element, das einen Wert von Mensch (Q5) in der Eigenschaft ist ein(e) (P31) besitzt, verwende: haswbstatement:P31=Q5, und für eine Element mit dem Wert "113230702" in der Eigenschaft VIAF (P214) nutze haswbstatement:P214=113230702. Man kann auch eine Suche durchführen, ohne einen Wert anzugeben, um beispielsweise nach nach allen Elementen mit der Eigenschaft VIAF (P214) (im Hauptwert) zu suchen, nutze haswbstatement:P214.

Um nach Elementen zu suchen, die eine bestimmte Aussage nicht enthalten, füge den Ausschluss-Modifikator hinzu, zum Beispiel -haswbstatement:P31=Q13442814.

Suchergebnisse aus Schwesterprojekten

Die Suche in Wikimedia-Projekten enthält verbesserte Suchergebnisse aus Schwesterprojekten (auch bekannt als Cross-Wiki- oder Interwiki-Suchergebnisse).

Erweiterte Suchoberfläche

Eingabeformular für die erweiterte Suche

Die Erweiterung AdvancedSearch fügt der Suche ein verbessertes Formular hinzu, das es erlaubt, einige der oben behandelten Suchoptionen auf nutzerfreundliche Weise zu nutzen. Sie befindet derzeit im Betastatus und ist in allen Wikis als Betafunktion verfügbar. Siehe hier für eine Anleitung.

Siehe auch

Externe Links

Anmerkungen

  1. Angemerkt sei, dass die tagline|Tagzeile nicht Teil des eigentlichen Inhalts ist. Um den durchsuchbaren Inhalt für eine Seite zu sehen, muss ?action=cirrusdump an die URL angehängt werden.
  2. Stoppwörter werden selten in CirrusSearch abgefragt, außer wenn sie in bestimmten Ausdrücken auftreten, wie unten erklärt.
  3. CirrusSearch-Parameter benutzen keinen einheitlichen Weg in der Behandlung dieser Suchbegriffe.
  4. Das gleiche Analysewerkzeug zum Indizieren des Wikitextes wird auch verwendet, um die Anfrage zu interpretieren.
  5. Beispielsweise werden gängige Begriffe in diesem Wiki, MediaWiki.org, redundant gesucht:
    • udp2log OR udp2log2
    • html2wt OR wt2html
    • log2ip OR ip2log
    Es gibt test2wiki, wiki2xml, wiki2dict, apache2handler, apache2ctl und weitere.
  6. CirrusSearch kann das Zeichen für einen Zeilenumbruch (newline character) nicht direkt ansprechen, aber der Punkt . passt auch auf einen Zeilenumbruch.
  7. Eine ausgiebige RegEx-Suche kann nicht das gesamte Suchsystem deaktivieren, aber die RegEx-Suche eines anderen Nutzers.
  8. Prefix passt nicht auf die Startzeichen vollständiger Seitennamen, deshalb kann man zwei Namenräume nicht zugleich durchsuchen, nur weil sie mit dem gleichen Buchstaben beginnen, etwa „Namensraum“ und „Namensraum Diskussion“.
  9. Benutzerskript bearbeiten (global.js beziehungsweise lokal common.js oder skinspezifisch) und dort einfügen (als eine Zeile):
    mw.loader.load( "//de.wikipedia.org/wiki/MediaWiki:Gadget-DeepCat.js&action=raw&ctype=text/javascript" );
    Siehe task T37402 in Phabricator.
  10. Zur formalen Definition siehe Lucene grammar for regular expressions (englisch).