Help:CirrusSearch/de

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.

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  . 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 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. 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  (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). 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.

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.

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  für ein einzelnes Zeichen oder ein Stern   für mehrere sein.
 * Die Wahrheitslogik kann AND und OR interpretieren, Parameter können das jedoch nicht. Beachte, dass die Operatoren AND und OR derzeit nicht entsprechend der traditionellen Methodik der Wahrheitslogik funktionieren! Für Details siehe mehr in logical operators (englisch).
 * Die Wahrheitslogik versteht - oder ! als Präfixe für einen Begriff, um die gewöhnliche Bedeutung des Begriffes von „Übereinstimmung“ zu „Ausschließen“ umzukehren.


 * Anführungszeichen, die einen Suchbegriff einschließen, kennzeichnen die Suche nach einem „genauen Ausdruck“. Bei Parametern werden sie auch benötigt, um Eingaben mit mehreren Wörtern zu abzugrenzen.
 * Die Abstammungssuche („Stemming“, siehe unten) ist automatisch aktiv, kann aber durch die Benutzung eines „genauen Ausdrucks“ ausgeschaltet werden.

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:

Die Mitteilung „Suche stattdessen nach“ wird ausgelöst, wenn ein allgemein unbekanntes Wort in einem Ausdruck ignoriert wird.
 * Bei Eingabe von „ words-joined_by_greyspace(characters) “ oder „ wordsJoinedByCamelCaseCharacters “ wird „ words joined by … characters “ gefunden, in reiner Form oder in Form von Greyspace.
 * Zu „ txt2number “ wird eine Übereinstimmung mit „ “ oder „ “ gefunden.
 * Stoppwörter werden für die 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 „ “.

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


 * Ein „genauer Ausdruck“ (exact phrase)  toleriert Greyspace (passt auf jedes Greyspace-Zeichen). Sowohl mit "exact_phrase" als auch "exact phrase" wird eine Übereinstimmung mit   gefunden.


 * Ein Greyspace-Ausdruck (greyspace_phrase) initiiert die Wortabstammungssuche („Stemming“, siehe unten) und die Prüfung auf Stoppwörter.


 * Bei Eingabe von CamelCase wird zusätzlich  gefunden (alles kleingeschrieben), weil CirrusSearch bei dieser Suche nicht auf Groß- und Kleinschreibung achtet.

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  lediglich den normalen Ausdruck in Anführungszeichen.

