Wikipedia:Verbesserungsvorschläge/Feature-Requests

Auf dieser Seite sollen Feature-Requests gesammelt werden, also Vorschläge, Wünsche oder Forderungen, der Software neue Funktionen hinzuzufügen bzw. eine vorhandene Funktionalität zu ändern. Wenn sie sich durchsetzten, werden sie an die Entwickler weitergeleitet. Durch die so erreichte Zustimmung haben sinnvolle Änderungen eine größere Chance. Umsetzungen finden sich auf Wikipedia:Projektneuheiten.

• Um allgemeine, nicht softwareabhängige Verbesserungsvorschläge zu machen, nutze bitte Wikipedia:Verbesserungsvorschläge.
• Um vermutete Softwarefehler (Bugs) zu melden, wende dich bitte an die Technik-Werkstatt.
• Um einen Vorschlag tatsächlich an die Programmierer weiterzugeben, wird jedoch Phabricator (ehemals: „Bugzilla“) verwendet, wo solche Vorschläge verwaltet werden.

Bitte gebt auf dieser Seite unter »dafür« (pro) oder »dagegen« (contra) eure Stimme ab, welche Feature requests an die Entwickler weitergeleitet werden sollen.

(Mehr Kommunikationsmöglichkeiten auf der Kontaktseite.)

Neuen Beitrag erstellen

… und bitte mit --~~~~ unterschreiben.

Wenn ein Abschnitt abgearbeitet ist, kann er mit {{Erledigt|1=--~~~~}} markiert werden, wodurch er nach fünf Tagen ins Archiv verschoben wird. Anfragen, deren letzter signierter Beitrag mindestens 100 Tage zurückliegt, werden ebenfalls archiviert.
Sollen bereits archivierte Beiträge wieder diskutiert werden, erstellt hier bitte einen neuen Abschnitt mit Verweis auf den archivierten.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 100 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 5 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Dauerbrenner

• Cursor im Suchfeld: Bug 1864 (als Helferlein verfügbar: Einstellungen -> Helferlein -> Cursor-Platzierung auf der Hauptseite immer in der Suchbox)
• Trennung von Artikel und Meta-Daten: In Entwicklung, siehe Wikidata
• Verbesserung der Suchfunktion: Bug 974, Bug 1837 u. a.
• Globale Benutzereinstellungen: Bug 14950 (globale CSS und JS: Bug 13953)
• Timeline aus allen in Texten geschriebenen Datumsangaben – Priorisierung nach Artikelgröße pp
• Beobachtung von Abschnitten: Geplant, siehe Flow

Feature-Requests

Erweiterung zur Anzeige von Einbindungen bei Commons

Nachdem es derzeit bei Wikipedia genauso wie bei Wikimediafremden Wikis keine Möglichkeit gibt, einfach anzuzeigen, welche Bilder oder Dateien von Commons eingebunden sind, wäre eine Erweiterung recht praktisch, sodass es genauso wie die Spezial:Präfixindex anzeigen, wo ich nur die fremden Dateinamen sehe. --K@rl 13:23, 21. Mär. 2013 (CET)

Soeben gefunden: mw:Mentorship programs/Possible projects#Build an interwiki notifications framework and implement it for InstantCommons. Ob und wann ein Google Summer of Code-Student die Idee aufgreift, ist ungewiss. — Raymond ^Disk. 11:04, 23. Mär. 2013 (CET)

danke - man sieht, dass es nicht ein alleiniger Wunsch von mir ist ;-) --gruß K@rl 11:14, 23. Mär. 2013 (CET)

Es müsste als Erweiterung doch möglich sein, dass ich alle verwendeten Dateien als Query abfrage, ob sie lokal oder auf COmmons stehen. Dann sind keine Zugriffe von Commons auf die Fremdwikis notwendig. --K@rl 22:08, 26. Apr. 2013 (CEST)

→Wikipedia:Technik/Werkstatt #API Abfrage - Commonseinbindungen --PerfektesChaos 21:53, 6. Jul. 2013 (CEST)

Wikipedia:Notifications

Die englische Wikipedia hat seit kurzem ein Feature en:Wikipedia:Notifications. Das finde ich sehr praktisch, wird man doch z. B. sofort auf Revertierungen hingewiesen und kann ganz unproblematisch jemandem für eine hilfreiche Zuarbeit mit einem Klick danken. Sinnvoll sicher auch für die deutsche Wikipedia. --Frze (Diskussion) 09:08, 2. Jun. 2013 (CEST)

Das steht im Zusammenhang mit einer weltweiten ausgedehnten Änderung der Benachrichtigungs- und Beo- und Diskussions- und Kommunikationstechnologie.

Die enWP erprobt zurzeit Teile davon auf Praxistauglichkeit; so auch die von dir angesprochenen Komponente.

Nach Ende der Entwicklungen wird dies weltweit auf allen Wikis eingeführt werden. Vorher sind Aktivitäten nicht sinnvoll.

Schönen Sonntag --PerfektesChaos 10:10, 2. Jun. 2013 (CEST)

Danke, Dir auch. --Frze (Diskussion) 10:36, 2. Jun. 2013 (CEST)

Dynamische Listen

