Wikipedia:Umfragen/Technische Wünsche 2017/Suchen

Umfrage Technische Wünsche 2017

Rubrik „Suchen“

Lesen  •   Suchen  •   Bearbeiten  •   Wartung  •   Beobachten & Benachrichtigen  •   Soziales  •   Schwesterprojekte  •   Mediendateien  •   Projekte ehrenamtlicher Entwickler  •   Sonstiges

Bitte nicht mehr abstimmen - diese Umfrage ist abgeschlossen. Herzlichen Dank an alle, die Vorschläge eingereicht, abgestimmt und die Umfrage mit fachlichem Rat begleitet haben.

Sprachen-Links auf der Suchseite (und vielleicht auch auf anderen Spezial-Seiten)

Was ist das Problem?

Die Standard-"Suchseite“ hat keinen Links zu den in anderssprachigen Wikipedias: Es gibt zwar links im Menü den Punkt "Sprachen" aber da steht nichts. Mein Workflow ist im Moment auf die Hauptseite zu wechseln, dort die Sprache zu ändern und dort von Neuem zu suchen.

Mittlerweile erhält man teils die anderssprachige Ergebnisse: "Suchergebnisse von der englischsprachigen Wikipedia" und bei wenigen Ergebnissen "...suche nach „BlaBla“ in anderssprachigen Wikipedias". Das ist schön und hat mich sehr gefreut; aber warum die Sprachlinks nicht da einbinden wo sie hin gehören und sonst auch immer sind - links im Menü unter der Überschrift "Sprachen".

Wen betrifft das Problem besonders?

Jeder, der mehr als eine Sprache spricht, und sich ein durchgängiges Seiten-Design wünscht (und von einer Menü-Überschrift die gar keinen Inhalt hat Design-Augenkrebs bekommt).

Lösungsvorschlag

Auf dieser Seite links im Menü unter der Überschrift "Sprachen" die anderen Sprachen anbieten. (Wenn alle zu viel sind, genügen vielleicht nur die 10 größten Wikis.)

Anmerkungen

Das gleiche Problem gibt es im Prinzip auf allen Spezialseiten. Warum kann ich nicht von meiner „Beobachtungsliste“ über einen Sprachen-Link zu meiner „Watchlist” im en-Wiki?

Vorschlagende Person

Jahobr (Diskussion) 19:42, 29. Mai 2017 (CEST)

Diskussion

@Jahobr: Mit Benutzer:Schnark/js/specialinterwiki lässt sich das bereits heute einrichten. --Flominator 08:24, 30. Mai 2017 (CEST)

Danke für den Hinweis. Eine Skript-Modifikation für technisch versierte angemeldete Benutzer löst mein grundlegendes Anliegen allerdings nicht. 99% der Nutzer sind nicht angemeldet; ich bin es auf der Arbeit (meist) auch nicht. Es zeigt aber wie simpel das ins grundlegende MediaWiki integrierbar wäre. --Jahobr (Diskussion) 09:03, 30. Mai 2017 (CEST)