Bitte beachte, dass Groß- und Kleinschreibung bei der Wortabstammungssuche 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  findet CirrusSearch im Kontext eines genauen Ausdrucks (der den Kontext des „insource“-Parameters beinhaltet) keine Übereinstimmung mit ,   oder  , sondern nur eine mit.

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 gewöhnliche Wortsuche benutzt Leerzeichen und ist agressiv in Bezug auf die Wortabstammung („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. 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 sowie die Wortabstammung. 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  und   darstellt.

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


 * Plan9 oder Plan_9 passt zu:,  ,  ,  ,
 * "plan9" passt nur zu  (ungeachtet von Groß- und Kleinschreibung)
 * Plan*9 passt zu  oder.

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 der Wortabstammung 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.
 * 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.

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.

Die Verwendung von Anführungszeichen deaktiviert die Wortabstammungssuche („Stemming“), das Anhängen der Tilde ( "but appending"~ ) reaktiviert das Stemming.

Insource
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, auf jeder Seite mit Ausnahme von Weiterleitungsseiten. Dieser Ausdruck ignoriert vollkommen Greyspace: insource: "state state autocollapse" passt zu.

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. 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. 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 Berücksichtigung der Wortabstammmung („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.

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 „Erweiterte Suche“ 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. Der Suchbereich kann dort als Profil von Namensräumen eingestellt werden. 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ückzusetzen, 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 ihn grafisch an. „Inhaltsseiten“ (Hauptnamensraum), „Multimedia“ (Dateien), „Alles“ ( und  ), „Ü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  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  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  Wirkung, sonst wird er ignoriert.

Namensraumaliasse werden akzeptiert.

Wie alle Suchparameter müssen  und   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. 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  erlaubt kein Leerzeichen vor einer Namensraumangabe, aber Leerraum vor einem Seitennamen.

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  einschließt. das weist CirrusSearch an, diesen Inhalt nicht in den Suchindex aufzunehmen (siehe für weiteren Kontext).

Zusätzlich kann Inhalt als Zusatzinformation markiert werden, indem man die Klasse  verwendet. Das weist CirrusSearch an, den Inhalt vom Haupttext in ein Hilfsfeld zu verschieben, das eine geringere Gewichtung 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.

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).

Ein Namensraum ist eine vorgegebene Suchdomäne, aber kein Filter, da ein Namensraum allein nicht ausgeführt wird. Ein Präfix wird verneint, daher handelt es sich um einen Filter. Die folgenden Suchparameter sind Filter; sie können mehrfach verwendet werden.

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.  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.
 * cow*
 * Finde Artikel, deren Titel oder Text Wörter enthält, die mit „cow“ beginnen.
 * intitle:foo
 * Findet Artikel, deren Titel „foo“ enthält. Die Wortabstammungsssuche („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“.

Seit ist die Suche mit Regulären Ausdrücken (eine RegEx-Suche) auch für intitle möglich:
 * intitle:/regex/, intitle:/regex/i

Alles, was unter Suche mit regulären Ausdrücken geschrieben steht, ist auch hier gültig – einschließlich der Warnungen.

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“).

Das Deepcat-Helferlein, das zuvor die Suche mit diesem Parameter ermöglichte, wurde im Januar 2020 entfernt.

Note that some deepcat searches return incomplete results. See bug for more details.

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  (lokalisiert  ) erfolgen können (sie muss auf   passen, für die aktuelle Seite wäre das „“).

findet keine Weiterleitungen (Redirects). Es findet nur, 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

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

Hastemplate
Die Einbindung von Vorlagen kann mit  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"

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 ist ein „gieriges" (englisch greedy) Schlüsselwort, was bedeutet, dass es nicht mit anderen Suchanfragen kombiniert werden kann. Wenn man mehrere Suchanfragen gemeinsam durchführen will, kann man stattdessen morelikethis benutzen:
 * 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.
 * morelikethis:bee hastemplate:"featured article"
 * Findet Artikel über Bienen (englisch bees), die auch die Vorlage „featured article“ enthalten.

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:

Diese Einstellungen können dauerhaft gespeichert werden durch Überschreiben von  in den Systemmitteilungen.
 * 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.
 * cirrusMltUseFields – : Nutze ausschließlich die Felddaten. Standard ist  : Das System extrahiert den Inhalt des Feldes , um die Suche zusammenzustellen.
 * cirrusMltPercentTermsToMatch – Der Prozentwert an Begriffen, die passen müssen. Der Standard ist 0.3 (30 %).
 * Beispiel:

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. Prefer-recent wird nur angewandt, wenn für die Sortierreihenfolge der Standard  genutzt wird.

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  oder durch den System&shy;mitteilungs&shy;parameter. Eine Suche mit  überschreibt die Inhalte von. Die Syntax ist ein wenig ungewöhnlich, wurde aber so gewählt, damit sie möglichst einfach ist. Genau wie bei prefer-recent wird boost-templates nur angewandt, wenn für die Sortierreihenfolge der Standard  genutzt wird. 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  könnte die Eingabe im Suchfeld auf   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 : Werden sehr, wirklich sehr große oder kleine Prozentwerte verwendet, schwächen sie massiv das gesamte Bewertungssystem. Wenn beispielsweise in der englischen Wikipedia 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  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.

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:"{ {template}}" insource: / "{ {template}}<\/tag>" /
 * insource:"[ [title|link label]]'s" insource: / "[ [title|link label]]'s" /
 * insource: / regexp / prefix:{ {FULLPAGENAME}}

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

Zum Beispiel: Special:Search/insource:/regex/ prefix: 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 jede Seite des aktiven Suchbereichs Zeichen für Zeichen. 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  ermöglichen. das sind in Reihenfolge absteigender Effektivität:


 *  insource:""  mit Anführungszeichen; den regulären Ausdruck ohne Maskierungszeichen zu wiederholen ist ideal.
 *  intitle:  (ohne RegEx-Suche),  incategory:  und  linksto:  sind exzellente Filter.
 *  hastemplate:  ist ein sehr guter Filter.
 *  "Wort1 Wort2 Wort3" , mit Anführungszeichen oder ohne, sind gut.
 *  :  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).

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 . Eine Eingabe von   ist mehrdeutig, deshalb muss man dies als   schreiben.
 * Eine ganze Zeichenfolge kann in doppelte Anführungszeichen gesetzt werden . 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 ist eine einfache Möglichkeit, nach vielen Arten von Folgen zu suchen, aber innerhalb des Ausdruck kann keine Maskierung mit Backslash erfolgen.


 * anstelle von.
 * ist genau so gut wie.
 * Aber das funktioniert nie:.
 * Und das hängt davon ab, was bezweckt war: . 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 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  zu erzeugen, bei dem man die anderen Metazeichen nicht beachten muss, sondern nur   und  :
 * 1) Schreibe die Folge auf:   (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): , was die gemeinsame Verwendung beider Maskierungsmethoden nebeneinander zeigt (drei Teilfolgen in Anführungszeichen, dazwischen zwei mit Backslash maskierte Einzelzeichen).

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.
 * passt auf kein oder ein Leerzeichen dazwischen. Das Gleichheitszeichen = ist kein Metazeichen, aber das Pluszeichen + ist eines.
 * insource:"[ [link|2\3?]]\" insource:/"[ [link|2\3?]]< "\/" tag>"/

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


 * und  sind nicht dafür reserviert, einen Zeilenumbruch zu finden. Um nach einer Zeichenkette zu suchen, die einen Zeilenumbruch enthält, kann man eine Suche wie   durchführen – das bedeutet „keine geschweifte Klammer, dann zwei geschweifte Klammern, dann zwei beliebige Zeichen außer einer geschweiften Klammer, einem Leerzeichen oder einem senkrechten Strich, dann ein -Tag“. Der Teil „jedes Zeichen außer“ schließt den Zeilenumbruch in die Suche ein. Beachte aber, dass diese Suche ausschließlich dafür entworfen wurde, um auf folgende Zeichenkette 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   eine globale Suche je Seite mit einem regulären Ausdruck und Anzeige der passenden Seiten in einer Ergebnisauflistung (englisch global per document, regular expression, search-results-list each document).
 * und  bieten die Möglichkeit, einen mehrstelligen Zahlenbereich zu suchen, wie es auch mit   möglich ist, aber ohne auf die Zahl der Stellen zu achten oder auf den Intervall an jeder Position, daher funktioniert   und sogar.