Mein Feature-Request läuft unter dem Vorbehalt, nichts von einer solchen Funktion zu wissen. Sollte sie bereits existieren, wäre es nett, mich darauf hinzuweisen ;) Also, kurz zusammengefasst: Ich vermisse dynamische Listen, die viel Arbeit und Koordination ersparen könnten. Derartige Inhalte ließen sich in Fließtext-Artikeln sowie auch als Teil einer größeren Liste verwenden. (Z.B. wenn man Listen über verschiedene Staaten zusammenführen oder vergleichen will. Am wichtigsten wäre aber der Vorteil durch die Synchronität, wie sie ganz allgemein im Web 2.0 vorzufinden ist.

Wie gesagt, die Existenz eines solchen Features erscheint mir so plausibel, dass ich dessen Nichtvorhandensein stark bezweifeln würde. Andererseits würde ich mich nicht melden, wenn ich es in den letzten Jahren irgendwann mal gesehen hätte. Bin gespannt. --Sagehorn (Diskussion) 17:15, 14. Jun. 2013 (CEST)

Ich habe ehrlich gesagt nicht verstanden, was du mit „dynamisch“ meinst. Ich denke, du meinst das, was Wikidata bieten wird. Es wird möglich sein, Listenartikel zu bauen, die im Quelltext nur aus der Einleitung und einer relativ kurzen Vorlage bestehen. Die Listen- oder Tabelleneinträge werden dann aus den in Wikidata vorliegenden Daten erzeugt. --TMg 11:26, 11. Jul. 2013 (CEST)

Spezialseite "Linkliste / Links auf diese Seite" auch für Überschriften und Anker

Es ist nicht möglich, via http://de.wikipedia.org/wiki/Spezial:Linkliste nach Überschriften oder Ankern zu suchen, z.B. nach Links auf "Porsche 911#Stückzahlen". Es wird dann nur nach Verlinkungen gesucht auf das Lemma Porsche 911.

Das Problem ist mir insbesondere in diesem Zusammenhang aufgefallen. Ja, so eine Suche brauche ich (siehe voriger Link), und nein, ich habe nicht vor, in einem lokalen WP-Dump rumzusuchen.

Vielleicht gibt's ja auch nur eine spezielle Schreibweise ('?' statt '#' zwischen Lemma und Anker), die ich nicht kenne?

--arilou (Diskussion) 13:52, 18. Jun. 2013 (CEST)

Der Wunsch ist berechtigt und wurde häufiger geäußert.

Zurzeit ist es nicht über eine Spezialseite realisierbar. Grund: In der Datenbank wird bei jeder Seite anhand jedes Wikilink ein Eintrag angelegt, der den standardisierten Seitennamen des Wiki-Linkziels (nur innerhalb des Projekts) enthält. Alle gleichen Seitennamen teilen sich einen Eintrag. Um deinen Wunsch zu unterstützen, müsste ein optionales zweites Feld oder besser eine Liste von Feldern angelegt werden, worin die geforderten Fragmente dieser Zielseite gespeichert wären.

Ob man bereit wäre, für diesen Wunsch die Datenbanken aller Wikis der Welt zu vergrößern, steht dahin.

Es gibt irgendwo ein Werkzeug und/oder eine Wartungsliste, wo Links auf Fragmente mit fehlendem Ziel zusammengesucht werden.

Dir und allen würde auch ein Werkzeug nützen, das auf Anforderung alle bis zu 500 Treffer der Spezialseite durchgeht und auflistet, ob und wo Fragmente angegeben sind. Gibt es aber mutmaßlich im Moment nicht. Vielleicht in der neuen Tool-Sammlung einmal.

Zu deiner konkreten Problemstellung: Es gibt 40 Seiten mit Porsche-911-„Stückzahlen“. Noch charmanter ist in diesem Sonderfall wäre die Google-Suche nach „BCckzahlen“. Weil Google den HTML-Text liest und nur dort das Encoding der Fragmente St.C3.BCckzahlen erfolgt, kanst du dir recht sicher sein, dass es nur wenige Verlinkungen auf diese Überschrift gibt; es wird momentan sogar nur eine Nikon (TOC) und kein Porsche gefunden.

Letzte Sicherheit böte in der Tat ein Dump, einige Wochen nach einer Umstellung zur Nachbereitung.

LG --PerfektesChaos 10:53, 19. Jun. 2013 (CEST)

Ich hab' die Erklärung zwar nicht 100% verstanden, aber ich bin recht gut im Raten, was du meinst.

Hm, könnte man nicht auch ansetzen bei "Alle gleichen Seitennamen teilen sich einen Eintrag." ? Und das aufheben - statt der "standardisierten Seitennamen" wird eben "Seitenname#Unterlink" abgelegt.

Schade ist, dass das Porsche-Beispiel tatsächlich nur ein Beispiel war, und nicht das konkrete Problem. (Was nun genau mein damaliges konkretes Prob. war, müsst' ich erst wieder nachschauen...) Dieser nette Trick mit dem "BC" ist leider zu spezifisch, aber danke für deinen Einsatz X-)

--arilou (Diskussion) 11:47, 19. Jun. 2013 (CEST)

„Druckversion“ und „als PDF herunterladen“ – Anpassungsmöglichkeiten

Ich fände es sehr hilfreich, wenn man beim Klick auf „Druckversion“ bzw. auf „als PDF herunterladen“ eine Reihe von Anpassungsmöglichkeiten hätte:

• Seitenvorschau,
• Schriftgröße vergrößern/verkleinern
• Schriftart auswählen (zumindest neben der Standard-Serifen-Schrift auch die Standard-WP-Artikelschrift wie im Internet angezeigt
• Knopf für „Bilder ausblenden/einblenden“
• Inhaltsverzeichnis ausblenden/einblenden

--Zulu55 (Diskussion) _Unwissen 16:25, 25. Jun. 2013 (CEST)

Die MediaWiki-Erweiterung, die für die PDF- und Buchausgabe verantwortlich ist, heißt mw:Extension:Collection. Wünsche sollten an die dortigen Entwickler gerichtet werden. Aber Vorsicht, nicht den MediaWiki-Bugzilla dafür verwenden. Die Entwickler sitzen bei Wikipedia:PediaPress und haben ihre eigenen Kommunikationswege (oder auch nicht, beispielsweise geben sie das mieseste Changelog heraus, das ich je gesehen habe). Die Druckansicht ist eine Kernfunktion vom MediaWiki. Beide Funktionen werden über CSS gesteuert (nachdem erst im März diesen Jahres mehrere Sonderfunktionen der Collection-Erweiterung wortlos weggefallen sind), vgl. MediaWiki:Print.css. Das heißt, alle deine Wünsche sind mit benutzerdefiniertem CSS möglich. Das funktioniert zum Teil jetzt schon, siehe en:Help:User style#Print view tweaks. Ob die PDF-Ausgabe das beachtet, habe ich jetzt nicht getestet. Ich denke, nein, denn das würde bedeuten, dass individuelle PDFs erzeugt werden müssten. Das wäre wie gesagt ein Wunsch, der an die PediaPress-Leute gerichtet werden müsste (die verstehen auch Deutsch). Was du mit „Vorschau“ meinst, verstehe ich nicht. Die hast du doch automatisch, wenn du dir die Druckansicht oder das PDF ansiehst. --TMg 11:21, 11. Jul. 2013 (CEST)

Beobearbeitung verbessern + temporäres Beobachten

Leider kann man die Beobachtungsliste nicht so bearbeiten, dass man nur die Einträge in einem Namensraum zum Bearbeiten angezeigt bekommt oder nur max. 500 Einträge pro Seite oder so. Denn wenn man nur die Möglichkeit hat, alle Einträge auf einmal ansehen und bearbeiten zu können, dann kann man bei sehr vielen Einträgen (im 5-stelligen Bereich) gar nix mehr bearbeiten, das kickt dann den Browser regelmäßig weg. Und so bleibt die Beo dauerhaft recht schlecht benutzbar, da sie nicht mehr mehrere Tage anzeigt, sondern < 1 Tag (bei max. 1000 Einträgen). Gibt’s dazu eigentlich auch schon nen (Uralt-)Bug? Das wäre essenziell, um die Beo überhaupt irgendwie benutzbar halten zu können. Ich bearbeite die nun gar nicht mehr direkt und warte nun schon lange darauf, dass endlich irgendwelche Softwareverbesserungen stattfinden, die die irgendwann wieder bearbeitbar machen.

Gut wäre es zudem für alle zukünftigen Neueinträge auf der Beo, wenn man Seiten (alternativ zu dauerhaft) nur temporär beobachten könnte (z. B. 1 Monat / 30 Tage oder auch 3 bzw. 6 Monate), dazu hab ich jedenfalls auch diverse Uraltbugs und Vorschläge gesehen, die nicht bearbeitet werden. Sodass alle Änderungen, die man mit „klein“ markiert (dazu gehören auch Vandalismusreverts) oder – je nach eigener Voreinstellung selbst einstellbar – die man nachsichtet, automatisch nach der Zeitspanne x (am besten auch selbst definierbar oder aus mehreren Optionen auswählbar) wieder von der Beo runterfliegen, wenn man sie nicht explizit dauerhaft draufsetzt. --Geitost 13:53, 4. Jul. 2013 (CEST)

1. Also, wer versuchen würde, alle deine Wünsche umzusetzen, würde wohl ein unbeherrschbares Usability-Monster erschaffen, um das mit entsprechenden Interfaces und Filterregeln und Häkchen sowie Häkchen auf Gruppen alles konfigurierbar zu machen. Beim temporären Beobachten ist jedenfalls zu riskant, dass dir unbemerkt etwas von der Beo flutscht und du dich hinterher beschwerst, dass eine ganz wichtige Seite plötzlich nicht mehr beobachtet wird und du deshalb eine ganz ganz wichtige Info nicht mitbekommen hast. Du musst ja dann auch noch für alle Seiten die Wichtigkeit und ob dauerhaft oder nur temporär verwalten; darauf wird sich niemand einlassen.
2. Was ich nicht nachvollziehen kann, ist deine Beschwerde hinsichtlich Namensraum-Filter. Diese kannst du doch heute schon (und auf Wunsch mit/ohne zugehörige Disku) filtern.
3. Grundsätzlich empfehlen kann ich dir ansonsten mein Benutzer:PerfektesChaos/js/listPageOptions.
   • Es ermöglicht unter anderem die Etablierung von dauerhaften Filtern, um bestimmte Aktivitäten nach Benutzer (ggf. sogar BK) aus der Liste auszublenden (allerdings erst nachdem mit einem Limit von 1000 die Antwort vom Server kam).
   • Auch die Möglichkeit zum schnellen Nicht-Beobachten ist gegeben. Wenn du deinen Namen per CSS grell hervorhebst, kannst du eine Woche zurückgehen und alle Seiten finden, die du vor einer Woche bearbeitet hast; und wenn es da keine Beschwerden gab, bei abgeschalteten mehrfachen Einträgen dein Name noch sichtbar ist und es deshalb noch die aktuelle Version ist, dann kannst du diese Seiten mit einem Klick von der Beo aus unwatschen.
4. Die Beo ist für das gedacht, was ein Mensch verkraften kann. Wenn du dich im fünfstelligen Bereich bewegst, übernimmst du dich vielleicht etwas. Jede Änderung auf dem Server mit noch mehr Datenfeldern würde allen Benutzern in jedem Wiki eine größere Datenbank und noch mehr Ankreuzfelder bescheren. Und wenn du der einzige Supermann auf diesem Planeten bist, der das handhaben kann, dann wird man das wohl kaum realisieren.

VG --PerfektesChaos 14:52, 4. Jul. 2013 (CEST)

Es geht ihm um Spezial:Beobachtungsliste bearbeiten oder Spezial:Beobachtungsliste bearbeiten/raw, die bei 5-stelligen Seiten wohl etwas groß sind und die keine Namensraumfilter haben. Da man aber bei so großen Beobachtungslisten auch nichts entfernen kann, wächst es zwangsläufig. Ich habe mal etwas von Versuchen gesehen, das in MediaWiki zu ändern, aber da stand auch etwas von Ajax, was dir nicht hilft. Der Umherirrende 20:26, 4. Jul. 2013 (CEST)

Ach so.

O je, das wird kompliziert.

• Es wird nur über API-Aktionen und mühsames Gefummel gehen.
• Die Info über die Beo ist vertraulich, und er muss allein damit klarkommen.
• Einen Verbesserungsvorschlag halte ich für aussichtslos. Niemand wird sich für verhobene Power-User ein Bein ausreißen, wenn nicht der Umherirrende patscht.

Es geht erstmal ohne Ajax, nur mit Browser und gutem Text-Editor.

• Mit mw:API:Watchlistraw braucht man als eingeloggter Benutzer noch nicht einmal den Token.
• Damit kann man sich nach Namensräumen sortiert und in Blöcken zu 500 seine beobachteten Seiten anzeigen lassen.
• Daraus lässt sich in einem Editor eine Liste aller beobachteten Seiten zusammenstellen.
• Daraus kann man sich raussuchen, was man nicht mehr mag.

Dann hat man wenigstens eine Liste der Seiten auf der Festplatte. Aber die einzeln anzeigen und entbeobachten ist fad bei 2.000 Stück.

• Die Kollegen in der enWP haben leider auch kein Skript, das man mit einer Liste von Seitennamen füttern könnte und die dann in Blöcken zu 100 unwatchen. Der Token von den Einstellungen ist nur für Feeds; man braucht also auch noch aktuelle Token (gar für jede Seite einen neuen?).
• Ich bin auch auf Monate ausgebucht und kann keinen Massen-Entbeobachter schreiben, der sich auch außerhalb der Wiki-Öffentlichkeit ausführen ließe.
• Möglicherweise ginge etwas über die neue POST-Spielwiese, so dass pro entbeobachter Seite ein C&P für die Seiten-Identifikation und ein Button-Klick ausreicht. Das ist immer noch besser als jede Seite einzeln herunterzuladen.
• Ansonsten eine Liste der URL für die entzubeobachtenden Seiten in der normalen Spielwiese ungespeichert anzeigen, aber nicht für den Seiteninhalt, sondern für die action=info; die dürften mit am kürzesten sein. Und diese Links dann eins nach dem anderen in ein anderes Fenster und dort entbeobachten und danach die ganzen Fenster dutzendweise wieder zu.

Viel Spaß --PerfektesChaos 09:18, 5. Jul. 2013 (CEST)

Für temporäres Beobachten gibt es schon uralte Bugs, die ich aber mühsam suchen müsste, da einer - ich glaube - von mir stammt. Irgendwann 2008/9. Sie müssen nicht kompliziert sein, eben nur eine zweite BEO, wo die Einträge, die älter als 2 Wochen (?) sind, gelöscht werden. Praktisch: zeitlich begrenzte Diskussionen mit Benutzern, schauen, ob Korrekturen im ANR revertiert werden, bei Admins dann sehr nützliches Feature für viele viele Zwecke. -jkb- 09:26, 5. Jul. 2013 (CEST)

In der Thread-Eröffnung sind zwei völlig verschiedene Vorschläge durchmischt:

1. Eine Namensraum-Eingrenzung für den Beo-Bearbeiten-Modus, damit diese Liste auch bei fünfstelliger Zahl der beobachteten Seiten wieder handhabbar wird. Letzteres ist im Moment das Hauptproblem von Geitost.
2. Die Geschichte mit temporären Beobachtungen wäre heutzutage über ein Gadget lösbar, anders als unter den Bedingungen von 2009. An eine Erweiterung der weltweiten Datenbanken dafür glaube ich hingegen eher nicht; neben Performance auch wegen des erwähnten Risikos der unbemerkten Entbeobachtung (Krankheit, Urlaub) und der immer zunehmenden Verkomplizierung der Benutzeroberflächen.
   • Mit einem Gadget kann man heute lokal auf seinem Rechner eine Erinnerungsliste hinterlegen, die sich zur Seitenidentifikation auch ein Verfallsdatum merkt. Automatisch einmal täglich oder auf Nachfrage kann man sich dann die Seiten anzeigen lassen, die man nach Fristablauf immer noch beobachtet, und dann wählen zwischen entbeobachten / Versionsgeschichte zeigen / dauerhaft weiterbeobachten. Voraussetzung ist, dass man auf demselben PC bleibt und der nicht puttginge; dann wären auch diese Daten futsch. Aber man könnte eine Backup-Liste anbieten; die müsste man dann aber auch ständig abrufen. Als Benutzerseite kostet das unzumutbar viele Seitenversionen, und die Beo-Info ist vertraulich.
   • Die enWPler haben einige ältere Tools für die Beo, aber sowas ist meines Wissens nicht dabei.

Sonnige Zeiten --PerfektesChaos 10:04, 5. Jul. 2013 (CEST)

Mal abgesehen von den Verbesserungsvorschlägen, nur als Möglichkeit überhaupt sukzessive die Beobachtungsliste abzubauen, gäbe es ja Wikipedia:Helferlein/Navigation-Popups. Da kann man ja direkt in der Beobachtungsliste mit der Maus auf den Link (zum Artikel, Versionsgeschichte oder -vergleich) fahren, dann öffnet sich die Vorschau, dort im Aktionen-Menü entbeobachten. Also mit 1-Klick. Die Seite ist entbeobachtet, ohne dass man noch eine Bestätigung oder Meldung erhält.

• Wenn man damit täglich alles entbeobachtet, was verzichtbar ist, sollte man irgendwann unter 1000 landen.
• Oder man entbeobachtet der Reihe nach jede Seite und legt sich für die noch gebrauchten Seiten Lesezeichen an. Dann sollte man irgendwann unter 1000 landen und sie wieder bearbeiten können. Später kann man die Lesezeichen aufrufen, um die Beobachtungsliste wieder zu füllen.
• Oder man entbeobachtet der Reihe nach jede Seite und geht dann seine Bearbeitungen (Doppeleinträge ausblenden) durch und setzt mit Navigations-Popups jede gewünschte Seite wieder mit je 1-Klick auf die geleerte Beobachtungsliste.

Wären das mit Zähneknirschen akzeptable Möglichkeiten? Ich setze dabei voraus, dass nicht mehr als 1000 Seiten dabei sind, die selten geändert werden. Das du in der Zeit dieser Reinigung mal etwas verpasst, musst du positiv sehen, auch wenn du seit neuestem nicht mehr in Wikipause bist. Wenn du einmal eine bearbeitbare Beobachtungsliste hast kannst du dir die ja auch aufteilen, eine, die du täglich nutzt, eine, die du nur einmal in der Woche lädst, und eine, die du nur einmal im Monat lädst. Grüße --Diwas (Diskussion) 12:21, 5. Jul. 2013 (CEST)

• Wikipedia:Technik/Baustellen/Massenhafte Entbeobachtung
• Wikipedia:Technik/Baustellen/Beobachtung nach Karenzzeit beenden

--PerfektesChaos 21:51, 6. Jul. 2013 (CEST)

Danke für Eure Mühe. Aber ich möchte nochmal darauf hinweisen, dass das Problem (zumindest meines) weniger die Länge der Beobachtungsliste als vielmehr die schiere Anzahl der dort angezeigten Edits ist (oder genauer war, denn inzwischen spiegle ich ja die betreffenden Seiten mit den vielen Edits/Tag). Wer eigentlich nur die zwei (relativ wenig frequentierten) Seiten WD:VM und WD:SP beobachten will, der überschreitet unter Umständen schon nach 2 Tagen Abwesenheit das Limit von 1000 Beiträgen, weil WP:SP und WP:VM sich so oft ändern. Wenn man dieses API-Limit nicht erhöhen kann (auch nicht für einen eingeschränkten Benutzerkreis?), muss ich das allerdings wohl so akzeptieren. --Grip99 01:32, 7. Jul. 2013 (CEST)

Das wäre ein dritter grundverschiedener Aspekt in diesem Thread.

• Es ist zwingend erforderlich, dass eine derartige Datenbankabfrage auf einen Maximalwert begrenzt wird. Man hat vor zehn Jahren die 1000 als runde Nummer genommen; es hätten auch 1100 oder 1200 oder heute 2000 sein können. Man geht davon aus, dass Benutzer bei einer derartig langen Liste der Änderungen aber nicht mehr sinnvoll nachvollziehen können, was da alles geschehen war.

Wenn du partout WP:VM beobachten möchtest und zwei Tage abwesend warst, wäre ein anderes Vorgehen komfortabler: Auf WP:VM gehen, dieses entbeobachten, die inzwischen längst archivierten Seiten der letzten Tage im Kontext lesen (was sehr viel übersichtlicher ist als die Brösel auf der Beo), die Beo ohne die WP:VM abrufen, diese durchgehen, zum Schluss WP:VM wieder beobachten.

VG --PerfektesChaos 12:56, 7. Jul. 2013 (CEST)

Ja, so ähnlich habe ich es früher auch gemacht und mache es heute noch gelegentlich so. Trotzdem wäre eine Erhöhung auf 2000 schön. Dass eine Grenze da sein muss, ist klar.

Ich will allerdings gar nicht WP:VM beobachten, nur WD:VM. Es wäre also manchmal schon hilfreich, wenn man das trennen könnte. Artikel ohne Diskussionsseite beobachten kann ja weiter verboten bleiben, aber wenigstens die umgekehrte Richtung sollte zulässig sein. Von mir aus auch nur außerhalb des ANR. --Grip99 00:44, 9. Jul. 2013 (CEST)

• Für WD:VM gilt das Gleiche. Es ist komfortabler, nach einigen Tagen Abwesenheit Thread für Thread (auch bereits archivert) im inhaltlichen Zusammenhang zu lesen, als lauter Brösel.
• Wenn es dagegen um ein Überfliegen geht, etwa hinsichtlich bestimmter Benutzernamen, steht in der VG der WD:VM das Gleiche wie auf der Beo; nur gefiltert.
• Bereits beim Limit von 1000 (was konfiguriert werden kann auf 1000 unterschiedliche Seiten und ohne Bots und nur in einem NR) ist es bereits jenseits der menschlichen Möglichkeiten, hier den Durchblick zu behalten. Dazu ist die Beo auch nicht gedacht. Ein Anlass für irgendwelche Entwickler, hier mit projekt- oder wohl weltweiten Konsequenzen (es gibt zurzeit keinen Konfigurationsparameter) etwas zu verändern, ist nicht schlüssig.
• Auf Wikipedia:Technik/Skin/Benutzerskripte #Beo sind mehrere Hilfsmittel für erfahrene Benutzer dazu genannt; darunter auch mein Benutzer:PerfektesChaos/js/listPageOptions, das die unerwünschten Seiten unsichtbar schaltet (wobei sie gleichwohl auf das 1000-Limit angerechnet werden).

VG --PerfektesChaos 21:54, 10. Jul. 2013 (CEST)

Zu Punkt 1: Ich will aber nicht "Thread für Thread" lesen, sondern nur die neuen Brösel. Den Rest habe ich noch halbwegs im Gedächtnis.

Zu Punkt 3: ist es bereits jenseits der menschlichen Möglichkeiten, hier den Durchblick zu behalten.

Was bezeichnest Du als "den Durchblick behalten"? Ich brauche nicht jeden der 1000 oder 2000 Edits im Einzelnen durchgehen. Hauptsache, ich finde in den 2000 das, was mich interessiert.

Wenn es nicht geht, dann geht es eben nicht, dann kann man nichts machen. Klar kann ich als Workaround Versionsgeschichten durchgehen, aber das ist eben nicht derselbe Komfort, wie ihn die erweiterte Beobachtungsliste durch ihre Zusammenstellung auf einer einzigen Seite bietet.

Übrigens, was ich wohl auch schon früher mal irgendwo angeregt hatte, war die Möglichkeit, anstatt "vor 6 Stunden" oder "vor 1 Tag" eine Startzeit für die Beobachtungsliste einzugeben, meinetwegen auch bloß in der Adresszeile per offset oder sowas. Vielleicht sogar noch eine Endzeit. Das würde das Problem auch entschärfen, denn dann könnte man die Beobachtungsliste Tag für Tag oder im 12-Stunden-Rhythmus durchgehen. --Grip99 01:24, 13. Jul. 2013 (CEST)

Spezialseite fürs Vorlage expandieren simuliert Namensraum

Hallo. Ich habe gerade in ein Lua-Modul eine Abfrage zum Namensraum eingebaut. Da es aber der Namensraum für Artikel ist und nur dort die entsprechenden Fehlermeldungen erscheinen sollen, läßt sich das zur Zeit schlecht testen. Ich habe daher angefangen einen Pseudoartikel zu editieren, klicke dort auf Vorschau, speichere denn aber nicht. Das ist doch unpraktisch. Das könnte doch über Spezielseite "Vorlage expandieren" mit erledigt werden, indem dort der Namensraum für solche Fälle simuliert werden kann. Ginge so eine Ergänzung der Software? Gruß --Tlustulimu (Diskussion) 07:01, 5. Jul. 2013 (CEST)

1. Für Spezial:Vorlagen expandieren eine sinnvolle Verfeinerung.
2. Für das Lua-Modul aber ohnehin ein ungeeignetes Vorgehen.
   • Beim Bearbeiten des Modul-Quelltextes gibt es zweimal „Vorschau“:
     1. Die normale, zusammen mit Änderungen und Speichern.
     2. Darunter die Vorschau im Seitenkontext. Hierhin gehört etwa die jeweilige Testseite. Da kannst du auch das ungespeicherte Modul im Kontext bestimmter Artikel und Nicht-Artikel erproben.

Sonnigen Tag --PerfektesChaos 09:30, 5. Jul. 2013 (CEST)

Genau dafür gibt es auf Spezial:Vorlagen expandieren das Eingabefeld "Kontexttitel". Wenn das Feld FULLPAGENAME definiert, dann auch NAMESPACE oder ähnliches. Und aus der mw:Extension:TemplateSandbox gibt es bei Vorlagen und Modulen im Bearbeitungsfenster die Möglichkeit, den aktuellen Quelltext als Vorschau für beliebige Seiten zu nehmen. Der Umherirrende 14:32, 5. Jul. 2013 (CEST)

Dynamische Grafik im Suchfeld bitte wieder entfernen

Wenn man die Maus im Suchfeld platziert, erscheint rechts etwas unterhalb des Feldes eine kleine Grafik, gleitet etwa eine Zeile höher, verschwindet wieder. Der Vorgang wird als wertfrei, als völlig nutzlos spielend erkannt. Folgender Eindruck nötigt sich auf: "Ein Verursacher verfolgt das Ziel, die solide Umgebung der Wikipedia zu einem Tummelplatz für *Kitschliebhaber* zu degenerieren."

Es ist hoffentlich wichtig, dass die Wikipedia ihren unbefangen einladenden, seiösen Charakter schnellstmöglich wieder zurückerhält. Bitte weist den Verursacher mit Dringlichkeit zurück. Bitte entfernt die dynamische Grafik wieder aus der Software. (nicht signierter Beitrag von Granut (Diskussion | Beiträge) 12:51, 12. Jul. 2013 (CEST))

Bei mir erscheint ein kleines Tastatursymbol, mit dem man die Eingabesprache ändern kann (Firefox 22, Win 8). Welchen Browser und welches Betriebssystem verwendest du? XenonX3 – (☎ – RIP Lady Whistler)) 12:57, 12. Jul. 2013 (CEST)

Ich arbeite mit Firefox 20 Portable, Windows 7. Ja, es ist wohl ein Tastatursymbol. Da es flüchtig ist, beachte ich es nicht. Wenn ich die Maus nicht platziere, erscheint es nicht. Selbst betont kindliche Spiele "arbeiten" mit derartigem nicht. In der Wikipedia nervt es natürlicherweise.

Richtig sollte sein, den Button statisch und dauerhaft zu platzieren. Dann und nur dann kann es ein nützliches, dankenswertes Feature sein.

--Granut (Diskussion) 15:07, 12. Jul. 2013 (CEST)

Formeln im Kontrastdesign nicht / schlecht lesbar

Beim Farbschema mit schwarzen Hintergrund im Browser sind die Formeln schlecht lesbar. Sie wurden eindeutig für einen weißen Hintergrund optimiert. Vielleicht kann man das irgendwie hinkriegen, gerade abends ist es viel besser nicht vor dem schlafen gehen auf einen weißen Monitor zu schauen. (nicht signierter Beitrag von Boguszschubert (Diskussion | Beiträge) 14:59, 14. Jul 2013 (CEST))

Wähle in deinen Einstellungen MathJax für die Darstellung mathematischer Formeln. --Schnark 09:06, 15. Jul. 2013 (CEST)

Die normale Darstellungsart steht vor einem Dilemma. Es handelt sich um PNG-Grafiken, was viele Nachteile aber den großen Vorteil hat, dass die Formeln nahezu unabhängig von den Fähigkeiten des Webbrowsers korrekt angezeigt werden. Diese Grafiken werden mit schwarzer Schrift und ohne Hintergrund gerendert. Damit sehen sie in allen Skins, die teilweise Farbschattierungen als Hintergrundfarben verwenden, gleich gut aus. Hätten die Grafiken weiße Hintergründe, würden sich viele Benutzer über die weißen Kästen beschweren. Die erwähnte Umstellung ist da wirklich die besten Lösung. --TMg 21:42, 16. Jul. 2013 (CEST)

Player für animierte GIFs

Quicksort erklärung. wie schritt für schritt durch die erklärung gehen *hmmm*

AVM des Gehirns in der Magnetresonanztomographie. Wie anhalten und im Detail betrachten... *hmmm*

Hi, konnte zu diesem Thema nicht noch nichts finden und wurde von der Wikipedia:Grafikwerkstatt hierherverwiesen. Also, Es gibt in den verschieden-sprachigen Wikipedias durchaus eine rege Verwendung von animierten GIFs als Format für kleine Animationen und technische Skizzen. Ein Usabilityproblem mit diesen ist, es existieren keine Kontrollstrukturen für den Leser, zB um anzuhalten oder hin- und herzuspulen (wie bei einem Player für Videos) um sich Details anzuschauen. Ein Beispiel wäre diese Animation einer Gefäßmalformation. Dieses Problem wurde schon vor einiger Zeit einem Wikipediaverwender (http://slbkbs.org/jsgif/ mit Problembeschreibung) erkannt und auch gelöst, über einen plattformneutralen, Javascript basierenden GIF Player, JSGIF (leicht auszuprobieren, Verwendungserklärung als Bookmarklet im Link). Der Code liegt auf GIT-Hub unter einer MIT-Lizenz, sollte also verwendbar sein. Könnte ein solches Feature sinnvoll sein und in die Wikipedia integriert werden? schönen Gruss Shaddim (Diskussion) 00:24, 25. Jul. 2013 (CEST)

Das Bookmarklet mag eine nette Idee sein, aber ist keine Lösung, insbesondere keine Lösung für alle Benutzer:

• Die Navigationsleiste ist bei schmalen Bildern einfach abgeschnitten, ich kann im zweiten Beispiel oben nicht einmal auf Pause klicken.
• Die einzelnen Funktionen sind nicht selbsterklärend, auch wenn das auf der Seite behauptet wird. Ich verstehe beim besten Willen nicht, was "Pin" tun soll.
• Etwa 10 % aller Wikipedia-Leser verwenden einen Browser, in dem das Skript nicht funktioniert.
• Aus Lizenzgründen muss die Bildbeschreibungsseite verlinkt werden, was nach Anwendung des Skripts nur noch durch das unscheinbare Symbol (und bei Gallerien gar nicht mahr) erfüllt ist.

Fazit: Das sollte auf gar keinen Fall für alle Benutzer aktiviert werden, und wer es für sich selbst verwenden will, kann das ja bereits tun. --Schnark 09:34, 25. Jul. 2013 (CEST)

• +1 hinsichtlich Bookmarklet.
• Betreffend MediaWiki, Server und so:
  • Ja, das klingt sehr schlüssig und technisch umsetzbar.
  • Es müsste bei bestimmten Animationen ein zusätzlicher Bildparameter mitgegeben werden, dass ein entsprechendes Gadget benötigt wird.
  • Für Videos gibt es diese Player ja bereits, ansonsten sehe ich noch keine Vorhaben in dieser Richtung.

Liebe Grüße --PerfektesChaos 11:19, 25. Jul. 2013 (CEST)

Danke für die Rückmeldungen, dass bookmarklet sollte vor allem Beispiel für den "Leidensdruck" dienen, der ja so gross war das ein WP-Leser einen Player sich selbst recht flink zusammen gebastelt hat. ;) Für die meisten nicht "technisch" affinen Leser ist die Option "Bookmarklet" (geschweige die Programmierung einer eigenen JS lösung) völlig out-of-scope. Deswegen denke ich auch WP sollte eine (optionlae) Lösung in irgendeiner Form anbieten. gruesse Shaddim (Diskussion) 11:40, 26. Jul. 2013 (CEST)

Nette technische Spielerei, aber wie so häufig eher ein Proof of Concept. In meinem Opera zum Beispiel ist es nicht bedienbar. Der Dekodierungsschritt ist mindestens irritierend. Von der fehlenden Notwendigkeit ganz zu schweigen. Für Videos, die man anhalten und spulen kann, haben wir ein auf die Zukunft gerichtetes Format. Es wäre meiner Ansicht nach verfehlt, eine veraltete und in jeder Hinsicht unzureichende Technik quasi per Polyfill künstlich zu einem Videoformat aufwerten zu wollen. Das macht alles nur schlimmer. --TMg 20:57, 25. Jul. 2013 (CEST)

Notwendigkeit wurde dargelegt, die weitläufige Verwendung auch in ausgezeichneten Seiten oder als ausgezeichnetes Bild unterstreicht dies (z.B. dieses File:Animated_gun_turret.gif). Technische Alternativen für die Use-case die GIF-Animationen abdecken (im Grenzbereich zwischen fixen Bild und echtem Video) konnten sich bis jetzt (durchaus aufgrund relevanter technischer Nachteile) nicht durchsetzen. grüsse Shaddim (Diskussion) 11:40, 26. Jul. 2013 (CEST)

Ich sehe hier genauso „relevante technische Nachteile“. Dass GIF-Animationen „weitläufig verwendet“ würden, wage ich zu bezweifeln. Ohne wirklich nachgezählt zu haben, behaupte ich, dass sie nur in einem von 1000 bis 2000 Artikeln vorkommt. Und auch in denen gibt es nie die Notwendigkeit, sie anzuhalten. Wenn tatsächlich Bedarf dafür bestehen würde, müsste JSGIF im Web weit verbreitet sein. Ist es aber offenbar nicht. Für die Darstellung von Phasen gibt es andere Lösungen: als Video, schlicht untereinander oder notfalls per Vorlage:Galerie. Was die selben Nachteile hat und möglichst nicht verwendet werden sollte. --TMg 23:19, 26. Jul. 2013 (CEST)

Es scheint so als wärst du kein Freund von GIF. :) Nichtsdestotrotz, animierte GIFs sind eine Realität, inzwischen mehr als noch vo ein paar Jahren, sie haben ein Revival erlebt (NY times artikel) und werden für zB auch für Stereogramme (New York Library) und Cinemagramme ([1]) verwendet. Auch wir haben einen riesigen Bestand an animierten GIFs auf den Commons (allein in der Kategorie 7800 http://commons.wikimedia.org/wiki/Category:Animated_GIF) und verwenden diese in vielen vielen Artikeln. D.h. sie werden so schnell nicht verschwinden, auch wenn diesen seit den 90ern den GIFs der Tod gewünscht wurde, man mag es technisch Bedauern (oder auch nicht) animiertes GIF ist der Webstandard im Grenz-Bereich zwischen festem Bild und echtem Video mit durchaus guten technischen eigenschaften, lang bekanntes Format, alle Browser und Betriebssystem unterstützen es out of the box ohne Plugins etc. (MNG und APNG haben es durch hickhack ja verhindert das sie GIFs Platz einnehmen konnten, echte videoformate sind overengineered, erfordern plugins, etc...) Die Notwendigkeit für einen Playern ergibt sich Wikipedia spezifisch also auch kein wirklches Argument dagegen ein Player hier zu etablieren. Als GIF 2012(!) zum Wort des Jahres gewählt wurde, geschah dies mit Begründung dass GIF sich zu einem ernsthaften Werkzeug für Journalismus und Forschung gewandelt habe... Wikipedia ist einer dieser Fälle. (The GIF has evolved from a medium for pop-cultural memes into a tool with serious applications including research and journalism, and its lexical identity is transforming to keep pace.” [2])

PS: diese Webseite widmet sich der Vielfalt der auf den Commons verfügbaren GIFs wikigifs.org :) gruesse Shaddim (Diskussion) 12:37, 28. Jul. 2013 (CEST)

Das ist alles ganz nett, hat aber nicht viel mit unserem Projekt und unseren Projektzielen zu tun. Wikipedia ist nicht Tumblr oder Reddit. Wikipedia ist ein Projekt zum Aufbau einer Enzyklopädie und als solches müssen wir bestrebt sein, alle wesentlichen Informationen so aufzubereiten, dass sie jeden Export (PDF, E-Books etc.) weitestgehend überleben. JSGIF ist wie ich schon sagte kaum mehr als ein Proof of Concept. Für den Produktiveinsatz ist das viel zu wenig durchdacht, zu schlecht bedienbar und fehlerhaft. Stereo- und Cinemagramme brauchen sowieso keine Pausetaste. Bei den wie schon argumentiert ohnehin nur extrem wenigen GIFs in Artikeln ergibt es meist gar keinen Sinn, sie anzuhalten. Für diesen mit der Lupe zu suchenden Nutzen müssen alle Leser aller Artikel ein weiteres Bündel fehleranfälliges JavaScript herunterladen? Als ob es davon nicht schon viel zu viel gäbe? Nein, tut mir leid, das ist schlicht nicht verhältnismäßig. Die Stärke von GIF, die du beschreibst, liegt gerade darin, dass es so wahnsinnig simpel ist. Das würde durch so ein Skript ad absurdum geführt. Sinnvoll könnte es vielleicht bei Commons sein. Frag dort mal nach. --TMg 18:39, 7. Aug. 2013 (CEST)

Dem stimme ich zu, eine integrierte Lösung in WP ist vor einem externen Skript zu bevorzugen. Das Skript sollte nur als Proof-of-concept der technischen Lösbarkeit als auch als Beispiel für den "Leidensdruck" der User dienen. gruesse Shaddim (Diskussion) 19:23, 7. Aug. 2013 (CEST)

...und jetzt noch mal langsam?

Ein paar Anmerkungen:

• Zu JSGIF gibt es ja eine coole Beschreibung: "Featuring Windows 3.11-style graphics, Web 3.11-style rounded corners, and the world's least efficient LZW decoder, jsgif is the needlessly-convoluted animated GIF player of choice for those with more CPU cycles and RAM than they know what to do with." Hehe!
• Unterstützer und Interessenten für einen "animated gif player" könntest Du bei den Schachliebhabern finden:
  • en:Wikipedia:Village_pump_(technical)/Archive_109#Display Chess games (with animation) using PGN data;
  • Wikipedia:WikiProjekt_Vorlagen/Werkstatt/Archiv_2013/1#Interaktives_Schach;
  • Benutzer:Antimaterie/Schach/Interaktive_Diagramme.
• Für einen als Standard integrierten "animated gif player" bietet sich commons an. Wer sich Frames genau einzeln anschauen will, wird wohl auch die größte Bildauflösung suchen, die gibt es bei Commons.
• Für diejenigen, die das Geflacker von animated gif einfach nur nervt, gibt es übrigens ein user script, en:User:Ll0l00l/gadget-gif-hider.js (hide gifs after mouse-out from image box. return mouse to image for unhide it. ver 1.1 / 2010-06-05).

Gruss --Atlasowa (Diskussion) 10:28, 8. Aug. 2013 (CEST)

Danke für die Verbindung zu den Schachspielern... zu der JSGIF Eigenbeschreibung: der Autor hat Humor... und für so eine Ankündigung funktioniert der Player ganz vorzüglich und wartet mit Funktionalitäten auf die optimisischer abgekündigte Player nicht haben (wie Rückwärtsabspielen) ;) gruesse Shaddim (Diskussion) 11:05, 8. Aug. 2013 (CEST)