Zu deiner Anmerkung: Die "crosswiki watchlist" ist derzeit in Arbeit - d.h. man wird sich dann in einem Wiki auch die Einträge auf den Beobachtungslisten anderer Wikis anzeigen lassen können. Es ist noch nicht klar, wann die Arbeit an dem Projekt fertig sein wird. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 09:53, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Jahobr (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 13:47, 19. Jun. 2017 (CEST)
3.  Pro Zabia (Diskussion) 16:58, 20. Jun. 2017 (CEST)
4.  Pro --Bluemel1 (Diskussion) 13:47, 21. Jun. 2017 (CEST)
5.  Pro Michi 19:09, 21. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 19:17, 21. Jun. 2017 (CEST)
7.  Pro --NearEMPTiness (Diskussion) 21:34, 21. Jun. 2017 (CEST)
8.  Pro -- P.W. Siebert (Diskussion) 21:43, 21. Jun. 2017 (CEST)
9.  Pro --GodeNehler (Diskussion) 19:19, 22. Jun. 2017 (CEST)
10.  Pro --Konfressor (Diskussion) 20:38, 22. Jun. 2017 (CEST)
11.  Pro -- Dostojewskij (Diskussion) 21:15, 22. Jun. 2017 (CEST)
12.  Pro --Atamari (Diskussion) 14:12, 23. Jun. 2017 (CEST)
13.  Pro --Querstedt (Diskussion) 18:32, 23. Jun. 2017 (CEST)
14.  Pro --Cmecklen67 (Diskussion) 09:46, 24. Jun. 2017 (CEST)
15.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
16.  Pro --Silas1989 (Diskussion) 00:39, 27. Jun. 2017 (CEST)
17.  Pro Request dafür haben wir schon länger: [1] --Azaël (Diskussion) 17:10, 29. Jun. 2017 (CEST)
18.  Pro --aVogg (Diskussion) 18:40, 29. Jun. 2017 (CEST)
19.  Pro klingt nicht allzu schwierig... -- hgzh 19:20, 29. Jun. 2017 (CEST)
20.  Pro --Sebastian Wallroth (Diskussion) 21:30, 29. Jun. 2017 (CEST)
21.  Pro --Warichnich (Diskussion) 12:12, 30. Jun. 2017 (CEST)
22.  Pro --Hartmann Linge (Diskussion) 13:49, 30. Jun. 2017 (CEST)
23.  Pro Vor allem auch weil die Englische Wikipedia mehr Content hat. Was ich mir wünschen würde wäre eine Einstellung, die es erlaubt auf der Webseite und in der App mehrsprachig zu suchen. Wenn man was englisches eingibt kommen eben nur Ergebnisse aus dem Englischem Wikipedia und umgekehrt. --Fixuture (Diskussion) 18:14, 1. Jul. 2017 (CEST)
24.  Pro --ProloSozz (Diskussion) 20:19, 1. Jul. 2017 (CEST) (NB: zu diesem Thema wurden noch weitere Lösungsvorschläge eingereicht)
25.  Pro --alexscho (Diskussion) 00:13, 2. Jul. 2017 (CEST)
26.  Pro --Hanekomi (Diskussion) 00:49, 2. Jul. 2017 (CEST)
27.  Pro -- X:: black ::X (Diskussion) 13:02, 2. Jul. 2017 (CEST)
28.  Pro --Horst Emscher (Diskussion) 17:18, 2. Jul. 2017 (CEST)
29.  Pro -- Mr N (Diskussion) 21:15, 2. Jul. 2017 (CEST)
    
    

Suche bestimmter Werte in Vorlagen ermöglichen

Was ist das Problem?

Es ist bisher nicht möglich, gezielt nach Daten zu suchen, die schon innerhalb von Vorlagen strukturiert vorliegen. Beispielsweise sollen alle Artikel gefunden werden, die innerhalb der Vorlage:Literatur im Parameter Autor= Goethe nennen oder alle Zitate (Vorlage:Zitat) von Lichtenberg oder, etwas komplexer, alle Mitglieder der Leopoldina (Vorlage:Leopoldina) mit einer Mitgliedsnummer zwischen 100 und 150.

Wen betrifft das Problem besonders?

Systematisch arbeitende Autoren, die Lücken füllen wollen, und erfahrenes Wartungspersonal, das so beispielsweise besser Fehler finden kann

Lösungsvorschlag

Cirrus um entsprechende Parameter erweitern (bspw. intemplate: inparameter: o.ä.)

Vorschlagende Person

Mabschaaf 20:29, 29. Mai 2017 (CEST)

Diskussion

Du kannst auch jetzt schon nach Werten in Vorlagenparametern suchen. Das benötigt aber zugegebenermaßen fortgeschrittene Syntax. Nur weiß ich nicht, ob immer noch weitere Suchparameter die Suche wirklich besser machen. Die Hilfe für CirrusSearch (mw:Help:CirrusSearch) ist doch jetzt schon ziemlich groß. Zu Deinen Beispielen:

• : hastemplate:literatur insource:autor insource:goethe insource:/\{\{ *[Ll]iteratur[^}]*Autor *=[^|}]*Goethe/
• : hastemplate:zitat insource:lichtenberg insource:/\{\{ *[Zz]itat[^}]*Lichtenberg/ (vermutlich mit false positives, aber kaum besser möglich, da der Autor auch als unbenannter zweiter Parameter genannt werden kann)
• : hastemplate:leopoldina insource:/\{\{ *[Ll]eopoldina[^}]*\|( *1 *=)? *<100-150> *\|/

Ich denke, man sieht auch, dass die Syntax schon für die Beispiele wegen der unterschiedlichen Parameter individuell angepasst werden musste, so dass ich befürchte, die Programmierung passender Suchparameter wäre sehr aufwendig. — Speravir – 01:53, 30. Mai 2017 (CEST)

@Speravir: Dass man sich mit kryptischen RegEx da einigermaßen hinhangeln kann, ist mir klar. Aber elegant ist das wahrlich nicht, benutzerfreundlich erst recht nicht. Und laienhaft würde ich den Aufwand für die technische Umsetzung des Wunschs als eher gering einstufen, den Gewinn aber eher groß.

Selbstverständlich sind die tatsächlichen Suchprobleme oft komplexer als die hier genannten Beispiele. Dann helfen auch noch komplexere Regex nicht oder führen zu false-positives. Wenn Du bspw. alle Vorlage:GESTIS mit Datum=12. Mai 2017 suchen willst, wirst Du unweigerlich auf Anethol treffen, weil dort Datum=12. Mai 2017 in Vorlage:Sigma-Aldrich steht.--Mabschaaf 17:17, 30. Mai 2017 (CEST)

Nö, nicht gefunden: : hastemplate:gestis insource:"12. Mai 2017" insource:/\{\{ *[Gg]ESTIS[^}]*"12. Mai 2017"/. Dass es nicht an den Suchparametern liegt, siehst Du mit dem richtigen Abrufdatum für Anethol: : hastemplate:gestis insource:"23. Juli 2016" insource:/\{\{ *[Gg]ESTIS[^}]*"23. Juli 2016"/. Aber: Wie tückisch das ist, zeigt sich wenn ich den Parameternamen Datum einfüge: Mit : hastemplate:gestis insource:"23. Juli 2016" insource:/\{\{ *[Gg]ESTIS[^}]*Datum *= *"23. Juli 2016"/ erhalte ich plötzlich keinen Treffer.— Speravir – 19:05, 30. Mai 2017 (CEST)

@Mabschaaf: Hallo! Mit Beginn der Abstimmung (19. Juni) werden die Diskussionen zu den einzelnen Wünschen in dieser Umfrage eingeklappt, damit klar ist, dass man seine Stimme für den Wunsch abgibt und nicht beispielsweise für Vorschläge in den Kommentaren. Falls du denkst, dass die Hinweise in den Kommentaren dabei helfen können, dass alle Lesenden den Wunsch gut verstehen, ergänze sie doch noch in der Beschreibung des Wunsches. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 13:18, 9. Jun. 2017 (CEST)

Warum wird nicht gleich eine "Fortgeschrittene Suche" angeboten, die einem Suchenden die Regexp-Syntax vollständig erspart? Einfache Formularfelder, die bei vom Benutzer darin eingetragenen Werten aktiviert werden und aus denen die Regexp-Suche gebaut wird, scheinen mir kein programmiertechnisches Hexenwerk. Darin kann auch die Suche nach Vorlagen und deren Inhalten geschehen. --Tommes ^✉ 15:24, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Mabschaaf (Einreichende Person)
2.  Pro Schnark 11:28, 19. Jun. 2017 (CEST)
3.  Pro -- X:: black ::X (Diskussion) 13:30, 19. Jun. 2017 (CEST)
4.  Pro --Tommes ^✉ 15:24, 20. Jun. 2017 (CEST)
5.  Pro --Noobius2 (Diskussion) 15:54, 20. Jun. 2017 (CEST)
6.  Pro --FNDE 16:05, 20. Jun. 2017 (CEST)
7.  Pro --Andropov (Diskussion) 16:12, 20. Jun. 2017 (CEST)
8.  Pro --Rjh (Diskussion) 16:16, 20. Jun. 2017 (CEST)
9.  Pro --Aristeas (Diskussion) 17:36, 20. Jun. 2017 (CEST)
10.  Pro --Bluemel1 (Diskussion) 13:53, 21. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 19:17, 21. Jun. 2017 (CEST)
12.  Pro --MGChecker – (📞| 📝| ) 19:54, 21. Jun. 2017 (CEST)
13.  Pro --GodeNehler (Diskussion) 19:20, 22. Jun. 2017 (CEST)
14.  Pro --Atamari (Diskussion) 14:14, 23. Jun. 2017 (CEST)
15.  Pro --Frīheidasliova (FRĀGĀ) 09:04, 24. Jun. 2017 (CEST)
16.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
17.  Pro --DomenikaBo (Diskussion) 21:40, 25. Jun. 2017 (CEST)
18.  Pro--Silas1989 (Diskussion) 00:39, 27. Jun. 2017 (CEST)
19.  Pro -- ɦeph 18:32, 27. Jun. 2017 (CEST)
20.  Pro schöner Traum, stell ich mir aber sehr aufwendig vor. -- hgzh 19:21, 29. Jun. 2017 (CEST)
21.  Pro siehe dazu auch: en:Category:Wikipedia articles by infobox content und Can the contents of the infobox be parsed and searched? --Fixuture (Diskussion) 18:19, 1. Jul. 2017 (CEST)
22.  Pro -- Platte ^{∪∩∨∃∪} 23:26, 1. Jul. 2017 (CEST)
23.  Pro --Zaccarias (Diskussion) 20:07, 2. Jul. 2017 (CEST)
24.  Pro --Ghilt (Diskussion) 09:27, 4. Jul. 2017 (CEST)
    
    

Ausgabe der Cirrus-Suchergebnisse flexibler machen

Was ist das Problem?

Cirrus so erweitern, dass Suchergebnisse auch als Tabelle oder .csv-File und/oder sortiert nach verschiedenen Kriterien (Datum der letzten Bearbeitung, alphabetisch nach Lemma, Datum der Artikelerstellung) ausgegeben werden können. Zur Erstellung von (Wartungs-)Listen oder Tabellen wäre es wünschenswert, die Suchergebnisse in einer entsprechenden Form geliefert zu bekommen, die sich automatisiert weiterverarbeiten lässt. Letztlich spielen hier viele Punkte zusammen:

• Die Ergebnisse sollten (zumindest auf spezielle Anforderung) vollständig sein, keine vorzeitig abgebrochene Suche
• Wenn eine Ausgabe der Suchergebnisse als Tabelle ermöglicht wird, sollte diese auch sortierbar sein.
• In Erweiterung wäre vorstellbar, dass auch die zurückgelieferten Daten der Artikel-Treffer noch konfigurierbar sind: Alle Angaben, die über die Seiteninformationen eines Artikels (URL+&action=info) abrufbar sind, könnten so verfügbar gemacht werden

Der Wunsch orientiert sich an den verschiedenen Ausgabeoptionen von PetScan.

Mögliche Anwendungsfälle:

• Finde die kürzesten Artikel mit Geokoordinate im Raum Eisenach
• Finde die am längsten nicht bearbeiteten Artikel in der Kategorie:Biathlet, die an Verfolgungsrennen teilgenommen haben (oder dieses Wort im Text nennen)

Wen betrifft das Problem besonders?

alle, die (Wartungs-)Listen oder Tabellen erstellen wollen

Lösungsvorschlag

Cirrus um entsprechende Parameter erweitern (bspw. sorted: und format: o.ä.)

Anmerkungen

Wenn dieser Wunsch umgesetzt wird, sollte auch über eine spezielle Funktion nachgedacht werden, die eine vollständige Suche selbst bei höherer Serverbelastung ermöglicht. Tabellen/Listen sind meist nur dann wirklich sinnvoll, wenn alle Treffer genannt werden und die Suche nicht vorzeitig abgebrochen wird.

Vorschlagende Person

Mabschaaf 20:45, 29. Mai 2017 (CEST)

Diskussion

Zu Deiner Anmerkung: Ein Abbruch der Suche geschieht doch eigentlich nur, wenn man eine reine RegEx-Suche durchgeführt hat. Genau das soll man ja aber sowieso nicht tun (na ja, eben wegen der Serverbelastung – und wegen der Serverbelastung erfolgt auch der Abbruch). In der deutschen Hilfe ist das leider nicht so deutlich zu lesen, aber in CirrusSearch-Hilfe auf MediaWiki dafür umso so häufiger und eindringlicher. — Speravir – 02:04, 30. Mai 2017 (CEST)

Benutzer, die Syntaxfixe querbeet in der WP ausführen (so wie Aka Tippfehlerkorrekturen) können Regex-Suchen nicht zusätzlich einschränken. Hier ist eine vollständige Suche essentiell - und sei sie noch so serverbelastend. Wenn man Missbrauch vermeiden will, könnte man dieses Feature ja an den Sichterstatus koppeln, wobei ich persönlich davon nichts halte.--Mabschaaf 17:55, 30. Mai 2017 (CEST)

Hallo Mabschaaf, du hast geschrieben, dass solch eine Ausgabe für die Wartung wichtig ist. Könntest du noch konkreter den Anwendungsfall dahinter beschreiben? Das würde für eine spätere Suche nach einer Lösung enorm helfen. Viele Grüße -- Johanna Strodt (WMDE) (Diskussion) 10:24, 30. Mai 2017 (CEST).

Zur Erstellung von (Wartungs-)Listen oder Tabellen wäre es wünschenswert, die Suchergebnisse in einer entsprechenden Form geliefert zu bekommen, die sich automatisiert weiterverarbeiten lässt. Letztlich spielen hier viele Punkte zusammen:

• Die Ergebnisse sollten (zumindest auf spezielle Anforderung) vollständig sein, keine vorzeitig abgebrochene Suche
• Wenn eine Ausgabe der Suchergebnisse als Tabelle ermöglicht wird, sollte diese auch sortierbar sein.
• In Erweiterung wäre vorstellbar, dass auch die zurückgelieferten Daten der Artikel-Treffer noch konfigurierbar sind: Alle Angaben, die über die Seiteninformationen eines Artikels (URL+&action=info) abrufbar sind, könnten so verfügbar gemacht werden

Der Wunsch orientiert sich an den verschiedenen Ausgabeoptionen von PetScan.

Mögliche Anwendungsfälle:

• Finde die kürzesten Artikel mit Geokoordinate im Raum Eisenach
• Finde die am längsten nicht bearbeiteten Artikel in der Kategorie:Biathlet, die an Verfolgungsrennen teilgenommen haben (oder dieses Wort im Text nennen)

Viele Grüße --Mabschaaf 17:55, 30. Mai 2017 (CEST)

Diese Erweiterung wäre mir auch sehr lieb, siehe nächsten Punkt! --Alva2004 (Diskussion) 17:12, 30. Mai 2017 (CEST)

@Mabschaaf: Danke! Ich war so frei, deine Ergänzungen der Problembeschreibung hinzuzufügen, weil die Diskussion zur Abstimmung ausgeblendet wird. Du kannst natürlich noch umformulieren, aber so sind sie schon mal „gerettet“.-- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:10, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Mabschaaf (Einreichende Person)
2.  Pro --Rjh (Diskussion) 16:17, 20. Jun. 2017 (CEST)
3.  Pro --Aristeas (Diskussion) 17:42, 20. Jun. 2017 (CEST)
4.  Pro --FriedhelmW (Diskussion) 19:48, 20. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 19:18, 21. Jun. 2017 (CEST)
6.  Pro --Alva2004 (Diskussion) 13:43, 24. Jun. 2017 (CEST)
7.  Pro --Leyo 01:11, 25. Jun. 2017 (CEST)
8.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
9.  Pro -- hgzh 19:22, 29. Jun. 2017 (CEST)
10.  Pro --Zaccarias (Diskussion) 20:07, 2. Jul. 2017 (CEST)
    
    

Beim Werkzeug "Links auf diese Seite" für alle Artikel auf einmal das vollständige Sprungziel ausgeben.

Was ist das Problem?

Wenn ich in einem Artikel auf den viele andere Artikel verlinken, beispielsweise Bernoulli-Gleichung, die Überschrift "== Bernoulli ==" ändern möchte, ist es mühsam herauszufinden, welche Artikel beispielsweise mittels "[[Bernoulli-Gleichung#Bernoulli|Daniel Bernoulli]]" hierauf verlinken.

Zum einen liefert "Links auf diese Seite" eine Liste von max. 500 Artikeln, die auf Bernoulli-Gleichung verlinken, dort steht aber nicht die Sprungadresse. Ich müsste also jeden Artikel einzeln öffnen und nach "Bernoulli-Gleichung#Bernoulli" suchen.

Zwar funktioniert insource:/\[\[Bernoulli-Gleichung\#Bernoulli/, ist aber bei Sonderzeichen und vielen Treffern auch umständlich.

Wen betrifft das Problem besonders?

Menschen, die vorhandene Artikel bearbeiten.

Lösungsvorschlag

In der Funktion "Links auf diese Seite" die vollständige Sprungadresse ausgeben. Im Beispiel [[Bernoulli-Gleichung#Bernoulli|Daniel Bernoulli]] wäre die Ausgabe "Bernoulli-Gleichung#Bernoulli" wünschenswert.

Vorschlagende Person

Alva2004 (Diskussion) 11:09, 30. Mai 2017 (CEST) Zabia (Diskussion) 19:24, 9. Jun. 2017 (CEST)

Diskussion

Aktuell gibt es dafür Benutzer:Flominator/Contexter. (Konkret also so.) Wäre aber schöner, wenn diese Funktionalität in MediaWiki integriert werden könnte. --Schniggendiller Diskussion 17:45, 30. Mai 2017 (CEST)

Lieber Schniggendiller, Vielen Dank! Damit kann ich arbeiten! :))) --Alva2004 (Diskussion) 08:44, 31. Mai 2017 (CEST)

@Alva2004, Johanna Strodt (WMDE): Ja. Genau das meine ich auch. Ich will jene Artikel da finden, die den Anker betreffen. In meinem Projekt BLKÖ verlinke ich tausende dieser Anker, da ist es mühsam, da rumzusuchen, vor allem wenn es einfach gehen könnte. Die Lösung von Schniggendiller ist für mich leider nichts, eher das komplizierte: (insource:/\[\[BLKÖ:Löw von Löwenberg, Leonhard\#Löw von Löwenberg, Nikolaus der Aeltere/ in Wikisource. Zabia (Diskussion) 19:24, 9. Jun. 2017 (CEST)

Unterstützung

1.  Pro Alva2004 (Einreichende Person)
2.  Pro Zabia (Einreichende Person)
3.  Pro -- Peter Gröbner -- 17:01, 20. Jun. 2017 (CEST)
4.  Pro --HerrAdams (D) 18:42, 20. Jun. 2017 (CEST)
5.  Pro --Bluemel1 (Diskussion) 13:54, 21. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 19:18, 21. Jun. 2017 (CEST)
7.  Pro --GodeNehler (Diskussion) 19:21, 22. Jun. 2017 (CEST)
8.  Pro --Cm95 (Diskussion) 11:18, 25. Jun. 2017 (CEST)
9.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
10.  Pro --Mushushu (Diskussion) 16:15, 25. Jun. 2017 (CEST)
11.  Pro --DomenikaBo (Diskussion) 21:41, 25. Jun. 2017 (CEST)
12.  Pro -- hgzh 19:22, 29. Jun. 2017 (CEST)
13.  Pro —DerHexer (Disk., Bew.) 21:26, 29. Jun. 2017 (CEST)
14.  Pro --Sebastian Wallroth (Diskussion) 21:32, 29. Jun. 2017 (CEST)
15.  Pro --Warichnich (Diskussion) 12:15, 30. Jun. 2017 (CEST)
16.  Pro Das wäre wirklich sehr nützlich. Siehe dazu auch: "What links here" for article sections. Ich würde diese Verbesserung relativ hoch priorisieren. Ebenfalls nützlich wäre eine Option zur Exklusion von Links auf diese Seite, die nur von einem Template auf die Seite verlinken. --Fixuture (Diskussion) 18:36, 1. Jul. 2017 (CEST)
17.  Pro -- X:: black ::X (Diskussion) 11:41, 2. Jul. 2017 (CEST)
    
    

Standard-Suchfeld verbessern

Was ist das Problem?

Zur Zeit führen meine Wege häufig zu Google&co, weil es effizienter ist, obwohl ich eigentlich nur Wikipedia lesen will.

Der Zugang zum Suchfeld mit der Maus ist nach dem Scrollen im Artikel ineffizienter als die Adress- und Suchleiste, die doch meist mit Google&co vorbelegt ist. Die Tab-Taste führt nur manchmal zum Suchfeld, also faktisch nutzlos. Und das öffnen einer neuen reinen Suchseite die schnell lädt ist nahezu unmöglich (Sucheseite)

Verbesserungspotential ist gegeben und wir sollten unsere Leser (= Spender und Autoren) binden und nicht ständig zu Google&co schicken.

Wen betrifft das Problem besonders?

Vielleser, Autoren bei der Themenumfeld rechreche

Lösungsvorschlag

Das erste Drücken der Tab-Taste sollte immer im Suchfeld enden. Hat man auf einer Seite noch nicht rumgeklickt (Inhaltsverzeichnis) ist das ja auch so. Nach einem Raute(#)-Link geht der Sprung zum Suchfeld auch nicht mehr. Damit verliert die Verwendung der Tab-Taste ihre Funktion, da man nie weiß, ob die jetzt gerade funktioniert.

Eigentlich sollte jede Tastatur-Eingabe sofort zum Suchfeld führen, denn es gibt ja per Definition keine weiteren Eingabemöglichkeiten für Leser. Speziell gilt das für die Hauptseite, die gerne Startpunkt einer Wikipedia-Suche dient, denn die blanke Suchseite ist nicht wirklich zugänglich als Lesezeichen (und funktioniert anderst als das Standard-Suchfeld).

Interessant wäre auch ein Suchfeld, das mit-scrollt und somit immer sichtbar und zugänglich ist. Vielleicht auch einfach nur eine transparente Lupe die mit einem Klick zum Suchfeld wird oder erst sichtbar wird, wenn der Mauszeiger in der nähe der Bildschirmecke ist. Weitere Möglichkeit wäre, das beim hochscrollen (Mausrad, Pfeiltasten, etc.) ein Suchfeld eingeblendet wird.

Schöne wäre es auch wenn der Wikipedia-Ball mit-scrollt. Das schaut nicht nur schön aus (Bildschirme sind heute groß genug) sondern man kann leicht einen neuen Reiter mit einer zweiten Wikipedia-Suche öffnen.

Die Lösungsvorschläge sind nur eine kleine Ideensammlung. Es sollen somit verschiedene Möglichkeiten zur leichteren Nutzbarkeit des Standard-Suchfelds ermittelt, evaluiert und umgesetzt werden.

Anmerkungen

keine

Vorschlagende Person

Menner (Diskussion)

Diskussion

Oder das Suchfeld könnte direkt den "Fokus" haben, damit man gleich lostippen kann. Siehe hier 3 Vorschläge weiter unten.

toko~dewiki

@Toko~dewiki: Deinen Vorschlag finde ich zu spezifisch. Eine Verbesserung an so einer zentralen Funktion sollte offen angegangen werden. Den Umsetzenden sollte kreativer Spielraum gelassen werden. Die sind ja nicht dumm, sondern können selbst erst Handeln, wenn sie einen Auftrag bekommen. Somit findet sich auch dein Vorschlag in meiner Ideensammlung. -- Menner (Diskussion) 10:25, 4. Jun. 2017 (CEST)

@Menner: Danke für den Vorschlag! In der Lösungsbeschreibung nennst du auch einige Probleme, die sich sehr gut für die Problembeschreibung eignen würden. Was hälst du davon, zum Beispiel den ersten Absatz (ohne den ersten Satz) dorthin umzusiedeln? Und bei der Problembeschreibung auch zu erwähnen, dass es aktuell nicht gut möglich ist, eine zweite Wikipediasuche zu starten, wenn man schon etwas tiefer im Artikel ist (wenn ich dich da richtig verstanden habe ;) ). Viele Grüße, Lea Voget (WMDE) (Diskussion) 15:30, 31. Mai 2017 (CEST)

Anmerkung eingearbeitet -- Menner (Diskussion) 10:11, 4. Jun. 2017 (CEST)

Siehe auch #Beim Laden der WP Seite sollte das Suchfeld automatisch den Cursorfokus haben. Der Umherirrende 17:14, 31. Mai 2017 (CEST)

@Menner: Die Aussage „Bildschirme sind heute groß genug“ trifft auf die allermeisten tragbaren Geräte nicht zu – und es gibt Menschen, die auch auf diesen nicht die mobile Vversion benutzen wollen, wei deren Funktionsumfang eingeschränkt ist (siehe unter Anderem die ganzen Wünsche zur Verbesserung der molbilen Version) – daher sollten meiner Meinng nach alle mitscrollenden Suchelemente nur als Opt-In für angemeldete Benutzer realisiert werden. Es fehlt aber in den Menüs (entweder oben oder links) ein Link zur Spezialseite Spezial:Suche, der beim daraufklicken automatisch in enem neuen Tab öffnet (ein solcher Link kann bei Bedarf hinter ein kleines platzsparendes Symbol gelegt werden, insbesondere, wenn er in obenren Menü eingebaut wird). --X:: black ::X (Diskussion) 12:07, 2. Jul. 2017 (CEST)

Unterstützung

1.  Pro Menner (Einreichende Person)
2.  Pro --Bluemel1 (Diskussion) 13:57, 21. Jun. 2017 (CEST), zu: die erste Tab-Taste landet im Feld „Suche“
3.  Pro --Thomas Obermair 4 (Diskussion) 19:18, 21. Jun. 2017 (CEST)
4.  Pro --GodeNehler (Diskussion) 19:21, 22. Jun. 2017 (CEST)
5.  Pro --Konfressor (Diskussion) 20:38, 22. Jun. 2017 (CEST)
6.  Pro --Nichtich (Diskussion) 22:17, 23. Jun. 2017 (CEST)
7.  Pro --Cmecklen67 (Diskussion) 09:50, 24. Jun. 2017 (CEST)
8.  Pro --Alva2004 (Diskussion) 13:46, 24. Jun. 2017 (CEST)
9.  Pro --Christian (Diskussion) 19:45, 24. Jun. 2017 (CEST)
10.  Pro ----Cd1973 (Diskussion) 21:58, 24. Jun. 2017 (CEST)
11.  Pro --Hajotthu (Diskussion) 09:23, 27. Jun. 2017 (CEST)
12.  Pro --Sebastian Wallroth (Diskussion) 21:34, 29. Jun. 2017 (CEST)
13.  Pro —SDKmac (Disk., Bew.) 02:35, 30. Jun. 2017 (CEST)
14.  Pro --WaltR (Diskussion) 05:07, 30. Jun. 2017 (CEST)
15.  Kontra --Warichnich (Diskussion) 12:24, 30. Jun. 2017 (CEST) sehe kein Problem mit der Sucheseite, ansonsten sollte vllt. die verbessert werden.
16.  Kontra --ProloSozz (Diskussion) 20:28, 1. Jul. 2017 (CEST) Von "herumwandernden Suchfeldern" halte ich nicht viel; zudem will sollte viel mehr die "nackte Texteingabe" eine Text-finden-Funktion ermöglichen. A propos Suchfeld: Spezifische Suche wäre wünschenswert (Wildcards, Textteile, Kombination mehrere Wörter etc.)
    
    

Zufälliger Artikel nach Portal

Was ist das Problem?

Ich nutze gerne den Link "Zufälliger Artikel", da man da sehr interessante Artikel finden kann, auch wenn man nun keinen spezifischen Anhaltspunkt hat. Allerdings kommt dann sehr oft eine Biographie oder ein Ort, der mich nicht interessiert. Ich würde gerne einen zufälligen Artikel aus einem Portal (z.B. Technik) erhalten.

Wen betrifft das Problem besonders?

Leute, die etwas Wissenswertes erfahren wollen, deren Interesse aber auf gewisse Themengebiete beschränkt ist.

Lösungsvorschlag

Es gibt bereits ein Skript von erwin85, welches einen zufälligen Artikel aus einer Kategorie finden kann: https://tools.wmflabs.org/erwin85/randomarticle.php Allerdings sind Kategorien noch sehr spezifisch für einen zufälligen Artikel.

Es gibt auch eine Spezialseite für Kategorien: Spezial:Zufällig in Kategorie, welche aber keine Unterkategorien mit betrachtet. Da Portale die Artikelzugehörigkeit über Kategorien definieren, wäre ein möglicher Lösungsansatz auch, dass die Spezialseite Unterkategorien betrachtet. Der Umherirrende 17:10, 31. Mai 2017 (CEST)

Vorschlagende Person

Simon Dörrer (Diskussion) 22:02, 30. Mai 2017 (CEST)

Diskussion

Es gibt auch eine Spezialseite für Kategorien: Spezial:Zufällig in Kategorie, welche aber keine Unterkategorien mit betrachtet. Da Portale die Artikelzugehörigkeit über Kategorien definieren, wäre ein möglicher Lösungsansatz auch, dass die Spezialseite Unterkategorien betrachtet. Der Umherirrende 17:10, 31. Mai 2017 (CEST)

@Simon Dörrer: Hallo Simon, möchtest du den Lösungsansatz vom Umherirrenden noch oben unter „Lösungsansatz“ ergänzen? Hintergrund: Die Diskussionen zu den Wünschen werden zu Beginn der Abstimmung (19. Juni) ausgeblendet. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:19, 8. Jun. 2017 (CEST)

Danke! -- Johanna Strodt (WMDE) (Diskussion) 19:51, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Simon Dörrer (Einreichende Person)
2.  Pro Zellmer (Diskussion) 15:24, 20. Jun. 2017 (CEST)
3.  Pro --Noobius2 (Diskussion) 15:55, 20. Jun. 2017 (CEST)
4.  Pro oder zufälliger Artikel in einer Oberkategorie --Uranus95 (Diskussion) 10:05, 21. Jun. 2017 (CEST)
5.  Pro sk (Diskussion) 16:45, 21. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 19:19, 21. Jun. 2017 (CEST)
7.  Pro --Maaatze87 (Diskussion) 00:15, 22. Jun. 2017 (CEST)
8.  Pro --Nichtich (Diskussion) 22:18, 23. Jun. 2017 (CEST)
9.  Pro --DomenikaBo (Diskussion) 21:42, 25. Jun. 2017 (CEST)
10.  Kontra -gpf- (Diskussion) 09:35, 30. Jun. 2017 (CEST)
11.  Pro Ein cooles Feature das zB auch in die App eingebaut werden könnte. Genau derartiges sind die innovativen Verbesserungen, die die Plattform modernisieren würden, neue User anlocken bzw engagieren und Pageviews generieren würden. Außerdem ist es schon zu 80% implementiert, da es mit dem wikitool bereits (so gut wie) möglich ist (zumindest für WikiProjects). Zufälliger WikiProject Science Fiction Artikel. (nicht signierter Beitrag von Fixuture (Diskussion | Beiträge) 18:43, 1. Jul. 2017‎)
12.  Pro Definitiv ein Pro. Schon vor einigen Jahren habe ich mal im Technikportal diesen Wunsch angebracht. Er wurde auch umgesetzt (siehe Lesetipps: Zufällig ausgewählter Technikartikel ). Ich fände eine Einbindung einer Suche für kategorie-spezifischen Zufallsartikel auf der Hauptseite sehr sinnvoll. Allerdings könnte ich mir auch eine Spezialseite, wie diese, dafür vorstellen. Allerdings darf diese nicht direkt auf den gefundenen Artikel springen sondern sollte eine Liste zeigen. Die Artikel könnte man dann in einem neuen Tab öffnen und jederzeit zur Suchseite zurückkehren. (nicht signierter Beitrag von Snurb3010 (Diskussion | Beiträge) 15:34, 2. Jul. 2017)
13.  Pro --Ghilt (Diskussion) 09:30, 4. Jul. 2017 (CEST)
    
    

Verfeinerte Suche mittels AND, OR, NOT

Was ist das Problem?

Wenn ich nach dem Bernoulli-Effekt beim Abdecken eines Hauses bei Starkwind suche, bekomme ich jede Menge Seiten die die Begriffe einzeln enthalten. Ich suche aber einen Artikel der alle vier Schlagworte gleichzeitig enthält. Suchmaschinen in Datenbanken haben dafür die Operatoren AND, OR, NOT. Das wünsche ich mir in der Wikipedia auch! Vorbildlich ist imho die DNB Suche.

Wen betrifft das Problem besonders?

Menschen, die in der Wikipedia etwas suchen und sich ein bisschen mit Recherchen auskennen.

Lösungsvorschlag

Es gibt mehrere Möglichkeiten:

• Die Operatoren AND, OR, NOT als Operatoren unterstützen.
• In der erweiterten Suche mehrere Suchfelder implementieren, die mit den Operatoren verknüpft werden können.
• Einzuschränken der Suche auf bereits gefundene Artikel ermöglichen. Sinnvoll ist in diesem Zusammenhang das Abspeichern von Suchergebnissen. Wenn dann eine eingeschränkte Suche in die Irre führte, kann man es mit einer anderen Einschränkung nochmal versuchen.
  Vorschlagende Person

Alva2004 (Diskussion) 12:58, 1. Jun. 2017 (CEST)

Diskussion

Hallo @Alva2004:. Diese Such-Operatoren gibt es bereits. 'Und' ist der Standard, mit '-' kannst du Wörter ausblenden und mit 'OR' kannst du nach entweder-oder suchen. Mehr Infos dazu gibt es unter Hilfe:Suche/Cirrus. Außerdem entwickeln wir gerade eine Erweiterte Suche-Seite mit der diese Suchen über eine einfach zu bedienende Suchmaske genutzt werden können, mehr Infos dazu hier. Ist dein Wunsch damit bereits erfüllt? -- Michael Schönitzer (WMDE) (Diskussion) 13:10, 1. Jun. 2017 (CEST)

Ja, Danke! Fände es prima, wenn diese Möglichkeiten bei der erweiterten Suche kurz erwähnt würden, insbesondere, weil der Wikipedia-Syntax vom Standard abweicht! Beispielsweise wäre eine Zeile wie

Einschränkung mittels UND, - ("nicht"), OR, "Text" (buchstäbliche Suche). Weitere Details finden Sie unter Hilfe:Suche.

Gleich auf einen riesigen Artikel verweisen schreckt (mich) ab. Auch hier ist die DNB-Seite imho vorbildlich! --Alva2004 (Diskussion) 13:25, 1. Jun. 2017 (CEST)

Imho ist die UND-Verknüpfung falsch implementiert und eher eine OR-Verknüpfung. Wenn ich nach "Massenmittelpunkt UND Kegel" suche, bekomme ich die erstaunliche Meldung

Der Artikel „Massenmittelpunkt UND Kegel“ existiert in der deutschsprachigen Wikipedia nicht

Diese Antwort ist irreführend, denn wenn Wikipedia das UND richtig interpretieren würde, dann müsste ja eine Meldung wie "es gibt keinen Artikel, der 'Massenmittelpunkt' und 'Kegel' enthält" oder "es gibt keinen Artikel, der ihren Suchkriterien entspricht" kommen ohne irgendwelche Treffer(listen). Die tatsächliche Antwort suggeriert ganz im Gegenteil, Wikipedia hätte nach einem Artikel Massenmittelpunkt UND Kegel gesucht, den es natürlich nicht gibt, was auch keiner erwarten würde. Die Trefferliste suggeriert weiter eine Suche gemäß "Massenmittelpunkt OR Kegel".

Ratlos klicke ich auf das angebotene Wikipedia:Suchhilfe und bekomme auf der Seite als Links

1. Suchfeld von Wikipedia, was mich wieder an den Ausgangspunkt zurückbringt.
2. Hilfe:Suche, das
   1. ganz oben ein Suchfeld anbietet, was mich wieder an den Ausgangspunkt zurückbringt.
   2. im Abschnitt Hilfe:Suche#Ergebnisse stärker eingrenzen steht dann in der Tabelle in der Zeile "Ast OR Baum" die erstaunliche und falsche Aussage, die Und-Verknüpfung wäre standardmäßig.

Für eine Suchmaschine ist das imho ein klägliches Verhalten!

Ich bin nicht für eine standardmäßige Und-Verknüpfung, sondern für eine standardmäßige OR-Verknüpfung, wie sie im Moment implementiert ist. Wenn man aber nach "Massenmittelpunkt UND Kegel" sucht, dann muss eine echte UND-Verknüpfung mit entsprechend leerer Trefferliste und einer Antwort "es gibt keinen Artikel, der 'Massenmittelpunkt' und 'Kegel' enthält" oder "es gibt keinen Artikel, der ihren Suchkriterien entspricht" kommen.

Außerdem darf nicht behauptet werden, die Und-Verknüpfung wäre standardmäßig. --Alva2004 (Diskussion) 07:45, 5. Jun. 2017 (CEST)

Hallo @Alva2004: die Suche geht derzeit wie folgt vor: Zunächst schaut sie, ob es einen Artikel gibt, der genau so heißt wie das was der Nutzer eingegeben hat. Wenn dies nicht der Fall ist, wird der von dir zitierte Text ausgegeben und der Suchbegriff an die Volltextsuche weitergegeben; erst diese interpretiert die Schlüsselwörter. Der Grund dafür ist, das es ja auch Artikel gibt, die die Schlüsselwörter im Namen enthalten. Das ganze ist etwas verwirrend und die Hilfe-Seite dazu ist sehr lange – deshalb entwickeln wir gerade eine neue erweiterte Suchseite. Schau dir mal das Mokup hier an. Du kannst und Feedback im Phabricator oder hier geben. -- Michael Schönitzer (WMDE) (Diskussion) 13:25, 6. Jun. 2017 (CEST)

Michael Schönitzer (WMDE), davon, dass standardmäßig eine "UND"-Verknüpfung implementiert ist, scheinst Du zu träumen. Und diese absolut unmögliche, unverständliche und total überfrachtete "Suche"-Hilfeseite (die bisher einzige Hilfeseite mit der ich auch nach jahrelanger WP-Arbeit absolut nix anfangen kan), ebenfalls. Suche mal mit den Begriffen "Kugel" und "Mittelpunkt". Da gibt es jede menge Ergebnisse, bei denen nur der eine oder nur der andere Begriff vorkommt. Ich benutze für kompliziertere Suchen, wie Alva2004, ebenfalls Google um gezielt auf der Domain "de.wikipedia.org" zu suchen, da reicht es "Kugel" und "Mittelpunkt" jeweils in Anführungszeichen gesetzt in die Suchzeile zu schreiben und es kommen ausschließlich Ergebnisse in denen beide Begriffe vorkommen.--Ciao • Bestoernesto • ✉ 03:17, 12. Jun. 2017 (CEST)

@Bestoernesto: So nachvollziehbar der Wunsch ist, dass unsere Suche so funktionieren soll, wie man es von Google gewohnt ist: Google ist seit fast 20 Jahren auf Suchen spezialisiert und hat inzwischen über 70.000 Mitarbeiter. Deshalb werden wir nie die Qualität und Funktionsvielfalt von Google erreichen können. Außerdem sind die Algorithmen, die Google nutzt, leider nicht öffentlich.

Was die UND-Verknüpfung angeht: Die UND-Verknüpfung ist bei unserer Suche tatsächlich der Standard, aber es spielt wie gesagt Folgendes dort mit hinein:

1. Im ersten Schritt wird wortwörtlich gesucht, was im Suchfeld steht, also z. B. “Kugel UND Mittelpunkt”. Es wird deshalb zuerst wörtlich gesucht, um Artikel zu finden, die die Schlüsselwörter im Namen enthalten. Dass dieser Schritt aus Nutzersicht verwirrend ist, ist nachvollziehbar, und man kann sicher noch besser darstellen, was hier eigentlich passiert.
2. Im zweiten Schritt sucht die Suche dann nach “Kugel” UND “Mittelpunkt” und findet wie beabsichtigt Seiten, die beide Suchwörter enthalten. Sie werden direkt unter dem Hinweis zur wörtlichen Suche („Der Artikel ‘Kugel UND Mittelpunkt’ existiert in der deutschsprachigen Wikipedia nicht.“) angezeigt.

Du schreibst, dass es bei der Suche nach "Kugel" und "Mittelpunkt" jede Menge Ergebnisse gebe, bei denen nur der eine oder nur der andere Begriff vorkommt. Kannst du den Link auf deine Suche hier ergänzen und Beispiele für betreffende Suchergebnisse benennen? Unsere Recherchen liefern nur Ergebnisseiten, die beide Begriffe enthalten, sowohl mit UND-Verknüpfung als auch ohne UND, auch wenn in der Vorschau nicht immer beide Suchwörter fett hervorgehoben sind.

Ich hoffe, dadurch ist es klarer geworden. Viele Grüße, Michael Schönitzer (WMDE) (Diskussion) 02:54, 16. Jun. 2017 (CEST)

@Alva2004, Bestoernesto: Eine fehlerhafte Hilfeseite ist aber auch nichts, was hierher gehört. Dass muss auf der Diskussionsseite dieser Hilfe angesprochen werden und/oder vermutlich in Wikipedia:Technik/Werkstatt. Ich bin mir unsicher, aber glaube selbst, dass Hilfe:Suche veraltet ist. — Speravir – 22:51, 15. Jun. 2017 (CEST)

@Alva2004: Vielleicht wäre es eine Idee, dass du deinen eher allgemeinen Wunsch etwas eingegrenzt auf den oben beschriebenen ersten Schritt, zum Beispiel dass die wörtliche Suche verwirrend ist und dass das übersichtlicher gemacht werden soll. Du musst dafür noch keine Lösungsideen nennen. Die Diskussion wird übrigens mit Beginn der Abstimmung (19. Juni) eingeklappt. Wenn hier also noch Aspekte drinstehen, die für das Verständnis deines Wunsches wichtig sind, arbeite sie auch in deinen Wunsch mit ein. -- Viele Grüße, Michael Schönitzer (WMDE) (Diskussion) 02:56, 16. Jun. 2017 (CEST)

@Speravir, Michael Schönitzer (WMDE):, vielen Dank für die Hinweise! Die Hilfe ist für mich nur ein Nebenkriegsschauplatz.

Es ist sogar noch schlimmer: Die Suche nach "bezugssystem UND invariant" liefert (manuell formatiert):

• Bezugssystem
  rotierende Bezugssystem zu den beschleunigten Bezugssystemen. Körper, die sich außerhalb der Drehachse befinden, erfahren im rotierenden Bezugssystem eine nach
  25 KB (2.985 Wörter) - 17:01, 28. Apr. 2017
• Beobachter_(Physik)
  Beobachter bedeutet daher im Allgemeinen auch den Wechsel zu einem anderen Bezugssystem und damit zu einer anderen Beschreibung desselben Phänomens. Größen, deren
  12 KB (1.506 Wörter) - 14:23, 2. Mär. 2016
• Turmargument
  ein bewegtes Bezugssystem heißt Galilei-Transformation; ein Naturgesetz, das in jedem ruhenden oder gleichförmig bewegten Bezugssystem die gleiche Form
  2 KB (242 Wörter) - 22:11, 18. Dez. 2013
• Radialsymmetrie
  der das Objekt invariant gegenüber allen Rotationen (also allen Winkeln und allen Achsen durch die Objektmitte) ist. Für ein Bezugssystem ist also nur der
  3 KB (352 Wörter) - 20:09, 15. Mai 2017
• usw.

Das ist die Ausgabe einer Suche nach "Bezugssystem OR UND OR invariant"! Standardmäßig ist also eine OR-Verknüpfung implementiert! Schlimm ist, dass Radialsymmetrie mit allen drei (:@) Worten erst an vierter Stelle erscheint. Ich stelle mir einen python-Pseudocode für die Suche nach "text" wie folgt vor:

if ( 'AND' in text or 'OR' in text or 'NOT' in text or '"' in text ):
    ans = 'Es gibt keinen Artikel der ihren Suchkriterien entspricht'
else:
    ans = 'Der Artikel „text“ existiert in der deutschsprachigen Wikipedia nicht...'
treffer = suche( text )
if treffer == []:
    print ans
else
    print treffer

Dafür braucht es keine 70.000 Mitarbeiter ;) Die Ausgabe ist aber auch zweitrangig. Wichtig ist

1. dass eine UND-Verknüpfung implementiert wird, was noch nicht der Fall ist!!!,
2. dass Artikel, die allen Suchkriterien entsprechen am Anfang der Ausgabe stehen und
3. dss auch keine weiteren Artikel folgen.

Ich persönlich würde die Schlüsselwörter (AND, OR, NOT) der Mixtur (UND, OR, -) vorziehen, weil letzteres nicht dem Standard entspricht.--Alva2004 (Diskussion) 11:17, 16. Jun. 2017 (CEST)

Hi @Alva2004: Ich weiß nicht wie du von deinem Beispiel darauf kommst, dass standardmäßig eine OR-Verknüpfung implementiert sei!? Wenn du dir die Seiten anschaust, wirst du sehen, das alle Treffer alle drei Worte "bezugssystem", "und" und "invariant" enthalten ("und" ist eben kein Schlüsselwort). Das Entspricht einer Oder-Suche. Oder reden wir hier an einander vorbei? -- Michael Schönitzer (WMDE) (Diskussion) 11:50, 16. Jun. 2017 (CEST)

Ok, danke für den Hinweis. Die Frage, wie ich darauf komme, ist schnell beantwortet: Weil mich die Suchergebnisse in die Irre geleitet haben. Ist das erwünscht? Will Wikipedia verwirren oder informieren? Das führt auf einen neuen technischen Wunsch, siehe unten. --Alva2004 (Diskussion) 12:11, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Alva2004 (Einreichende Person)
2.  Pro Zabia (Diskussion) 17:00, 20. Jun. 2017 (CEST)
3.  Pro -- Peter Gröbner -- 17:02, 20. Jun. 2017 (CEST)
4.  Pro --Aristeas (Diskussion) 17:37, 20. Jun. 2017 (CEST) Tatsächlich gibt es diese Funktionalität bereits (siehe Diskussion). Dass aber dieser Wunsch gestellt wurde, zeigt, dass diese Funktionalität bisher zu verborgen ist; und der Verlauf der Diskussion mit allerlei Hin und Her zeigt, dass sie auch nicht einfach und klar zu benutzen ist. Daher würde ich eine klare und sichtbare Implementation für sehr sinnvoll halten, etwa mit einer auf Wunsch (per Klick auf "Mehr...") einblendbaren komplexeren Suchmaske, in der man die Begriffe einzeln eingeben und dann aus kleinen Popup-Menus die Verknüpfungen (und, oder, entweder oder, nicht) wählen kann.
5.  Pro --Mellebga (Diskussion) 08:35, 21. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 19:19, 21. Jun. 2017 (CEST)
7.  Pro Looperz (Diskussion) 02:38, 22. Jun. 2017 (CEST)
8.  Pro --GodeNehler (Diskussion) 19:22, 22. Jun. 2017 (CEST)
9.  Pro --Dan-YELL 17:24, 23. Jun. 2017 (CEST)
10.  Pro --Daniel749 Disk. (ST–WPST) 21:18, 23. Jun. 2017 (CEST)
11.  Pro --Cmecklen67 (Diskussion) auf Wunsch (per Klick auf "Mehr...") einblendbare erweiterte Suchmaske 09:53, 24. Jun. 2017 (CEST)
12.  Pro --Christian (Diskussion) 19:41, 24. Jun. 2017 (CEST)
13.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 23:47, 24. Jun. 2017 (CEST)
14.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
15.  Pro --DomenikaBo (Diskussion) 21:42, 25. Jun. 2017 (CEST)
16.  Pro --Sophiston (Diskussion) 00:29, 27. Jun. 2017 (CEST)
17.  Pro --WaltR (Diskussion) 05:09, 30. Jun. 2017 (CEST)
18.  Kontra -gpf- (Diskussion) 09:42, 30. Jun. 2017 (CEST)
19.  Pro -- Shoeper 18:13, 30. Jun. 2017 (CEST)
20.  Pro Dromedar61 (Diskussion) 14:39, 1. Jul. 2017 (CEST)
21.  Pro Das wäre sehr nützlich und mich wundert es stark, dass das noch nicht möglich ist. Das Suchinterface könnte später noch verbessert werden, so dass das auch normale Nutzer einfach benutzen können (über Buttons / extra Felder oÄ). (nicht signierter Beitrag von Fixuture (Diskussion | Beiträge) 18:45, 1. Jul. 2017)
22.  Pro ProloSozz (Diskussion) 20:31, 1. Jul. 2017 (CEST) Ob dies nun per "AND/OR/NOT" zu bewerkstelligen sei oder per Operatoren wie Pluszeichen, Minuszeichen, etc. lasse ich an dieser Stelle offen.
23.  Pro idealerweise mit der Möglichkeit, komplexere Abfragen mit Klammern zu setzen, so á la ((brot ODER brötchen ODER semmel) UND (aufschnitt ODER butter ODER margarine)) ODER butterbrot ODER canapé --Hanekomi (Diskussion) 00:49, 2. Jul. 2017 (CEST)
24.  Pro -- ist überfällig! Übrigänse: Wieso bekomme ich KEIN Ergebnis, wenn ich nach einer Chemikalie mit der CAS-Nummer suche? Ich habe mir schon mehrfach einen Wolf gegoogelt, nur um im dann endlich aufgefundenen Artikel genau meine CAS wieder zu finden! Merke: Wer sucht, hat gar keine Zeit zu finden! Horst Emscher (Diskussion) 17:23, 2. Jul. 2017 (CEST)
25.  Pro --Zaccarias (Diskussion) 20:08, 2. Jul. 2017 (CEST)
    
    

Artikel-ID in der API-Suche ausgeben

Was ist das Problem?

Wenn man eine Suche mit der API durchführt, kann man lediglich den Seitentitel empfangen, nicht aber die ID.

Wen betrifft das Problem besonders?

Entwickler, Botbetreiber, Wartungsmitarbeiter

Lösungsvorschlag

Die Artikel-ID optional anbieten :-)

Anmerkungen

 Info: Dieser Wunsch wurde im Zuge des Wikimania Hackathons 2017 von einem freiwilligen Entwickler (ShapeOfMatter) umgesetzt. Die Änderung ist seit Ende vergangener Woche aktiv.

• Beispiel für eine Suche
• Ticket auf Phabricator: T172700 (Englisch)

-- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:38, 21. Aug. 2017 (CEST)

Vorschlagende Person

FNDE 01:06, 11. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro FNDE (Einreichende Person)
2.  Pro Conny 22:15, 20. Jun. 2017 (CEST).
3.  Pro sk (Diskussion) 16:46, 21. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 19:22, 21. Jun. 2017 (CEST)
5.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
6.  Pro --Gr1 (Diskussion) 12:34, 29. Jun. 2017 (CEST)
7.  Pro klingt machbar -- hgzh 19:23, 29. Jun. 2017 (CEST)
8.  Pro --Sebastian Wallroth (Diskussion) 21:43, 29. Jun. 2017 (CEST)
9.  Pro -- Shoeper 18:14, 30. Jun. 2017 (CEST)
   
   

Suche von Wörtern in einem Artikel auf der mobilen Seite

Was ist das Problem?

Auf der mobilen Version von Wikipedia sind die einzelnen Abschnitte beim Öffnen eines Artikels zugeklappt. Dadurch kann zunächst über den Browser nicht im Text gesucht werden. Es müssen immer erst alle Abschnitte aufgeklappt werden, um dann die "Suche auf dieser Seite"-Funktion anzuwenden, was sehr umständlich ist.

Wen betrifft das Problem besonders?

Benutzer der mobilen Seite

Lösungsvorschlag

Eine einfache Lösung wäre z.B. ein Button "Alle Abschnitte aufklappen".

Vorschlagende Person

Rewo (Diskussion) 21:47, 11. Jun. 2017 (CEST)

Diskussion

Das ist schon drüben in "Lesen" unter Volltextsuche im mobilen Browser vorhanden --h-stt !? 18:15, 20. Jun. 2017 (CEST)

Ich verwende einen Übersetzungsdienst. Es gibt derzeit eine Funktion im Beta-Modus: https://de.m.wikipedia.org > "Hamburgermenü" > Einstellungen > Beta > Alle Abschnitte expandieren. Für den Fall, dass Sie möchten, dass E-Mail über diese, mobile-l@lists.wikimedia.org wäre eine gute Liste. Entschuldigung für die Kürze! ABaso (WMF) (Diskussion) 20:52, 13. Jul. 2017 (CEST)

Unterstützung

 Info: Wohl Identisch mit Wikipedia:Umfragen/Technische Wünsche 2017/Lesen#Suche im Volltext bei Mobile Leser Falls nicht: bitte Unterschied darstellen und diesen Hinweis entfernen. -- Reise Reise (Diskussion) 10:19, 1. Jul. 2017 (CEST)

1.  Pro Rewo (Einreichende Person)
2.  Pro --Gnom (Diskussion) 17:01, 20. Jun. 2017 (CEST)
3.  Pro Conny 22:15, 20. Jun. 2017 (CEST).
4.  Pro --SkiFreak99 (Diskussion) 00:28, 21. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 19:23, 21. Jun. 2017 (CEST)
6.  Pro -- Dostojewskij (Diskussion) 21:16, 22. Jun. 2017 (CEST)
7.  Pro --Cm95 (Diskussion) 11:19, 25. Jun. 2017 (CEST)
8.  Pro --Sophiston (Diskussion) 00:31, 27. Jun. 2017 (CEST)
9.  Pro --Neptuul (Diskussion) 10:52, 29. Jun. 2017 (CEST)
10.  Pro —DerHexer (Disk., Bew.) 21:30, 29. Jun. 2017 (CEST)
11.  Pro --Jaquento (Diskussion) 02:22, 30. Jun. 2017 (CEST)
12.  Pro -- Shoeper 18:16, 30. Jun. 2017 (CEST)
13.  Pro -- X:: black ::X (Diskussion) 12:30, 2. Jul. 2017 (CEST)
14.  Pro -- Ich würde ja die mobile Seite altenativ einstellen... Spaß beiseite: Ist definitv wünschenswert. Horst Emscher (Diskussion) 17:25, 2. Jul. 2017 (CEST)
15.  Pro -- Mr N (Diskussion) 21:26, 2. Jul. 2017 (CEST)
    
    

Chronologische Sortiermöglichkeit von Treffern in Archiven

Was ist das Problem?

Durchsucht man ein Archiv, geht man in der Regel chronologisch vor. Dies scheint jedoch derzeit hier nicht möglich zu sein – die Wikisuche sortiert die Treffer einer Volltextsuche auch bei Archivseiten nach anderen Kriterien, nicht aber nach dem Zeitpunkt ihres Entstehens. Insofern wäre das sicherlich eine hilfreiche Option für die Archivsuche.

Wen betrifft das Problem besonders?

Alle aktiven NutzerInnen

Anmerkungen

Hinweis von Johanna Strodt (WMDE) (Diskussion) 22:57, 18. Jun. 2017 (CEST):

Nach einer ersten Einschätzung im Team Technische Wünsche zu diesem Wunsch hängt die Machbarkeit stark davon ab, was im Einzelnen gewünscht ist:

1. Für eine Sortierung von Suchergebnisseiten könnte evtl. eine technische Lösung gefunden werden.
2. Das Sortieren von Themen innerhalb der Seiten wäre jedoch sehr viel komplexer und läge außerhalb des Rahmens des Projekts „Technische Wünsche“.
   Vorschlagende Person

Curc (Diskussion) 23:47, 11. Jun. 2017 (CEST)

Diskussion

Für die Archivsuche wird die normale Suche verwendet. Für die Bevorzugung aktueller Treffer gibt es den Suchparameter prefer-recent. Ergänze einmal am Ende einer solchen Suche einfach prefer-recent:1,1. Anders ausgedrückt: Ein weiteres Problem, für das es bereits eine Lösung gibt, nur weiß das offensichtlich kaum jemand. — Speravir – 01:39, 12. Jun. 2017 (CEST)

Auch ich wusste da nichts davon, aber jetzt wo ich es weiß, hilft es mir auch nicht weiter. Was da auf der Hilfe-Seite geschrieben steht, ist wohl von Vollprofis für Vollprofis gemacht, ich steige da nicht durch--Ciao • Bestoernesto • ✉ 06:03, 12. Jun. 2017 (CEST)

Hilft dir mw:Help:CirrusSearch/de#Prefer-recent? — Speravir – 17:50, 12. Jun. 2017 (CEST)

Und ich bin kein Vollprofi, ich habe mich nur anhand der vorhandenen Dokumentation intensiver mit der Suchsyntax befasst. — Speravir – 17:53, 12. Jun. 2017 (CEST)

Könnte man aber mit einer einfachen Checkbox für weniger versierte Benutzer anbieten, oder? --FNDE 19:59, 12. Jun. 2017 (CEST)

Keine Ahnung. Wenn, dann aber per Einbau in die verwendete Vorlage. — Speravir – 23:33, 12. Jun. 2017 (CEST)

@Curc, Bestoernesto, Speravir: Eine Rückfrage zu diesem Wunsch: Wonach genau soll sortiert werden können?

• nach dem Datum der letzten Bearbeitung (prefer-recent)?
• nach dem Zeitpunkt der Archivierung (das wäre nach einer ersten Schätzung nur mit sehr hohem Aufwand möglich)
• oder ist noch etwas anderes gemeint?

Curc, könntest du unter „Was ist das Problem?“ noch mal genauer darauf eingehen, bis heute (15. Juni) Abend? -- Danke und viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:13, 15. Jun. 2017 (CEST)

Johanna Strodt (WMDE), nach dem Zeitpunkt der Archivierung zu suchen, wäre ja ziemlich wenig aussagekräftig, derweil die Archivierung ja manuell oder per Bot mit den unterschiedlichsten Zeitabständen zur letzten Bearbeitung passiert sein kann. Aber eine Sortierung nach der letzten Bearbeitung oder wahlweise der ersten Bearbeitung (also der Erstellung) wäre toll. Meine Idealvorstellung geht dahin, einfach diese Sucheingabe-Maske mit

1. die bereits auswählbaren Namensräume um ankreuzbaren Kästchen zur Archivsuche (soweit Archive existieren) zu erweitern
2. eine zusätzliche Auswahlmöglichkeit "Sortierung" mit a) "keine Sortierung", b) "Sortierung nach letzter Bearbeitung", sowie c) "Sortierung nach erster Bearbeitung", zum Ankreuzen. Das Sahnehäubchen (wäre mir persönlich am interessantesten) wäre: d) "Sortierung nach Benutzernamen"

Nur die Suche über eine solch geartete Eingabemaske (was FNDE vermtl mit Checkbox oder Speravir mit "Einbau in die verwendete Vorlage" meint) ist IMHO von wirklichem arbeitserleichternden und zeitsparenden Nutzen gegenüber bisheriger Methoden. Erst mal stundenlang in Fachchinesisch geschriebene Hilfeseiten durchkauen zu müssen um irgendwelche passenden Suchparameter und Syntaxen rauszufischen und diese nach dem "Try and Error"-System durchzuprobieren ist absolut kontraproduktiv und erfordert locker das dutzendfache an Zeitaufwand gegenüber der Verwendung einer durchdachten und selbsterklärenden Such-Eingabemaske. Besonders dann wenn letztere direkt über einen Schalter [Erweiterte Suche] von jeder x-beliebigen WP-Seite z.B. aus der linken Spalte unter "Werkzeuge" oder rechts oben direkt unterhalb des einfachen Sucheingabe-Feldes jeder Seite, aufrufbar wäre. Dann hätten auch blutige Anfänger unter den aktiven Wikipedianern sowie alle interessierten unter den reinen "Nur-Lesern" eine sehrsehr große Chance zu finden was sie suchen, und das in kürzester Zeit--Ciao • Bestoernesto • ✉ 20:03, 15. Jun. 2017 (CEST)

(BK) Ich wollte nur auf die Möglichkeit mit prefer-recent hinweisen, bei der man übrigens auch nicht volständige Perfektion erwarten darf. — Speravir – 20:05, 15. Jun. 2017 (CEST)

Ich stellte gerade eben fest, dass prefer-recent das Alter des Suchindexes beachtet. Wenn, wie offensichtlich bei den Fragen zur Wikipedia dieses sich auch für ältere Archive ändert (weil der entsprechende Suchindex neu angelegt wurde?), werden Treffer daraus leider vor solchen aus jüngeren Archiven ausgegeben, womit dieser Parameter dann nicht sinnvoll verwendbar ist. Das wäre eventuell etwas, das bearbeitet/geändert werden sollte. — Speravir – 00:25, 16. Jun. 2017 (CEST)

@Curc, Bestoernesto, Speravir: Hier bin ich noch mal. Wir haben uns mit dem Technik-Team noch mal über den Wunsch ausgetauscht und möchten sicherheitshalber noch eine Verständnisfrage stellen:

1. Geht es um die Sortierung von Suchergebnisseiten? (zum Beispiel eine solche?)
   prefer-recent ließe sich hier, wie von Speravir vermutet, tatsächlich nicht sinnvoll nutzen, denn es sortiert nach dem Zeitpunkt, wann der Index für diese Seite zuletzt aktualisiert wurde (also faktisch nach dem letzten Update der Seite). Aber man könnte versuchen, dem Suchindex beizubringen, die Suchergebnisse alphabetisch nach dem Seitentitel zu sortieren, denn viele Archive folgen ja einer solchen Benennungskonvention.
2. Oder sollen auch die einzelnen Themen innerhalb der Seiten chronologisch sortiert werden können? Das wäre tatsächlich sehr, sehr komplex und außerhalb des Rahmens des Projekts „Technische Wünsche“.

Es wäre toll, wenn ihr hier nochmal eure Meinung kundtun könntet. :)

• Wenn 1) gemeint ist, könntet ihr das im Wunsch (z. B. bei „Was ist das Problem?“ noch kurz spezifizieren? (bitte bis Sonntagnachmittag)
• Wenn es um 2) geht, bitte auch bis Sonntagnachmittag Bescheid geben. Dann würde ich den Wunsch nach „Wünsche außerhalb des Projektrahmens“ verschieben.

-- Viele Grüße und dankeschön, Johanna Strodt (WMDE) (Diskussion) 21:44, 16. Jun. 2017 (CEST)

Mal davon abgesehen, dass ich höchstrangig eine wie von mir oben beschriebene Suchmaske bevorzugen würde, deren Beschreibung ja selbsterklärend entsprechende Ergebnisse liefern würde, kann ich mich zu der prefer-recent-Problematik mangels Durchblick nicht weiter groß äußern. Bauchgefühlt macht meines Erachtens nur 2) einen wirklich brauchbaren Sinn.--Ciao • Bestoernesto • ✉ 18:48, 17. Jun. 2017 (CEST)

@Curc: Weil du als Autor des Wunsches dich zu meiner Frage nicht mehr dazu geäußert hast, habe ich eine Anmerkung im Wunsch selbst vorgenommen - unter „Anmerkung“ :). Ich hoffe, das ist okay so. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 22:57, 18. Jun. 2017 (CEST)

