Hilfe:CirrusSuche

Hinweis: Wenn Du diese Seite bearbeitest, stimmst Du zu, dass Dein Beitrag unter CC0 veröffentlicht wird. Mehr Informationen findest du auf der Public Domain Hilfeseite.

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 .

For information about debugging, see Help:CirrusSearch/Debug .

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 mit dem Suchbegriff übereinstimmen, 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.

Der Algorithmus, der zur Rangfolge von Vorschlägen verwendet wird, wird im Detail unter Erweiterung:CirrusSearch/CompletionSuggester beschrieben.

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. 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, Überschriften und Bildlegenden, Inhaltsverzeichnissen sowie aller 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 Menge aller Arbeitsaufträge im Hintergrund.) 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:

• Sortierung von Navigationsvorschlägen nach Anzahl der eintreffenden Links.
• Beginn 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. 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. Greyspace characters are otherwise ignored unless, due to query syntax, they can be interpreted as modifier characters.

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: Depending on their placement in the syntax they can apply to a term, a parameter, or to an entire query. Word and phrase modifiers are the wildcard, proximity, and fuzzy searches. Each parameter can have their own modifiers, but in general:

• 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 mit Titeln oder Weiterleitungen übereinstimmen, werden aber auch mit jeder Seite übereinstimmen, 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: Each method of hinting has a side-effect of how tolerant the matching of the word sequence will be. For greyspace, camelCase, or txt2number hints:

• 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			N	N	N	N
"parser function"	N	N			N	N
parser_function	N				N	N
parserFunction					N	N
"parser:function"	N	N	N	N
"parser_function"	N	N			N	N
"parSer_funcTion"	N	N			N	N
parSer_FuncTion	N	N

Bitte beachte, dass Groß- und Kleinschreibung bei 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. You can use any of those three forms. 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, $plans9, $planned9th, $planned92, $plans
• $plan92 passt nur zu $plan93 (ungeachtet von Groß- und Kleinschreibung)
• $planast passt zu $plan94 oder $planet.

plan9, plans 9, planned 9th, (planned) 9.2, "plans" (9:24)

• "plan9" only matches plan9 (case insensitive)

• Plan*9 matches plan9 or 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"		N	N	N
"flowers algernon"~0		N	N	N
"flowers algernon"~1			N	N
"flowers algernon"~2				N
"flowers algernon"~11
"algernon flowers"~1	N	N	N	N
"algernon flowers"~2		N	N	N
"algernon flowers"~3			N	N
"algernon flowers"~4				N
"algernon flowers"~13

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					Stemming ist im Einsatz.
"flowers"		N		N	Eine Näherungssuche deaktiviert Stemming.
"flowers"~					Näherung plus Stemming durch Anhängen einer Tilde.
"flowers for algernon"	N	N		N	Eine Näherungssuche deaktiviert Stemming.
"flowers for algernon"~	N	N			Näherung plus Stemming durch Anhängen einer Tilde.
"flowers algernon"~1	N	N		N	Eine Näherungssuche deaktiviert Stemming.
"flowers algernon"~1~	N	N			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. 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. 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 von beiden führt Suchen durch 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. Wenn die ersten Zeichen mit einem Namensraum und einem Doppelpunkt übereinstimmen, dann wird der Suchbereich geändert.

Ist allein ein Namensraum angegeben, wird prefix: mit allen seinen Seitennamen übereinstimmen. 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 übereinstimmen, stimmen per Definition auch die Titel ihrer Unterseiten überein.

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 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 Ausdruckssuchen finden Übereinstimmungen in Titeln einer Seite und zugleich in den 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*
  • Findet 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 „foo“ nicht enthält und deren Titel oder Text „bar“ enthält.
• incategory:Music
  • Findet Artikel aus „Category:Music“ (auch, wenn „Category“ eventuell zu „Kategorie“ lokalisiert ist).
