Wikiup Diskussion:Umfragen/Technische Wünsche/Top 20

aus Wikipedia, der freien Enzyklopädie

Diese Seite gehört zum Wikipedia-Archiv.

Der Inhalt dieser Seite ist nicht mehr aktuell. Sie wird aber nicht gelöscht, damit die Geschichte der Wikipedia nicht verloren geht. Falls es sich um eine Arbeitsunterlage handelt, ist sie womöglich durch andere Seiten ersetzt worden. Bestehende Weiterleitungen auf diese Seite sollen das Wiederauffinden ermöglichen.

Wenn du meinst, diese Seite sei weiterhin von aktueller Bedeutung, solle weiter benutzt werden und ihre Funktion sei nicht besser in bestehende Seiten integriert, dann kümmere dich bitte um ihre Aktualisierung.

Aufwand

Was heißen denn 2 Sprints, 50%, 2 Personen etc. in normalverständlicher Sprache? Kann man das irgendwie in Tagen, Wochen etc. ausdrücken? -- TZorn 13:54, 28. Feb. 2014 (CET)

Ein Scrum-Sprint ist bei uns 2 Wochen lang. Die Prozente geben an, ob ein Entwickler Vollzeit an einem Wunsch arbeitet kann oder ob das wahrscheinlich weniger sinnvoll ist, etwa wenn Zuarbeit von Foundation-Mitarbeitern vonnöten ist. Alle Zahlen sind nur erste grobe Einschätzungen. --Thiemo Mättig (WMDE) 16:56, 4. Apr. 2014 (CEST)

Analyse Wunsch 1

Umseitig habe ich soeben die Analyse von Abraham und Thiemo von WMDE mit 5 Umsetzungsideen veröffentlicht. Wer hat welche Präferenzen?

  • Nachtrag durch nachfolgende Bearbeitung
  • Warnung
  • Ergänzungshilfe
  • Vollautomatische Ergänzung im Wikitext
  • Anzeige am Artikelende auch ohne <references />-Tag