PGN und FEN

Gibt es eine Möglichkeit die Extension:EmbedChessboard (eingebundenes Schachbrett) von Wikimedia auf der deutschen Wikipedia zu installieren? z. B. um prominente Schachspiele, Eröffnungen etc. besser nachvollziehen zu können, da man dann einzelne Partien „abspielen“ kann (Züge vor und zurückmachen kann etc.

Wer kann das?--Dudy001 (Diskussion) 19:23, 25. Jul. 2013 (CEST)

Ach je, schon wieder? Siehe WP:WikiProjekt Vorlagen/Werkstatt/Archiv 2013/1#Interaktives Schach. Kurze Antwort: Es gibt aktuell nur ein paar Dutzend Artikel, in denen man das anwenden könnte. Bei aktuell 1,6 Millionen Artikeln rechtfertigt das den Aufwand meiner Meinung nach in keinster Weise. Das Skript muss gepflegt werden. Wer soll das machen, wenn es nur so wenige Artikel sind, die von Fehlern und notwendigen Anpassungen an zukünftige Browserversionen betroffen sein werden? Es ist viel logischer, einen guten Weblink anzugeben, unter dem man sich die Partie ansehen kann. --TMg 20:45, 25. Jul. 2013 (CEST)

Ich habe mal die Beschreibung der Erweiterung auf MediaWiki ergänzt. Mit anderen Wort: Nein, auf gar keinen Fall. --Schnark 09:49, 26. Jul. 2013 (CEST)

Wikimedia und Celestia (Reisen durchs Universum)

Da in Wikipedia viele Artikel auch über Sterne, Universum, Exoplaneten sind, böte es sich an diese mit Himmelskoordinaten auszustatten und mit einem geeigneten Sternenkarten-Programm (Vorschlag: Celestia zu verknüpfen und so virtuelle Reisen ins Weltall zu ermöglichen (ähnlich wie google earth).--Dudy001 (Diskussion) 21:12, 17. Aug. 2013 (CEST)

Darstellung der Volltextsuche mit anderem Leerzeichen

Wäre es möglich, zur Kenntlichmachung der gefundenen Suchwörter im Suchergebnis der Wikipedia-Volltextsuche ein anderes Leerzeichen als das gewöhnliche zu nutzen? Dann könnte man mit der Browsertextsuche im Suchergebnis nach den Suchwörtern außerhalb von Komposita suchen. --Diwas (Diskussion) 22:24, 8. Sep. 2013 (CEST)

Im Prinzip ist vieles möglich, wobei ich zwar weiß, was Komposita sind, aber noch nicht verstanden habe, wie du ein ungewöhnliches Leerzeichen in die Browsersuche reinbringst und wie viele Benutzer dir das nachmachen könnten, und wieso dies helfen würde.

Günstig wäre es, wenn du ein Beispiel angibst für:

• Die Eingabe in das Suchfeld,
• eine simulierte Sammlung unterschiedlicher Resultat-Zeichenketten,
• wie du was jetzt in die Browser-Suche auf der Ergebnisseite eingibst,
• und wonach du eigentlich gesucht hattest.

Schönen Abend --PerfektesChaos 23:03, 8. Sep. 2013 (CEST)

Vielleicht kommt es tatsächlich gar nicht so oft vor, aber wenn ich samt im Volltext suche werden mir unter den ersten 50 Ergebnissen ein Bischof samt und unter den zweiten 50 Suchergebnissen ein Regierung samt und ein Bischof samt. Im Artikel steht aber Bischofsamt ohne Leerzeichen. Bei manchen spezielleren Suchen, beispielsweise "samt des" gibt es das Wort samt kaum noch, sondern fast nur noch die Reste von Komposita ohne Wortstamm. Dabei frage ich mich jetzt gerade, ob diese Leerstellen im Suchergebnis einen Sinn haben oder das ein Fehler ist, oder ist das nur bei mir so? Es entsteht wohl aus der Verlinkung des Wortstammes? Jedenfalls könnte ich in der Browsertextsuche in den genannten Beispielen " samt " bzw. " samt des " eingeben und erhielte nur die wirklichen Wörter samt hervorgehoben, nur werden hier durch die Trennung durch die eingefügten Leerzeichen im Suchergebnis die Reste als eigenständige Wörter vorgegaukelt. Mein Gedanke war nun, dass man, falls man dort weiterhin Leerzeichen im Suchergebnis haben möchte, irgendeine andere Kodierung verwendet, die nicht anders aussieht aber von der Browsertextsuche nicht als Leerzeichen erkannt wird. Wenn aber sonst niemand im Suchergebnis sucht, ..., dann wäre ich doch immerhin neugierig, ob die Leerzeichen Absicht sind. Grüße --Diwas (Diskussion) 02:23, 9. Sep. 2013 (CEST)

• „Es entsteht wohl aus der Verlinkung des Wortstammes?“
  • Exakt. Im Quelltext steht etwas wie
    1. [[Regierung]]samt
    2. [[Regierung]]<nowiki/>samt
• Die Aufbereitungsmaschine vor der Suchmaschine geht jede Nacht mindestens durch alle Seiten (Artikel, Disku) durch, die in den letzten 24 Stunden geändert wurden; und fügt dem Index hinzu bzw. entfernt nicht mehr vorhandene Wörter. Weil letzteres ziemlich mühsam ist, kann es auch sein, dass täglich der Gesamtindex aller Wörter, die in über zehn Millionen Seiten vorkommen, neu aufgebaut wird.
  • Dabei werden aus dem Quelltext die meisten Sonderzeichen entfernt und gewissermaßen durch ein Leerzeichen als Worttrenner ersetzt. Ein paar Satzzeichen bleiben stehen und werden als eigenständige Wörter betrachtet, deshalb durch Leerzeichen abgetrennt.
  • Dieser Algorithmus muss sehr schnell und effizient flutschen.
  • Im Prinzip könnte man dem Aufbereitungsfilter etwas Wikisyntax beibiegen, die links und rechts an Buchstaben anschließenden Regierung]]samt zunächst ausfiltern (löschen) und erst danach die normale Wandlung der Sonderzeichen ausführen. Damit entstünde kein störendes Leerzeichen im Suchergebnis.