• 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"
  • Findet Artikel, die sich in „Category:Musicals“ oder einer der Unterkategorien befinden (auch, wenn „Category“ eventuell zu „Kategorie“ lokalisiert ist).

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 mit dem gesamten Titel der Seite genau übereinstimmen ohne Anzeige-Modifikationen, wie sie durch {{DISPLAYTITLE:…}} (lokalisiert {{SEITENTITEL:…}}) erfolgen können. (Sie muss mit {{FULLPAGENAME}} übereinstimmen, 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"

Um Unterseiten auszuschließen, füge einen negierenden Titelfilter hinzu, der einen Schrägstrich (Slash) enthält. Da der Schrägstrich ein Metazeichen ist, muss das Regex-Format verwendet und der Strich maskiert werden:

-intitle:/\//

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 mit einem Thema übereinstimmen, 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 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.

≥ 1.45 Gerrit change 1191677

Dieses Schlüsselwort erlaubt es, einen Verstärkungsfaktor zu setzen, um die Gewichtung der verschiedenen Themen zu beeinflussen, nach denen gesucht werden soll:

• articletopic:books^2.0|fashion^0.2 – um Artikel über Bücher (books) oder Mode (fashion) aufzulisten, aber denjenigen zum Thema Bücher eine größere Gewichtung zuzuordnen.
• articletopic:books^100 – um diesem Schlüsselwort (books) im Vergleich zu anderen Rangordnungskriterien (andere Schlüsselwörter oder Wörter, Anzahl der eingehenden Links oder Popularität der Seite …) eine besonders große Gewichtung zu verleihen.

Dieser Verstärkungsfaktor muss eine positive Zahl sein.

Articlecountry

Dieses Schlüsselwort ermöglicht es, Seiten anhand der Empfehlungen des Article-country-Modells zu filtern und zu bewerten.

Die unterstützten Werte sind in Help:CirrusSearch/articlecountry dokumentiert:

• articlecountry:and – Seiten filtern, die einen Bezug zu Andorra haben könnten
• articlecountry:bel|fra – Seiten filtern, die einen Bezug zu Belgien oder Frankreich haben könnten.

Ähnlich wie bei articletopic kann man einen Verstärkungsfaktor hinzufügen.

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

creationdate / lasteditdate

Suchergebnisse können mit zwei Filtern nach Datum eingegrenzt werden:

• lasteditdate: – for when pages were last edited
• creationdate: – for when pages were first created (the date of their first revision).

Dies erlaubt es, nach kürzlich aktualisierten Inhalten, nach Seiten, die eine gewisse Zeit lang nicht aktualisiert wurden, oder nach Seiten, die in einem bestimmten Zeitraum angelegt wurden, zu suchen. Alle Suchanfragen mit Datum nutzen die lokale Zeitzone des Wikis, auf dem die Suche durchgeführt wird; die persönlichen Einstellungen für die Zeitzone haben keinen Einfluss auf die Suchergebnisse.

Man kann Vergleichsoperatoren vor jedes Datum setzen, um die Suche einzuschränken:

Operator	Bedeutung	Beispiel	Beschreibung
>	nach …	creationdate:>2024	nach 2024 erstellte Seiten
>=	am oder nach …	lasteditdate:>=2024	zuletzt 2024 oder später bearbeitete Seiten
<	vor …	creationdate:<2025	vor 2025 erstellte Seiten
<=	am oder vor …	lasteditdate:<=2020	zuletzt 2020 oder früher bearbeitete Seiten

Ohne Operator wird nur nach exakten Treffern innerhalb des angegebenen Zeitraums gesucht.

Die Genauigkeit der Suche hängt davon ab, wie das Datum angegeben ist. Bei der Angabe eines absoluten Datums hängt es davon ab, wie genau Ihr Datum ist:

Genauigkeit	Beispiel	Beschreibung
Jahr	creationdate:2025	im Jahr 2025 irgendwo erstellte Seiten
Monat	lasteditdate:2025-09	zuletzt im September 2025 bearbeitete Seiten
Tag	creationdate:2025-09-01	am 1. September 2025 erstellte Seiten

Alternativ kann mit now oder today eine relative Datumsangabe gesetzt werden. Die Genauigkeit der Suche wird durch das verwendete Schlüsselwort bestimmt. Das Schlüsselwort kann mit einem Minuszeichen (-) angehängt werden, gefolgt von einer Zahl und einer Zeiteinheit. Die folgenden Zeiteinheitensuffixe stehen zur Verfügung:

Schlüsselwort	Genauigkeit	Beispiel	Beschreibung
now	stundengenau	lasteditdate:now	zuletzt in der laufenden Stunde bearbeitete Seiten
now	stundengenau	creationdate:now-1h	in der letzten Stunde erstellte Seiten
now	stundengenau	lasteditdate:>=now-1d	in den letzten 24 Stunden bearbeitete Seiten
today	taggenau	creationdate:today	heute erstellte Seiten
today	taggenau	lasteditdate:today-1d	gestern zuletzt bearbeitete Seiten
today	taggenau	creationdate:>today-1y	irgendwann im letzten Jahr erstellte Seiten

Es gibt zwar keinen eigenständigen Operator für die Abfrage eines Zeitraumes, man kann aber einen Zeitraum erzeugen, indem man zwei Datumsfilter in derselben Abfrage kombiniert.

Beispiel	Beschreibung
creationdate:>=2010 creationdate:<2020	Pages created in the 10's (from January 1, 2010 to January 1, 2020).

hasrecommendation

Dieses Schlüsselwort kann verwendet werden, um auf Seiten zu filtern, für die ein Maschinenlernmodell eine Empfehlung abgegeben hat (allgemein durch die Erkennung, dass Verbesserungen vorgenommen werden müssen).

• hasrecommendation:image – auf Seiten filtern, für die ein Modell empfohlen hat, dass ein Bild hinzugefügt werden sollte

Die Art der Empfehlungen hängt vom Modell und von den Wikis ab, für die dieses System aktiviert wurde.

Zum Beispiel gibt es auf WMF-Wikis Modelle, die für Folgendes eine Empfehlung geben können:

• image – Artikel, denen ein Seitenbild hinzugefügt werden könnte.
• image_section – Artikel, denen ein Bild in einem Abschnitt hinzugefügt werden könnte.
• link – Artikel, denen ein Link hinzugefügt werden könnte.

This keyword is generally used by other tools such as Growth/Personalized first day/Structured tasks .

If the recommendation is stored with its confidence score the keyword can be used to filter using a threshold and/or boost using a factor. For instance if you want to filter pages where a recommendation of type tone has a confidence score above 0.5 you can use: hasrecommendation:tone>0.5. Similarly if you want the hasrecommendation to influence the ranking of the search results you can use a boost factor: hasrecommendation:tone^1.0. You can also combine these two with: hasrecommendation:tone^1.0>0.5.

• the confidence score threshold must be a decimal number between 0 and 1.
• the boost factor must be a positive number

This keyword highly depends on the recommendation models enabled for a particular wiki and may not work on all the WMF wikis.

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 damit übereinstimmen, 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 Suchbegriffen, die berücksichtigt werden müssen.
• cirrusMltMinTermFreq – Angabe, wie häufig ein Suchbegriff mindestens in den vorgegebenen Dokumenten vorkommen muss, damit er berücksichtigt wird. Bei kleinen Feldern (title) sollte der Wert 1 sein.
• cirrusMltMinWordLength – Minimale Wortlänge eines Suchbegriffs, damit er berücksichtigt wird. Der Standard ist 0.
• cirrusMltMaxWordLength – Maximale Wortlänge, über der Wörter ignoriert werden, standardmäßig 0 (unbegrenzt).
• cirrusMltFields (Liste von Werten, mit Kommata getrennt) – Die Felder, die verwendet werden können. Erlaubt sind title, text, auxiliary_text, opening_text, headings und all.
• cirrusMltUseFields (true | false) – Nutze ausschließlich die Felddaten. Standard ist false: Das System extrahiert den Inhalt des Feldes text, um die Suchanfrage zusammenzustellen.
• cirrusMltPercentTermsToMatch – Der Prozentwert an Suchbegriffen, die übereinstimmen 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 die Vorlage Featured article („Ausgewählter Artikel“) mit 1 Million Prozent Verstärkung bewertet würde, würden bei einer Suche nach Begriffen, die zufällig in solchen ausgewählten Qualitätsartikeln vorkommen, diese Artikel sogar vor dem einen Artikel, der genau diese Begriffe zum Thema hat, einsortiert werden.

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:

Versuche, soweit irgend möglich, eine reine Regex-Suche insource:/regex/ zu vermeiden. Sie wird wahrscheinlich nach 20 Sekunden abgebrochen werden und nur ein Teilergebnis präsentieren, währenddessen sie die Suchanfragen anderer, verantwortungsbewusster Nutzer blockiert.

Eine einfache indexbasierte Suche findet Wörter, die sichtbar auf einer Seite dargestellt werden. Satz- und andere Interpunktionszeichen, Klammern, Binde- und Schrägstriche sowie mathematische oder Computersymbole stellen für Wörter nur Wortgrenzen dar. Sie werden generell nicht in einen Suchindex aufgenommen. 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 Grenzen einer indexbasierten Suche zu umgehen, können Regex-Suchen verwendet werden. These specify a regular expression that the raw wikitext of the page being searched for has to match.

How regex searches work

On large wikis with millions of pages, running a regular expression on every single one (or every single one in a set of namespaces) would be impossible to implement efficiently. In order to optimize regex searches, the search system attempts to extract three-character sequences of text that any string matching the regular expression must also contain. These are known as trigrams. For example, the regex foo(bar|baz)? can only match strings starting with "foo".

If any such trigrams are found, they are checked against a separate index of all pages' wikitext, and the regex is only run on pages containing the relevant trigrams. If at least one trigram is relatively rare, such as ||}, then the search will complete relatively fast – searching for that on this wiki completes in only a few seconds.

On the other hand, if trigrams cannot be extracted from a regex (possibly because the regex is too complicated to parse or doesn't require the wikitext to contain any specific 3-character strings), or the only trigrams that can be extracted are extremely common (like the), then the domain of pages to run the regex on will be extremely large. The search system has to scour these character-by-character, which is very slow and likely to time out (resulting in incomplete results).

Using the index first to filter results

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 oft hilfreich.
• 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.

Zum Beispiel passen die folgenden kursiv dargestellten Regex-Ausdrücke zu einer spezifischen Zeichenfolge, deren Suchbereich durch die einen fett dargestellten indexbasierten Suchfilter eingeschränkt wird:

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

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 Ausdruck passt, wird im Suchergebnis hervorgehoben. Es werden diese Seite (in der Datenbank) und ihre Unterseiten durchsucht, sofern vorhanden.

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

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

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.

Regular expression syntax

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

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. Add a regex term, rather than search with a bare regex, when possible. Start by noting the number of pages in a previous search before using an exact string search. Querying with an exact string is best with a filtered search domain.

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:

• 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 $ sind nur für intitle://-Suchen erhältlich, aber nicht für insource://. Bei der Titelsuche stehen ^ und $ dafür, dass die Suche mit dem Beginn beziehungsweise dem Ende des Titels übereinstimmen muss. So wie grep eine globale Suche je Zeile mit einem regulären Ausdruck und Anzeige der übereinstimmenden Zeilen darstellt (global per line, regular expression, print each line), bewirkt insource:/…/ eine globale seitenweise Suche mit einem regulären Ausdruck und Anzeige der übereinstimmenden 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>.

Zeichenklassen

Die Regex-Suche unterstützt eine minimale Anzahl von Zeichenklassen. Während negierte Klassenkürzel wie \W nicht verfügbar sind, können die Klassen als Teil einer Zeichenklasse wie in [^\w] negiert werden.

CirrusSearch	Beschreibung
\w	Passt zu jedem alphanumerischen ASCII-Zeichen und dem Unterstrich. Äquivalent zu [A-Za-z0-9_]
\s	Passt zum Leerzeichen und weiteren Unicodezeichen für Leerraum. Äquivalent zu [\f\n\r\t\v\u0020\u00a0\u1680\u2000-\u200a\u2028\u2029\u202f\u205f\u3000\ufeff]
\d	Passt auf jede Ziffer. Äquivalent zu [0-9]

Maskierungscodes

Die Regex-Suche unterstützt auch eine geringe Anzahl an Maskierungscodes, die es ermöglichen, nach nicht-druckbaren Zeichen zu suchen.

CirrusSearch	Beschreibung
\r	Wagenrücklauf (Carriage return, CR)
\n	Zeilenvorschub (Line Feed, LF; auch New Line)
\t	Tabulatorzeichen
\uHHHH	Kann für jedes Unicode-Zeichen stehen. Es müssen genau 4 Hexadezimalzeichen für den Codepoint angegeben werden. Zeichen außerhalb der BMP (U+10000 bis U+10FFFF) werden durch zwei direkt aufeinander folgende Sequenzen dargestellt. Die Suche nach einer halben Sequenz wird keinen Treffer ergeben.

Escaping metacharacters

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:/regex/). 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 Ausdrucks 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. Regexes are sensitive to space characters, so copying from snippets is dangerous.

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>"/
• insource:"</references>" insource:/\<\/references>/

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
• 3D

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 $2 und anderen Wikimedia-Präsenzen, die Wikibase verwenden, etwa bei der Bildersuche mittels Strukturierter Daten in $4. This is useful on Wikidata and other Wikibase sites, including to search for images with Structured data on 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:

• https://www.mediawiki.org/w/index.php?search=foo&sort=last_edit_desc

Erlaubte Sortiervorgaben sind:

&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=random

zufällig

&sort=relevance

Eine Relevanz-Sortierung, die viele Merkmale des Dokuments in Betracht zieht

&sort=title_natural_asc

Sort by title ascending

&sort=title_natural_desc

Sort by title descending

&sort=user_random

Randomized, but stable per user. Each user will see a unique, seemingly random order of results, but that order will remain the same every time that specific user runs the same search.

&sort=none

Unsortierte Liste mit willkürlicher Reihenfolge. Bevorzugt für umfangreiche Ergebnismengen.

Interaktion von Suchoptionen

Einige Suchoptionen, können, wenn sie gemeinsam eingegeben werden, eine andere Option beeinflussen oder deren Ergebnis verändern im Vergleich zur alleinigen Nutzung.

• Search options that impact relevance such as prefer-recent, boost-templates, and boost-neartitle have no effect when sort is not relevance. Keyword morelike may have marginal impact.

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

• Extension:CirrusSearch/de
• CompletionSuggester – Vervollständigungsvorschläge, die inkrementelle Besonderheit der Suche mit CirrusSearch
• Wikimedia Search Platform/Search/Glossary – Definitionen, Kontext und Links zu suchebezogenen Begriffen.
• 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)
• Vollständige Spezifikationen in den Browsertests der Erweiterung As of 2017
• Extension:CirrusSearch/Profiles – Zusammenstellung von anpassbaren Parametern, die verschiedene Aspekte der Indexierung beeinflussen
• Wikimedia-Blogartikel zum Thema Suche
• Globale WMF-Suche