War das jetzt als "Abstimmung" gedacht? Zunächst mal befürworte ich eindeutig "Anzeige am Artikelende auch ohne -Tag", jedoch mit dem Ziel bei Abschnittsbearbeitungen eine Vorschau zu bekommen. Für den gesamten Artikel besteht die Infrastruktur für eine Warnung für fehlende <references /> ja bereits, die man dann mit einer solchen Vorschau kombinieren kann (sowas wie "In diesem Artikel fehlt noch ein <references />-Tag an dessen stelle die folgenden Referenzen automatisch eingefügt werden:". Die Notwendigkeit für ein automatisches Einfügen sehen ich nicht (zu viel Aufwand und schwierig umzusetzen, da nunmal jedes Projekt seine eigenen Präferenzen hat wie und wo die Referenzen eingefügt werden). --Patrick87 (Diskussion) 14:47, 26. Apr. 2014 (CEST)

Es ist aber technisch schwierig bzw. muss viel bedacht werden am Ende eines Abschnitts ein references-Tag zu simulieren. Beispielsweise wenn eine benannte Referenz in einem anderen Abschnitt definiert wurde und jetzt nur verwendet wird. Dafür müsste im Hintergrund der gesamte Artikeltext extrahiert werden, damit solche Dinge dann aufgelöst werden können. Das Rückreferenzen sich nicht "richtig" nummerieren, kann man wohl verkraften. Der Umherirrende 18:12, 26. Apr. 2014 (CEST)
  1. Ich hätte gern, dass der Level der umseitigen Vorschlags-Überschriften auf H3 gesetzt wird, damit sich Vorschläge und Lösungsvarianten noch optisch unterscheiden.
  2. Zu Wunsch 1 references
    • Glasklare Absage an alles, was automatisch ein Tag in den Wikitext einfügt oder einfach ignoriert, dass es fehlt, und magisch die Dinger reinzaubert.
      • Sonst setzt niemand mehr das Tag, weil, es funktioniert ja auch so, und alles ist fein.
      • Ohne manuelle Mitwirkung hat es aber keine Überschrift, und die Liste wird sonstwo generiert.
      • Die Platzierung müsste sein: Vor der obersten Navileiste und allen medizinischen Rechtshinweisen, und das weltweit für alle Wikis definiert. Nicht einmal in der deWP gibt es aber einen Standard, dies einheitlich wegen Länge, Übersichtlichkeit und von den meisten Lesern ignoriert hinter Lit+Weblinks zu schreiben; irgendwer muss da seine persönlichen Marken am Baum setzen – diejenigen könnten aber ihre individuelle Sondergestaltung durch manuelles Einfügen des Tags ausleben.
      • Keine Überschrift ist konsensfähig; weltweit ohnehin nicht und in der deWP schon gleich gar nicht. Laut Google anscheinend 600.000 „Einzelnachweise“ unter geschätzt 1.000.000 references; der Rest sind Belege, Anmerkungen, Quellen, Einzelbelege, Fußnoten, Quellenbelege, Endnoten oder sonstwas, die von den „Hauptautoren“ als individuelle Note mit Zähnen und Krallen verteidigt werden. Und wehe, ein Tool wagt es, das böse böse Wort dort einzufügen; das ist eine Verschwörung der WMF gegen die Autoren.
      • Neben fehlendem <references /> gibt es noch weitere Ursachen: Tippfehler im Gruppen- oder Einzelnamen, Tags nicht geschlossen oder Syntaxfehler im öffnenden Tag usw. Automatisches Einfügen des <references /> würde ohnehin nicht alle Fehler beseitigen.
    • Kein BF wegen Unverständlichkeit gegenüber Newbies; zumindest nicht durch Verhinderung einer Abspeicherung.
      • BF ja, falls nur Tracking; das ist aber überflüssig, weil ohnehin in der Wartungskat landend.
      • Gegenüber Anfängern, die zum ersten Mal im Leben ein <ref> setzen, darf es keine komplexen Syntax- und Stil-Erläuterungen geben, und der Bearbeitungsfluss darf nicht unterbrochen werden, sondern die Abspeicherung muss so oder so erstmal erfolgen. Dann muss den Newbies halt ein Profi hinterherarbeiten; das ist bereits Status quo. Es darf aber nicht dazu kommen, dass auf mysteriöse Weise und unter kryptischen Vorwänden Bearbeitungen nicht akzeptiert werden.
    • Keine Blockade einer Abspeicherung, nur weil irgendwo ein > fehlt, aus den umseitig bereits beschriebenen Gründen.
      • Textänderung mitsamt Syntaxproblem erstmal speichern.
      • Wenn der letzte Bearbeiter es nicht gelöst bekommt, müssen halt Routiniers ran.
    • Es kann nur vom Typ „Warnung“ sein.
      • Mittel der Wahl wäre JS-Gadget mit Opt-Out (und deshalb nur angemeldet) oder Server-gestützte Lösung, immer und für alle.
      • Die DB könnte zur Beschleunigung ein Feld erhalten: references vorhanden (für bestimmte Gruppen); dann kann ein bearbeiteter Abschnitt schnell abgeglichen werden.
      • Wobei die Cite-Extension nicht Standard-MediaWiki ist und die DB ein solches Feld nicht vorsehen muss.
      • Bei Bearbeitung des Gesamttextes kann in allen Modi der Gesamttext von JS oder Server in jedem Stadium analysiert werden. Für JS aber eine Quälerei mit den Benutzerressourcen.
      • API-Abruf und Online-Analyse eines Quelltextes von 500 kB mit jedem Bearbeitungsschritt bei der Abschnittsanalyse wäre für JS zu ausbremsend; das würde ich nicht einmal als Opt-In aktivieren. Entweder die API sagt bei der Abschnittsbearbeitung, welche references sie kennt (unbenannt, Gruppen; womöglich definierte ID) und der aktuelle Abschnittstext wird dagegen abgeglichen, oder der Server analysiert bei jedem submit und platziert eine Warnbox.
      • Im Prinzip müsste der Server die gesamte Seite mitsamt dem aktuell veränderten Abschnitt so montieren, als ob bereits abgespeichert wurde, alle Vorlagen expandieren, weil auch diese sich auswirken können, und diese Gesamtseite dann auf ref-Probleme analysieren. Das übersteigt mit Sicherheit die Ressourcen im Browser des Benutzers; er hätte noch nicht mal Cache-Zugriff auf Vorlagen mit Tags drin.
    • Ich würde einen verlinken Warnhinweis zwischen den Knöpfen Speichern und Vorschau empfehlen.
      • Ich selbst habe seit ewig einen Plan für ein Gadget in der Vorschau, das auf beliebiges class="error" irgendwo mitten in den zig Bildschirmseiten hinweist, und das ein Warndreieck mit Link auf das erste Vorkommen zwischen den beiden genannten Buttons einfügt. Hilft aber nicht auf der Diff-Ansicht, und bei dem speziellen Problem hier nicht für Abschnittsbearbeitung.
      • Das in Aussicht genommene Hilfsmittel könnte eine Warnbox mit Bedienungsanleitung am Seitenkopf platzieren, und ein dorthin linkendes Warndreieck unmittelbar am Speichern-Button; auch innerhalb der Speichern-Beschriftung (wäre dort aber nicht mehr anklickbar).
      • Eine Warnung wird nur möglich sein, wenn vor dem Abspeichern noch einmal preview oder diff bereits mit dem Syntaxproblem im Text erfolgen; ansonsten würde die Situation „Abspeicherungsblockade“ entstehen.
    • Restlos wird sich das Problem nicht lösen lassen; durch Tags innerhalb von Vorlageneinbindungen, benannte ref-Definitionen, die aus dem aktuell bearbeiteten Abschnitt gelöscht aber anderswo doch noch benötigt werden, und durch unerfahrene Benutzer wird es immer wieder Fälle geben, wo sich die Fehler erst nach dem Abspeichern herausstellen.
      • Aber die versehentlichen Abspeicherungen durch erfahrene Benutzer, die nur einen kleinen Edit machen wollten, und dabei unbemerkt eine > aus einem Tag gekillt htten, oder sich bei der Bearbeitung des Abschnitts und Einfügen eines Nachweises darauf verlassen hatten, das in einem so langen Artikel bereits ein <references> existieren würde, nähme deutlich ab.
      • Bei der Seitenansicht nach dem Abspeichern wird auch nicht unterschieden, ob das ein globaler Nur-Leser des Artikels oder der letzte Bearbeiter ist. Dem letzten Bearbeiter könnte man ansonsten eine Warnmeldung anzeigen; aber auch die muss nicht gesehen werden, wenn der Tab sofort nach dem Speichern weggeklickt wird (was ohnehin unweise ist).
    • Welche ref-Nummern sich hinterher für diesen Abschnitt ergeben würden, ist sehr volatil und komplex; keine zwingende Notwendigkeit, das bereits in der Abschnittsvorschau endgültig zu erfahren.
      • Ggf. in der Abschnittsvorschau statt einfacher Zahlen was anderes anzeigen; geklammerte Kleinbuchstaben oder sonstwas. Dann ist niemand verwirrt, dass die [1] hinterher eine [38] wird.
    • Fazit: Es werden auch mit Hlfsmittel Restprobleme in der Wartungskat auflaufen; aber ihre Zahl kann deutlich reduziert werden und sollte sich auf Anfängerfehler beschränken. Erfahrene Benutzer können vor unerwarteten Fehlersituationen rechtzeitig gewarnt werden, falls sie nach der Quelltextänderung nochmals submit auslösen.

--PerfektesChaos 22:03, 26. Apr. 2014 (CEST)

@PerfektesChaos: Ich hätte gern, dass der Level der umseitigen Vorschlags-Überschriften auf H3 gesetzt wird...: It's a Wiki.
@Patrick87:: War das jetzt als "Abstimmung" gedacht? Würde ich eher informell so sehen. Zum Diskutieren der Vor- und Nachteile jeder Lösungsidee.
Die Lösung 5 Anzeige am Artikelende auch ohne <references />-Tag gefällt mir persönlich am besten. Weil sie am intuitivsten ist. Nacharbeit ist notwendig, kann aber über eine Wartungskategorie gelöst werden. — Raymond Disk. 10:04, 27. Apr. 2014 (CEST)
zustimmung. in der art vom Inhaltsverzeichnis, wenn <references />-Tag gesetzt erscheinen die en dort, sonst am ende.wäre am einfachsten für alle nicht wp-erfahrenden. müsste zwar ggf dann nachgearbeitet werden, aber bisher ja auch. --Wetterwolke (Diskussion) 20:48, 27. Apr. 2014 (CEST)
Variante fünf halte ich von allen vorgeschlagenen Lösungen auch für die sinnvollste. Gruß, IW 13:16, 29. Apr. 2014 (CEST)
Ich wäre (ohne den Programmieraufwand zu berücksichtigen) bei Angemeldeten für eine "Ergänzungshilfe". Vollautomatiken wie in den Varianten 4 und 5 würde ich für angemeldete Benutzer ablehnen, weil ich fürchte, dass die Vollautomatik nicht so gut programmiert werden kann, dass sie wirklich jeden erwünschten Fall abdeckt (siehe auch PerfektesChaos oben). Und irgendwann muss man ja auch korrekte Syntax lernen. Für Unangemeldete kann man von mir aus Bots nachschicken, also "Nachtrag durch nachfolgende Bearbeitung".
Ich halte allerdings Wunsch 19 für deutlich wichtiger als Wunsch 1. Wenn also tatsächlich bei Umsetzung von Wunsch 19 die Umsetzung von Wunsch 1, Variante 5 quasi als Nebenprodukt abfällt, während die anderen Umsetzungen von Wunsch 1 noch deutliche Zusatzarbeit verursachen, dann wäre Variante 5 aus meiner Sicht doch noch akzeptabel, wenn auch ungeliebt. --Grip99 01:27, 28. Apr. 2014 (CEST)

Wir haben im Team und in Abstimmung mit Raymond beschlossen, uns an der Umsetzung der Variante „Anzeige auch ohne <references />-Tag“ zu versuchen, zweckmäßigerweise gleich in Kombination mit Wunsch 19 (Vorschau bei Abschnittsbearbeitung), da das technisch wahrscheinlich fast dasselbe werden dürfte. Es wird in jedem Fall eine Einstellung der Cite-Erweiterung werden, die dann nach Community-Beschluss ein- oder ausgeschaltet werden kann. --Thiemo Mättig (WMDE) 00:49, 27. Mai 2014 (CEST)

@Thiemo Mättig (WMDE): Ist der Bug soeben mit Gerrit:141583 gelöst worden? Getestet habe ich den Patch noch nicht. — Raymond Disk. 07:39, 1. Jul. 2014 (CEST)

Wunsch 21 von 20 (exakte Suche im Quelltext)

"Konkrete Use-Cases" wären z.B.:

  • Suche nach der Verlinkung eines bestimmten Diff- oder Permalinks (ähnliche Funktion wie "Links auf diese Seite"), wichtig unter anderem bei der Abschätzung des Effekts von Seitenlöschungen
  • Suche nach Diskussionbeiträgen von Usern, die nicht mit ihrem Benutzernamen, sondern mit (teils sogar noch wechselnder) Signatur (aber korrekter Verlinkung) unterzeichnen
  • Suche nach Links auf einen bestimmten Abschnitt (und nur auf diesen) aus anderen Artikeln (wichtig z.B. bei Änderung einer Überschrift ohne Anker)

Es würden auch Aufgaben wie die Weblinksuche, wo nur Insider überhaupt das entsprechende, bereits vorhandene Tool finden, für den Normalsterblichen leicht zugänglich. --Grip99 01:38, 28. Apr. 2014 (CEST)

Eine Umsetzung im Rahmen von CirrusSearch scheint momentan die beste Option zu sein, wäre aber zugunsten der Vorteile (echte Integration in die normale Suche, schnell, Echtzeit-Aktualisierung) auch mit Einschränkungen verbunden. So wäre es nicht möglich, nach Sonderzeichen zu suchen, da das dem Konzept eines Index zuwider läuft. Eine Quelltextsuche würde wahrscheinlich auch kein für alle sichtbarer Schalter in Spezial:Suche werden, sondern wie die meisten Expertenfunktionen als Operator (z. B. insource:) oder Spezialseite zur Verfügung stehen. Weitere Anmerkungen:
  • Bei der Suche nach Diff- und Permalinks müsste man alle IDs durchgehen, was schnell unpraktisch werden dürfte. Mindestens ebenso wichtig für die Abschätzung des Effekts von Seitenlöschungen wären externe Links. Dabei kann die Suche natürlich nicht helfen.
  • Diskussionsbeiträge kann man aktuell mit Spezial:Linkliste/Benutzer:… finden. Natürlich fehlt dort die Möglichkeit zur weiteren Einschränkung – abgesehen von der Filterung nach Namensraum. Zu bedenken ist auch, dass eine Quelltextsuche das Problem nicht 100-prozentig lösen wird, wenn „Benutzer:Peter Mustermann“ beispielsweise mit [[User:Peter_Mustermann]] unterschrieben hat.
  • Abschnittslinks haben leider das selbe Problem, z. B. würde [[Schlüssel#Schlagschl.C3.BCssel]] als „Schlagschl“, „C3“ und „BCssel“ indexiert.
Aktueller Stand: bugzilla:65783. --Thiemo Mättig (WMDE) 00:16, 27. Mai 2014 (CEST)
Danke für die Antwort und den Bugzilla-Eintrag.
Ohne Sonderzeichen und Umlaute wäre schon eine starke Einschränkung. Via insource wäre hingegen völlig in Ordnung, es muss nicht jeder die Quelltextsuche durch einen Button aufgedrückt bekommen. Spezialseite außerhalb der normalen Suche wäre vermutlich wieder mit irgendwelchen besonderen Einschränkungen verbunden (siehe unten "Ad Punkt 2"), oder nicht?
Ad Punkt 1: Alle externen Links auf eine WP-Seite zu berücksichtigen, wäre ohnehin unmöglich. Das kann niemand von der WP verlangen. Es geht nur um die internen Links. Wenn man z.B. die Seite Benutzer_Diskussion:Grip99/foo löschen wollte, dann würde man nach insource:index.php?title=Benutzer_Diskussion:Grip99/foo suchen. Das würde zwar nicht alle Diff- und Permalinks auf die Seite liefern, weil ja die Notation derartiger Links nicht eindeutig ist (und der Seitentitel ohnehin nicht unbedingt im URL enthalten sein muss oder der URL sogar eine ganz andere Seite suggerieren kann). Aber zumindest einen Großteil derartiger Verlinkungen dürfte es schon finden.
Ad Punkt 2: Genau, es fehlt die Filterung oder allgemeiner die Kombinationsmöglichkeit mit den übrigen Suchbegriffen. Wenn ich z.B. wissen will, wo Benutzer:Grip99 das Wort "foobar" in die Finger genommen hat, dann kann ich mit der bestehenden Textsuche (aber nicht per Linkliste) nach Grip99 foobar suchen, weil ich weiß, dass in meiner eigenen Signatur immer explizit (also ohne Berücksichtigung des Quelltexts) mein Name auftaucht. Bei anderen Benutzern gilt das aber nicht immer. Und wenn der Benutzername nur aus 1 oder 2 Buchstaben besteht oder ein vielbenutztes Wort ist, dann ist eine derartige Suche sogar im Fall, dass der Benutzer immer mit seinem tatsächlichen Namen signiert, praktisch unmöglich, während eine echte Quelltextsuche nach foobar insource:[[Benutzer:A]] bzw. foobar insource:[[Benutzer_Diskussion:A]] ein einigermaßen brauchbares Ergebnis liefern dürfte. (Natürlich kann die Verlinkung theoretisch auch in der Form [[BD:A]] oder [[talk:A]] oder [[user:A]] erfolgen, aber das sind dann die Ausnahmen.) --Grip99 02:02, 19. Jun. 2014 (CEST)

 Info: Eine Lösung wurde mit Gerrit:137733 realisiert und sollte in 1-2 Wochen live gehen. — Raymond Disk. 11:01, 19. Jun. 2014 (CEST)

Stand 25. Juni

Gestern gabs eine Telco zwischen 3 Entwicklern von WMDE und mir zum Stand der Dinge. Die von Benutzer:Thiemo Mättig (WMDE) weiter oben erwähnte Lösung für Wunsch 1 befindet sich intern in der Programmierung. Damit verbunden ist der Review des Patches von Wunsch 19. Zu Wunsch 3 und 10 findet eine Einarbeitung in das neue CirrusSearch statt. Die Idee ist, CatScan/Schnittmengensuchen direkt in die Suche zu integrieren, ohne dass Umwege über ToolLabs genommen werden müssen. Ich drücke die Daumen, dass das alles so klappt :-) — Raymond Disk. 10:30, 26. Jun. 2014 (CEST)

Stand Wunsch 1

Wund 1 ist als erledigt markiert, die Änderung scheint aber noch nicht live zu sein. Ein <ref>foo</ref> erzeugt immer noch eine Fehlermeldung… Wann geht die Änderung live? -- Michi 19:17, 10. Jul. 2014 (CEST)

Heute abend, vergleiche Wikipedia:Projektneuheiten#Vorschau auf Version 1.24wmf12. Der Umherirrende 19:44, 10. Jul. 2014 (CEST)
Nun funktioniert es. Der Umherirrende 21:04, 10. Jul. 2014 (CEST)

Einblendung der Autoren direkt am Artikeltext / Alternative

  • Kopie von Vorderseite --Martina Disk. 17:43, 12. Apr. 2015 (CEST)
  • Wir haben Artikel mit (teils mehreren) Tausend Autoren (Hamburg, Berlin, Paris, London oder sowas in der Art).
  • Die genannte Extension zählt einfach alle auf, einschließlich mehrerer Dutzend Interwiki-Bots, und alle 2000 gleichrangig, und momentan sogar revertierte Beiträge.
  • Das ist schlicht und einfach Nonsens und keine ernstzunehmende Alternative für ein großes Wiki; nur für private Kleinprojekte mit ein oder zwei Dutzend Benutzern.
Das Grundproblem ist nicht lösbar: Gesucht werden ein oder ein paar Dutzend Autoren, die inhaltlich am meisten beigetragen haben.
  • Dieser Beitrag kann aber sehr unterschiedlich ausfallen und ist nicht durch computertechnisch-quantifizierende Methoden zu ermitteln.
  • Mit relativ wenig Textumfang können konzeptionell richtungsweisende, strukturierende Beiträge am Anfang die wesentliche Arbeit geleistet haben.
  • Wegen der wenigen Bytes oder Wörter kommt der geistige Hauptautor aber nur auf Platz 234.
  • Andere fügen mit C&P eine umfangreiche Daten-Tabelle ein oder aktualisieren URLs, die wegen geändertem Pfad jetzt viel länger sind als früher, und fügen das Abrufdatum hinzu und bibliografische Routinedetails. Großer Beitrag, großes Geranke.
  • Jemand entfernt ein völlig sinnentstellendes „nicht“ – negativer Beitrag, keine Würdigung.
  • Genauso die anspruchsvolle Korrektur einer Formel oder fehlerhafter Daten; plusminus Null. Kein wesentlicher Beitrag.
  • Ein wenig Umformulierung in Kanzleistil, Beamtendeutsch, Substantivierung, Geschwurbel: Umfangreiche Erweiterung. Hohes Ranking.
  • Desgleichen bei einem automatisierten Syntax-Upgrade von veraltetem HTML3 auf aktuelles style= – deutlicher Byte-Zuwachs, wichtiger Autor.
Das Zusammenwirken vieler Autoren im Lauf mehrerer Jahre (oder gar eines Jahrzehnts) an einem komplexen Artikel kann nur durch Menschen beurteilt werden; an dem ganzen Wunsch wird eine ultranaive Vorstellung von den Auswertungs- und Bewertungsmöglichkeiten mittels Software deutlich. Den Wunsch selbst kann man ja hegen, aber kommt um eine persönliche Einschätzung jedes Einzelfalls nicht herum.
VG --PerfektesChaos 10:28, 11. Apr. 2015 (CEST)
@PerfektesChaos: Ich denke es geht bei diesem Wunsch darum, dass die Rolle der Autoren überhaupt irgendwie (und im Sinner der Lizenz) gewürdigt wird. In die Versionsgeschichte, die aktuell quasi als Attribution herhalten muss verirrt sich nämlich kaum ein Leser. Und wenn, dann weiß er damit (wie Du ja schön beschreibst) ohne tiefergehendes Hintergrundwissen kaum was anzufangen. Von daher ist jede Art der Auflistung von Autoren besser als das, was wir gerade haben.
Außerdem führt das ja nicht nur dazu, dass irgendwelchen Wikipedianern der Bauch gekrault wird, sondern vermittelt idealerweise auch dem geneigten Leser, dass so ein Artikel nicht von irgendeinem angestellten Redakteur, sodnern von einer Vielzahl von freiwilliger Autoren erstellt wird und er selbst einer davon sein könnte. // Martin K. (Diskussion) 12:04, 11. Apr. 2015 (CEST)
Dann sollte in jedem Fall bei diesem ganzen Wunsch glasklar herausgearbeitet werden, was genau überhaupt der Zweck der ganzen Aktion sein soll, und wer genau jetzt was genau vom Resultat lernen soll. VG --PerfektesChaos 12:09, 11. Apr. 2015 (CEST)
  • Kopie ENDE
Natürlich wäre eine gut funktionierende Hauptautorennennung wünschenswert, sie ist aber wohl einfach technisch unmöglich. Eine Auflistung aller Autoren am Artikelende fände ich daher schon einen ziemlich großen Schritt in die richtige Richtung. Dabei sollte man meiner Meinung nach idealerweise Bots, IPs, kleine Edits und Revertierte Edits nicht berücksichtigen. Die Auflistung sollte alphabetisch erfolgen und mit einem Link auf die Versionsgeschichte ("und weitere") enden. Das hätte auch den Vorteil, das eine (komplett) ausgedruckte Version des Artikels einfach weiterverbreitet werden kann ohne eine URV zu begehen. -- Michi 23:32, 12. Apr. 2015 (CEST)
  • Deutschland: 3.553 Autoren – Hamburg 2.589 Autoren – Österreich 2.197 – Johann Wolfgang von Goethe 1.351 – usw. usw. usf.
    • Bei einem zentralen Artikel, der ein Jahrzehnt lang bearbeitet wurde, ist das eine Gaga-Aktion.
  • Ich wiederhole meine Frage:
    • Welcher Personenkreis genau soll exakt welchen Erkenntniswert daraus ziehen, dass am Ende des Artikels mehrere Hundert Nicks aufgezählt werden?
    • Was sagt mir diese Liste von Bugs17, Bunny84, Tom34, Jerry09, Micky16, Maus98, etc. etc. etc.?
    • Nach welchen Kriterien sollen wie viele Hundert Nicks aus der Masse der Autoren herausgegriffen werden? Nach Byte-Anzahl (wertlos, siehe oben)? Nach Häufigkeit von Mini-Bearbeitungen (ganz doll viele Einzeledits machen zun Hauptautor)? Wie wird die Löschung eines lange unbemerkten Fehlers nach aufwändiger Recherche bewertet (negativer Beitrag)? Gilt die mühsame Korrektur einer Formel als „kleine Änderung“?
    • Und wozu das alles?
VG --PerfektesChaos 00:55, 13. Apr. 2015 (CEST)
Deine grundsätzliche Kritik bzw. deine Zweifel wurden in früheren Diskussionen schon angesprochen. Die Lizenzen CC und GFDL verlangen beide eine Urhebernennung von Nachnutzern. Bislang ist diese nur sehr mühselig aus der Versionsgeschichte ableitbar. Der umseitige Software-Wunsch bzgl. Autorenauflistung sieht eine Community-Diskussion und -Abstimmung vor der Einführung vor. Insofern kann es derzeit erstmal nur darum gehen, verschiedene technische Ansätze auf Machbarkeit, Aufwand, Kosten zu prüfen und anschließend müssten wir projektintern gucken, was davon wir wie umsetzen wollen. Theoretisch kann am Ende z.B. ein Link "Autoren" am Seitenende (analog zu "Abrufstatistik") dabei herauskommen. Wie etwa in dem genannten Beispiel einer Credit-Seite
Ein paar Anmerkungen und Erklärungsversuche zu deinen Einzelpunkten:
Zweck - Anerkennung der Autoren, lizenzkonforme Nachnutzung erleichtern (→ mehr Rechtssicherheit für Nachnutzer)
Pseudonyme wie Bugs17, Bunny84, Tom34 etc. - Auch Pseudonyme sind rechtsgültig; jeder dieser Autoren kann theoretisch sein Pseudonym bei der VG Wort angemeldet haben und damit als Urheber seine Vergütungsansprüche aus den Kopierabgaben anmelden. Persönliche Bewertungen solcher Pseudonyme spielen für den Anspruch auf Autorenennung bei Weiternutzungen und für Vergütungsansprüche keine Rolle.
Artikel mit sehr hohen Autorenzahlen - Dies wäre ein Punkt, der technisch noch zu prüfen ist. Vorschläge waren etwa bestimmte Edits nicht mitzuzählen (Reverts, Bots, gekennzeichnete kleine Änderungen, anonyme Beiträge usw.). Ein weiterer Ansatz wäre, nur bestimmte Beitragsmengen als Mit-Autorenschaft zu werten. Die VG Wort setzt die Grenze bei 10% Anteil an einem Text; alles andere wird als schlichte Korrekturleistung bewertet. Wenn es gelingen sollte, für diese Punkte pragmatische Ansätze zu finden, bliebe auch bei langen Artikeln mit sehr vielen Autoren mutmaßliich und meiner Erfahrung nach (anhand von WikiHistory) eine überschaubare Anzahl echter Hauptautoren übrig.
Persönlich bin ich der Meinung, dass wir uns von schwierigen Einzelfällen nicht von dem Anstreben einer praktikablen Lösung abhalten lassen sollten. --Martina Disk. 17:31, 13. Apr. 2015 (CEST)
Wir schauen uns den Alternativ-Vorschlag von Martina auf Aufwand und Machbarkeit nochmal an (vielen Dank fürs Einbringen) - Anzeige von allen Autoren ohne Gewichtung nach Anteil ist erstmal machbar(er), aber das müsste man sich genau ansehen. Ich spreche die Machbarkeits- und Aufwands-Abschätzung des Alternativ-Vorschlags bei uns an und melde mich hier zurück, wenn ich weiß, wann das gemacht werden kann. Momentan sind wir hierbei. Und ja - nach der Abschätzung der Alternative ist dies auf alle Fälle ein Wunsch, der sehr breit diskutiert und abgestimmt werden müsste. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 18:37, 13. Apr. 2015 (CEST)
@Birgit: Prima, danke. --Martina Disk. 18:56, 13. Apr. 2015 (CEST)
Für die Umsetzer: Es gibt ein API-Modul: Spezial:ApiHelp/query+contributors mit dem man sich zumindestens alle Benutzer zu einer Seite anzeigen lassen kann, aber die entsprechende Datenbankabfrage zu bauen war auch ein HickHack, weil das wohl nicht so performant geht. Vielleicht kann man ja die Abfragen dahinter erstmal nutzen, um sie auf den Seiteninfos (action=info) anzuzeigen, als Anfang. Ich kann mir aber vorstellen, dass das dann wieder auf WMF-Wikis deaktiviert wird, weil es zu inperformant ist, so wie mit einigen Zählern auf action=info. Der Umherirrende 20:14, 13. Apr. 2015 (CEST)

Als Hintergrundlektüre empfehle ich

da wurde verglichen und pro und kontra diskutiert, ganz gutes Stimmungsbild. Im übrigen mal ein paar Fragen:

  • Wieviele Versionen haben die 50% Artikel mit den wenigsten Versionen? Wieviele die 5% Artikel mit den meisten Versionen?

Hat da mal jemand ein paar Zahlen für deWikipedia? Per quarry (Wikipedia:Technik/Labs/Quarry) oder so? Zahl der Versionen ist nicht gleich Bearbeiterzahl, klar, aber als Anhaltspunkt? Bspw. Schnarks Tool wird irgendwann (+400 Versionen?) langsam und da wäre es interessant wieviele Artikel betroffen sind. --Atlasowa (Diskussion) 20:43, 13. Apr. 2015 (CEST)

Für ein paar Zahlen: Spezial:FewestRevisions und Spezial:MostRevisions. Der Umherirrende 20:59, 13. Apr. 2015 (CEST)
Danke, Umherirrender, da steht leider "Maximal 5.000 Ergebnisse sind im Cache verfügbar. Die Aktualisierungsfunktion dieser Seite ist zurzeit deaktiviert. Die Daten werden bis auf Weiteres nicht erneuert." und bei Spezial:Wenigstbearbeitete_Seiten noch "Diese Spezialseite ist außer Betrieb." Hm? Ansonsten finde ich dort:
Laut Spezial:Statistik hat dewiki zur Zeit 1.805.085 Enzyklopädische Artikel. Also wären 5000 Artikel nur 0,27%. Also hätten die restlichen 99,46% (1.795.085 Artikel) zwischen 2 und 1.065 Bearbeitungen. (Und weniger als ~500 unterschiedliche Autoren?) --Atlasowa (Diskussion) 21:54, 13. Apr. 2015 (CEST)
Mal ein paar zufällige Artikel:
--Atlasowa (Diskussion) 22:02, 13. Apr. 2015 (CEST)
Hab mal das oben genannte Extrembeispiel Deutschland angeschaut: von den über 3500 Autoren bleiben nach Abzug der IPs und der User die nur kleine Änderungen gemacht haben noch knapp über 1000 Autoren übrig. Bots und Revertierte Edits hab ich nicht untersucht, dürfte die Autorenzahl aber nochmal ein Stück reduzieren. 1000 Autoren in Schriftgröße 8 im Blocksatz abzudrucken wäre zwar hässlich aber kein Problem (2-5 cm je nach Monitor und Design) und das wäre wie Atlasowa demonstrierte eines von wenigen Extrembeispielen. Zu Martina Punkten möchte ich noch ergänzen das es für Leser eine interessante Information ist wie viele Personen an einem Artikel mitgeschrieben haben. Kaum ein Leser weiß, geschweige den kann es sich vorstellen, dass so viele Leute an dem Artikel Deutschland mitgewirkt haben. -- Michi 23:40, 13. Apr. 2015 (CEST)


Zurück zur Anfrage von 17:31, 13. Apr. 2015

  • Aha; nun kommen wir der Sache näher.
    • Zielgruppe: Nachnutzer.
    • Zweck: Lizenzkonforme Nennung der Autoren.
    • Gesucht: (Zitat) „Urhebernennung von Nachnutzern“
  • Na, da können wir helfen; beispielsweise für den Artikel Deutschland in seiner Fassung vom heutigen Tage:
    //de.wikipedia.org/w/index.php?curid=1497705&action=history&year=2015&month=4&day=16
    (Anmerkung: day= ist momentan nicht implementiert, weil bislang kein Bedarf; wäre aber mit Leichtigkeit nachzurüsten. Kein Schaden, dann halt der komplette Monat.)
    • Vorteil: Alle Autoren sind nicht nur bloß mit Nick erwähnt, sondern auch gleich verlinkt, und deren Beiträge sind auch nachvollziehbar.
    • Nebenbei wäre es unfair, die IP per se abzuziehen. Auch sie haben teils umfangreiche Beiträge geleistet; es könnte die Situation eintreten, dass die angemeldeten nur Kleinkram machten und der eigentliche Artikel von Anonymen stammt. In der Autorennennung stünde dann nur ein einziger Angemeldeter mit katfix, oder nur ein Bot oder überhaupt niemand.
    • Eine Herausfilterung von scheinbar kleinen Änderungen (ausgenommen Reverts und Leerzeichen-Edits) wäre unzulässig, weil sich softwareseitig nicht sicher feststellen lässt, was eine inhaltliche Korrektur (ggf. durch Löschungen) und was eine marginale Änderung ist.
    • Es gibt bei unseren Artikeln grundsätzlich keine andere als die „nur sehr mühselig aus der Versionsgeschichte ableitbar“ zu konstruierende Nennung; aber für die Einhaltung der Lizenz ist es auch völlig egal, welche Hunderte von Autoren es konkret waren, sondern der Link auf das Original-Wiki reicht völlig aus, um sich in beliebiger Detaillierung ein Bild von den Einzelbeiträgen machen zu können. Dadurch ist gleichzeitig immer auch der Rückgriff auf den Originaltext am ursprünglichen Veröffentlichungsort gegeben.
  • Wenn man bei Lesern Reklame dafür machen will, dass an Artikeln viele Leute mitgearbeitet haben, dann kann man das zu Weihnachten in die Spendenbanner dazutun und noch mal dick und fett in Wikipedia:Über Wikipedia reinschreiben.
    • Aber es wäre eine Belästigung sämtlicher Nutzer und überflüssige Belastung mit Netzwerktraffic und Antwortzeit, ungefragt bei jedem Artikel jedem diese Textwüste aufzuzwingen, die niemals jemand liest oder lesen will. Schon bis zu den references wird kaum je gescrollt.

Aber:

  • Alle anderen Wünsche nach WikiHistory wollen nichts von lizenzkonformer Nachnutzung wissen, sondern zielen glasklar auf den einen oder die zwei Hauptautoren eines Artikels ab.
  • Denen ist mit einer Auflistung der 1000 häufigsten Autoren nicht gedient.
  • Deshalb hinterfrage ich hier permanent, wozu das überhaupt gut sein soll.

Insgesamt konstatiere ich, dass das Ziel dieses Features völlig im Nebel liegt. Ursprünglich und mehrheitlich will man wohl den Hauptautor wissen, dann kommt irgendeine Aufzählung zu Lizenzzwecken ins Spiel, und schließlich ginge es um Werbung bei den Lesern für die Mühsal durch die vielen Autoren.

VG --PerfektesChaos 11:38, 16. Apr. 2015 (CEST)

Hallo zusammen, von Seite des Entwicklerteams steht erstmal eine erste Einschätzung zur Machbarkeit der Alternative mit auf der to do Liste der nächsten 2 Wochen. Wir würden uns einzelne Punkte hier auf der Disk schon mal mit ansehen (also z.B. Nicht-Anzeigen von IPs & Co). @PerfektesChaos:, deine und andere Punkte wären auf jeden Fall zentrale Fragen, die für den Fall das gut diskutiert und abgestimmt werden müssten. Autorennennung ist schon eine zentrale Veränderung des Status Quo - mit vermutlich sehr unterschiedlichen Positionen dazu. Da müsste klar sein, dass Leute das wirklich wollen und wenn ja, wie - im Rahmen dessen, was möglich ist. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 19:45, 16. Apr. 2015 (CEST)
Danke nochmal für die Info, Birgit. Für die Community-Entscheidung ist wichtig zu wissen, was im Detail überhaupt machbar ist und was realistische Optionen sind. Dafür ist eure Vorarbeit wichtig und sehr hilfreich. --Martina Disk. 19:59, 16. Apr. 2015 (CEST)
Gerne, das gebe ich so auch mal weiter, vielen Dank :) - Grüße, Birgit Müller (WMDE) (Diskussion) 09:20, 17. Apr. 2015 (CEST)

Einschätzung zur Machbarkeit des Alternativvorschlags

Die Funktionalität der Credit-Seite, wie sie auf wikitravel.org zur Verfügung steht, ist MediaWiki-Standard. In den Wikimedia-Projekten wurde diese aber explizit deaktiviert, weil der Inhalt auf Anfrage generiert wird. Die Performance muss optimiert werden und der Inhalt der Credit-Seiten müssen im Cache abgelegt werden, um eine Aktivierung zu ermöglichen (siehe dazu auch den Phabricator Task). Zudem muss irgendwo ein UI-Element hinzugefügt werden, das den Zugriff auf diese Daten ermöglicht (z. B. die Navigation auf der linken Seite). Die Machbarkeit ist auf jeden Fall gegeben, hängt aber ganz klar von den Anforderungen ab. Filtern von Revertierungen und eine gewichtete Auflistung nach Anzahl der Bearbeitungen oder Anzahl hinzugefügter Zeichen sorgen für höheren Berechnungsaufwand. Meiner Meinung nach sind das aber auch keine ausschlaggebenden Gewichtungskriterien. Kai Nissen (WMDE) (Diskussion) 19:01, 28. Apr. 2015 (CEST)

Nachtrag: Wenn bestimmte Filter angewandt werden sollten, müsste sich auf eine Variante geeinigt werden - also keine Auswahlmöglichkeit, entweder dies, das oder jenes auszublenden, sondern einen Standard. Je nach dem, was das ist, müssten wir noch mal sehen, wie sich das auf den Berechnungsaufwand auswirkt. Sollte Interesse bestehen, dass diese Variante der Autorennennung mittels Credit-Seite perspektivisch umgesetzt wird, wäre der nächste Schritt ein Meinungsbild von Community-Seite dazu. Bei den Details zu dieser Variante der technischen Umsetzung (X oder Y rausfiltern) - können wir gerne nochmal sprechen. Im Falle das, wie würde es danach weitergehen: Gibt es ein positives Meinungsbild zur Frage Autorennennung, würde die entsprechende Aufgabe zu den "nächsten Aufgaben" wandern. Wichtig wäre in jedem Fall, dafür sehr breit Öffentlichkeitsarbeit zu machen - dass es auch Autorinnen und Autoren erreicht, die weniger bis nie auf den üblichen Orga-Seiten unterwegs sind und die wesentlichen Knackpunkte anzusprechen (siehe z.B. Anmerkungen von Perfektes Chaos). Unterstützung bei möglichen Meinungsbild-Fragen gerne dort, wo es um Detailfragen zu den Möglichkeiten in der technischen Umsetzung geht. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 16:39, 6. Mai 2015 (CEST)

Konzept Technische Wünsche - Ideen und Feedback willkommen

Ausgehend von der umseitigen Top 20 und der vorausgegangenen Umfrage wird seit März in mehreren Veranstaltungen ("Tech on Tour") rund um die Frage diskutiert, wie technische Unterstützung für die Communitys organisiert werden kann. Für alle, die nicht bei den Veranstaltungen waren/sein werden oder noch was ergänzen wollen, läuft bis zum 20.5. ein "Wiki-Dialog". Wer Interesse hat, ist herzlich willkommen, bis zum 17.5. hier vorbeizuschauen, Anregungen, Ideen, Feedback... beizusteuern und mit zu diskutieren. Mehr Informationen zum Projekt gibt es auf WP:Technische Wünsche, in diesem Blogbeitrag sowie im Kurier. Herzliche Grüße, Birgit Müller (WMDE) (Diskussion) 17:05, 6. Mai 2015 (CEST)

Prototyp „Deepcat“-Gadget: Einladung zum ersten Testen

Die Umsetzung des Wunsches “CatScan-Funktionalität“ in die Software integrieren, ist einen Schritt weiter: In den letzten Wochen wurde ein Prototyp namens „Deepcat“ entwickelt – ein Gadget, mit dessen Hilfe Abfragen bis tief in die Unterkategorien hinein durchgeführt werden können."deepcat“ funktioniert als Schnittstelle zwischen einer Graphdatenbank, in der die Kategorienstruktur der deutschsprachigen Wikipedia über die page-ids der jeweiligen Kategorien abgebildet ist, und der Suchmaschine. Das Gadget übernimmt sozusagen die „Übersetzung“, holt sich die angefragte Information aus der Datenbank und liefert sie an die Suche. Das Gadget arbeitet im „Hintergrund“ - die Suchabfrage läuft ganz normal über das Suchfeld in der Wikipedia.

In der Testinstanz auf Tool Labs kann die Anwendung des ersten Prototyps nun ausprobiert werden.

Dort befindet sich ein Mini-Set aus der deutschsprachigen Wikipedia mit ca. 40000 Seiten. Nicht verwirren lassen: Neben vielen Artikeln sind auch Vorlagen, Bilder usw. nicht eingebunden, daher gibt es viele Rotlinks auf den Seiten. Entsprechend werden auch nur dort Ergebnisse geliefert, wo Kategorien und Artikel vorhanden sind.

Das Schlüsselwort für die Kategoriensuche ist „deepcat“. „deepcat“ ist mit allen anderen Möglichkeiten der Suchmaschine Cirrus kombinierbar – eine Auflistung der Suchmöglichkeiten findet sich hier. Damit die Abfrage funktioniert, muss "deepcat" genau so geschrieben werden, wie hier angegeben - kleingeschrieben.

Beispiele:

  • deepcat:Physik – liefert Ergebnisse aus den Unterkategorien von „Physik“
  • Berlin deepcat:Physik – Ergebnisse aus den Unterkategorien von „Physik“, in denen das Wort „Berlin“ vorkommt
  • deepcat:Maler deepcat:Kunstgeschichte – liefert Ergebnisse, die sich sowohl in Unterkategorien von „Maler“ als auch von „Kunstgeschichte“ befinden
  • deepcat:Maler -deepcat:Kunstgeschichte – liefert Ergebnisse, die sich zwar in Unterkategorien von „Maler“, aber nicht von „Kunstgeschichte“ befinden
  • deepcat:Maler Berlin deepcat:Kunstgeschichte – liefert Ergebnisse aus den Unterkategorien von „Maler“ und „Kunstgeschichte“, in denen das Wort Berlin vorkommt
  • deepcat:Maler -Berlin deepcat:Kunstgeschichte – liefert Ergebnisse aus den Unterkategorien von „Maler“ und „Kunstgeschichte“, in denen das Wort Berlin nicht vorkommt
  • deepcat:"Geschichte der Physik" oder deepcat:Geschichte_der_Physik - liefert Ergebnisse aus Kategorien, deren Titel aus mehr als einem Wort bestehen

Die Ergebnisse: Momentan sucht das Gadget bis Suchtiefe 10, maximal werden jedoch bis zu 50 Unterkategorien berücksichtigt (die Suche bricht also ab, wenn 50 Kategorien gefunden wurden). Dies soll noch erweitert und optimiert werden – gerne auch hier ein Feedback, was ein sinnvoller Wert wäre.

Wir freuen uns, wenn Leute Zeit und Lust haben, das auszuprobieren - Fragen und Anregungen sind herzlich willkommen! Feedback ist wichtig, um Schwachstellen zu finden und diesen (wirklich ersten) Prototypen weiterentwickeln zu können. Vielen Dank :) --Birgit Müller (WMDE) (Diskussion) 12:39, 20. Mai 2015 (CEST)