Ja, ist gut so! Da ich kein Experte bin, weiß ich auch nicht genau, was jeweils technisch machbar ist. LG--Curc (Diskussion) 22:20, 26. Jun. 2017 (CEST)

Unterstützung

1.  Pro Curc (Einreichende Person)
2.  Pro --Bluemel1 (Diskussion) 13:58, 21. Jun. 2017 (CEST)
3.  Pro --Thomas Obermair 4 (Diskussion) 19:23, 21. Jun. 2017 (CEST)
4.  Pro --Nichtich (Diskussion) 22:19, 23. Jun. 2017 (CEST)
5.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
6.  Pro —DerHexer (Disk., Bew.) 21:32, 29. Jun. 2017 (CEST)
   
   

Bei der Suche Interpunktionszeichen ignorieren

Was ist das Problem?

Bei der Suche, egal ob im Suchfeld rechts oben oder in der Volltextsuche werden aktuell Interpunktionszeichen wie z.B. der Apostroph berücksichtigt. Da verständlicherweise viele Autoren beim Artikel-Schreiben beispielsweise von Galleria d’Arte Moderna (hier mit Apostroph typografisch korrekt) das Apostroph-Ersatzzeichen verwenden (Galleria d'Arte Moderna) findet man bei der Suche je nach verwendetem Zeichen eben auch nur die eine (hier 183 Ergebnisse) oder die andere (hier 106 Ergebnisse) Fassung. Beim Finden von Überschriften ist es hingegen meist egal, da vorausschauende Autoren in der Regel entsprechende Redirects für die unterschiedlichen Schreibweisen der Interpunktionszeichen angelegt haben.

Wen betrifft das Problem besonders?

Es trifft so ziemlich alle aktiven Benutzer wie suchende Leser, die nicht schon mal per Zufall von den typografischen Unterschieden bei Apostroph- oder Bindestrich-/ Gedankenstrich-Wahl gehört oder gelesen haben. Beispielsweise kannte den bei einer spontanen Umfrage im persönlichen Umfeld niemand und alle hielten ausschließlich die auf der "Normal-Tastatur" angebotenen Zeichen als die einzig in Frage kommenden. Somit wären die alle nur beim zweiten oben als Beispiel angeführten Suchergebnis gelandet.,

Lösungsvorschlag

Mal bei den Kollegen von der englischen WP nachfragen, die haben das Problem bereits gelöst. Dort ist es egal welches Interpunktionszeichen man im Suchfeld eingibt, es werden immer alle Varianten ausgegeben.

Anmerkungen

Google-Suchen sind hier besonders tolerant und akzeptieren im Falle des Apostrophs sogar Ejektiv-Zeichen, Prime, einfaches schließendes Anführungszeichen oder Leerzeichen usw, selbst bei "genauer Wortlaut"-Suche. Dies ist in der engl. WP nicht so der Fall, hier werden dann bei der genauen Suche (Suchbegriff in "Anführungszeichen") auch nur exakt die bei der Eingabe verwendeten Zeichen wiedergegeben.

Vorschlagende Person

Ciao • Bestoernesto • ✉ 05:24, 12. Jun. 2017 (CEST)

Diskussion

Hallo Bestoernesto, es ist schade, dass du die Frist verpasst hast, und auch verständlich, dass du dich darüber ärgerst. Aber Ausnahmen wären gegenüber allen anderen Teilnehmenden nicht fair, die sich an die Frist gehalten haben. Daher möchten wir dich bitten, dass du den Wunsch wieder rausnimmst. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 00:07, 17. Jun. 2017 (CEST)

Unterstützung

1.  Pro bestoernesto (Einreichende Person)
2.  Pro --Claell (Diskussion) 19:22, 20. Jun. 2017 (CEST)
3.  Pro --Carolus requiescat (Diskussion) 17:15, 21. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 19:24, 21. Jun. 2017 (CEST)
5.  Pro --GodeNehler (Diskussion) 19:24, 22. Jun. 2017 (CEST)
6.  Pro --Atamari (Diskussion) 14:18, 23. Jun. 2017 (CEST)
7.  Pro --Daniel749 Disk. (ST–WPST) 21:19, 23. Jun. 2017 (CEST)
8.  Pro --Abubiju (Diskussion) 12:07, 24. Jun. 2017 (CEST)
9.  Pro --Alva2004 (Diskussion) 13:46, 24. Jun. 2017 (CEST)
10.  Pro --Cm95 (Diskussion) 11:21, 25. Jun. 2017 (CEST)
11.  Pro --Varina (Diskussion) 14:16, 25. Jun. 2017 (CEST)
12.  Pro --Mushushu (Diskussion) 16:15, 25. Jun. 2017 (CEST)
13.  Pro --DomenikaBo (Diskussion) 21:43, 25. Jun. 2017 (CEST)
14.  Pro --Curc (Diskussion) 22:23, 26. Jun. 2017 (CEST)
15.  Pro --Sophiston (Diskussion) 00:32, 27. Jun. 2017 (CEST)
16.  Pro —DerHexer (Disk., Bew.) 21:32, 29. Jun. 2017 (CEST)
17.  Pro --Sebastian Wallroth (Diskussion) 21:47, 29. Jun. 2017 (CEST)
18.  Pro --Jaquento (Diskussion) 02:25, 30. Jun. 2017 (CEST)
19.  Pro --WaltR (Diskussion) 05:12, 30. Jun. 2017 (CEST)
20.  Pro --Anima (Diskussion) 14:04, 30. Jun. 2017 (CEST)
21.  Pro -- Mboesch (Diskussion) 11:17, 1. Jul. 2017 (CEST)
22. Abwartend --ProloSozz (Diskussion) 23:20, 1. Jul. 2017 (CEST) Muß per Option ein- und Ausschaltbar sein; am besten bei der Suche selbst (d.h. Globaleinstellung in den Benutzereinstellungen setzbar und bei der Suche ankreuzbar, ob ignorieren oder nicht.
23.  Pro --Linopolus (Diskussion) 11:01, 2. Jul. 2017 (CEST)
24. Abwartend. Nur wenn optional, das heißt ein- und ausschaltbar (wie von ProloSozz vorgeschlagen: am besten in den Benutzereinstellungen eine individeuelle Voreinstellung wählbar machen folglich und bei der Suche ad hoc ankreuzbar machen, ob ignoriert wird, oder nicht). --X:: black ::X (Diskussion) 13:01, 2. Jul. 2017 (CEST)
25.  Kontra -- Muss auch mal sein. IMHO erhöht das die Trefferzahl unnötig. Horst Emscher (Diskussion) 17:27, 2. Jul. 2017 (CEST)
26.  Pro --Devotus (Diskussion) 20:38, 2. Jul. 2017 (CEST)
27. Abwartend --Ghilt (Diskussion) 09:32, 4. Jul. 2017 (CEST) als Option gerne