• Seit 28. August wird eine neue Suchmaschine CirrusSearch/ElasticSearch auf dem Software-Wiki (rein englisch) erprobt.
  • An der bisherigen Lucene wird niemand mehr etwas machen; die neue ElasticSearch baut allerdings methodisch darauf auf.
  • Was die neue Suchmaschine mit deutscher Sprache macht, wird abzuwarten sein.
  • Infos.
  • Solange jemand aktuell daran werkelt und in die Thematik eingearbeitet ist, wäre der günstigste Moment, dich möglichst selbst dorthin zu wenden und deine Anregung vorzutragen. Es ist eine Bugzilla-Schiene genannt; eine klassische Wiki-Diskussion dazu gibt es wohl nicht. Notfalls müsstest du dir jemand suchen, der das für dich auf englisch in Wikipedia:Technik/Bugzilla einfädelt.
• Komposita sind eine relativ deutsche Angelegenheit, in einigen anderen Sprachen auch noch relevant, im Englischen als Muttersprache der Software-Entwicklung hingegen selten. Das erhöht den Überzeugungsaufwand.
  • Ziemlich selten unter den Sprachen der Welt samt nicht-lateinischer Schriftsysteme dürfte der Fall sein, dass der abgetrennte Teil des Kompositums ein eigenständiges, sinnvoll suchbares Wort ergibt wie hier „samt“.