Für diejenigen, die auf unser Testwiki per HTTPS zugegriffen und in der Suche kein Ergebnis bekommen haben: Das Problem sollte jetzt behoben sein, bitte ggf. Browsercache leeren, die Seite neu laden und nochmal probieren. --Johannes Kroll (WMDE) (Diskussion) 14:07, 20. Mai 2015 (CEST)

@Birgit Müller (WMDE): Erst mal großen Dank für das Anpacken dieses Features! Gibt es auch eine zentrale Sammelstelle für die Rückmeldungen?--Mabschaaf 15:10, 20. Mai 2015 (CEST)

Hallo Mabschaaf, danke Dir! Oh ja, das ist nicht wirklich klar geworden in meiner Ankündigung: Rückmeldungen gerne auch hier auf der Disk! - Beste Grüße, Birgit Müller (WMDE) (Diskussion) 17:06, 20. Mai 2015 (CEST)

Rückmeldungen und Fragen zu DeepCat

@Birgit Müller (WMDE), Johannes Kroll (WMDE): Bei mir geht es nicht, weder mit http noch mit https. --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 16:57, 20. Mai 2015 (CEST)

Hallo MGChecker, kannst du genau sagen, was passiert - bekommst du irgendeine Meldung? Danke, Birgit Müller (WMDE) (Diskussion) 17:06, 20. Mai 2015 (CEST)
Ich fand es irritierend, zunächst einmal gar keine Treffer zu erhalten - bis ich herausgefunden hatte, dass auch nur ein kleiner Teil der Kategorien in die Testumgebung übertragen wurde. Also unbedingt darauf achten, dass die zu durchsuchende Kat überhaupt anwesend ist... Überhaupt kann man in der Testumgebung ein Feeling von Wikipedia-vor-10-Jahren erhalten, alles voll mit Rotlinks ;-)--Mabschaaf 17:33, 20. Mai 2015 (CEST)
Beides hat Birgit ja oben schon erklärt. @MGChecker: ist dein Problem damit gelöst? --Johannes Kroll (WMDE) (Diskussion) 17:52, 20. Mai 2015 (CEST)
<quetsh> Nein. Bei mir kommt zum Beispiel bei deepCat:Geschichte der Physik gar kein Ergebnis. Die Ergebnisseite ist unter dem "Inhaltsseiten Multimedia Alles Erweitert"-Balken sofort zuende. --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 19:07, 20. Mai 2015 (CEST)
Bei der Suche nach Titeln mit Leerzeichen müssen entweder Anführungszeichen verwendet oder die Leerzeichen durch Unterstriche ersetzt werden, da unterscheidet sich das Gadget nicht von anderen Keywords die Titel entgegennehmen wie z. B. incategory:. Also in diesem Fall entweder deepCat:"Geschichte der Physik" oder deepCat:Geschichte_der_Physik. --Johannes Kroll (WMDE) (Diskussion) 19:23, 20. Mai 2015 (CEST)
Hab das mal als weiteres Beispiel oben eingefügt - Danke für den Hinweis! Birgit Müller (WMDE) (Diskussion) 19:36, 20. Mai 2015 (CEST)
Toll! Jetzt klappts. Ist schon bekannt, wann das für die Wikipedia eingeführt wird? Zumindest als Beta-Feature? --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 20:36, 20. Mai 2015 (CEST)
Hey, prima! - Es gibt noch keinen genauen Zeitpunkt für die Aktivierung in der Wikipedia. Diese und nächste Woche ist erstmal zum Ausprobieren in der Testumgebung eingeplant. Dann kann man sehen, was an Rückmeldungen gekommen ist, was für Probleme/Bugs noch aufgetaucht sind, wie aufwendig Sachen sind, die noch verbessert werden sollten und wann die nächsten Schritte folgen. Updates gibt es jeweils auf der Vorderseite. Wird aber insgesamt nicht mehr "ewig" dauern ;). Birgit Müller (WMDE) (Diskussion) 08:29, 21. Mai 2015 (CEST)
Schön :) --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 15:56, 21. Mai 2015 (CEST)

