Zum Inhalt springen

Hilfe:CirrusSuche

Aus MediaWiki
Diese Seite ist eine übersetzte Version der Seite Help:CirrusSearch und die Übersetzung ist zu 100 % abgeschlossen sowie aktuell.
Sprachen:
PD Hinweis: Wenn Du diese Seite bearbeitest, stimmst Du zu, dass Dein Beitrag unter der [CC0] veröffentlicht wird. Mehr Informationen findest du auf der Public Domain Hilfeseite. PD

Der schnellste Weg, etwas in Wikimedia-Projekten zu finden, besteht darin, gezielt danach zu suchen. Auf jeder Seite befindet sich dazu ein Suchfeld.

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. 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/de .

Zur Nutzung in Wikidata siehe Hilfe:Erweiterung:WikibaseCirrusSearch .

Wie die Suche funktioniert

Man gibt Schlüsselwörter und Ausdrücke in das Suchfeld ein und drückt je nach Tastatur Enter oder Return oder man 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 "Suchen" 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.

Bei allen folgend behandelten Schlüsselwörtern ist zu beachten, dass sie in Kleinbuchstaben zu verwenden sind.

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?

Es gibt zwei primäre Suchindexe, die zu berücksichtigen sind:

Der erste besteht aus einer Volltextsuche auf einer eigenen Suchseite (Special:Search oder lokalisiert beispielsweise Spezial:Suche). Dieser Index wird nahezu in Echtzeit aktualisiert. Seitenänderungen sollten innerhalb weniger Minuten in den Suchergebnissen erscheinen, aber auch eine Verzögerung von 30 Minuten wird noch als normal angesehen. Veränderungen an Vorlagen sollten in den Artikeln, die sie enthalten, innerhalb wweniger Minuten wirksam werden; in Abhängigkeit von der Zahl der Artikel, in die eine Vorlage eingebunden ist, kann es aber auch mehrere Stunden dauern. Ein Null-Edit an dem Artikel wird die Veränderung erzwingen, dies sollte aber nicht nötig sein, solange alles normal verläuft.

Der zweite zu beachtende Index ist die unscharfe Titelsuche mit Autovervollständigung. Dieser Index wird einmal pro Tag aktualisiert und spiegelt wider, was der Volltext-Suchindex in diesem Moment beinhaltete. Abhängig vom Zeitpunkt ihrer Speicherung kann es bis zu zwei Tage dauern, bis eine neue Seite im unscharfen Titelindex gefunden wird. Wer das für inakzeptabel hält, wenigstens für einen bestimmten Einsatzzweck, kann in seinen Sucheinstellungen die Titelsuche auf den klassischen Präfixsuchmodus umstellen, der den Volltext-Suchindex verwendet.

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 jederzeit wieder auf die Ergebnisseite.

In manchen Sprachen werden Akzente und Diakritika ignoriert; die Details sind sprachspezifisch.

The algorithm used to rank suggestions is described in more detail at Extension:CirrusSearch/CompletionSuggester#Ranking criteria.

Volltextsuche