Liebe Grüße --PerfektesChaos 09:26, 9. Sep. 2013 (CEST)

Danke für deine Auskünfte, mal schauen, ob ich mich aufraffe. Falls sich jemand anderes an den eingefügten Leerzeichen stört, kann er es hier ja mal kundtun, oder gleich in Bugzilla. Wahrscheinlich sind es aber tatsächlich nur Einzelfälle, in denen sie nennenswert stören. Grüße --Diwas (Diskussion) 12:26, 9. Sep. 2013 (CEST)

Ein Bug gibt es schon: Bug 22515. Der Umherirrende 19:06, 9. Sep. 2013 (CEST)

Danke, wie groß ist schätzungsweise die Wahrscheinlichkeit, dass dieser Lucene-Bug gleich bei der neuen Suchmaschine ausgemerzt oder vermieden wird? Wäre ja ein naheliegendes Vorgehen das Neue auf die alten Bugs abzuklopfen. --Diwas (Diskussion) 22:19, 9. Sep. 2013 (CEST)

Meine Einschätzung tendiert gegen nahe Null.

Es ist schon trickreich, statt der zwei alten bugs auf component=lucene-search-2 einen neuen aufzumachen als component=CirrusSearch; dann merkt vielleicht keiner, dass das schon seit drei Jahren liegt. Jetzt haben Entwickler den Code grad vor der Nase; 2014 kann sich keiner mehr an was erinnern. LG --PerfektesChaos 23:26, 9. Sep. 2013 (CEST)