Ein kleiner Bug: Klickt man nach erfolgreicher Suche sich durch zu einem Artikel und nutzt dann den Zurück-Button des Browsers, steht nicht mehr der ursprüngliche Suchausdruck im Suchfeld, sondern eine Reihe von kryptischen IDs.--Mabschaaf 17:33, 20. Mai 2015 (CEST)

Das Problem ist uns bekannt, gleiches passiert beim Klick auf "Weitere X Ergebnisse". Werden wir noch ändern. --Johannes Kroll (WMDE) (Diskussion) 17:52, 20. Mai 2015 (CEST)
P.S.: @Mabschaaf:, Die IDs sind die page-ids (Seitenkennzahlen) der jeweiligen Kategorien und stammen aus der Abfrage in der Graphdatenbank, in der nicht die wörtlichen Bezeichnungen der Kategorien, sondern die page-Ids der jeweiligen Kategorien-Seiten abgebildet sind. Dass das schon ziemlich irritierend ist, ist auf jeden Fall ein wichtiger Hinweis, danke - :) --Birgit Müller (WMDE) (Diskussion) 18:15, 20. Mai 2015 (CEST)
Und ja - das Wikipedia 2004-Gefühl ist toll ;) - Ganz schön was passiert in der Zeit... Birgit Müller (WMDE) (Diskussion) 19:05, 20. Mai 2015 (CEST)