Eine Volltextsuche ist eine indexbasierte Suche. Alle Seiten werden in der Wiki-Datenbank gespeichert und alle darin enthaltenen Wörter (sofern es sich nicht um eine Weiterleitung handelt) 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 viele Male in vielen speziellen Indexen indiziert, und jeder davon liest den Wikitext so aus, 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. Es werden auch Open-Source-Bibliotheken von Drittanbietern verwendet, um zusätzliche Sprachen zu unterstützen, die nicht von Elasticsearch abgedeckt werden.

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 Details variieren von Sprache zu Sprache, speziell für Sprachen ohne Leerzeichen, aber üblicherweise erkennt die Suche als ein Wort:

  • eine 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). Die Liste der Stoppwörter ist sprachspezifisch, und nicht alle Sprachen unterstützen Stoppwörter.[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 (Joker) innerhalb eines Wortes kann ein (maskiertes) Fragezeichen \? für ein einzelnes Zeichen sein oder ein Stern * für null oder mehrere.
  • 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.
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, 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.
Die beiden Wildcard-Zeichen (Joker) 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 by … characters“ 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 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 invisible hand im Text 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). Sowohl mit "exact_phrase" als auch "exact phrase" wird eine Übereinstimmung mit "exact]phrase" 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 camelcase gefunden (alles kleingeschrieben), weil CirrusSearch bei dieser Suche nicht auf Groß- und Kleinschreibung achtet. Beachte, dass die CamelCase-Suche nicht in allen Sprachen aktiviert ist.

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“, der Wortabstammungssuche, 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 Yes Yes N N N N
"parser function" N N Yes Yes N N
parser_function N Yes Yes Yes N N
parserFunction Yes Yes Yes Yes N N
"parser:function" N N N N Yes Yes
"parser_function" N N Yes Yes N N
"parSer_funcTion" N N Yes Yes N N
parSer_FuncTion N N Yes Yes Yes Yes

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 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 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.[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 sonst bei 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 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 müssen vor dem *-Zeichen stehen.

  • Wenn * auf Zahlen passt, wird ein Komma als Teil der Zahl betrachtet, aber der Dezimalpunkt wird als Grauraum angesehen und wird zwei Zahlen abgrenzen.
  • Innerhalb eines exakten Suchausdrucks (Phrase in Anführungszeichen) wird * als Grauraumzeichen interpretiert und nicht als Joker, was bedeutet, dass das Zeichen hier eine Wortgrenze darstellt.

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.

Die Verwendung von Anführungszeichen deaktiviert die Wortabstammungssuche („Stemming“), das Anhängen der Tilde ("but appending"~) reaktiviert das 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, auf jeder Seite mit Ausnahme von Weiterleitungsseiten. 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 		Das 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 Suche mit regulären Ausdrücken beachtet standardmäßig Groß-/Kleinschreibung; das kann mit dem Modifikator i deaktiviert werden, was die Suche sogar noch ineffizienter macht.

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. RegExe laufen bei einer Suche als letztes; um daher eine unnötige Zeichenebenen-Überprüfung einzuschränken, sollte jede Suchanfrage andere (indexbasierte) Suchbedingungen beinhalten, um die Zahl der Dokumente einzuschränken, die durchsucht werden müssen.[7] Häufig ist die beste Variante, zur RegEx-Anfrage insource:/arg/ die Bedingung insource:arg hinzuzufügen, wobei arg bei beiden dieselbe Zeichenkette ist (und keine Joker verwendet werden).

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 andere 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 unten in Suche mit regulären Ausdrücken.

Der Parameter insource behandelt Wörter mit eingebettetem Doppelpunkt als ein Wort. Das wirkt sich aus bei Suchanfragen 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 Suchanfrage mit insource, bei der Groß-/Kleinschreibung ignoriert wird, zusammen mit einer einfachen Suche nach dem „blanken“ Begriff ohne Negierung (um eine bloße Regex-Suche zu vermeiden), zum Beispiel "in-law" insource:/-in-law/i oder "kung" insource:/!kung/i.

Prefix und Namensraum

Wird der Suchanfrage eine Zeichenfolge vorangestellt, die einem Namensraum entspricht, wie zum Beispiel file: (deutsch datei:), wird die Suche auf diesen spezifischen Namensraum eingeschränkt, statt das gesamte Wiki zu durchsuchen. Der Standardnamensraum ist der Hauptnamensraum.

Nur ein Namensraum kann im einfachen Suchfeld angegeben werden. Das muss entweder der erste Ausdruck in der Anfrage sein oder der letzte, wenn er den Parameter prefix: verwendet.

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

Um einen Namensraum anzugeben, trage diesen ein und stelle ihm einen Doppelpunkt voran, z. B. talk:. Nutze all:, um in allen Namensräumen zu suchen, oder : (ein einzelner Doppelpunkt), um nur im Hauptnamensraum zu suchen.

Der Parameter all: beinhaltet nicht den Dateinamensraum File:, der Medieninhalte einschließt, die in Commons gespeichert sind, beispielsweise PDF, die alle indiziert und durchsuchbar sind. Im Dateinamensraum zeigt der Namensraummodifikator local: Wirkung, sonst wird er ignoriert.

Genau wie Suchparameter müssen local: und all: klein geschrieben werden. Die Namensräume können dagegen in Groß- oder Kleinschreibung eingegeben werden.

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.

prefix:

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 - (Kurzstrich), ' (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. Dieser Parameter steht immer am Ende, damit die Zeichen für die Seitennamen doppelte Anführungszeichen (") enthalten können.

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.

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

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

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.

≥ 1.31
Gerrit change 413896

Seit MediaWiki 1.31-wmf.23 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.

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.

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.

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 vergleiche 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"
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.

Articletopic

Der Schlüssel articletopic: erlaubt es, Suchergebnisse nach Thema zu filtern. Zu möglichen Themen siehe unter Help:CirrusSearch/articletopic . Beispielsweise wird articletopic:books die Suchergebnisse auf Artikel über Bücher einschränken. articletopic:books|films wird nur Artikel über Bücher oder Filme anzeigen. articletopic:books articletopic:films wird auf Artikel filtern, die sowohl Bücher als auch Filme zum Thema haben.

Nur Artikel im Hauptnamensraum gehören zu Themen, und Themen sind nur in Wikipedias verfügbar. Anders als andere Filter führt articletopic auch eine Seitengewichtung durch; Artikel, die besser zu einem Thema passen, werden in den Suchergebnissen weiter oben angezeigt (während Artikel, die das Thema überhaupt nicht behandeln, von der Anzeige vollständig entfernt werden).

Themenmuster sind durch maschinelles Lernen von ORES abgeleitet. Jeder Artikel erhält eine Bewertung zu Dutzenden verschiedener Themen und kann daher unter verschiedenen Stichwörtern erscheinen. Beispielsweise kann der Artikel zu Albert Einstein sowohl als Physik- als auch als Biographieartikel angezeigt werden. Für alle Wikipedias sind Bewertungen verfügbar – einige haben lokalsprachliche Themenmuster, die alle Artikel abdecken. Andere Sprachen haben keine lokalen ORES-Muster und verwenden englischsprachige Bewertungen, welche Artikeln in der lokalen Sprache zugeordnet werden, die auch in der englischen Wikipedia existieren. Die Sprachen mit solchen "Cross-Wiki"-Bewertungen haben keine 100%-ige Abdeckung – je nach Sprache sind möglicherweise nur für etwa 60% der Artikel Themen verfügbar.

Themenmusterbezogene Suchdaten werden wöchentlich aktualisiert, daher werden kürzlich angelegte Artikel eventuell nicht in themenbasierten Suchergebnissen angezeigt.

Pageid

Das Schlüsselwort pageid: begrenzt die Suchergebnisse auf den vorgegebenen Satz an Seiten-IDs. Das ist nicht gerade sinnvoll bei manueller Suche; es kann aber von Software-Tools eingesetzt werden, um zu überprüfen, ob ein bestimmter Satz an Wikiseiten mit dem vorgegebenen Satz an Suchbedingungen übereinstimmt (beispielsweise um gecachte Suchergebnisse zu revalidieren).

Seitengewichtung

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

Wenn die Suchanfrage 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.

morelike ist ein „gieriges" (englisch greedy) Schlüsselwort, was bedeutet, dass es nicht mit anderen Suchanfragen kombiniert werden kann. Wenn man mehrere Anfragen gemeinsam durchführen will, kann man stattdessen morelikethis benutzen:

  • morelikethis:bee hastemplate:"featured article"
    • Findet Artikel über Bienen (englisch bees), die auch die Vorlage „featured article“ enthalten.

Die Suche mit morelike: arbeitet in der Weise, dass ein Set an Wörtern der vorgegebenen Artikel ausgewählt wird und dann eine Suchanfrage 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.
  • cirrusMltUseFields – true: Nutze ausschließlich die Felddaten. Standard ist false: Das System extrahiert den Inhalt des Feldes text, um die Suchanfrage 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. Prefer-recent wird nur angewandt, wenn für die Sortierreihenfolge der Standard relevance 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 Suchanfragen 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 - Wochen
  • prefer-recent:1,1 - Tage
  • prefer-recent:1,0.0007 - Minuten
  • prefer-recent:1,0.0001 - 8,64 Sekunden
  • prefer-recent:1,0.00001 - Sekunden

Boost-templates

Man kann die Bewertungen von Seiten auf der Grundlage der darin enthaltenen Vorlagen erhöhen. Dies kann auf alle Suchanfragen angewandt werden, indem man Verstärkungsfaktoren über MediaWiki:Cirrussearch-boost-templates deklariert, oder ad-hoc für einzelne Suchanfragen über den boost-templates:""-Operator. Wenn der boost-templates-Operator in einer Suchanfrage gesetzt ist, dann wird der Inhalt von cirrussearch-boost-templates ignoriert. Ähnlich wie bei prefer-recent wird boost-templates für die Standard-Sortierreihenfolge relevance angewandt. In anderen Sortiervorgaben hat der Parameter keinen Effekt.

Die Syntax des Filters ist wie folgt:

  • Alles vom Rautezeichen „#“ bis zum Ende der Zeile wird als Kommentar angesehen und ignoriert.
  • Jede nicht-leere Zeile wird als exakter Name einer Vorlage interpretiert (inklusive Namensraumpräfix), deren Bewertung verstärkt werden soll, gefolgt vom Pipe-Zeichen „|“, dann einer Zahl und zuletzt dem Prozentzeichen „%“.

Gute Beispiele („template“ ist das englische Präfix für „Vorlage:“): 

 Template:Important|150%
 Template:Very_Very_Important|300%
 Template:Less_important|50%

Schlechte Beispiele: 

 Template:Foo|150.234234% # Dezimalpunkte sind nicht erlaubt.
 Foo|150% # Technisch korrekt, bewertet aber nur Transklusionen des Artikels Foo (agiert also im Hauptnamensraum) statt der Vorlage Template:Foo.

Einige Beispiele:

boost-templates:"Template:Quality_Image|200%" incategory:china
Findet Dateien in der Kategorie „China“, und Qualitätsbilder werden dabei an den Anfang einsortiert.
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.
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.

Dezimalpunkte (oder Kommata) sind in den Prozentangaben nicht erlaubt. Der Bewertungsprozess des Suchsystems funktioniert derart, dass es unwahrscheinlich ist, dass Angaben von Bruchteilen eines Prozents einen Unterschied ergeben würden.

Zu beachten ist, dass sehr niedrige oder sehr hohe Prozentwerte, die über cirrussearch-boost-templates eingegeben werden, das Volltext-Bewertungssystem massiv beeinträchtigen können. 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 brave new world würde daher einen Qualitätsartikel auch dann als erstes Ergebnis ausgeben, wenn die drei Wörter darin einfach einzeln verteilt vorkommen, statt dem exakten Ergebnis „Brave New World“ selbst.

Suche mit regulären Ausdrücken

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

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. Meist ist dieses Suchverhalten vom Nutzer erwünscht, manchmal jedoch möchte jemand die Möglichkeit besitzen, eine präzisere Suche durchzuführen.

Um die syntaktische Einschränkung einer indexbasierten Suche zu umgehen, können Regexp-Suchen verwendet werden. Weil aber Abfragen, die ausschließlich aus Regexp-Ausdrücken bestehen, sehr langsam und ressourcenabelastend sind, sollten sie immer mit einer indexbasierten Suche kombiniert werden, so dass die Regexp-Suchdomäne auf die Ergebnisse einer oder mehrerer indexbasierter Suchen beschränkt wird.

Eine RegEx-Suche nach einer exakten Folge ist eine simple 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 (indexbasierter Suchbereich fett markiert, RegEx-Teil kursiv gesetzt):

  • 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 auf einer Seite (zum Beispiel in der Bearbeitungsvorschau), aber {{FULLPAGENAME}} funktioniert 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 Suchanfrage 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 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 /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: (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.
  • <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).[9]

Die Verwendung einer exakten Zeichenfolge 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.

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

  • \n und \r\n 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 insource:/[^\}]\}\}[^\} \|]{2}\<noinclude/i 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 ‎<noinclude>-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:
}}