So extrem wie in Deinem "samt"-Beispiel ist es mir noch nie aufgefallen, aber ich war schon immer allgemein mit der wikiinternen Suche unzufrieden. Warum gibt man überhaupt das Trennzeichen hinterher wieder mit aus, wenn es bloß für den Suchprozess selbst von Bedeutung ist? Man könnte ja etwas Exotischeres als ausgerechnet ein Leerzeichen zur Trennung nehmen. Und wenn man es doch am Ende brauchen sollte, warum dann kein weiches Trennzeichen? Das würde wenigstens seltener stören (nur bei Zeilenumbrüchen). Aber gut, die Programmierer werden sich wohl was dabei gedacht haben ... --Grip99 00:33, 10. Sep. 2013 (CEST)

Ich vermute, dass bislang noch nie jemand der Lucene Wikisyntax beigebracht hatte, obwohl das wohl ginge.

• Der standardmäßige Lucene-Algorithmus geht durch den angelieferten Rohtext und ersetzt alle Sonderzeichen durch Leerzeichen; bzw. genauer: schließt beim Antreffen eines Sonderzeichens das vorangegangene Einzelwort, verarbeitet dieses, ignoriert die Gruppe der Sonderzeichen und beginnt mit dem nächstfolgenden Buchstaben ein neues Einzelwort. Ein paar Satzzeichen werden dabei (durch Leerzeichen isoliert) als Einzelwort behalten. Dass die Situation Buchstabe+]]+Buchstabe in Wikisyntax nicht als Trennung von Einzelwörtern behandelt werden soll, muss erst noch angesagt werden; mit der ersten ] wird das vorangegangene Einzelwort abgeschlossen und als solches in die Datenbank eingearbeitet.
• Weiches Trennzeichen (und insbesondere die im Quelltext sichtbare Form als Entity) sind hingegen Killer für jeden Tokenizer; das & jedes Entity führt zur Beendigung des vorstehenden Einzelworts. Weiche Trennzeichen müssten im Gegenteil erst entfernt werden, weil sie sonst ein abweichendes unauffindbares Einzelwort bilden oder silbenweise in Einzelwörter splitten.

Bei der neuen Programmierung unter CirrusSearch werden vor dem Start von Lucene+ alle Vorlagen expandiert. In dieser Phase müssten dann schließlich auch die Buchstabe+]]+Buchstabe zusammengezogen werden. Insofern stehen die Chancen jetzt gerade besonders gut.

VG --PerfektesChaos 10:10, 10. Sep. 2013 (CEST)

Möglichkeit die Anzahl der Abrufe/Klicks für Links per CSS/JS anzeigen zu lassen

Wäre es (zukünftig irgendwann) möglich sich per CSS/JS-„Spielerei“ die Abrufstatistik eines Links im letzten Monat/Quartal/halben Jahr anzeigen zu lassen? Also ähnlich wie man sich schon jetzt anzeigen lassen kann, wenn ein Link eine BKL ist oder einen QS-Baustein enthält. Vorteil: Auf BKL-Seiten könnte man auf einfache Weise nach Relevanz sortieren, sofern nicht eine alphabetische Sortierung, wie z.B. bei Personennamen, vorzuziehen ist. --BlueCücü (Diskussion) 00:50, 10. Sep. 2013 (CEST)