Regex bei Seitentiteln
Da Schlüsselwort insource durchsucht nur den Inhalt des Seitenquelltextes. Um eine Regex-Suche auf den Seitentitel anzuwenden, kann intitle:/regex/ verwendet werden.

Ein fortgeschrittenes Beispiel
Man will 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 kommt in der Vorlage „Val“ ein benannter Parameter argument vor, ebenfalls eventuell mit Leerzeichen von anderen Zeichen abgetrennt (es kann sich um denselben oder einen separaten Vorlagen-Aufruf handeln):



Beachte, dass das Gleichheitszeichen in  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.

Eingrenzung
Die Suche kann auf Seiten beschränkt werden, deren Themeninhalt sich in der Nähe bestimmter Geokoordinaten befindet. Die Koordinaten können entweder als Paar  (  für die Breite,   für die Länge) angegeben 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  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
Seit MediaWiki 1.28 unterstützt CirrusSearch das Indizieren und die Suche nach einigen Dateieigenschaften im entsprechenden Namensraum. Das beinhaltet:
 * Dateityp
 * MIME-Typ
 * Größe
 * Breite und Höhe
 * Auflösung
 * Bittiefe für Dateien, die das unterstützen

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:



Diese Liste kann in Zukunft eventuell erweitert werden. Siehe auch -Konstanten in.

Die Syntax für die Suche ist filetype:{type}. 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.

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  (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  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.

Dateiabmessungen
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  als einem der Maßparameter und   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  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 in Wikibase
Die Erweiterung definiert einige Such-Schlüsselwörter, um es einfacher zu machen, nach bestimmten Wikibase-Elementen zu suchen. Zur Zeit ist das nur auf Wikidata-Seiten von Nutzen. Für Details siehe.

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

Explizite Vorgabe der Sortierreihenfolge
Zusätzlich zur standardmäßigen relevanzbasierten Sortierung bietet CirrusSearch die Möglichkeit für einige weitere ausdrückliche Vorgaben der Sortierreihenfolge. Wird eine andere Sortierreihenfolge angegeben als, werden alle Suchschlüsselwörter deaktiviert, die eine Bewertung bewirken, wie   oder. Die Schlüsselwörter werden weiterhin geparst, haben aber keinen Effekt mehr.

Sortieroptionen sind derzeit über die MediaWiki-API erhältlich durch Nutzung des Parameters.

Sortieroptionen können manuell einer Such-URL hinzugefügt werden, indem man  an die Adresse anhängt, ein Beispiel: https://www.mediawiki.org/w/index.php?search=foo&sort=last_edit_desc.

Erlaubte Sortiervorgaben sind:

Erweiterte Suchoberfläche


Die Erweiterung Extension:AdvancedSearch fügt der Suche ein verbessertes Formular hinzu, das es erlaubt, einige der oben behandelten Suchoptionen auf nutzerfreundliche Weise zu nutzen. Siehe hier für eine Anleitung.

Siehe auch

 * CompletionSuggester – Vervollständigungsvorschläge, die inkrementelle Besonderheit der Suche mit CirrusSearch
 * Wikimedia Discovery/Search/Glossary - Definitionen, Kontext und Links zu suchebezogenen Begriffen.
 * Siehe in Search/Old zu Details der Entwicklung und zum Start von CirrusSearch.
 * Siehe Hilfe:Suche für MWSearch, die Suchmaschine, die in vielen Wikis verwendet wird, die keine Sucherweiterung installiert haben.
 * Siehe Hilfe:Suche für MWSearch, die Suchmaschine, die in vielen Wikis verwendet wird, die keine Sucherweiterung installiert haben.

Externe Links

 * Apache Lucene, hoch relevante Dokumentation (englisch)
 * (as of 2017-12-06)
 * Extension:CirrusSearch/Profiles – Zusammenstellung von anpassbaren Parametern, die verschiedene Aspekte der Indexierung beeinflussen
 * Wikimedia blog articles related to search