<noinclude>
  • 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.[10]
  • ^ und $ sind nicht mit einer Sonderbedeutung belegt. 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 (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 [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>.

Substitutionen für manche Metazeichen

Während die Zeichenklassen \n, \s und \S nicht unterstützt werden, können sie für den Fall, dass man doch dringend auf sie zugreifen muss, um sie in einem regulären Ausdruck zu verwenden, auf folgende Weise ersetzt werden:

PCRE CirrusSearch Beschreibung
\n [^ -􏿿] Suche nach dem Zeilenvorschub (englisch „newline“; das Regex-Muster findet auch ein Tabulatorzeichen)[11]
[^\n] [ -􏿿] Jedes Zeichen außer einem Zeilenvorschub und einem Tabulator
\s [^!-􏿿] Zeichen für Leerraum (englisch „whitespace“): Leerzeichen, Zeilenvorschub, Tabulator
\S [!-􏿿] Jedes Zeichen außer den Zeichen für Leerraum

In diesen Regex-Suchmustern wird „ “ (ein Leerzeichen) als das Zeichen genutzt, das im Zeichensatz als erstes nach den Steuerzeichen steht, „!“ als das Zeichen, das diesem unmittelbar folgt, und „􏿿“ als das Zeichen mit dem Codepunkt U+10FFFF, das in Unicode das letzte erlaubte Zeichen ist. Daher umfasst der Bereich von „ “ bis „􏿿“ alle Zeichen mit Ausnahme der Steuerzeichen, die in Artikeln als Zeilenumbrüche und Tabulatoren enthalten sein können, während der Bereich von „!“ bis „􏿿“ alle Zeichen mit Ausnahme von Steuerzeichen und dem Leerzeichen umfasst.

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.
  • insource:"<tag>[[link|2\3?]]\</tag>" insource:/"<tag>[[link|2\3?]]<"\/"tag>"/

Regex bei Seitentiteln

Das 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 argumentfmt=commas vor, ebenfalls eventuell mit Leerzeichen von anderen Zeichen abgetrennt (es kann sich um denselben oder einen separaten Vorlagen-Aufruf handeln):

hastemplate:val insource:"fmt commas" insource:/\{\{ *[Vv]al *\|[^}]*fmt *= *commas/ insource:/\{\{ *[Vv]al *\|[^}]*[-+]?[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

Suche auf Grundlage der (primären) Koordinaten, die mit den Seiten verknüpft sind. Abhängig von Erweiterung:GeoData und {{#coordinates:}}

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 <lat>,<lon> (<lat> für die Breite, <lon> 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.776,-122.39
  • nearcoord:42km,37.776,-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.776,-122.39
  • boost-nearcoord:42km,37.776,-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}. 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).
  • -filemime:pdf - alle PDF-Dokumente ignorieren (vor allem in Commons).

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.

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 {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 in Wikibase

Die Erweiterung Wikibase definiert einige Such-Schlüsselwörter, um es einfacher zu machen, nach bestimmten Wikibase-Elementen zu suchen. Von Nutzen ist das auf Wikidata und anderen Wikimedia-Präsenzen, die Wikibase verwenden, etwa bei der Bildersuche mittels Strukturierter Daten in Wikimedia Commons . Für Details siehe Help:WikibaseCirrusSearch .

Suchergebnisse aus Schwesterprojekten

Es existieren zwei Sorten von wikiübergreifenden Suchergebnissen, die unter Umständen angezeigt werden, wenn man in der Wikipedia etwas sucht.

Eine projektübergreifende Suche (auch bekannt als Interwiki-Suche, Schwesterprojekt-Suche oder kurz Schwestersuche) zeigt zusätzliche Ergebnisse aus anderen Projekten (Wiktionary, Wikisource, Wikiquote usw.) an, dargestellt seitlich neben den Ergebnissen der eigentlichen Wikipediasuche. Solch eine projektübergreifende Suche auf den meisten Wikipedias mit vorhandenen Schwesterprojekten verfügbar.

Sprachübergreifende Suche (siehe Blogbeitrag) meint zusätzliche Ergebnisse, die unterhalb der Hauptergebnisse angezeigt werden und von einer anderen Wikipedia-Sprachversion stammen. Die sprachübergreifende Suche nutzt eine stark modifizierte und optimierte Version eines einfachen Sprachendetektors namens TextCat . Soche sprachübergreifenden Suchen sind derzeit nur auf wenigen Wikipedias verfügbar (für Details siehe unter dem Textcat-Link).

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 relevance, werden alle Suchschlüsselwörter deaktiviert, die eine Bewertung bewirken, wie prefer-recent oder boost-templates. 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 srsort.

Anleitung:

Sortieroptionen können manuell einer Such-URL hinzugefügt werden, indem man &sort=order an die Adresse anhängt, ein Beispiel:

Erlaubte Sortiervorgaben sind:

URL-Ergänzung Beschreibung
&sort=incoming_links_asc Aufsteigend nach Anzahl der Links auf diese Seite (d.h. niedrigste Anzahl zuerst). Das ist näherungsweise vom Unpopulärsten zum Populärsten.
&sort=incoming_links_desc Absteigend nach Anzahl der Links auf diese Seite (d.h. höchste Anzahl zuerst). Das ist näherungsweise vom Populärsten zum Unpopulärsten.
&sort=last_edit_asc Aufsteigend nach Zeitpunkt der letzten Bearbeitung (d.h. älteste zuerst)
&sort=last_edit_desc Absteigend nach Zeitpunkt der letzten Bearbeitung (d.h. neueste zuerst)
&sort=create_timestamp_asc Aufsteigend nach Anlegezeitpunkt der Seite (d.h. älteste zuerst)
&sort=create_timestamp_desc Absteigend nach Anlegezeitpunkt der Seite (d.h. neueste zuerst)
&sort=just_match Eine einfache Relevanz-Sortierung, die nur auf Textübereinstimmung beruht
&sort=relevance Eine Relevanz-Sortierung, die viele Merkmale des Dokuments in Betracht zieht
&sort=random zufällig
&sort=none Unsortierte Liste mit willkürlicher Reihenfolge. Bevorzugt für umfangreiche Ergebnismengen.

Erweiterte Suchoberfläche

Eingabeformular für die erweiterte Suche

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

Anmerkungen

  1. ↑ Angemerkt sei, dass die 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 oder udp2log2 (durch die zusätzliche 2 wird die Seitengewichtung beeinflusst)
    • html2wt oder wt2html
    • log2ip oder 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 langsame RegEx-Suche kann nicht das gesamte Suchsystem deaktivieren, aber die RegEx-Suche eines anderen Nutzers verhindern, weil nur eine begrenzte Anzahl an gleichzeitigen RegEx-Suchen erlaubt ist.
  8. ↑ Prefix passt nicht auf die Startzeichen vollständiger Seitennamen; deshalb kann man zwei Namensräume nicht zugleich in einer Anfrage durchsuchen, allein weil sie mit dem gleichen Buchstaben beginnen, etwa „Namensraum“ und „Namensraum Diskussion“.
  9. ↑ Zur formalen Definition siehe Lucene grammar for regular expressions (englisch).
  10. ↑ Class RegExp, Lucene-RegExp-Syntax
  11. ↑ Um auch das Tabulatorzeichen auszuschließen, kopiere es und füge es der Zeichenauswahl hinzu.
Abgerufen von „https://www.mediawiki.org/w/index.php?title=Help:CirrusSearch/de&oldid=6694291“