Frage zur Suchtiefe: "Fairbank deepCat:Gravitation" findet den Artikel "Gravity Probe" aber "Fairbank deepCat:Physik" findet ihn nicht mehr. Dabei sind es nur 4 Unterkategorien und ihr meintet oben, ich sucht 10 Ebenen tief, ist hier das Maximallimit von 50 Kategorien erreicht? Die Tiefe von 10 Kats schein mir ausreichend aber die Gesamtzahl von 50 recht wenig. Auf jeden Fall sollte wenn die Suche aufgrund der Tiefe/Größe abgebrochen wird ein Hinweis diesbezüglich eingeblendet werden. Sonst sehr schön. -- Michi 14:01, 2. Jun. 2015 (CEST)

Hallo Michi, ja, das liegt an dem Limit von 50 Kategorien. Die Suchtiefe ist zwar 10, aber momentan wird abgebrochen, sobald 50 Kategorien erreicht sind. Was da ein guter und vor allem auch für Cirrus leistbarer Wert ist, müsste nochmal geschaut werden. Was denkst du, was ausreichend wäre? - Danke für dein Feedback und die Anregung mit dem Hinweis, ich nehm' das mit ins nächste Teamtreffen. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 17:23, 2. Jun. 2015 (CEST)
Wie arbeitet das Propgramm eigentlich? Beipsiel:
  • Kategorie in der gesucht wird (X)
    • Unterkat 1
      • Unterkat A
    • Unterkar 2
      • Unterkat B
X-1-A-2-B oder X-1-2-A-B Wäre wegen dem 50-Kats-Limit ganz interessant. --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 17:39, 2. Jun. 2015 (CEST)
Hi MGChecker! Es wird eine Breitensuche gemacht, d. h. in diesem Fall wäre die Reihenfolge X-1-2-A-B. In dem existierenden Prototyp werden maximal 50 Kategorien an CirrusSearch übergeben. Für eine praktische Nutzung ist das zu wenig: Bei einer Kategorie wie Physik hat man bei Suchtiefe 3 schon ca. 200 Unterkategorien. Wie weit wir das Kategorienlimit erhöhen können, hängt u. a. davon ab, wie viel CirrusSearch realistisch "verkraftet". Das müssen wir herausfinden. Auch dieses Detail müssen wir noch klären. --Johannes Kroll (WMDE) (Diskussion) 22:01, 2. Jun. 2015 (CEST)

Tolle Sache, gerade erst gesehen! Bei meinem Test dort mit Suche "deepCat:Geschichte_der_Physik" rödelt es aber nur so vor sich hin. (Oder muss man eingeloggt sein?) --Atlasowa (Diskussion) 10:35, 18. Jun. 2015 (CEST)

Das Feature bietet eine sehr ähnliche Funktion wie commons:Help:FastCCI, oder? (JavaScript gadget. advanced interface: arbitrary category intersections) --Atlasowa (Diskussion) 10:40, 18. Jun. 2015 (CEST) Oha, ein paar Nummern größer. Aber jedenfalls wäre commons auch sehr interessierter Nutzer von Deepcat! --Atlasowa (Diskussion) 10:45, 18. Jun. 2015 (CEST)
Hi, Deepcat ist auch für Commons geplant - eines der Dinge, an denen gerade gearbeitet wird. Auf der Testinstanz musst du nicht eingeloggt sein. Aber es gibt gerade ein Problem, hab das schon weitergegeben. Theoretisch kann das Gadget inzwischen auch schon in der Wikipedia ausprobiert werden (siehe Update auf der Vorderseite). Dazu gibts hier auf der Disk auch nochmal eine Meldung, wenn es grundsätzlich wieder funktioniert. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 10:57, 18. Jun. 2015 (CEST)
Danke, Birgit Müller (WMDE)! Installiert. Aber, hm, momentan zeigt mir das hier nur diese Seite als Ergebnis: https://de.wikipedia.org/w/index.php?title=Spezial:Suche&search=deepCat%3AGeschichte_der_Physik Mal abwarten. --Atlasowa (Diskussion) 12:55, 18. Jun. 2015 (CEST)
Hi Atlasowa, die Schreibweise von "deepcat" ist inzwischen dem üblichen Standard angepasst und wird komplett kleingeschrieben (wie "incategory" auch). So: https://de.wikipedia.org/w/index.php?deepCatSearch=deepcat%3AGeschichte_der_Physik&title=Spezial%3ASuche&search=+&deepCatError=deepcat-error-tooldown bekommst du die Meldung, dass das Tool gerade nicht erreichbar ist - ich melde mich, wenn es wieder läuft :). Viele Grüße, Birgit Müller (WMDE) (Diskussion) 13:05, 18. Jun. 2015 (CEST)

@Atlasowa: es sollte jetzt wieder funktionieren - Tool Labs war down für einige Tage, daher war auch die Graphdatenbank, auf die deepcat zurückgreift, nicht erreichbar. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 12:30, 23. Jun. 2015 (CEST)

Test:

  • deepcat:Geschichte der Physik [1] = 144 Ergebnisse
  • deepcat:Geschichte_der_Physik [2] = 80 Ergebnisse
  • incategory:Geschichte_der_Physik [3] = 32 Ergebnisse

Die beiden letzteren stimmen mit den Angaben auf Kategorie:Geschichte_der_Physik überein :-) --Atlasowa (Diskussion) 14:25, 3. Jul. 2015 (CEST)

Dein erster Test sucht nach "deepcat:Geschichte", außerdem nach den Wörtern "der" und "Physik". Denke das war nicht deine Absicht :-) Glaube wir hatten das oben schon mal: bei Kategorien mit Leerzeichen müssen Unterstriche benutzt werden, wie in deinem Test Nr. 2. Oder mit Anführungszeichen: deepcat:"Geschichte der Physik". Ist wenn man mal drüber nachdenkt auch logisch: Die Suchwörter sind mit Leerzeichen getrennt. Ohne Anführungszeichen oder die Ersetzung durch Unterstriche kann das Gadget nicht wissen, wo der "deepcat"-Begriff aufhört und die restlichen Suchwörter beginnen. Ist bei anderen Keywords wie "incategory" oder "intitle" übrigens genauso. --Johannes Kroll (WMDE) (Diskussion) 20:27, 3. Jul. 2015 (CEST)

Aktueller Status

Wie siehts aktuell eigentlich mit dem Gadget aus? Ist es fertig, oder die Entwicklung noch im Gange bzw. pausiert? --MGChecker – (📞| 📝| Bewertung) 16:00, 14. Okt. 2015 (CEST)

Hi MGChecker. Ja, es ist fertig und wird demnächst kommuniziert. Leider hat sich die Kommunikation krankheitsbedingt verzögert. Viele Grüße, --Kasia Odrozek (WMDE) (Diskussion) 16:04, 26. Okt. 2015 (CET)

Globale Beobachtungsliste mit „crosswatch“: Einladung zum Testen

Hallo zusammen, Benutzer:sitic hat in den letzten Monaten an einem Tool gebaut, mit dem die Beobachtungslisten von allen Wikimedia-Projekten an einem zentralen Ort abgerufen werden können. Nun ist der erste Prototyp fertig und auf Tool Labs verfügbar. Als zusätzliche Funktionen werden unter anderem ungelesene Benachrichtigungen projektübergreifend angezeigt und es können unterschiedliche Filter angewandt werden. Interessierte sind herzlich eingeladen, das Tool zu testen und auf der Diskussionsseite der Projektdokumentation Feedback zu geben oder Fragen an sitic zu stellen (gerne auch auf Deutsch).

Die projekt- und sprachenübergreifende Beobachtungsliste ist ein Wunsch der umseitigen WP:Umfragen/Technische Wünsche/Top 20. Insbesondere auch an diejenigen, die dafür abgestimmt hatten, daher zusätzlich die Frage: Würde das Tool den Wunsch aus Eurer Sicht abdecken? @Michi, Pc3021, Firefly05, wdwd, Oursana, Entbert, Morten Haan, Daniel749, TZorn, PerfektesChaos, Hoff 1980, Reinhard Müller, Tobias, kmk, Man77, Patrick Stützel, Frank C. Müller, Patrick87 und alle weiteren Interessierten - Anmerkungen dazu gerne hier im Anschluss. Vielen Dank! Birgit Müller (WMDE) (Diskussion) 10:46, 14. Aug. 2015 (CEST)

Ich könnte damit leben ;) lg, … «« Man77 »» Ḏū hāḏā t-tawfīʿ 10:58, 14. Aug. 2015 (CEST)
Sieht auf Anhieb sehr gut aus. Ausführlicherer Tests folgen noch. <korinthenkackmodus>Über die Option Zeige Flaggen anstelle des Names der Sprache werden sich unter Garantie unsere Österreicher, Schweizer, Belgier, Dänen usw. sehr freuen. Nicht. </korinthenkackmodus>
Deshalb ist die Flaggenoption auch so gut versteckt ein SmileysymbolVorlage:Smiley/Wartung/;) . Mir ist natürlich klar, dass Länder-Flaggen keine Sprachen symbolisieren, inzwischen könnte die Option eigentlich auch wieder raus, da jedes wiki eine zufällige Farbe erhält. Grüße sitic (Diskussion) 19:59, 14. Aug. 2015 (CEST)
Erstmal vielen Dank für die Umsetzung dieses Wunsches! Ich würde mir wünschen, dass das Frontend etwas weniger Javascript-lastig wäre. rekonq 0.9.1 mit Webkit beißt sich schon am Login die Zähne aus, und bei abgeschaltetem JavaScript sehe ich gar nichts mehr. --Reinhard Müller (Diskussion) 11:46, 14. Aug. 2015 (CEST)
Ja, das ganze besteht zu sehr vielen Teilen aus Javascript, woran manche Browser (leider auch Internet Explorer) zu knabbern haben. Der Grund dafür ist, dass ich mit crosswatch gerne etwas experimentieren möchte wie eine Beobachtungsliste aussehen und funktionieren könnte. Dazu benutze ich einige moderne Technologien, mit denen manche Browser weniger gut klarkommen. Ich lege an crosswatch nicht die gleichen Browser-Support Ansprüche, die z.B. MediaWiki hat, da es ein optionales Tool ist und damit vieles deutlich einfacher ist. Ich hoffe, dass irgendwann MediaWiki auch nativ eine globale Beo hat, und dann crosswatch immer noch eine Nutzen für manche hat. Liebe Grüße sitic (Diskussion) 19:59, 14. Aug. 2015 (CEST)
Sieht gut aus, was ich persönlich aber etwas unpraktisch finde, ist, dass es keine Gliederung nach Tagen mit einer Angabe der Uhrzeit gibt (wie auf der aktuellen Beo), sondern nur eine Angabe wieviele Stunden oder Tage die Änderung her ist. Ebenfalls störend finde ich dass zu sichtende Änderungen ausgeklappt sind (was man aber offenbar ausschalten kann) und dass das Ganze sehr Javascriptlastig ist. Ein großer Vorteil ist auf jeden Fall, dass man sich die Diff-Ansicht schon in der Beo anschauen kann. Viele Grüße Patrick Stützel (Diskussion) 12:01, 14. Aug. 2015 (CEST)
Mir gefällt es auch, absolute statt relativen Zeitangaben habe ich mir bereits auf Phabricator gewünscht. --MGChecker – (📞| 📝| Bewertung) 13:02, 14. Aug. 2015 (CEST)
Über die relative Zeitangabe haben sich schon mehrere beschwert, ich habe dafür auch den Task phab:T104608 angelegt. Der Grund für die relative Zeitangabe ist, das diese viel einfacher umzusetzten ist als die absolute Angabe. Ich setzte mich nochmal dran, dass Problem neben Zeitzone und Datumsformat richtig zu raten sind auch interne Probleme mit den Zwischenüberschriften für die Tageswechsel. Liebe Grüße sitic (Diskussion) 19:59, 14. Aug. 2015 (CEST)
Vielen Dank, auch dafür, dass Ihr mich benachrichtigt habt; von mir aus hätte ich das nicht gefunden! Ich find's gut, dass Ihr sowas bastelt. Den Einstieg mit dem OAUTH finde ich etwas verwirrend. Und da ich meine Cookies standardmäßig ausgeschaltet habe, funktioniert's natürlich zuerst mal nicht, und keiner sagt einem, dass das mit den Cookies zu tun hat. Da ich das aber schon kenne, bin ich schließlich mal wieder selbst drauf gekommen.
Die Liste selbst funktioniert anscheinend ganz gut. Auch ich würde absolute Zeitangaben absolut bevorzugen! Mir persönlich ist die Oberfläche noch zu bunt! Neben der Überschrift "Beobachtungliste" gibt es ein Lupensymbol: Wenn man es anklickt, weiß man nicht so recht, was passiert. Auch das standardmäßige Aufgeklapptsein der zu sichtenden Änderungen sollte man zumindest wegkonfigurieren können. Der Platz für die Filter und die Einstellungen ist für den Dauereinsaatz zu prominent, aufklappbare Überschriften würden hier auch reichen. Normalerweise will ich die Liste sehen und nicht die selten benötigten Einstellungen!
gruß, fcm. --Frank C. Müller (Diskussion) 17:36, 14. Aug. 2015 (CEST)
  • Für die Cookies habe ich mal den Task phab:T109108 angelegt, damit er eine Warnung anzeigt.
  • Das Lupensymbol sollte den Tooltip "Beobachtungsliste durchsuchen" anzeigen, wenn man die Mauszeiger drüberhält. Ich bin noch am überlegen, wie man die Suchfunktion besser lösen kann. Mit den Farben muss ich auch noch etwas rumprobieren, was passt.
  • Das Ausklappen von ungesichteten Änderungen kann man in den Einstellungen (über den etwas unscheinbare Knopf neben "Filter") abschalten.
  • Die Option die Filter/Einstellungen einklappen zu können hab ich in Planung, siehe dazu den Task phab:T107736
Vielen Dank an alle, für das Testen und die vielen Rückmeldungen. Vielen herzlichen Dank an dieser Stelle auch an Brigit und Kasia vom WMDE für die Unterstützung. --sitic (Diskussion) 19:59, 14. Aug. 2015 (CEST)
Ich hab das Tool mal auf meinem iPod getestet und muss sagen, dass es dort bedingt durch die Größe des Displays und das viele Javascript ein paar Probleme gibt.
  • Die Einstellungen sehen etwas merkwürdig aus, da im Bereich Filter die Haken zum Teil auf dem Text liegen.
  • Lange Seitentitel werden am Rand angeschnitten.
  • Das Scrollen gestaltet sich zum Teil schwierig, da hier sehr vieles anklickbar ist.
  • Durch die vielen Javascript Elemente ist die Seite sehr Ressourcen-Fressend und sorgt gelegentlich auch mal für Browser-Abstürze, wenn man etwas zu hektisch ist.
Viele Grüße Patrick Stützel (Diskussion) 17:39, 19. Aug. 2015 (CEST)
Hallo, danke für die Benachrichtigung. Ich kann sagen, dass dieses praktische Tool meine Wünsche abdeckt und bspw. durch die Anzeige der Benachrichtigungen übertrifft. Insbesondere vielen Dank an sitic für die Entwicklung – super! Viele Grüße --Pc3021 (Diskussion) 20:49, 19. Aug. 2015 (CEST)
@Sitic: Vielen Dank für die tolle Arbeit! Das kommt meiner Wunschvorstellung schon sehr nahe! Featurerequests gibt es natürlich immer ;) die mir am wichtigsten wäre:
  • Die Filter/Einstellungen-box einklappbar machen
  • Bedankenfunktion einbauen
  • Ein "Alle Seiten als besucht markieren"-Button
  • Animationen abschaltbar machen
Was ich noch nicht verstanden habe ist, was ist das Kriterium, ob Wikis damit beobachtet werden können oder nicht? -- Michi 22:22, 19. Aug. 2015 (CEST)
Hallo Michi, sobald man in einem Wiki eine Seite beobachtet, wird das jeweilige Wiki zu der Liste der beobachteten Wikis hinzugefügt. Ich hatte es ausprobiert und die Aktualisierung war ziemlich schnell. Oder meintest Du etwas anderes? Viele Grüße, Birgit Müller (WMDE) (Diskussion) 14:52, 14. Sep. 2015 (CEST)
Hi, ich hatte auf enWiki schon seit langem einige Seiten auf beobachten, ebenso auf deWikibooks. Trotzdem tauchten diese bei mir nicht auf als ich crosswatch das erste mal nutzte. Daher dachte ich vielleicht gibt es eine Schwelle wie x Bearbeitungen in den letzten x Monaten. Nach ein paar Wochen tauchten sie jedoch auf. Vielleicht war's ja nur ein Bug. -- Michi 23:35, 14. Sep. 2015 (CEST)

Ich finde das Tool auch sehr gelungen, danke dafür, sitic! Was ich mir noch wünschen würde: Dass man den oberen Teil (Filter / Einstellungen) einklappen kann und das standardmäßig auch so bleibt. Der Teil nimmt doch ziemlich viel Platz an prominenter Stelle weg und die Filter und Einstellungen ändert man nach erster Konfiguration doch sicherlich eher selten. Ansonsten: Tip top! :) Yellowcard (D.) 15:12, 14. Sep. 2015 (CEST)

Kategorien in der Beobachtungsliste – Link „Versionsgeschichte“

Hallo Birgit, Kai et al., erstmal auch von mir vielen Dank für die Implementierung dieser Funktion. :) Ich habe sie heute auf Commons entdeckt, und dabei ist mir Folgendes aufgefallen: Ich habe in den Einstellungen die Option „In der Beobachtungsliste alle und nicht nur die aktuellsten Änderungen anzeigen“ aktiviert. Dadurch werden bspw. alle 12 Neuuploads in die Kategorie Category:Uploaded with LrMediaWiki‎‎ unter einen ausklappbaren Punkt zusammengefasst. Neben diesem Punkt gibt es die Links „12 Änderungen“ und „Versionsgeschichte“. Normalerweise zeigen führen diese zu einem Diff über alle Änderungen sowie zur Versionsgeschichte der beobachteten Seite. Nun führen diese aber auf die zuletzt in die Kategorie eingefügte Seite. Das finde ich wenig intuitiv. Meiner Meinung nach sollten die Links entweder auf die beobachtete Kategorie zeigen, oder ganz entfernt werden, wenn es sich nur um Kategorieänderungen handelt. Grüße, ireas (Diskussion) 14:42, 20. Aug. 2015 (CEST)

Hi Ireas, danke! Dafür wurde bereits ein Ticket eröffnet: T109688, das deckt dein Kommentar mit ab, oder? Wir sammeln erstmal alles ein, um einen Überblick zu bekommen, und schauen dann, was und wieviel Feinarbeit noch gemacht werden kann/muss (bzw. fragen auch nochmal nach). Viele Grüße! Birgit Müller (WMDE) (Diskussion) 15:25, 20. Aug. 2015 (CEST)
@Birgit Müller (WMDE): Ja, danke! :-) – Aber warum wurde denn jetzt revertiert? Grüße, ireas (Diskussion) 23:08, 20. Aug. 2015 (CEST)
@Ireas: - siehe Update zum Wunsch auf der Vorderseite. Wir sind froh, dass das so schnell sichtbar geworden ist, jetzt kann man anfangen, herauszufinden, wo das Problem genau liegt. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 11:44, 21. Aug. 2015 (CEST)
Warum muss der Task denn eigentlich versteckt werden, wenn die Lücke eh nicht genutzt werden kann, da die neue Funktion ja nicht mehr live ist? --MGChecker – (📞| 📝| Bewertung) 12:00, 21. Aug. 2015 (CEST)
Es könnte sein, das dort Screenshots mit den entsprechenden IPs angehängt sind. Das Angriffsmuster kann vielleicht noch wo anders genutzt werden und muss dort noch gepatched werden. Oder es wurde noch nicht daran gedacht, das wieder sichtbar zu machen, keine Zeit gefunden. Interessieren würde es mich auch, Neugierig ist man da schon, vorallem weil man so einen Fehler nicht selber programmieren möchte. Der Umherirrende 22:27, 21. Aug. 2015 (CEST)
Da kann ich dir recht geben. (Wenn ich sowas programmieren könnte…) Aber da könnte man sicher eine Lösung finden, schließlich wissen wir inzwischen eh schon fast alles über den Bug, und vor allem der Fortschritt wäre interessant. Und neugierig bin ich sowieso jederzeit… Soweit ich weß, könnte man aber wenn Bilder angehängt sind, explizit diese verstecken und den Task offen lassen. --MGChecker – (📞| 📝| Bewertung) 00:15, 22. Aug. 2015 (CEST)
Dank Krinkles Kommentar zu PS20 ist das doch defakto öffentlich. --Schnark 09:15, 22. Aug. 2015 (CEST)

phab:T109951 – mal sehn. VG --PerfektesChaos 21:55, 22. Aug. 2015 (CEST)

Wie ist denn hier der weitere Plan – ist schon absehbar, wann das Feature wieder live geht? Yellowcard (D.) 20:02, 2. Sep. 2015 (CEST)

Die offenen Punkte und Erkenntnisse aus dem ersten Live-schalten werden in gerrit:233441 gesammelt bearbeitet, um am Ende die Funktion weiterhin zu ermöglichen. Anders gesagt: Es ist (weiterhin) in Arbeit. Der Umherirrende 20:19, 2. Sep. 2015 (CEST)
Ah, alles klar, danke! Yellowcard (D.) 20:21, 2. Sep. 2015 (CEST)

Commons - HotCat

Ist wahrscheinlich die falsche Stelle. Wollte mal schnell loswerden, das es super ist, wenn Kategorie und Sortkey Ä in der Zusammenfassungszeile automatisch erscheinen.--Oursana (Diskussion) 23:21, 22. Okt. 2015 (CEST)

“Deepcat” abgeschlossen: Tief- und Schnittmengensuche auf Wikipedia und Commons ab sofort möglich

Während neue Wünsche für 2016 im Rahmen einer Umfrage gesammelt wurden, ist ein Wunsch aus dieser “alten” Top20 - “CatScan-Funktionalität“ in die Software integrieren - umgesetzt und abgeschlossen worden. Entwickelt wurde das Deepcat - Gadget, dessen Prototyp bereits Ende Mai hier zum Testen zur Verfügung gestellt wurde. Vielen Dank nochmal an der Stelle für alle Fragen und Anregungen, die dabei geholfen haben, das Gadget zu verbessern. Deepcat funktioniert mittlerweile auch auf Wikimedia Commons und in anderen Wikis. Hier geht es zum entsprechenden Kurierartikel, hier geht es zur Infoseite: Hilfe:Suche/Deepcat und hier können Fehler gemeldet werden. Viel Spaß mit Deepcat! --Kasia Odrozek (WMDE) (Diskussion) 15:22, 3. Nov. 2015 (CET)

Crosswatch als globale Beobachtungsliste

Ich halte es für ein Unding, ein Workaround, das eine Übergangslösung für die fehlende globale Watchlist darstellen sollte und dessen duerhafte Maintenance nicht sichergestellt ist, als dauerhaften Ersatz für die fehlende Watchlist zu verkaufen und damit die Aufgabe für erledigt zu erklären. --MGChecker – (📞| 📝| Bewertung) 19:49, 23. Nov. 2015 (CET)

Hey MGChecker, ich hab mal ne Klammer um das "Erledigt" gesetzt - was erledigt ist, ist, dass es die Möglichkeit gibt, sich eine projektübergreifende Beobachtungsliste anzeigen zu lassen. Es ist ein cooles Tool & jemand hat da viel Zeit & Mühe reingesteckt. Die Art der Umsetzung ist nochmal ne andere Frage - deswegen auch der Zusatz zum Erledigt-Kommentar umseitig, was so ein bisschen die Quintessenz ist aus der Feedbackrunde hier auf der Seite vor einiger Zeit - eine überwiegend gute Lösung fürs Erste. Viele Grüße, Birgit Müller (WMDE) (Diskussion) 22:18, 23. Nov. 2015 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup_Diskussion:Umfragen/Technische_Wünsche/Top_20&oldid=178324007“