Wikipedia:Umfragen/Technische Wünsche 2017/Wartung

Umfrage Technische Wünsche 2017

Rubrik „Wartung“

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

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

Geschlechterspezifische Anzeige der Kategorien im Artikel

Was ist das Problem?

Personenkategorien sammeln Artikel zu Personen (von ein paar offensichtlichen Ausnahmen abgesehen) unabhängig von ihrem Geschlecht (das ist kein Problem, sondern das erwünschte Verhalten). Bei der Benennung wurde das generische Maskulinum gewählt (das kann als Problem angesehen werden, aber darum soll es hier nicht gehen. Irgendeinen Namen muss die Kategorie ja haben.) Um im folgenden ein konkretes Beispiel zu haben: Kategorie:Koch führt alle Köche auf, egal ob Mann oder Frau, eine separate Kategorie:Köchin ist nicht erwünscht.

Das Problem, das in diesem Zusammenhang besteht, sind Artikel über Köchinnen, etwa Julie Goodwin. Weil die Kategorie so heißt wie sie eben heißt, steht in der Zeile mit den Kategorien auch hier das männliche „Koch“, während es in diesen Fällen schöner wäre, wenn dort „Köchin“ stünde, aber weiterhin auf die Kategorie:Koch verlinken würde und den Artikel auch dorthin einsortieren würde.

Es wäre daher schön, wenn die im Artikel angezeigte Kategoriebezeichnung sich dem Geschlecht anpassen würde, aber weiterhin alle Personen unabhängig vom Geschlecht in den gleichen Kategorien aufgeführt werden.

Wen betrifft das Problem besonders?

• Alle Artikel über Frauen bzw. alle Leser, besonders die Frauen, die vom rein maskulinen Sprachgebrauch abgeschreckt werden.

Lösungsvorschlag

In vergangen Diskussionen wurde immer wieder vorgeschlagen, Kategorieweiterleitungen dafür zu verwenden:

• Wikipedia:Fragen zur Wikipedia/Archiv/2015/Woche 33#Weibliche Berufsform als Kategorieanzeige
• Wikipedia Diskussion:Kurier/Archiv/2017/03#Hochschullehrer, Deutscher, Frau

Im obigen Beispiel würde das bedeuten, dass wir Kategorie:Köchin als Weiterleitung auf Kategorie:Koch anlegen und die Software so angepasst wird, dass eine Verwendung von [[Kategorie:Köchin]] im Artikel fast die gleiche Auswirkung hat wie [[Kategorie:Koch]], mit dem Unterschied, dass im Artikel selbst die Kategorie auch tatsächlich als „Köchin“ bezeichnet wird.

Neben der reinen Kategorien-Weiterleitung wäre der anspruchsvollere Teil der technischen Lösung die geschlechtsmäßig korrekte Anzeige der Artikel, die in der Ursprungskategorie stehen, aber das jeweils andere Geschlecht anzeigen sollten (das sind derzeit rund 100.000 Artikel zu Frauen, die möglichst nicht alle geändert werden müssen). Also sollte in einem Artikel (zu einer Frau, erkennbar daran, dass der Artikel in der Kategorie:Frau steht), in dessen Quelltext die Kategorie:Koch steht, Kategorie:Köchin angezeigt werden; in einem Artikel (zu einem Mann, erkennbar daran, dass der Artikel in der Kategorie:Mann steht), in dessen Quelltext aber (warum auch immer) Kategorie:Köchin steht, sollte trotzdem Kategorie:Koch angezeigt werden. Das Beispiel Koch/Köchin illustriert auch gut, dass es auch nicht alleine mit dem Anhängen von "-in" getan ist: eine Hochschullehrerin gibt es, nicht aber eine Kochin. Es müsst also an geeigneter Stelle (wahrscheinlich in der jeweiligen Kategorie) hinterlegt werden, welches Geschlecht der Name der Katgeorie impliziert (welches andere Geschlecht also ein Alias haben müsste) und wie der Alias zu lauten hat. In einer Kategorie:Koch müsste also in geeigneter Form (zum Beispiel einer Vorlage) stehen, dass die andere Form weiblich ist und „Köchin“ lautet. In einer Kategorie:Papst sollte hinterlegt werden können, dass die Form männlich ist und dass es keine weibliche Form gibt. In der Kategorie:Äbtissin, dass die Form weiblich ist und dass es keine männliche Form gibt. In der Kategorie:Frauenrechtlerin, dass die andere Form männlich ist und „Frauenrechtler“ lautet. In einer Kategorie:Person (Bielefeld) müsste kein Alias hinterlegt werden. Am Ende sind also alle Artikel „sicher“ was die Verwendung geschlechtsanzeigender Kategoriennamen betrifft – unabhängig vom Quelltext. Es müssten aber nach und nach durch die Community Zehntausende Kategorien mit Alias versehen werden – in aller Regel aber nur einmal. Bonuswunsch: Eine Kategorie, die einen Alias hat, zeigt in der Kategorie – nicht in den zugeordnten Artikeln – beide Namen an: Kategorie:Koch/Köchin (oder unterinander Kategorie:Koch und Kategorie:Köchin)

Anmerkungen

Die Alternative wäre eine Aufspaltung zahlreicher Personen-Kategorien in männliche und weibliche Formen, was zu einer größeren Unübersichtlichkeit und geringeren Durchsuchbarkeit führen würde. Außerdem müssten hunderttausend Artikel angepasst werden. Eine Trennung zum Beispiel nach „Hochschullehrerin (Harvard University)“ und „Hochschullehrer (Harvard University)“ ist auch aus enzyklopädischer Sicht nicht sinnvoll.

Vorschlagende Person

Schnark 11:00, 29. Mai 2017 (CEST) und Thomas Wozniak (HSP) (Diskussion) 17:47, 30. Mai 2017 (CEST) und Drahreg01 13:59, 11. Jun. 2017 (CEST)

Diskussion

Nicht nur ich befürworte diesen Wunsch seit vielen Jahren. --Anima (Diskussion) 19:01, 29. Mai 2017 (CEST)

Andererseits könnte man auf den ersten Blick vermuten, es würde sich hierbei um die „Kategorie:Köchin“ handeln. Welche Kategorie sich tatsächlich hinter dem Namen verbirgt, erfährt man erst, wenn man draufklickt. Möglicherweise sorgt das sogar dafür, dass ein Leser nicht auf „Kategorie:Köchin“ draufklickt, weil er „Kategorie:Koch“ sucht und sich sicher ist, das Gesuchte nicht mit einem Klick auf „Kategorie:Köchin“ finden zu können. Darum fände ich es besser, wenn Kategorien bei ihrem Namen genannt werden. Allerdings kann man für die Benutzer, die es brauchen vielleicht ein Helferlein entwickeln. ーTesser4D 【Diskussion】 11:37, 30. Mai 2017 (CEST)

Darüber wurde unter Wikipedia:Meinungsbilder/Generisches Maskulinum und Gendering in der WP lange diskutiert. Die Konklusion: das generische Maskulinum, was übrigens Standarddeutsch ist, wurde damit als das gängige Modell angenommen. Und es gibt auch keinen Grund jetzt zwei Kategorien (Köchin und Koch) für den gleichen Beruf aufzuführen. Das generische Maskulinum ist nun Mal so wie die Leute heute sprechen.--Rævhuld (Diskussion) 16:37, 30. Mai 2017 (CEST)

Danke Schnark für diesen Vorschlag. Ich finde den Vorschlag gut und wollte ihn nach dem o. g. Kurierbeitrag und den in der Diskussion formulierten Ideen von Drahreg01 auch einbringen. Mir schwebt folgende technische Umsetzung vor ohne Anlegen von Weiterleitungskats.

Jede Kategorie ändert von sich aus in der ANZEIGE die Geschlechtsangabe. Grundsätzlich wird immer ein "in" in der Anzeige angehängt, dies funktioniert bei den Standardfällen wie "Pianist" zu "Pianistin", "Klempner" zu "Klempnerin" super. In Spezialfällen (von denen es einige gibt) muss der Kategorie "gesagt" werden, wie dieser lautet "Koch" zu "Köchin", "Alleinerziehender" zu "Alleinerziehende". Woher weiß die Kategorie, wie sie sich verhalten soll? Die Steuerungswerte sind die bestehenden Kategorien "Mann" und "Frau". Jeder Personenartikel ist (bzw. sollte) in einer dieser beiden Kategorien sein. je nachdem in welcher dieser beiden Kategorien der Artikel eingeordnet ist, "weiß" die Spezialkategorie, wie sie sich verhalten soll. Ggf. kann man zukünftig dieses Modell auch für Transgender erweitern.

Sonderfälle können für eine Migration auf eine Unterseite vorbereitet werden.

der Vorteil dieser Variante ist, dass keine Weiterleitungen angelegt werden müssen. Gruß -- ^Thomas 08:20, 31. Mai 2017 (CEST)

nachtrag: Wikipedia:Umfragen/Technische_Wünsche_2017/Lesen#Geschlechterspezifische_Anzeige_der_Kategorien -- ^Thomas 08:26, 31. Mai 2017 (CEST)

Die Formulierung der Überschrift gefällt mir besser, ich habe sie daher entsprechend angepasst. –Schnark 09:14, 31. Mai 2017 (CEST)

Mir sind folgende Gesichtspunkte wichtig:

• Es sollen keine Verdoppelungen von Kategorien angelegt werden. Eine Kategorie:Koch und eine Kategorie:Köchin sollen nicht parallel existieren. So eine Trennung nach Geschlecht wäre auch aus enzyklopädischer Sicht in der weit, weit überwiegenden Mehrzahl der Fälle unsinnig. Weibliche und männliche Personen, die das Merkmal X tragen, sollen gemeinsam in der X-Kategorie stehen.
• Änderungen unserer Konventionen zum generischen Maskulinum sind nicht Gegenstand dieses Wunsches.
• Es geht darum, Inkonsistenzen in der enzyklopädischen Darstellung von Inhalten zu beseitigen. Wenn oben im Artikel steht, eine Person sei beispielsweise eine deutsche Köchin, ist es verwirrend (bis gegebenenfalls verärgernd) wenn am Fuße derselben Seite „Kategorie:Koch Kategorie:Deutscher Kategorie:Frau“ steht.
• Damit nicht alle knapp 100.000 Artikel aus der Kategorie:Frau bezüglich der Kategorien bearbeitet werden müssen und die Gewohnheitstiere unter den Wikipedia-Autoren auch bei Frauen als Artikelgegenstand weiter die männlichen Kategoriennamen verwenden können, sollte die zu entwickelnde technische Lösung den alternativen (meist: weiblichen) Kategoriennamen anzeigen, wenn der Artikel in der Kategorie:Frau steht, und den Standard- (meist: männlichen) Kategoriennamen in allen anderen Fällen.

Es wäre toll, wenn durch die technische Lösung folgende Bedingungen erfüllt würden:

• Die Kategorienseite enthält als angezeigten Seitentitel beide Schreibweisen (z. B. Kategorie:Koch und Kategorie:Köchin, besser untereinander als nebeneinander).
• Die Verwendung des alternativen Kategoriennamens im Artikelquelltext (z. B. per Copy und Paste) funktioniert.

Insofern wäre mein Lösungsvorschlag für das angesprochene Problem statt einer Kategorien-Weiterleitung eher ein an geeigneter Stelle zu hinterlegender Kategorien-Alias. Meine Phantasie geht dahin, in der jeweiligen Kategorie z. B. in Form einer Vorlage zu hinterlegen, wie der Alias dieser Kategorie lautet. In der Kategorie:Koch würde hinterlegt, dass der (weibliche) Alias "Köchin" heißt. Die Kategorie:Frauenrechtler sollte (als eine der wenigen Ausnahmen) in Kategorie:Frauenrechtlerin umbenannt werden; in der Kategorie würde hinterlegt, dass der (männliche) Alias "Frauenrechtler" heißt.

Viele Grüße und vielen Dank für eine etwaige Umsetzung dieses Vorschlags, --Drahreg01 (Diskussion) 23:51, 1. Jun. 2017 (CEST)

Wenn man die angelegenheit geschlechterspezifisch anschauen müßte, würde das darauf hinauslaufen, daß man jeweils mehrere Kategorien mit Unterkategorien einführen müßte. Das liefe in eine (wohl unerwünschte) Verzettelung hinaus: in der Kategorie "Koch" dürften nur männliche, in der Kategorie "Köchin" nur weibliche Personen drin sein; die gemeinsame (Über)Kategorie müßte dann sowas wie "Köchinnen und Köche" lauten, damit "Koch" (nur mask.) und "Koch" (generisch nicht geschlechtsspezifisch) nicht vermischt würden; sonst wären in "Koch" mask. & fem., in "Köchin" aber nur fem. (und die mask. nicht auch separat); und das kann es nicht sein. Sofern sich bei Personen die Meta-Information des Geschlechts einbauen ließe und aufgrund dessen dann eine daran angepaßte Kategoriebezeichnung möglich wäre (i.S.v. "Kategorie-Alias"), wäre das zwar wünschenswert; es würde aber dennoch irgendwie befremden, wenn dann bei einer Köchin in der zugehörigen "Kategorie Köchin" dann auch Köche (mask.) auftauchen würden, wenn man der Kategorie folgt. Deutsch ist nicht symmetrisch, was die Geschlechterbezeichnungen anbelangt; und dies ist ein Beispiel, bei dem das etwas doof ist. Ich sehe keine andere Lösung, als "(geschlechtsneutrale) Oberkategorie" (also: "Köchinnen und Köche") mit beiden geschlechtsspezifischen Unterkategorien ("Koch", "Köchin"), bei denen dann die Personen jeweils sowohl in die Oberkategorie, als auch in eine der Unterkategorien gehören (und somit jeweils in zwei Kategorien wären, so nicht Elemente der Unterkategorie automatisch auch Elemente der Oberkategorie). Und das bläht die Sache ziemlich auf ... --ProloSozz (Diskussion) 10:16, 6. Jun. 2017 (CEST)

Hallo Drahreg01, ich denke bei diesem Wunsch spielt explizit der Lösungsvorschlag eine große Rolle und abhängig davon werden dann auch die Stimmen vergeben. Am besten wäre es, wenn du deinen Lösungsvorschlag nochmal in einen extra Wunsch verpackst, damit genau dafür abgestimmt werden kann und er nicht verloren geht. Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird (und damit wären dann deine Ergänzungen unsichtbar und es würde nur für den anderen Lösungsvorschlag abgestimmt werden). -- Viele Grüße, Charlie Kritschmar (WMDE) (Diskussion) 18:06, 8. Jun. 2017 (CEST)

@Schnark: Am 19. Juni werden die Diskussionen zu den Wünschen ausgeblendet, damit klar ist, wofür man bei der Abstimmung seine Stimme abgibt. Wenn in den Diskussionen also Ergänzungen, Ideen, Einwände, ... gemacht werden, kann es sinnvoll sein, sie bei „Was ist das Problem?“, „Lösungsvorschlag“ etc. zu ergänzen. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:17, 8. Jun. 2017 (CEST)

@Johanna Strodt (WMDE), Charlie Kritschmar (WMDE): Ihr müsstet euch so ein bisschen einig werden, was ihr wollt. Unter Wikipedia:Umfragen/Technische Wünsche 2017/Lesen#Geschlechterspezifische Anzeige der Kategorien wird vorgeschlagen, Wünsche zusammenzulegen; hier heißt es erst, ein (minimal anderer) Lösungsvorschlag solle in einen neuen technischen Wunsch gepackt werden; dann aber, andere Ideen sollten doch in diesen eingearbeitet werden. Wat denn nu? --Drahreg01 (Diskussion) 18:53, 8. Jun. 2017 (CEST)

@Charlie Kritschmar (WMDE): --Drahreg01 (Diskussion) 18:55, 8. Jun. 2017 (CEST)

@Drahreg01:Das ist eigentlich auch so. Wünsche eher zusammenlegen. in diesem Fall ist das jedoch etwas anders weil die Abstimmung stark vom Lösungsvorschlag abhängig ist, denn der könnte eine grundlegende Veränderung für die Kategorien bedeuten, d.h. einige würden evtl. nicht für den Wunsch abstimmen weil sie mit dem Lösungsvorschlag unzufrieden sind. Hier geht es also nicht nur einfach um technische Umsetzungsmöglichkeiten sondern viel mehr um grundlegende Veränderungen über die die Community abstimmen können sollte. Ich hoffe das macht Sinn :) Beste Grüße --Charlie Kritschmar (WMDE) (Diskussion) 19:12, 8. Jun. 2017 (CEST)

Wenn man den Vorschlag größer aufzieht und dabei endlich "Category intersection" bekommt, wäre es eine feine Sache.--Avron (Diskussion) 17:15, 21. Jun. 2017 (CEST)

@Rævhuld:„Das generische Maskulinum ist nun Mal so wie die Leute heute sprechen.“ Aufgrund einer Verordnung bin ich (in Wort und Schrift) als Universitätsassistent zu einer genderneutralen Sprache verpflichtet. Ich bin der Ansicht das es eine Frage der Umgebung ist, ob das generische Maskulinum üblich ist oder nicht, in der Pateizentrale der Grünen sicher nicht und an der Universität ist es schon sehr ausgestorben, dass es sich (noch) immer in der Wikipedia durchsetzt, sehe ich als eine Frage der Altersklasse die hier editiert.

@Drahreg01: Ich bin dafür das es z.B. Kategorie:Koch und Kategorie:Köchin sollen parallel existieren, aber auf die wikt:selbe Datei zurückgreifen also Zwei URLs die auf das selbe zugreifen (ohne sie spiegeln zu müssen). Somit definiert muss man nicht definieren ob es unter dem generischen Maskulin oder unter dem generische Feminin gespeichert ist, bzw für 0815-Wikipedianer ist es zumindest nicht ersichtlich unter was es gespeichert ist und was nur der Alias-Name ist.  — Johannes Kalliauer - Diskussion | Beiträge 19:28, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Schnark (Einreichende Person)
2.  Pro Thomas Wozniak (HSP) (Einreichende Person)
3.  Pro Drahreg01 (Einreichende Person)
4.  Pro -- Marcus Cyron Reden 10:24, 19. Jun. 2017 (CEST)
5.  Pro DestinyFound (Diskussion) 10:49, 19. Jun. 2017 (CEST)
6.  Pro 22:40, 19. Jun. 2017 (CEST)@KPFC:(unvollständig signierter Beitrag von KPFC (Diskussion | Beiträge) 22:40, 19. Jun. 2017 (CEST))
7.  Pro --Andrea014 (Diskussion) 06:15, 20. Jun. 2017 (CEST) Mit herzlichem Dank an alle, die nicht müde wurden, an einer Umsetzung zu arbeiten!
8.  Pro --Itti 07:08, 20. Jun. 2017 (CEST)
9.  Pro --Momel ♫♫♪ 07:29, 20. Jun. 2017 (CEST)
10.  Pro -- Barnos (Post) 07:53, 20. Jun. 2017 (CEST)
11.  Pro --Innobello (Diskussion) 08:09, 20. Jun. 2017 (CEST)
12.  Pro Iva 08:15, 20. Jun. 2017 (CEST) Wurde eigentlich irgendwann mal darüber nachgedacht, die Kategorie des Geschlechts nicht als letzte Kategorie zu nennen, wenn es sie gibt?(hätte das in den Abschnitt Diskussion gehört?)
13.  Pro --Kritzolina (Diskussion) 08:56, 20. Jun. 2017 (CEST)
14.  Pro -- LG -- Benutzerin:Reisen8 • Benutzerin Diskussion:Reisen8 • Wikiliebe?! 09:00, 20. Jun. 2017 (CEST)
15.  Pro --MatthiasGutfeldt (Diskussion) 09:59, 20. Jun. 2017 (CEST)
16.  Pro Arieswings (Diskussion) 10:03, 20. Jun. 2017 (CEST)
17.  Pro --emha ^d℩^b 10:11, 20. Jun. 2017 (CEST)
18.  Pro -- ^Thomas 11:14, 20. Jun. 2017 (CEST)
19.  Pro --Laury (Diskussion) 13:01, 20. Jun. 2017 (CEST)
20.  Pro --Alraunenstern۞ 14:40, 20. Jun. 2017 (CEST)
21.  Pro --Eingangskontrolle (Diskussion) 15:35, 20. Jun. 2017 (CEST)
22.  Pro Zabia (Diskussion) 17:12, 20. Jun. 2017 (CEST)
23.  Pro --Andropov (Diskussion) 17:24, 20. Jun. 2017 (CEST)
24.  Pro --Gnom (Diskussion) 17:44, 20. Jun. 2017 (CEST)
25.  Pro --Aristeas (Diskussion) 17:46, 20. Jun. 2017 (CEST)
26.  Pro --Anima (Diskussion) 18:32, 20. Jun. 2017 (CEST)
27.  Pro −Sargoth 18:54, 20. Jun. 2017 (CEST)
28.  Pro --WvB 19:54, 20. Jun. 2017 (CEST)
29.  Pro --Leserättin (Diskussion) 20:46, 20. Jun. 2017 (CEST)
30.  Pro –Queryzo ?! 22:36, 20. Jun. 2017 (CEST)
31.  Pro --jcornelius  11:39, 21. Jun. 2017 (CEST) (JA! Bitte! Endlich!)
32.  Pro --Schelmentraum (Diskussion) 13:22, 21. Jun. 2017 (CEST)
33.  Pro -- Silke (Diskussion) 15:26, 21. Jun. 2017 (CEST)
34.  Pro --Carolus requiescat (Diskussion) 17:20, 21. Jun. 2017 (CEST)
35.  Pro  — Johannes Kalliauer - Diskussion | Beiträge 19:28, 21. Jun. 2017 (CEST) Bin dienstlich (Universitätsassistent) zur geschlechterneutralen Sprache (per Verordnung) verpflichtet.
36.  Pro --Furfur ^{⁂ Diskussion} 23:25, 21. Jun. 2017 (CEST) Sprachlich wäre es sicher schöner und inhaltlich angemessener. Ich bin aber absolut gegen eine Aufspaltung der Personenkategorien in männlich/weiblich. Es gibt ja zunehmend auch Personen, die sich weder als das eine noch das andere sehen mögen. Wo tun wir die dann hin?
37.  Pro --HHill (Diskussion) 13:10, 22. Jun. 2017 (CEST)
38.  Pro --DianeAnna (Diskussion) 23:25, 22. Jun. 2017 (CEST)
39.  Pro --ArthurMcGill (Diskussion) 09:19, 23. Jun. 2017 (CEST)
40.  Pro mauriceKA (Diskussion) 13:21, 23. Jun. 2017 (CEST)
41.  Pro --Daniel749 Disk. (ST–WPST) 22:22, 23. Jun. 2017 (CEST)
42.  Pro -- Nichtich (Diskussion) 23:03, 23. Jun. 2017 (CEST)
43.  Pro --Chiborg (Diskussion) 23:10, 23. Jun. 2017 (CEST)
44.  Pro --Querstrebe (Diskussion) 11:37, 24. Jun. 2017 (CEST)
45.  Pro -- Freddy2001 ^DISK 11:59, 24. Jun. 2017 (CEST)
46.  Pro --Skrippek (Diskussion) 16:34, 24. Jun. 2017 (CEST)
47.  Pro--BohunkaNika (Diskussion) 18:05, 24. Jun. 2017 (CEST)
48.  Pro --KEO144000 (Diskussion) 18:42, 24. Jun. 2017 (CEST)
    
    

Korrekte Größenangaben in Versionsgeschichten nach Import

Was ist das Problem?

Wird eine Seite importiert, dann kann es passieren, dass bei einzelnen Änderungen in der Versionsgeschichte als Größenänderung eine falsche Angabe (nämlich nicht die Differenz, sondern fälschlicherweise die absolute Größe) angegeben wird.

Ein Beispiel sind die von #aufschrei, das Problem tritt aber auch bei neuen Importen auf (getestet mit dem aktuell letztem Import).

Das Problem sollte endlich mal behoben werden und (falls nötig) alte Versionsgeschichten ebenfalls korrigiert werden.

Wen betrifft das Problem besonders?

• Jeder, der versucht den Angaben der Versionsgeschichte sinnvolle Informationen zu entnehmen

Lösungsvorschlag

Es gibt sicher schon einen Eintrag auf Phabricator, wer ihn suchen möchte und findet, darf ihn gerne hier eintragen.

Anmerkungen

Da die Importfunktion vor allem in der deutschsprachigen Wikipedia eingesetzt wird, und in anderen Sprachen dieser Fehler daher nicht so auffällig vorkommt, ist das eine Aufgabe, die ganz wunderbar für WMDE geeignet ist. Ansonsten ist die Chance, dass das endlich mal jemand behebt, eher gering.

Vorschlagende Person

Schnark 11:26, 29. Mai 2017 (CEST)

Diskussion

Ich hatte mal den Import dahin etwas verbessert (gerrit:244496; damals war das Problem, das die falsche Parent-ID gespeichert wurde und dadurch die Unterschiede falsch waren; eine Bereinigung hat nicht stattgefunden), daher sieht es bei dem neuen Import nicht mehr schlimm aus. In deinem als neuen Import verlinkten Artikel sehe ich nur das Problem bei dem Übergang der letzten Importieren und der ersten selbsterstellten Version. Der Import trägt in diesem Fall die Parent-ID nicht bei der ersten Version nach (Dies hat beispielsweise auch den Vorteil, dass diese Version bei "Nur Seitenerstellungen anzeigen" in Spezial:Beiträge auftaucht). "Schlimmer" sieht es aus, wenn der Import und die bestehenden Versionen sich zeitlich überlappen, dann erhalten die importieren Versionen eine Reihe von Parent-ID und die bestehenden Versionen haben eine andere Reihe. Technisch als Baum mit zwei Ästen auszudrücken. Kann über Spezial:MergeHistory ähnliche Szenarien geben, da die Parent-ID nicht mit verwaltet wird. Der Umherirrende 21:18, 29. Mai 2017 (CEST)

Sehe ich es richtig, dass es zwei verschiedene Probleme gibt:

• Früher wurde beim Import irgendein Unfug bei den Größenänderungen berechnet. Der Fehler ist inzwischen behoben, aber die alten Versionsgeschichten sind noch fehlerhaft. Man müsste sich überlegen, ob es sich lohnt ein Wartungsskript zu erstellen und laufenzulassen, um diese so anzupassen, wie sie aussehen würden, wenn der Import heute erfolgen würde.
• Bei einem Nachimport stimmt die Reihenfolge der IDs und der Zeitstempel nicht mehr überein (was nicht zu verhindern ist). Aber teilweise wird als Sortierung die ID, teilweise der Zeitstempel zu Grunde gelegt. Beides kann sinnvoll sein, aber dort, wo die beiden Verfahren aufeinander treffen, kommt es zu merkwürdigen Anzeigen. Man müsste sich überlegen, wo welche Sortierung am besten ist, um möglichst wenig Inkonsistenzen zu erzeugen.

–Schnark 09:23, 31. Mai 2017 (CEST)

Zu Punkt 1: Technisch gesehen wurde kein Unfug berechnet, da der Größenunterschied erst zur Laufzeit ermittelt wird, aber es wurde die falsche Vorgängerversion gespeichert, auf der der Größenunterschied basiert. Das Visuelle Ergebnis ist aber richtig beschrieben. Hier wäre ein Wartungsskript zur Korrektur zu erstellen. Ich bin mir aber nicht sicher, ob das Ergebnis bei Zeitlich überschneidenen Imports besser ist und die Situationen können nach der Korrektur immer wieder auftreten, sofern nicht auch für diese Situation der Import geändert wird.

Zu Punkt 2: Der Unterschied zwischen Timestamp und ID wurde mit T4930 erst gerade etwas verbessert. Auch im Bereich der API gab es Änderungen, mehr unter T163532.

Der Umherirrende 16:54, 31. Mai 2017 (CEST)

Also am besten abwarten und dann noch bestehende Probleme abseits dieser Wunschliste direkt in Phabricator klären. –Schnark 11:03, 2. Jun. 2017 (CEST)

Unterstützung

1. 
   
   

Aktive Sichter sollten gelöschte Versionen einsehen können und bei Wieder-/Neuanlegung würde gelöschte Versionsgeschichte automatisch wiederhergestellt (incl. ehem. Quelltext)

Was ist das Problem?

Nur Admins können gelöschte Versionen einsehen; das sollte auf aktive Sichter erweitert werden; und bei einer Wieder-/Neuanlegung sollte die bisherige Versionsgeschichte wieder erscheinen; direkt-Revertieren wäre aber nur auf eine Version nach Neuanlegung notwendig, einsehen der früheren Quelltexte gehört natürlich dazu.

Stößt man auf ein gelöschtes Lemma (meist aufgrund einer Löschdiskussion), läßt sich nur indirekt erschließen, was zuvor bestanden hatte. Bei einer allfälligen Neuanlegung ist es sinnvoll, nicht nur die bisherige History einsehen zu können (zum einen, um nicht dieselben Fehler zu machen; zum anderen, um allenfalls auch darauf aufzubauen), sondern dass gleich auch die früheren Versionen wiederhergestellt werden. In der Versionsgeschichte würde dann nicht bei null angefangen, sondern die alte wiederherstestellt.

Wen betrifft das Problem besonders?

Sämtliche Bearbeiter, die nicht selbst mind. Admin-Status haben (und Admin sind nur wenige).

Auf Artikelebene sind v.a. jene Artikel betroffen, die wegen mangelnder Substanz per LD gelöscht wurden, aber duchaus ausbaufähig gewesen wären.

Lösungsvorschlag

Nicht nur Rechte der aktiven Sichter zur Einsichtnahme gelöschter Versionen entsprechend erweitern (aktive Sichter = angemeldete Benutzer mit "erweiterten Editierrechten",also nicht Neuangemeldete etc.), sondern auch automatisieren, dass die alte Versionsgeschichte automatisch wiederhergestellt würde

Anmerkungen

"Gesetzliche" Löschungen (infolge Urheberrechtsverletzung, Persönlichkeitsverletzung etc.) müss(t)en gesondert behandeln werden resp. fallen nicht darunter und bleiben unsichtbar und nur für Admins einsehbar.

Es wäre zu diskutieren, was Nichtangemeldete sehen würden ("kein Artikel vorhanden", "gelöscht", etc.); Will ein nichtangemeldeter einen Artikel neu anlegen, wäre sein Text bis zu einer sichtung nur für sichter einsehbar (Unangemeldete würden "kein Artikel" sehen); mit der Sichtung würde dann automatisch die alte Versionsgeschichte wiederhergestellt (aber nicht schon bei Eingabe des ungesichteten neuen Texts).

Vorschlagende Person

ProloSozz (Diskussion) 14:06, 29. Mai 2017 (CEST)

Diskussion

Einschub: Bitte Änderungen beachten! Der Antrag von Rævhuld betrifft nur die Einsichtnahme in die gelöschten Versionen; hier geht es (zusätzlich) um die automatische Wiederherstellung der früheren Versionsgeschichte. NB: Die bisherige Diskussion war noch vor der Änderung erfolgt. --ProloSozz (Diskussion) 02:30, 10. Jun. 2017 (CEST)

Das ist nichts, was ein technische Team entwickeln kann, es ist einfach eine Konfigurationsänderung. Dafür braucht es aber mindestens ein MB, wenn nicht in diesem Fall sogar eine Zustimmung von WMF-Legal, da es z.B. auch gelöschte URVen gibt. Ebenso wären Versiosngelöschte Beleidigungen wieder sichtbar. Viele Grüße, Luke081515 17:16, 29. Mai 2017 (CEST)

Das wird es nicht geben, egal wie viel danach gefragt wird. Weder die Community noch Legal würden da zustimmen. --MGChecker – (📞| 📝| ) 23:15, 29. Mai 2017 (CEST)

Und wieso nicht? Bitte begründen, danke --ProloSozz (Diskussion) 12:25, 30. Mai 2017 (CEST)

Erbitte ebenfalls Begründung. Einfach so sagen "Da wird keiner zustimmen" ist zu wenig. --C₂₁H₂₂N₂O₂ (V • T • E) 13:35, 30. Mai 2017 (CEST)

Ggf. wäre da eben doch etwas technisches drin: nämlich eine Unterscheidungsmöglichkeit, ob das nun wegen "gesetzlicher Löschung" für aktive sichter nicht sichtbar wird, oder ob das infolge "regulärer Löschdiskussion" sichtbar bleiben kann. Diese Unterscheidungsmöglichkeit müsste beim Löschen (durch den löschenden Admin) jeweils angegeben werden können. URV etc. sollen ja nicht betroffen sein! --ProloSozz (Diskussion) 12:25, 30. Mai 2017 (CEST)

Allerdings sollte dies nur für gelöschte Artikel gelten, nicht für Versionslöschungen. Bei der Löschung einer Seite sollte der löschende Admin entscheiden können, ob sämtliche Versionen der zu löschenden Seite automatisch versionsgelöscht sein sollten (für Sichter nicht einsehbar, nützlich bei erst vor kurzem erstellten Troll-Artikeln mit Titeln wie "X ist eine dumme Sau"). Somit sollte klar zwischen Löschungen aufgrund von Richtlinien-/Gesetzes-/Urheberrechtsverstößen (URV, schwere Beleidigung, etc.) und Löschungen nach "normaler" Löschdisk (Verstoß gegen Relevanzkriterien, nicht mehr benötigte Vorlagen/Kategorien) unterschieden werden. --C₂₁H₂₂N₂O₂ (V • T • E) 17:59, 29. Mai 2017 (CEST)

+1 --Anima (Diskussion) 23:19, 29. Mai 2017 (CEST)

Nicht zu vergessen: Verstöße gegen das Persönlichkeitsrecht. Ansonsten kann ich nur zustimmen: Admins sollten beim Löschen die Möglichkeit haben die Sichtbarkeit auf "nur für Admins" oder "nur für aktive Sichter" zu setzen. ーTesser4D 【Diskussion】 11:24, 30. Mai 2017 (CEST)

So meine ich es. Gut zusammengefasst. --C₂₁H₂₂N₂O₂ (V • T • E) 13:35, 30. Mai 2017 (CEST)

Hallo C21H22N2O2, Anima und Tesser4D, die Abstimmung beginnt am 19. Juni. Bis dahin können Vorschlagende ihre Wünsche noch anpassen und z.B. Rückmeldungen aus der Diskussion einarbeiten. Am 19. Juni wird dann bei jedem Wunsch die Diskussion eingeklappt und ein Abschnitt „Abstimmung“ ergänzt. Darum habe ich das {{Pro}} im Kommentar oben entfernt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:34, 30. Mai 2017 (CEST)

@Johanna Strodt (WMDE): Das Pro war noch da. Habs entfernt. ーTesser4D 【Diskussion】 11:40, 30. Mai 2017 (CEST)

Danke, Tesser4D! Das ist mir im Bearbeitungskonflikt durch die Lappen gegangen. -- Johanna Strodt (WMDE) (Diskussion) 11:43, 30. Mai 2017 (CEST)

Antrag ergänzt und umformuliert; Diskussion bis hier betraf den Antrag noch vor den Änderungen. --ProloSozz (Diskussion) 02:30, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:24, 19. Jun. 2017 (CEST)
3.  Pro -- Thomas Wozniak (HSP) (Diskussion) 11:52, 19. Jun. 2017 (CEST)
4.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:26, 19. Jun. 2017 (CEST)
5.  Pro -- Karl432 (Diskussion) 21:52, 19. Jun. 2017 (CEST)
6.  Pro -- Barnos (Post) 07:54, 20. Jun. 2017 (CEST)
7.  Pro --Eingangskontrolle (Diskussion) 15:37, 20. Jun. 2017 (CEST)
8.  Pro --emha ^d℩^b 10:14, 20. Jun. 2017 (CEST)
9.  Pro -- Peter Gröbner -- 16:54, 20. Jun. 2017 (CEST)
10.  Pro -- --Keuk (Diskussion) 18:47, 20. Jun. 2017 (CEST)
11.  Pro --Holder (Diskussion) 20:05, 20. Jun. 2017 (CEST)
12.  Pro --  Sir Gawain Disk. 20:32, 20. Jun. 2017 (CEST)
13.  Kontra „In der Versionsgeschichte würde dann nicht bei null angefangen, sondern die alte wiederherstestellt.“ – sowas nennt man Löschprüfung; dem Vorschlag nach ab jetzt jederzeit für alle Sichter zur Selbstbedienung. Und die rechtlich nicht einsehbaren Versionen müssten mindestens 2001–2017 dauergelöscht bleiben, weil frühestens ab 2018 neue Qualifikatoren für „doch nicht so ganz gelöscht“ eingeführt würden. Hier reicht noch nicht mal ein MB; das Ganze kollidiert mit WikiMediaLegal. @PerfektesChaos: (nicht signierter Beitrag von PerfektesChaos (Diskussion | Beiträge) 23:27, 20. Jun. 2017‎ PerfektesChaos)
14.  Neutral --Wikifreund (Diskussion) 23:59, 20. Jun. 2017 (CEST) Ich bin für ein einsehen der gelöschten Artikel ohne Einsicht wegen URV-Löschungen und ohne eine Wiederherstellungsoption.
15.  Pro --Uranus95 (Diskussion) 10:15, 21. Jun. 2017 (CEST)
16.  Pro --Schelmentraum (Diskussion) 13:25, 21. Jun. 2017 (CEST)
17.  Pro Michi 19:16, 21. Jun. 2017 (CEST)
18.  Pro --Kenny McFly (Diskussion) 19:31, 21. Jun. 2017 (CEST)
19.  Pro --ArthurMcGill (Diskussion) 09:21, 23. Jun. 2017 (CEST)
    
    

Redirectfunktion für Kategorien ermöglichen

Was ist das Problem?

Die meisten Geschichte-nach-Staat-Kategorien verlaufen nach dem Muster „[[Kategorie: Geschichte „(Staat)“]]“ Ich setze also gewohnheitsgemäß unter einen Artikel aus der Geschichte Chinas die Kategorie:Geschichte (China), die aber überraschenderweise rot erscheint, also möglicherweise noch nicht besteht. Soll ich sie also neu anlegen? Nach zeitraubender Suche finde ich den richtigen aber anders strukturierten Namen Kategorie:Chinesische Geschichte.

Wen betrifft das Problem besonders?

Alle WP-Benutzer, die einfach, rasch und korrekt eine Kategorie setzen wollen.

Lösungsvorschlag

Kategorienredirects werden bereits erfolgreich in commons praktiziert.
Bsp. in commons: beim Setzen der formal falschen Kat commons:Category:German history wandelt die Kat automatisch in die äquivalente, aber korrekt formulierte „commons:Category:History of Germany“.

Anmerkungen

Solche Kategorien könnten theoretisch schon angelegt werden; da sie aber keine Elemente enthalten, gelten sie als unerwünscht und sind sofort nach Anlegen akut von Löschung bedroht --ProloSozz (Diskussion) 12:11, 16. Jun. 2017 (CEST)

Vorschlagende Person

Wheeke (Diskussion) 15:07, 29. Mai 2017 (CEST)

Diskussion

Ist hier nicht eher das Problem, das es zwar Kategorienredirects gibt, das diese möglich sind, aber nicht erwünscht, und daher gelöscht werden? Wäre eher ein Fall für ein MB. Viele Grüße, Luke081515 17:17, 29. Mai 2017 (CEST)

Wo bitte ist diese Nichterwünschtheit dargelegt? Grüße --Wheeke (Diskussion) 11:26, 30. Mai 2017 (CEST)

Das Problem ist, dass so eine Kategorie keine Elemente drin hat, und eine Kategorie ohne Elemente ist eigentlich per se obsolet (da keine Elemente drin) ... Im Prinzip wäre eine Kategorie-WL durchaus sinnvoll (um eine Suche per Suchfeldeingabe zu erlauben, die auch einen Treffer bringt). --ProloSozz (Diskussion) 12:29, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Wheeke (Einreichende Person)
2.  Pro DestinyFound (Diskussion) 10:51, 19. Jun. 2017 (CEST)
3.  Pro --Abubiju (Diskussion) 17:10, 20. Jun. 2017 (CEST)
4.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:26, 22. Jun. 2017 (CEST)
5.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
   
   

Änderungen in Versionen leichter auffinden.

Was ist das Problem?

Ich habe oft, in Wikipedia aber auch vor allem in Wikisource das Problem, kleinere Änderungen, wie z. B. hinzugefügte Satzzeichen, Leerzeichen,... von anderen Usern nicht leicht zu erkennen. Die aktuelle hellfarbige Kennzeichnung ist kaum erkennbar und das Suchen nach Änderungen ist sehr zeitaufwendig.

Wen betrifft das Problem besonders?

Dies betrifft vor allem Bearbeiter eines Artikels. Und vor allem jene, die kleinere oder gröbere Sehprobleme haben.

Lösungsvorschlag

Vorstellbar wäre es, diese deutlich farbig zu kennzeichnen. (Eventuell einen farbigen Kreis, ... drüberzulegen).

Vorschlagende Person

Zabia (Diskussion) 13:13, 29. Mai 2017 (CEST) Zabia (Diskussion) 13:13, 29. Mai 2017 (CEST)

Diskussion

Danke fürs Umziehen hierhin, Zabia! -- Johanna Strodt (WMDE) (Diskussion) 15:58, 29. Mai 2017 (CEST)

Ich möchte noch hinzufügen: Ich sehe mir gerade auch die kleinsten Veränderungen bei meinen Bearbeitungen an, um zu lernen, und sie in Zukunft zu vermeiden. Zabia (Diskussion) 17:02, 29. Mai 2017 (CEST)

Hallo Zabia, zu Beginn der Abstimmungsphase am 19. Juni werden bei jedem Wunsch die Diskussionen eingeklappt (und ein neuer Abschnitt „Abstimmung“ hinzugefügt). Daher wäre es sinnvoll, den Hinweis auch oben im Wunsch noch zu ergänzen. Danke und Grüße -- Johanna Strodt (WMDE) (Diskussion) 11:44, 30. Mai 2017 (CEST)

@Zabia: Kannst Du dir bitte mal Benutzer:Schnark/js/diff oder/und Benutzer:TMg/cleanDiff ansehen, ob sie dem entgegenkommen, was Du willst? Dann könntest Du eventuell Deinen Wunsch dahingehend abwandeln. Du kannst beide Skripte auch prima gemeinsam einsetzen. — Speravir – 19:19, 30. Mai 2017 (CEST)

@Speravir: Das zweite, Benutzer:TMg/cleanDiff, sieht für mich gut aus, wenns funktioniert. Allerdings fühle ich mich eher überfordert ... Ich schaff es ja nicht mal in Wikipedia.de dieselbe Suchmaske wie in den anderssprachigen WP's einzustellen ... Ich muss auch betonen, ich kann heute kaum mehr Neues aufnehmen, mein Kopf ist voll mit den Artikeln die ich heut noch erstellen muss. ..., der Text tanzt vor meinen Augen.

Jedenfalls zeigen die 2 Beispiele, dass ich nicht allein mit meinem Problem bin. Funktioniert das eigentlich auch in Wikisource? Zabia (Diskussion) 19:45, 30. Mai 2017 (CEST)

Ja, beide funktionieren bei richtiger Einbindung auch dort. Da sollten wir dan aber auf Deiner Disk.-Seite klären (ebenso Dein kryptisches Problem mit der Suchmaske.) — Speravir – 23:32, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Zabia (Einreichende Person)
2.  Pro --FNDE 12:27, 20. Jun. 2017 (CEST)
3.  Pro --Johamar (Diskussion) 17:15, 20. Jun. 2017 (CEST)
4.  Pro --Aristeas (Diskussion) 17:48, 20. Jun. 2017 (CEST)
5.  Pro --Avron (Diskussion) 17:17, 21. Jun. 2017 (CEST)
6.  Pro --Pelz (Diskussion) 22:57, 21. Jun. 2017 (CEST)
7. --Furfur ^{⁂ Diskussion} 23:27, 21. Jun. 2017 (CEST)
8.  Pro --Jossi (Diskussion) 13:00, 22. Jun. 2017 (CEST)
9.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:27, 22. Jun. 2017 (CEST)
10.  Pro --GodeNehler (Diskussion) 19:33, 22. Jun. 2017 (CEST)
11.  Pro … «« Man77 »» (A) wie Autor 21:14, 22. Jun. 2017 (CEST)
12.  Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)
13.  Pro -- Freddy2001 ^DISK 12:01, 24. Jun. 2017 (CEST)
14.  Pro --MBxd1 (Diskussion) 18:12, 24. Jun. 2017 (CEST)
    
    

Rückgängigmachen erschweren

Was ist das Problem?

Sollte nur bei Vandalismus angewandt werden. Heute wird diese Funktion allerdings von vielen Leuten konstant benutzt. Nicht wegen Vandalismus, aber weil ihnen der Inhalt nicht passt oder sie eine Formulierung nicht mögen. Meines Erachtens nach ist es ziemlich traurig, wenn man viel Zeit investiert und etwas recherchiert und schreibt, das ganze dann aber mit einem Knopfdruck gelöscht werden kann. Wir sollten die Funktion nur dann nutzen, wenn es absolut notwendig ist! Wie bei Vandalismus. Ansonsten sollten Wikipedianer in den Artikel gehen und den Abschnitt verbessern / abändern. Wenn der Abschnitt vollkommen unpassend ist, dann sollte man auf die Diskussionsseite gehen und das ganze besprechen.

Wen betrifft das Problem besonders?

Die fleißigen Wikipedianer. Schreiben nimmt viel Zeit ein. Löschen mit einem Kopfdruck ist einfach.

Lösungsvorschlag

Rückgänig machen Funktion entfernen. Es durch einen "Vandalismus" Knopf ersetzen. Wenn drei Menschen das ganze melden, dann wird der Abschnitt rückgängig gemacht. Beim Benutzen soll dann noch davor gewarnt werden, dass man nur Vandalismus rückgängig machen kann. Und dann zur Wikiseite verlinken, die erklärt, was Vandalismus eigentlich ist.

Anmerkungen

Die "Schnellrückgängigmachung" bei ungesichteten Änderungen sollte nicht beeinträchtigt werden (dies nur als Hinweis für eine allfällige Umsetzung). --ProloSozz (Diskussion) 10:34, 6. Jun. 2017 (CEST)

Die derzeitige Möglichkeit, „kommentarlos zurücksetzen“ mittels CSS auszublenden, sieht zum einen nicht schön aus und ist zum anderen der falsche Weg. Es muss nicht jeder mit diesen Funktionen zwangsbeglückt werden; vielmehr sollten die, die sie wirklich sinnvoll einsetzen können (und willens sind), selbst aktivieren. -- 32X 20:13, 11. Jun. 2017 (CEST)

Vorschlagende Person

Rævhuld (Diskussion) 16:10, 29. Mai 2017 (CEST)

Diskussion

Hallo Rævhuld, damit schnell klar wird, worum es in diesem Wunsch geht, würde ich vorschlagen, den Namen des Wunsches zu ändern, z.B. zu „Rückgängigmachen erschweren“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:49, 30. Mai 2017 (CEST)

Vielen Dank @Johanna Strodt (WMDE):. Habe den Titel abgeändert.--Rævhuld (Diskussion) 16:03, 30. Mai 2017 (CEST)

Die "Schnellrückgängigmachung" bei ungesichteten Änderungen sollte nicht beeinträchtigt werden (dies nur als Hinweis für eine allfällige Umsetzung). --ProloSozz (Diskussion) 10:34, 6. Jun. 2017 (CEST)

@Rævhuld: Weil die Diskussion mit Beginn der Abstimmung (19. Juni) ausgeblendet wird: Möchtest du den Hinweis von ProloSozz noch oben ergänzen, z. B. unter „Lösungsvorschlag“? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:25, 8. Jun. 2017 (CEST)

Das mit dem „Wenn drei Menschen das ganze melden, dann wird der Abschnitt rückgängig gemacht.“ stelle ich mir schwierig vor - es dürfte genügend Artikel geben, wo es lange dauert, bis diese Zahl erreicht wäre. Da wäre mir ein schärferer Hinweis wie geschrieben („Beim Benutzen soll dann noch davor gewarnt werden, dass man nur Vandalismus rückgängig machen kann.“) lieber, um so einigen Benutzern deutlicher zu machen, dass sie selbst auf der VM landen können, wenn sie „nur“ kommentarlos revertieren, weil ihnen das Geschriebene nicht gefällt. --Blik (Diskussion) 16:32, 20. Jun. 2017 (CEST)

Es gibt Wikipedianer die hauptsächlich IP-Edits prüfen, wenn das drei melden müssen, dann werden wir in Zukunft doppelt so viele Leute dafür brauchen, deshalb bin ich in dieser Form dagegen, aber Nutzer die das Missbrauchen sollte manuell es zurückeditieren müssen (Entziehung der Rücksetzrechte, ohne Entziehung der Sichterrechte), oder alternativ nur an die Austeilen die sich auf Vandalismusprüfung "spezialisieren".  — Johannes Kalliauer - Diskussion | Beiträge 18:41, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Rævhuld (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 11:23, 19. Jun. 2017 (CEST) Umsetzungsvariante: Revertieren nur dann, nachdem der Ändernde angesprochen wurde und von ihm eine Antwort zurückkommt o.ä.
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:27, 19. Jun. 2017 (CEST)
4.  Pro--grim (Diskussion) 15:37, 20. Jun. 2017 (CEST)
5.  Pro @Blik:(nicht signierter Beitrag von Blik (Diskussion | Beiträge) 16:32, 20. Jun. 2017‎)
6.  Pro  — Johannes Kalliauer - Diskussion | Beiträge 18:41, 21. Jun. 2017 (CEST) Nur für Nutzer die das (mehrfach) missbrauchen.
7.  Pro Weil ich immer versehentlich raufklicke. --Kenny McFly (Diskussion) 19:34, 21. Jun. 2017 (CEST)
8.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:28, 22. Jun. 2017 (CEST)
9.  Pro mauriceKA (Diskussion) 13:23, 23. Jun. 2017 (CEST)
   
   

Sichten in der mobilen Wikipedia

Was ist das Problem?

Derzeit muss man, wenn man eine Version mit Minerva sichten will, zur Desktopversion wechseln. Selbst wenn man bei den Seiten mit ungesichteten Versionen auf den „Sichten“-Link geht, kommt man nur zum mobilen Versionsunterschied. Ohne Möglichkeit auch wirklich zu sichten.

Wen betrifft das Problem besonders?

Alle Sichter, die die mobile Version der Wikipedia benutzen

Lösungsvorschlag

Man füge einen Link zum Sichten einer Version beim Betrachten des Versionsunterschiedes, sowie im Artikel selbst einen Hinweis, dass er noch nicht gesichtete Versionen enthält mit Link auf die entsprechenden Versionen oder die Versionsgeschichte.

Anmerkungen

Dies gilt nicht für Versionsunterschiede zwischen mehreren Versionen, da dazu – aus welchem Grund auch immer – nicht die Seite Spezial:Mobiler Unterschied, sondern das Format mit title=Abc&diff=cur&oldid=xyz verwendet wird (obwohl es möglich ist, solche Versionsunterschiede auch mit Spezial:Mobiler Unterschied darzustellen).

Vorschlagende Person

KPFC 💬 19:04, 29. Mai 2017 (CEST)

Diskussion

@KPFC: Damit auch Laien gleich den Titel deines Wunsches verstehen: Was hälst du davon, statt Minerva "mobile Version von Wikipedia" zu schreiben? Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:57, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro KPFC (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 22:22, 19. Jun. 2017 (CEST)
3.  Pro --Carolus requiescat (Diskussion) 17:21, 21. Jun. 2017 (CEST)
4.  Pro -- Freddy2001 ^DISK 12:02, 24. Jun. 2017 (CEST)
   
   

Zusätzlichen Button "Zum Artikel" nach dem Sichten

Was ist das Problem?

Nach dem Sichten muss man mit der Maus wieder nach oben, um den gesichteten Artikel lesen zu können.

Wen betrifft das Problem besonders?

angemeldete User mit Sichten-Berechtigung, die nicht gezielt sichten, sondern nur, wenn sie einen ungesichteten Artikel lesen möchten und im Zuge dessen sichten.

Lösungsvorschlag

Es wäre nett, wenn neben den Buttons "Erledigt und gesichtet" und "Sichtung entfernen" ein zusätzlicher Button "zum Artikel" erscheint.

Anmerkungen

Das Problem stellt sich auch beim Danken oder beim Zurücksetzen/Verwerfen einer ungesichteten Änderung. Zudem muss das auch mit abgeschaltetem Scripting richtig funktionieren. ProloSozz (Diskussion) 12:14, 16. Jun. 2017 (CEST)

Vorschlagende Person

Hlambert63 (Diskussion) 19:09, 29. Mai 2017 (CEST)

Diskussion

Diesen Button vermisse ich auch ... das Problem ist ja, dass man manchmal (oder ist das inzwischen anders?) nicht wieder auf das Artikellemma klicken kann, sondern auf einer Spezialseite ist, und man dann ohne "zurück" nicht wieder direkt zum Artikel kommt ... --ProloSozz (Diskussion) 12:33, 30. Mai 2017 (CEST)

Also ich klicke nach dem Sichten immer auf den "Lesen"-Knopf ganz oben. Da das Feld mit der Sichtung sowieso recht weit oben steht, ist das m. E. kein großer "Umweg". --C₂₁H₂₂N₂O₂ (V • T • E) 14:54, 30. Mai 2017 (CEST)

Prinzipiell geht das zwar schon, aber nicht immer; manchmal landet man nach dem Sichten nämlich auf einer Spezialseite und kommt nur noch per "Browser-zurück" wieder zur eigentlichen Seite. --ProloSozz (Diskussion) 23:52, 5. Jun. 2017 (CEST)

Man muss das UI nicht noch weiter mit Buttons und Links, die jemand mal gebrauchen könnte, zukleistern. Nach oben kommst du mit der Taste Pos1. Wenn du (weil die Seite während des Sichtens noch nicht alle notwendigen ihre Skripte geladen hat) auf der Spezialseite landest, ist dort ein dicker, fetter Link auf den Artikel. -- 32X 20:19, 11. Jun. 2017 (CEST)

Nein, da ist nur der Button "Spezialseite"; und klickt man da drauf, heisst es, es sei kein Thema gewählt. Ohne "Browser-zurück" kommt man nicht zum Artikel zurück! NB: ich will nicht ausschließen, daß das nur bei abgeschaltetem Scripting nicht erscheint. Es sind aber viele Nutzer ohne Scripting unterwegs; das muß auch dann hinhauen. --ProloSozz (Diskussion) 12:18, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Hlambert63 (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 11:24, 19. Jun. 2017 (CEST)
3.  Pro Zabia (Diskussion) 17:15, 20. Jun. 2017 (CEST)
4.  Pro --GodeNehler (Diskussion) 19:34, 22. Jun. 2017 (CEST)
5.  Pro -- Freddy2001 ^DISK 12:02, 24. Jun. 2017 (CEST)
6. 
   
   

Bessere Mobile Versionsgeschichte

Was ist das Problem?

Die mobile Versionsgeschichte bietet nur die Möglichkeit, einen Diff zwischen zwei aufeinanderfolgenden Versionon auszuwählen. Nun ist es oft aber nötig, mehr als zwei Versionon als einen Diff zu betrachten. In der Desktopversion kann man dazu leicht zwei Versionon auswählen und dann die „gewählten Versionen vergleichen“.

Wen betrifft das Problem besonders?

Alle Wikipedianer und Wikipedianerinnen, die die mobile Version der Wikipedia verwenden.

Lösungsvorschlag

So etwas wie oben für die Desktopversion beschrieben sollte auch mobil hinzugefügt werden.

Vorschlagende Person

KPFC 💬 19:10, 29. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro KPFC (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 15:04, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 22:22, 19. Jun. 2017 (CEST)
4.  Pro -- Freddy2001 ^DISK 12:02, 24. Jun. 2017 (CEST)
   
   

Verlinkungsfehler anzeigen

Was ist das Problem?

Ich verlinke sehr viel und auch manchmal sehr umfangreiche Artikel (vor allem in WS). Dabei kommen natürlich auch Fehler vor. Ich erstelle, da ich bändeweise arbeite und Mitarbeiter ersparen will, sehr viele Rotlink, die ich per Copy&Paste einfüge. Ich arbeite diese Rotlinks dann sukzessive bändeweise ab. Dabei entstehen natürlich auch Kopierfehler, dann ist mal eine eckige Klammer zuwenig ([BLKÖ:Name|Name]] oder [[BLKÖ:Name|Name], oder eine pipe zuviel (im Quelltext erscheint dann: |Name). Normalerweise fände ich die, wenn ich den Quelltext nach (im BLKÖ) „BLKÖ“ durchsuche, allerdings mache ich pro Tag bis zu 50 Lemmata, da bin ich also nachlässig. Vor allem verlinke ich WS-Autoren und Personen, manchmal WS-Seiten oder WS-Werke. BLKÖ ist ein biographisches Lexikon.

Wen betrifft das Problem besonders?

Artikelersteller, Korrektoren.

Lösungsvorschlag

WS oder WP sollten diese Fehler unten im Bearbeitungsfenster rot anzeigen (analog wie bei Anmerkungsfehlern). Damit würde man sich nochmalige Korrekturzeit und technische Verlinkungsfehler ersparen.

Vorschlagende Person

Zabia (Diskussion) 10:22, 30. Mai 2017 (CEST)

Diskussion

Hallo Zabia, um den Wunsch zu verstehen, bräuchten wir noch etwas mehr Infos, beispielsweise: Was verlinkst du? Welchen Editor nutzt du? Wie gehst du vor? Und welche Fehler geschehen dann konkret? Auch wenn du nicht alle aufzählen kannst, vielleicht hast du Beispiele für besonders blöde Fehler? -- Danke und Grüße, Johanna Strodt (WMDE) (Diskussion) 11:54, 30. Mai 2017 (CEST)

Ich benutze MSWord und als Browser InternetExplorer11.

Ich erstelle, da ich bändeweise arbeite und Mitarbeiter ersparen will, sehr viele Rotlink, die ich per Copy&Paste einfüge. Ich arbeite diese Rotlinks dann sukzessive bändeweise ab. Dabei entstehen natürlich auch Kopierfehler, dann ist mal eine eckige Klammer zuwenig ([BLKÖ:Name|Name]] oder [[BLKÖ:Name|Name], oder eine pipe zuviel (im Quelltext erscheint dann: |Name). Normalerweise fände ich die, wenn ich den Quelltext nach (im BLKÖ) „BLKÖ“ durchsuche, allerdings mache ich pro Tag bis zu 50 Lemmata, da bin ich also nachlässig. Zabia (Diskussion) 14:03, 30. Mai 2017 (CEST)

Vor allem verlinke ich WS-Autoren und Personen, manchmal WS-Seiten oder WS-Werke. BLKÖ ist ein biographisches Lexikon. Zabia (Diskussion) 14:05, 30. Mai 2017 (CEST)

@Zabia: Danke! Ich war so frei, die Ergänzungen auch oben einzufügen, weil die Diskussion später bei der Abstimmung eingeklappt sein wird. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:20, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Zabia (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 11:32, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 22:23, 19. Jun. 2017 (CEST)
4. 
   
   

Zahlreiche, mehrfache, fehlerhafte Verlinkungen im Projekt (vor allem WS) mit einer Bearbeitung korrigieren.

Was ist das Problem?

Ich verlinke in WS vor allem das BLKÖ (ca. 26.000 Artikel), und erstelle dabei naturgemäß viele Rotlinks. Manchmal, auch öfter finde ich dabei Tippfehler in diese Rotlinks eventuell; muss auch mal ein solches Lemma umbenannt werden. Die Einzelkorrektur dieser Rotlinks ist sehr zeitaufwendig, auch Fehler sind möglich. BLKÖ:Barabás, Michael z.B. erfordert mehr als 50 Einzelkorrekturen. Ich führe natürlich eine Datei, in der ich meine Verlinkungen dokumentiere, allerdings verliere ich ab und an diese aktuelle Liste, und dann kommen erneut fehlerhafte Verlinkungen vor.

Wen betrifft das Problem besonders?

Verlinker (mich), Bearbeiter, Administratoren, die solches erledigen könnten,...

Lösungsvorschlag

Eine Möglichkeit für mich, solche Linkfixes mit einer einzigen Bearbeitung zu erledigen (eventuell nur für Bearbeiter mit Sichterstatus?).

Vorschlagende Person

Zabia (Diskussion) 10:35, 30. Mai 2017 (CEST)

Diskussion

@Zabia: Danke für deinen Wunsch! Könntest du noch ein bisschen mehr erklären, was das Problem ist? Wofür stehen zum Beispiel WS und BLKÖ? Und warum kannst du aktuell die Linkfixes nicht mit einer Bearbeitung erledigen? Erstellst du manchmal auch absichtlich Rotlinks, und warum? Viele Grüße, Lea Voget (WMDE) (Diskussion) 15:03, 30. Mai 2017 (CEST)

@Lea Voget (WMDE): WS steht für die deutsche Wikisource und BLKÖ für Biographisches Lexikon des Kaiserthums Oesterreich. Ich kann fehlerhafte Links nur einzeln (!) korrigieren ... wenn ich sie überhaupt auffinde. Ich kenne kein Werkzeug dafür. Ich kann mich erinnern, dass ich einmal 500 idente falsche Links einzeln abgearbeitet habe.

Naturgemäß erstelle ich sehr viele, tausende wohl, Rotlinks, indem ich Personen-Artikel, die noch nicht im BLKÖ existieren, intern schon verlinke, um mir einen weiteren Durchgang zu ersparen. Wenn ich einen Band fertig hab, vergleiche ich meine private Link-Liste mit der Artikelliste des Bandes und finde so textmäßige Falschlinks, die ich dann sehr aufwendig einzeln abarbeite. Da ich zum Teil auch mit einer veralteten privaten Link-Liste arbeite (ich hab einen sehr hohen Computerverschleiß), hab ich vor, bei Abschluß des Projektes (2018, 2019?) alle noch verbliebenen Rotlinks abzuarbeiten. Auch da fehlt mir wohl ein geeignetes Tool, diese zu erkennen. Ich gebe zu, die personelle Unterstützung in WS ist nicht optimal für mich, ich vermute, weil es ein rein österreichisches Werk ist. In meinem Fall jedenfalls handelt es sich ausschließlich um Rotlinks in Wikisource, die mit „BLKÖ:“ beginnen. Und mit jedem Band, den ich korrigiert habe, inzwischen sind es 40 von 60 Bänden, werden es weniger.

Wenn man feststellt, dass man mehrere hundert falsche Links korrigieren muss, kann man doch einen Botbetreiber fragen, ob sein Bot das für einen erledigen kann. --C₂₁H₂₂N₂O₂ (V • T • E) 19:29, 30. Mai 2017 (CEST)

@C21H22N2O2: Ja, aber nur, wenn wer willig ist. Und wenn da eventuell regelmäßig gebettelt werden muss, hält sich die Begeisterung in Grenzen. Zabia (Diskussion) 08:27, 11. Jun. 2017 (CEST)

Unterstützung

1.  Pro Zabia (Einreichende Person)
2. 
   
   

Nur jeweils letzte Bearbeitungsversion in den Benutzerbeiträgen anzeigen und frühere ausblenden

Was ist das Problem?

V.a. in den eigenen Benutzerbeiträgen interessiert oft, ob eigene Bearbeitungen noch aktuell sind oder nicht. Zwar steht "(aktuell)" fett in Klammern dabei; dies ist aber nicht besonders übersichtlich.

Wen betrifft das Problem besonders?

Wer sich in Bearbeitungslisten eine Übersicht verschaffen will ...

Lösungsvorschlag

a) zusätzlicher Filter "nur letzte Versionen anzeigen" (dann wird nur die jeweils letzte Bearbeitung eines Artikels aufgelistet und die früheren desselben werden ausgeblendet). Dieser Filter sollte mit "nur aktuelle" und "nur nicht aktuelle" kombinierbar sein, so dass auch nur nichtaktuelle letzte Bearbeitungen aufgelistet werden können.

b) die jeweils letzten Bearbeitungen farblich unterlegen (anders als die vorherigen).

Anmerkungen

Das Thema wurde hier in der Technikwerkstatt schon mal aufgeworfen. Diese Filterung muss auch ohne Scripting/ohne JavaScript funktionieren!

Vorschlagende Person

ProloSozz (Diskussion) 12:45, 30. Mai 2017 (CEST)

Diskussion

Das funktioniert schon, man muss nur in der Beitragsliste bei "Nur aktuelle Versionen anzeigen" ein Häkchen setzen und auf "Suchen" klicken. Evtl. könnte man das (aktuell) noch rechtsbündig einrücken, was die Liste auch so etwas übersichtlicher machen würde. --C₂₁H₂₂N₂O₂ (V • T • E) 14:46, 30. Mai 2017 (CEST)

Es geht wohl nicht um die aktuelle Bearbeitung, sondern ob die eigene letzte Bearbeitung noch aktuell ist. Wenn man also die geänderten Artikel nicht auf die Beobachtungsliste genommen hat, wäre eine solche Spezialseite hilfreich zum auffinden der Seiten die sich geändert haben, seit dem man selber dort bearbeitet hat (wobei eine Änderung durch sich selber nicht dazuzählt). Der Umherirrende 16:58, 31. Mai 2017 (CEST)

Das heißt, eine Spezialseite, die bei allen Artikeln, die ich bearbeitet habe, abgleicht, ob die aktuelle Version von mir stammt, und wenn nicht, alle Versionen nach meiner letzten Bearbeitung auflistet? Aber wenn ich in einem Artikel, der sehr häufig bearbeitet wird, irgendwann einmal einen Tippfehler beseitigt habe, würde dessen dauerhafte Bearbeitung diese Liste doch "fluten", oder? --C₂₁H₂₂N₂O₂ (V • T • E) 07:35, 2. Jun. 2017 (CEST)

Nein; andersrum! Ein Artikel soll nur ein einziges mal aufgelistet werden (die letzte eigene Bearbeitung; alle früheren Bearbeitungen würden ausgeblendet). Wenn ich z.B. einen Artikel mehrmals bearbeitet hatte, dann erscheint meine letzte Bearbeirung so lange als aktuell, bis sonstwer wieder etwas geändert hat. Mich interessiert aber nun meine letzte Bearbeitung (ob inzwischen wieder geändert wurde (und diese nicht mehr aktuell ist) oder nicht); wer und wie oft danach geändert wurde, interessiert überhaupt nicht; und meine vorangehenden Änderunge ebenso nicht. Oder anders formuliert: ich will mich nicht durch x-beliebige nicht-aktuelle Versionen durchwühlen, um die letzte zu suchen, um dann erst sehen zu können, ob diese überhaupt noch aktuell ist (resp. sie auch nicht mehr aktuell ist). Wenn der bearbeitete Artikel ein einziges mal aufgeführt ist (das letzte mal, als ich etwas bearbeitet hatte), reicht dann aus; die vorangehenden Versionen interessieren dann nicht. NB: die komplette eigene Bearbeitungsliste (ohne Filter) wäre nach wie vor beizubehalten. Hier wäre es als "Filter, der nur die jeweils letzte eigene Bearbeitung eines Artikels auflistet" angedacht (in einer Liste, die ohnehin ausschließlich eigene Bearbeitungen auflistet). --ProloSozz (Diskussion) 00:05, 6. Jun. 2017 (CEST)

@ProloSozz: Könntest du deine Erklärungen aus der Diskussion noch bei „Was ist das Problem?“ oder beim Lösungsvorschlag einfügen? Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird (und damit wären dann deine Ergänzungen unsichtbar). -- Viele Grüße, 16:30, 8. Jun. 2017 (CEST)

@Prolozz: Dein Lösungsvorschlag b) wird im Skript filterContributions umgesetzt(Nachtrag: mein Fehler, die Einfärbung erfolgt durch topcontrib). Und Dein „so dass auch nur nichtaktuelle letzte Bearbeitungen aufgelistet werden können“ aus Punkt a) ist per Schalter ebenfalls möglich (daher der Name filterContributions). — Speravir – 01:41, 14. Jun. 2017 (CEST)

@Prolozz: Hallo! Für mich liest es sich so, dass dieser Wunsch mit dem Skript schon erfüllt ist. Darum würde ich den Wunsch morgen Mittag nach Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche#Sonderzeichenliste_direkt_unter_dem_Bearbeitungsfenster verschieben. Falls du das anders siehst, gib bitte Bescheid und ergänze im Wunsch, was dir über das Skript hinaus noch fehlt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:14, 15. Jun. 2017 (CEST)

Nein; das ist noch nicht umgesetzt! Das muß auch ohne (resp. mit abgeschaltetem) Scripting funktionieren. Das genannte Script hat aber keine Funktion, wenn JS nicht eingeschaltet ist. --ProloSozz (Diskussion) 12:36, 16. Jun. 2017 (CEST)

@Johanna Strodt (WMDE):; @Speravir:: Danke, meinen Namen (auch wenn es nur ein Nickname ist) jeweils korrekt zu schreiben (mit Copy&Paste geht das ja ziemlich einfach :D ...); dann werde ich nämlich auch wirklich angepingt (was mehrmals nicht der Fall war) ... --ProloSozz (Diskussion) 19:36, 15. Jun. 2017 (CEST)

@ProloSozz: Ja, war mein Fehler und Johanna wird einfach von mir kopiert haben. So was soll gelegentlich mal vorkommen. Johanna hatte übrigens etwas gefragt, das scheinst Du nicht bemerkt zu haben. — Speravir – 19:59, 15. Jun. 2017 (CEST)

Ja, ich hab' gesehen, daß Ihr was geschrieben habt, bin aber noch nicht dazugekommen, das im Detail in die Finger zu nehmen. Ich sollte auf dieser Seite eh noch in mehreren Kapiteln rumwerkeln, und Zeit bleibt nicht mehr ewig ... :D ... NB: keine Ursache wegen Falschschreibung; das kann passieren (und ich muß sogar meinen richtigen Namen so gut wie jedesmal buchstabieren, damit der nicht falsch geschrieben wird) ... ist aber natürlich doof, wenn fehlerbehaftet dann gepingt werden soll. Sorry, momentan auch nur Kurzerwähnung ... --ProloSozz (Diskussion) 22:40, 15. Jun. 2017 (CEST)

OK. — Speravir – 23:25, 15. Jun. 2017 (CEST)

Frage: funzt das mit der commons.js dann nur, wenn Scripting eingeschaltet ist? Das wäre dann witzlos, da nur eingeschränkt nutzbar; ich bin meist mit einer Rechner-/Browserkombination unterwegs, die mit Scripting Mühe hat, weswegen JS abgeschaltet wird. Mit Scripting dauert dann der Seitenaufbau mehrere Minuten, während es ohne innert nicht mal Sekunden bewerkstelligt ist ... --ProloSozz (Diskussion) 03:23, 16. Jun. 2017 (CEST)

@ProloSozz: Oh nein, entschuldige! Ich nehme das jetzt mal zum Anlass in den Einstellungen anzuhaken, dass ich bei erfolglosem Pingen benachrichtigt werden möchte – was im Übrigen ja auch ein technischer Wunsch war. ;) Statt heute Mittag würde ich den Wunsch dann heute Nachmittag so ab 16.00 Uhr verschieben. Okay? -- Viele Grüße und danke für deine nette Reaktion! Johanna Strodt (WMDE) (Diskussion) 09:58, 16. Jun. 2017 (CEST)

Nein. Bitte KEINE Verschiebung. Zum einen geht das Script nur mit eingeschaltetem JS, und zum anderen kann das Script das Gewünschte wohl gar nicht; die Filterfunktion muss aber auch ohne Scripting funktionieren; oder mache ich was falsch? ... NB: nochmal, was hier gewünscht ist: gehe ich auf "meine Beiträge", so erscheinen sämtliche meiner Bearbeitungen. Ich will nun einen Filter, den jede bearbeitete Seite nur ein einziges mal (und zwar meine letzte Bearbeitung) anzeigt. Alle früheren Bearbeitungen (der jeweiligen Seiten) sollen ausgeblendet werden. Zusätzlich soll dieser Filter mit "nur aktuelle" resp. v.a. "keine aktuellen" kombiniert werden können. Ich sehe nicht, wie das mit dem genannten Script gehen soll ... --ProloSozz (Diskussion) 12:36, 16. Jun. 2017 (CEST)

@ProloSozz: Alles klar, danke für die Präzisierung. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 22:45, 16. Jun. 2017 (CEST)

Ich hatte die Skripte verwechselt: Die Einfärbung geschieht durch topcontrib. — Speravir – 20:13, 19. Jun. 2017 (CEST)

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 11:48, 19. Jun. 2017 (CEST)
3.  Pro --FNDE 15:34, 20. Jun. 2017 (CEST)
4.  Pro Zabia (Diskussion) 17:16, 20. Jun. 2017 (CEST)
5. 
   
   

Direkte Auflistung von existierenden Artikeln in anderen Sprachen

Was ist das Problem?

Gibt man einen Begriff im Suchfeld ein und existiert kein Artikel in der deutschsprachigen WP, so wäre es sinnvoll, gleich erkennen zu können, in welchen anderen Sprachen übhaupt ein Artikel besteht. Man kann zwar einzeln in anderen Sprachen suchen; das ist aber eine Herumstocherei i.S.v. Trial & Error. Eleganter wäre eine Liste mit direkten Links zu den jeweiligen anderssprachigen WPs, in denen unter dem Lemma ein Artikel besteht ...

Wen betrifft das Problem besonders?

Alle, die die WP neben Deutsch auch in weiteren sprachen nutzen oder lieber einen Artikel in einer anderen Sprche lesen, als nur googeln zu müssen.

Lösungsvorschlag

Ist ein Lemma in der deutschsprachigen WP nicht vorhanden (ggf. auch bei Löschungen), so erscheint eine Liste (wie bei existenten Artikeln), in welchen anderen Sprachen ein Artikel besteht. Man wird zwar darauf hingewiesen, daß in der de-WP kein Artikel besteht, und bekommt einen Link "in anderssprachigen WPs suchen"; da muß man dann aber jede Sprache einzeln durchprobieren, ob dort überhaupt was existiert. An der Stelle sollte dann gleich eine Liste erscheinen mit "xyz in der en-Wiki; xyz in der fr-Wiki" etc. (aufgelistet werden alle Sprachen resp. WPs, in denen das gesuchte Wort als Artikel existiert; am besten gleich mit der Anzahl Zeichen des Artikels).

Anmerkungen

Sollte ohne aktivem Scripting verfügbar sein; also bitte nicht mit JavaScript o.ä.

Vorschlagende Person

ProloSozz (Diskussion) 12:53, 30. Mai 2017 (CEST)

Diskussion

Bitte um ein konkretes Beispiel. Mir fallen nur welche ein, wo das nicht geht.--Wheeke (Diskussion) 13:39, 30. Mai 2017 (CEST)

So etwas ähnliches gibt es schon, nennt sich TextCat (vgl. Wikipedia:Kurier/Ausgabe 7 2016#TextCat oder: Die Suche wird mehrsprachig). Leider ist es aktuell weitgehend unbrauchbar, da die Suchergebnisse aus anderen Sprachen nur dann aufgeführt werden, wenn es auf deutsch keine Suchergebnisse gibt (was die absolute Ausnahme ist). Das sollte geändert werden, so dass auch dann anderssprachige Suchergebnisse angezeigt werden, wenn es deutsche Ergebnisse gibt (etwa wenn man nach Ortsartikeln sucht, es aber auf Deutsch nur Artikel zu Personen aus dem Ort, nicht aber den Ortsartikel selbst). --Orci Disk 11:51, 31. Mai 2017 (CEST)

Aha. Da lese ich "unter Umständen". Wenn ich das Ganze jetzt recht verstehe, ist das bei Namen wohl vorstellbar. Die sind übersetzungstechnisch vielfach kongruent oder mglw. rechtschreibtolerant, also rasch und einfach zu ermitteln. Andere Begriffe bedürften wohl einer Übersetzersoftware, oder? Das wäre allerdings höchst spannend, bei allen absehbaren technischen Einschränkungen. --Wheeke (Diskussion) 13:54, 31. Mai 2017 (CEST)

Es ist dann anzuwenden, wenn ein eingegebener Suchstring in der deutschen WP nicht vorkommt, aber im entsprechend buchstabierten Wortlaut in andersprachigen WPs. Es liegt in der Natur der Sache, daß das nicht nur, aber v.a. bei Namen vorkommt. Ein Übersetzungstool ist absolut NICHT gemeint, sondern es geht effektiv ausschließlich um die eingegebene "Buchstabenkombination". Beispiel (und das ist grad ein Name): Pali Chandra (in der de-WP ist das ein Rotlink); aber nicht in der en-WP: Pali Chandra in der en-WP]; per Interwiki besteht nun eine Verknüpfung mit der Hindi-WP: पाली चंद्रा in der hi-WP. D.h. also: sucht man in der deutschsprachigen WP nach Pali Chandra, so erscheint nicht viel mehr als "is nix da ..."; man kann dann auf gut Glück einzelne anderssprachige WPs einzeln abfragen (über "suchen in anderssprachigen WPs"). Die Idee ist nun, dass direkt aufgelistet wird, in welchen anderssprachigen WPs die genannte "Wortkombination" vorkommt. Im konkreten Fall würde direkt die en-WP aufgeführt. Da Hindi in einer anderen Schrift geschrieben wird, würde die Hindi-Version primär nicht auch erscheinen. Da diese aber per Interwiki verbunden ist, könnte es auch eingerichtet werden, daß alle per Interwiki verbundenen WPs aufgelistet werden. Wenn aber in unterschiedlichen Sprachen eine "Buchstabenkombination" nicht dasselbe heißt (auch das gibt's) und dies je nach Sprache auf unterschiedliche Interwiki-Einträge führen würde, wäre auch das zu berücksichtigen. Das heißt also: sofern ein Suchwort nicht existiert, müßte eine "Interwiki-Abfrage" gemacht werden; und wenn so ein eintrag in (irgend) einer Sprache vorhanden ist, wäre der (mit allen per diesem Interwiki-Eintrag verbundenen Sprachen) aufzulisten. D.h. also: anstatt einzeln in anderen Sprachen herumzustochern (und es mal mit irgend einer zu versuchen), könnten gleich alle Sprachen aufgelistet werden, in denen ein Artikel mit dem gesuchten Wort vorkommt. --ProloSozz (Diskussion) 00:27, 6. Jun. 2017 (CEST)

also weniger „Artikel“ denn „Buchstabenfolge“ auflisten. Warum nicht...--Wheeke (Diskussion) 09:46, 6. Jun. 2017 (CEST)

Hätte ich "Lemma" schreiben sollen? Wenn gar kein Artikel existiert, kann ich ja kaum "Artikel" schreiben; "Lemma" wäre zwar möglich, aber auch nicht unbedingt zutreffend. Mit "Buchstabenfolge" sollte explizit auch ausgedrückt werden, daß Übersetzungen o.ä. hier fehl am Platz wären (darum geht es nicht); hier geht es nur um das eingegebene Wort, nach dem "buchstabengetreu" gesucht werden soll (und das können eben auch "Nicht-Wörter" (wie Abkürzungen etc.) und sonst einiges mehr sein, für das sich die Bezeichnung "Buchstabenfolge" eben am besten zu eignen scheint, um bei allen zuzutreffen). Aufgelistet würden dann ohnehin nur "Artikel (die in andersprachigen WPs existieren)" ... --ProloSozz (Diskussion) 10:46, 6. Jun. 2017 (CEST)

@ProloSozz: Hallo und danke für den Wunsch! Ich möchte nur kurz darauf hinweisen, dass die Diskussion bei der Abstimmung (ab 19. Juni) eingeklappt wird, damit klar ist, worüber abgestimmt wird. Wenn in der Diskussion zu deinem Wunsch noch Informationen stecken, die für das Verständnis des Wunsches hilfreich sind, wäre es wichtig, dass du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:22, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 12:00, 19. Jun. 2017 (CEST)
3.  Pro --Noobius2 (Diskussion) 16:04, 20. Jun. 2017 (CEST)
4.  Pro Zabia (Diskussion) 17:17, 20. Jun. 2017 (CEST)
5.  Pro --Boehm (Diskussion) 08:07, 21. Jun. 2017 (CEST)
6.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:29, 22. Jun. 2017 (CEST)
7.  Pro --GodeNehler (Diskussion) 19:35, 22. Jun. 2017 (CEST)
8.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
9.  Pro -- Nichtich (Diskussion) 23:03, 23. Jun. 2017 (CEST)
10. 
    
    

Umfang der Artikel in den anderen Sprachen in der Sprachenübersicht anzeigen

Angaben in Kursiv angfügt von ProloSozz

Was ist das Problem?

Wenn man mit dem Artikel der eigenen Sprache (hier deutsch) noch nicht alle gefragte Information zusammengesammelt hat, zieht man in Betracht, dies bei Artikeln anderer Sprachen nachzulesen. Und da wäre es sehr nützlich, wenn man schon in der Übersicht mit den Existierenden Sprachversionen einen Anhaltspunkt hat, wie umfangreicht der jeweilige Artikel ausfällt und ob sich es überhaupt lohnt, die eine oder andere Sprache anzuwählen (was nicht der Fall wäre, wenn der nur ganz kurz und rudimentär wäre).

Wen betrifft das Problem besonders?

All jene, die auch Artikel in anderen Sprachen lesen.

Lösungsvorschlag

Bei der Liste der anderen Sprachen, in denen ein entsprechender Artikel existiert, z.B. die Anzahl Zeichen direkt in Klammern (ggf. klein) dahintersetzen.

Anmerkungen

In den verschiedenen Sporachen gibt es verschiedene Längen und Tiefen der Beiträge. Ich spreche zwar Dutzend Sprachen, aber andere, die das nicht können, gehen ärmer aus.

Vorschlagende Person

Grosswardeyn (Diskussion) 13:13, 30. Mai 2017 (CEST) Grosswardeyn
Ergänzend ausformuliert von (und mit unterstützend):
ProloSozz (Diskussion) 12:12, 5. Jun. 2017 (CEST)

Diskussion

Lieber Grosswardeyn, hier fehlen noch ein paar wichtige Angaben, z. B. ein Name für den Wunsch und eine ausführlichere Beschreibung, was genau das Problem und der Wunsch ist. Könntest du das bitte noch mal ausführlicher beschreiben? Vielleicht helfen dir diese Tipps zur Formulierung von Wünschen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:07, 30. Mai 2017 (CEST)

Fehlende Grundangaben in Kursiv von mir hinzugefügt; TE: bitte intervenieren, sollte es nicht wie gedacht dargestellt sein. Auch mir wäre das ein Anliegen. --ProloSozz (Diskussion) 12:12, 5. Jun. 2017 (CEST)

Es würde reichen, wenn die Artikelgrößen beim Bewegen der Maus über die Sprachen angezeigt werden (machbar?).--WeiterWeg (Diskussion) 22:04, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Grosswardeyn (Einreichende Person)
2.  Pro ProloSozz (Einreichende Person)
3.  Pro --WeiterWeg (Diskussion) 18:49, 20. Jun. 2017 (CEST)
   
   

Nutzer sollten gelöschte Artikel einsehen können

Was ist das Problem?

Wenn ein Text oder gar ein ganzer Artikel gelöscht wird, kann nur ein Admin diese dann einsehen. Oft werden Artikel gelöscht, weil sie nur ein "Stub" sind. Wenn ein Nutzer dann einen ausführlichen Artikel schreiben will, dann muss er von Null anfangen. Könnte er den alten Artikel einsehen, könnte er dies als Vorlage nutzen und auch die Löschdiskussion nutzen, um dann einen Artikel zu schreiben. Außerdem können Nutzer dann auch besser verstehen, warum ein Artikel gelöscht wurde (im Nachhinein). Artikel werden eben nicht nur wegen Irrelevanz (das auch transformativ ist) gelöscht, sondern oft wegen Mängel. Wenn man dann sehen kann, welche Mängel es gibt, kann man diese Mängel umschiffen.

Wen betrifft das Problem besonders?

Normale Nutzer*innen.

Lösungsvorschlag

Wer ein Nutzerkonto hat, sollte gelöschte Artikel einsehen können. Oben mit einer Verlinkung zur Löschdiskussion.

Anmerkungen

Die gelöschten Artikel sind meines Wissens nach für Admins einsehbar. Also wäre es schon möglich, dies für Bearbeiter*innen freizuschalten.

Vorschlagende Person

Rævhuld (Diskussion) 16:46, 30. Mai 2017 (CEST)

Diskussion

S. a. etwas höher. --Schniggendiller Diskussion 17:52, 30. Mai 2017 (CEST)

@Rævhuld, ProloSozz: Hallo! Wie wäre es, wenn ihr euren Wunsch gemeinsam einreicht?

Vorschlag: ProloSozz arbeitet die Beschreibung von Rævhuld mit in seinen Wunsch „Aktive Sichter sollten gelöschte Versionen (incl. gelöschte History/ehem. Quelltext) einsehen können“ ein und ergänzt Rævhuld als vorschlagende Person. Was meint ihr? — Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:53, 9. Jun. 2017 (CEST)

Jup, kann ich machen (wird aber wohl heute abend (spät) ... :) --ProloSozz (Diskussion) 17:18, 9. Jun. 2017 (CEST)

Durchgestrichen ... ich mach' das anders: es sollen beide Anträge portiert werden, aber in unterschiedlicher Ausführung; in diesem hier (dem einfachen) geht es nur um die Einsichtnahme alter Versionen; in meinem oben wird es um eine andere technische Herangehensweise gehen. --ProloSozz (Diskussion) 01:24, 10. Jun. 2017 (CEST)

Finde ich gut, würde aber per SLA gelöschte Artikel davon ausnehmen, bzw. anzeigen, dass dieser Artikel mal wegen SLA gelöscht wurde. (Impliziert i.d.R. Unsinn, POV, Werbung, ... und dürfte daher wenig sinnvolles Material beinhalten.) Daher nur gelöschte Artikel anzeigen lassen, die per LA/LD diskutiert und gelöscht wurden. Auch würde ich gelöschte Artikel nicht allen Benutzern gegenüber sichtbar machen, sondern z.B. nur allen Benutzern, die das aktive Sichterrecht haben. --Blik (Diskussion) 16:41, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Rævhuld (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 11:27, 19. Jun. 2017 (CEST) (bitte auch meinen erweiterten Vorschlag (mit automatischer Wiederherstellung der History) weiter oben beachten, danke)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:28, 19. Jun. 2017 (CEST)
4.  Pro --FNDE 15:40, 20. Jun. 2017 (CEST)
5.  Pro --Noobius2 (Diskussion) 16:05, 20. Jun. 2017 (CEST)
6.  Pro --Blik (Diskussion) 16:41, 20. Jun. 2017 (CEST)
7.  Pro --Holder (Diskussion) 20:06, 20. Jun. 2017 (CEST)
8.  Pro --Uranus95 (Diskussion) 10:18, 21. Jun. 2017 (CEST)
9.  Pro Michi 19:18, 21. Jun. 2017 (CEST)
10.  Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)
11.  Pro mauriceKA (Diskussion) 13:25, 23. Jun. 2017 (CEST)
    
    

Benutzersperren flexibler gestalten

Was ist das Problem?

Benutzer können entweder komplett oder gar nicht gesperrt werden, die einzigen Optionen hinsichtlich Flexibilität ist die Bearbeitbarkeit der eigenen BD. Dies wird den Anforderungen der Realität nicht gerecht, was bspw. Sperrprüfungen betrifft. Ein anderes Problem stellt ein Konflikt zweier Benutzer in einem Artikel, bspw. in einem Edit-War dar, der dazu führt, dass der Artikel für alle gesperrt werden muss. Missbrauchsfilter können diesen Anforderungen nicht gerecht werden, da sie nicht für die Anwendung im Tagesgeschäft geeignet sind.

Wen betrifft das Problem besonders?

Dieses Problem betrifft alle Benutzer, die aktiv mit Konfliktfällen in Berührung kommen.

Lösungsvorschlag

• T27400: Die Option, ob die BD bearbeitet werden darf, wird durch eine Option „Sperre gilt nicht für die Seiten“ ersetzt, wo eine durch Zeilenumbrüche getrennte Liste in einem Textfeld angegeben werden kann. Möglich ist dabei, darunter zusätzlich ein Dropdown einzufügen, in der mit Klick auf Einträge Seiten hinzugefügt oder entfernt werden können, die besonders häufig sind, zum Beispiel WP:SP und die eigene BD. Eine Alternative für diese häufigen Fälle wäre ein Standardwert für das Textfeld.
• T2674: Eine zusätzliche Option wird hinzugefügt, ähnlich der letzten, wo einzelne Seiten angegeben werden können, die der Benutzer nicht bearbeiten darf, um Konflikte im ANR zu deeskalieren. Dies würde die Grenzen zwischen Seitenschutz und Benutzersperre ein wenig verwischen lassen. Für mich persönlich hat das eine geringere Priorität als der erste Vorschlag, insbesondere da das eine deutliche Veränderung der Architektur und Idee der Benutzersperre mit sich führt, leicht durch dritte Parteien zu stören ist und besonders das auch bei dem nächsten Punkt auftretende Problem tangiert, dass so leicht mehrere „Benutzersperren“ mit verschiedenen Konditionen bspw. hinsichtlich Dauer benötigt werden. Hier habe ich noch keine Idee, wie das gelöst werden könnte. Zu beachten ist auch, dass Autoblock und ähnliche Funktionen in diesem Zusammenhang keinen Sinn mehr machen. Dies ließe sich vielleicht lösen, dass für eine vollständige Sperre (Status quo und erster Punkt) ein anderes Formular verwendet wird als für die „Quasisperren“ dieses und des nächsten Punktes. Bei näherer Betrachtung wäre vielleicht sogar eine vollständige Trennung beider zweckmäßig.
• T6995: Architekturtechnisch wahrscheinlich einfacher ist es, die Möglichkeit zu implementieren, dass eine Sperre nur für Uploads oder die E-Mail-Funktion gilt. Hier besteht aber ebenfalls von zuletzt genanntem Problem (in Konstellation mit „gewöhnlichen“ Benutzersperren, die zwischendurch für eine kürzere Zeitspanne festgelegt werden können, bspw.: Nach der Vollsperre des Nutzers würde bei der aktuellen Architektur der Upload/EmailUser schutz auslaufen). Die E-Mail ist dabei noch mal besonders gelagert, da sie aktuell gewöhnlich nicht mitgesperrt wird, das wäre bei einer Umsetzung zusätzlich zu beachten.
  Anmerkungen

Dieser Vorschlag erfordert vermutlich ein komplettes Refactoring der Benutzersperrfunktion. (T16636) Und die Vorlage kann nicht mit meinem Wunschformat umgehen.

Vorschlagende Person

MGChecker – (📞| 📝| ) 17:12, 30. Mai 2017 (CEST)

Diskussion

Sollte diese Art von Wunsch den Anforderungen, sich möglichst auf ein Problem zu bescheränken, nicht entsprechen, darf er gerne aufgeteilt werden. --MGChecker – (📞| 📝| ) 22:02, 30. Mai 2017 (CEST)

Unterstütz: als gesperrter Benutzer kann man von null komma plötzlich so gut wie gar nix mehr; v.a. können einem dann (unterschwellig) Dinge unterstellt werden, die nicht zutreffen. Es wäre wünschensert, wenn Sperren bei eizelnen "Editierproblemen" sehr gezielt ausgesprochen werden könnten. Dies sieht natürlich anders aus bei "Vandalisten-IPs" (mal überspitzt formuliert). Es wäre ggf. auch denkbar, dass in gewissen Bereichen (oder Benutzer-global) Sichtung notwendig sein würde. Missbrauch (d.h. etwas anderes als "zu Ende diskutieren der Probleme") würde dann zu einer "Komplettsperre" (ggf. ausser eigener Disk.Seite) führen. Wie das im Detail handzuhaben wäre, wäre zu diskutieren. Es ist jedoch unbefriedigend, wenn man über Umwege einen Dritten bemühen muss, z.B. eine Entschuldigung anzufügen o.ä. (man darf ja selbst nicht als IP etwas anfügen, da man sonst eine Sperrumgehung macht). Man könnte z.B. auch den gesamten ANR sperren, aber bei Diskussionen mehr als nur die eigene zulassen. Da aber LD o.ä. auch im ANR liegen, wären das näher zu betrachten. Ich bin nicht sicher, ob man auf eine VM noch etwas entgegnen kann; auch solche Überlegungen wären einzubeziehen, was noch möglich sein soll und was nicht. --ProloSozz (Diskussion) 12:27, 5. Jun. 2017 (CEST)

Die Sichtung hier mit einzubeziehen würde den Wunsch wohl deutlich verkomplizieren, zudem kann ich mir persönlich wenige Fälle vorstellen, wo das hilfreich wäre (falls doch, kann man Rechte entziehen). Die Sperre nach Namensraum kann man machen, ich habe das an dieser Stelle jedoch erstmal zurückgestellt. Ich glaube einfach nicht, dass es sonderlich produktiv und effektiv wäre, WPler selektiv aus dem ANR auszusperren. --MGChecker – (📞| 📝| ) 11:53, 6. Jun. 2017 (CEST)

Eine Sperre soll ja mehrere Dinge: zum einen die WP vor weiterem Schaden bewahren, zum anderen aber auch eine Saktion sein, und zudem dem Missetäter Zeit geben, sich über die verfehlten Aktionen Gedanken zu machen. Insofern haben Sperren durchaus ihre Berechtigung. Wenn diese aber differenziert ausfallen (wie wäre zu diskutieren), kann dem Missetäter auf eine etwas elegantere Weise die Möglichkeit gegeben werden, sein Tun in ein zutreffendes Licht zu rücken (sofern das sinnvoll und er dazu gewillt ist). Es soll aber in jedem Fall vermieden werden, dass weiter "Schaden angerichtet" wird. Eine Möglichkeit wäre, nicht nur gerade die eigene Diskussionsseite noch beschreibbar zu lassen, sondern auch jene Diskussionsseiten, an denen der User beteiligt war. Das bedingt natürlich, dass dieser sich a) an das seriöse Diskussionsniveau hält, und b) überhaupt eine Diskussionsbasis, die diskutiert werden kann, besteht. Das wird wohl nicht in allen Fällen gleich sein; und dass man Vandalen mal komplett aussperrt, wird auch weiterhin vorkommen. Jeder Fall ist natürlich einzeln anzugehen; es werden sich wohl gewisse Muster herausbilden, wie resp. was zu sperren ist. Sichtung war insofern gemeint, als man nicht gleich ganz sperren müssen sollte. Das wäre ein "Abfangen von weiteren Unflätigkeiten" zu verstehen gewesen; ich weiss aber nicht, ob das überhaupt praktikabel wäre. Grundproblematik ist: Sperren müssen sein; aber ob sie gleich komplett sein müssen (nur noch eig. Disk.Seite), und "wie differenzieren" sowie "wie umsetzen", ist doch hier die Frage ...--ProloSozz (Diskussion) 15:36, 6. Jun. 2017 (CEST)

Als einer, der mit dem momentanen Sperrprüf-Verfahren nicht sonderlich glücklich ist, will ich das Vorhaben hier gutgeheißen, und auf T119795, geschlossen als angebliches Duplikat zu T27400, hingewiesen haben. … «« Man77 »» (A) wie Autor 12:38, 5. Jun. 2017 (CEST)

Unterstützung

1.  Pro MGChecker (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 11:28, 19. Jun. 2017 (CEST) Benutzer sollten je nach "schwere des Falls" differnziert gesperrt werden (können)
3.  Pro DCB (Diskussion • Bewertung) 22:25, 19. Jun. 2017 (CEST)
4.  Pro -- X:: black ::X (Diskussion) 09:05, 20. Jun. 2017 (CEST)
5.  Pro--grim (Diskussion) 15:42, 20. Jun. 2017 (CEST)
6.  Pro --FNDE 15:43, 20. Jun. 2017 (CEST)
7.  Pro Michi 19:19, 21. Jun. 2017 (CEST)
8.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:29, 22. Jun. 2017 (CEST)
9.  Pro … «« Man77 »» (A) wie Autor 21:16, 22. Jun. 2017 (CEST)
10.  Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)
11.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
12. 
    
    

Überarbeite das Prinzip privater Missbrauchsfilter

Was ist das Problem?

Private Missbrauchsfilter sind sehr intransparent für Nicht-Admins. Nicht-Admins ist es nicht möglich, nachvollziehen, zu welchen Zeitpunkten ein Filter, der unter bestimmten Bedingungen anschlägt, beispielsweise von Loggen auf Verbieten geschaltet wurde – was einen massiven Einschnitt bedeutet – und wer dafür verantwortlich ist. Das ist intransparent für den Rest der Community, da so auch problemlos einschneidende Verschärfungen an privaten Missbrauchsfiltern vorgenommen werden können, ohne dass es einem Nicht-Admin auffallen oder dieser es nachvollziehen kann.

Wen betrifft das Problem besonders?

Alle Nicht-Admins, die Interesse an privaten Missbrauchsfilter haben.

Lösungsvorschlag

Während die Bedingungen für den Filter bei privaten MBFs geheim bleiben müssen, ist dies für die Aktionen (Loggen, Verwarnen, Sperren, nicht das Log) nicht der Fall: Sie stehen bereits in der Übersicht und können auch im Detail problemlos angezeigt werden. Selbiges gilt für die Versionsgeschichte der Filter (ohne die Diffs selbstverständlich), wobei ich mir an der Stelle unsicher bin, ob sich da nicht irgendwie doch vereinzelt eigentlich private Daten einschleichen können; ich glaube aber das ist nicht der Fall. Sollte das doch der Fall sein, ließe sich das damit einhergehende Problem über ein neues Recht abusefilter-history-private umgehen. Gerade die Versionsgeschichte ist von sehr großem Wert für Nicht-Admins, die die Vorgänge in diesem Bereich nachvollziehen wollen, gerade falls die Aktionen des Filters strenger eingestellt wurden.

Anmerkungen

Daran kann WMDE nichts ändern, aber ebenfalls hilfreich wäre, um ABFs stärker zur Vandalismusbekämpfung einsetzen zu können, Sichtern das Recht abusefilter-log-private zuzuweisen, mit denen die Treffer der Filter von Sichtern bearbeitet werden können. Einen bereits existenter Workaround dafür stellt allerdings die Option dar, Tags mit MBFs zu setzen, daher stellt das kein großes Problem dar.

Vorschlagende Person

MGChecker – (📞| 📝| ) 17:27, 30. Mai 2017 (CEST)

Diskussion

@MGChecker: Hallo und danke für deinen Wunsch! Ich bin noch nicht sicher, ob ich das Problem richtig verstanden habe. Könntest du unter „Was ist das Problem?“ noch mal ausführlicher die Situation schildern, in der das Problem auftritt?

• Wann nutzt du private Missbrauchsfilter und warum? (Z. B. „Ich als Autor nutze private Missbrauchsfilter, um ...“)
• Wie gehst du vor und wo kommst du an ein Problem?
• Was konkret ist intransparent?

Danke und viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:12, 9. Jun. 2017 (CEST)

Ich konkret habe kein Problem, aber habe in Verbindung verschiedener Konfliktfälle mit Beteiligung von Missbrauchsfiltern von diesem Problem gehört. Nicht-Admins ist es nicht möglich, nachvollziehen, zu welchen Zeitpunkten ein Filter, der unter bestimmten Bedingungen anschlägt, beispielsweise von Loggen auf Verbieten geschaltet wurde – was einen massiven Einschnitt bedeutet – und wer dafür verantwortlich ist. Das ist intransparent für den Rest der Community, da so auch problemlos einschneidende Verschärfungen an privaten Missbrauchsfiltern vorgenommen werden können, ohne dass es einem Nicht-Admin auffallen oder dieser es nachvollziehen kann. --MGChecker – (📞| 📝| ) 01:13, 10. Jun. 2017 (CEST)

@MGChecker: Vielen Dank! Ich war so frei, das oben unter „Was ist das Problem?“ zu ergänzen, weil die Diskussionen mit Beginn der Abstimmung (19. Juni) ausgeblendet werden. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:24, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro MGChecker (Einreichende Person)
2. 
   
   

Kategorisierung automatisieren

Was ist das Problem?

Es ist ziemlich kompliziert Kategorien hinzuzufügen. Erst einmal muss man herausfinden welche Kategorien benutzt werden. Dann muss man herausfinden welche Kategorien nur eine Weiterleitung sind. Und dann muss man noch herausfinden, ob man die Hauptkategorie oder eine Unterkategorie nehmen muss.

Wen betrifft das Problem besonders?

Bearbeiter.

Lösungsvorschlag

Teilautomatisierung. Also ein intelligenter Algorithmus unterstützt bei dem Kategorievorschlag.

Ok, ich habe keinen Plan. Aber ich finde schon, dass es etwas ist, womit es Probleme gibt!

Vorschlagende Person

Rævhuld (Diskussion) 00:00, 31. Mai 2017 (CEST)

Diskussion

Eine mögliche Lösung wäre über Wikidata zu schauen, welche Kategorien der Artikel in anderen Sprachversionen hat und diese Kategorien, wenn sie auf der deutschen Wikipedia vorhanden sind, dem Nutzer anzubieten. ChristianKl (Diskussion) 12:44, 7. Jun. 2017 (CEST) Hab mal deinen Beitrag in die Diskussion verschoben. VG --Charlie Kritschmar (WMDE) (Diskussion)

Eine noch bessere Lösung wäre manche Wikidata-Daten als Kategorien zu übernehmen.--Avron (Diskussion) 17:24, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Rævhuld (Einreichende Person)
2.  Pro --FNDE 15:44, 20. Jun. 2017 (CEST)
3.  Pro--grim (Diskussion) 15:47, 20. Jun. 2017 (CEST)# (Klassisches Machine learning. Kommt vllt. in 20-30 Jahren.)
4.  Pro --Noobius2 (Diskussion) 16:07, 20. Jun. 2017 (CEST)
5.  Kontra --Aristeas (Diskussion) 17:51, 20. Jun. 2017 (CEST) Sorry, aber das halte ich (beim derzeitigen Stand der Technik) für zu gefährlich, sprich, ich fürchte, dass viele falsche Kategorien hinzugefügt würden. Wenn 10% aller automatisch hinzugefügten Kategorien falsch wären, wäre das mMn schon zuviel.
6.  Kontra was automatisiert werden kann, wird schon z.B. über Vorlagen oder Infoboxen gemacht. Für alles andere braucht es Verstand und keine Automatisierung bei der Kategorisierung. --Orci Disk 22:41, 20. Jun. 2017 (CEST)
7.  Kontra --Furfur ^{⁂ Diskussion} 23:35, 21. Jun. 2017 (CEST) Ich kann mir nicht vorstellen, wie eine solche automatische Kategorisierung ablaufen sollte. Wie soll denn die MediaWiki-Software z. B. bei einem Biografieartikel erkennen, dass es sich um einen Politiker, einen Kriminellen, einen Künstler handelt, der z. B. Mitglied einer bestimmten Partei ist, der ein Trickbetrüger ist, oder der Musiker der Barockzeit ist? Es reicht ja nicht aus, die entsprechenden Attribute im Text zu suchen, es spielt ja auch der Sinnzusammenhang eine Rolle, in dem sie auftauchen. So etwas leistet keine Software wirklich zuverlässig.
8.  Kontra Möglicherweise nicht realisierbar. --Suriyaa Kudo · Archiv (Diskussion) 13:33, 22. Jun. 2017 (CEST)
   
   

Cat-a-lot in der Wikipedia

Was ist das Problem?

Wenn größere Artikelbestände von einer Kategorie in eine andere verschoben oder kopiert oder aus einer Kategorie entfernt werden sollen, muss dazu jeder Artikel geöffnet, angeschaut und bearbeitet werden. Dies ist bei der Masse der Artikelbestände und bei großen Kategorien eine mühselige "Schimpansenarbeit".

Wen betrifft das Problem besonders?

Autoren, Beobachtungslisten zumüllende Katschubser

Lösungsvorschlag

Schaffung eines Tools ähnlich wie Cat-a-Lot auf Commons für Wikipida

Vorschlagende Person

 ^Thomas 11:19, 31. Mai 2017 (CEST)

Diskussion

Cat-a-lot ist per persönlicher common.js schon jetzt mit

window.catALotPrefs = {editpages:  true};
mw.loader.using(['jquery.ui.resizable', 'mediawiki.util', 'jquery.mwExtension'], function(){
 importScriptURI('//commons.wikimedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-Cat-a-lot.js');
 importStylesheetURI('//commons.wikimedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki:Gadget-Cat-a-lot.css');
});

auch hier zum Kategorisieren von Artikeln verwendbar. – KPFC 💬 19:41, 31. Mai 2017 (CEST)

Die "Schimpansenarbeit" habe ich bisher TaxonKatBot erledigen lassen. Es wäre aber wirklich gut, diese Funktionalität in Wikipedia als aktivierbares Helferlein zu haben. In der Zwischenzeit versuche ich mal das obige js, danke für die Info. --bjs 22:13, 1. Jun. 2017 (CEST)

@KPFC: importScriptURI() und importStylesheetURI() sind seit über 2 Jahren veraltet, vgl. Wikipedia:Technik/Skin/JS/Obsolet#Einbindungen, Sie gehören aber zu den wenigen Überresten von wikibits, die noch nicht deaktiviert wurden. — Speravir – 00:41, 11. Jun. 2017 (CEST)

Oh, ok. Danke für die Information. Hab das irgendwann mal von irgendwo kopiert, such grade aber wo. -- KPFC 💬 01:47, 11. Jun. 2017 (CEST)

Häh? Cat-a-lot funktioniert auf Commons doch nur für Dateien, aber nicht für Artikel?! Das würde uns auf de.wikipedia wenig nützen. Man müsste die Funktionalität auf Artikel erweitern.

Noch was: In der Vergangenheit hat sich das Kategorien-Projekt wegen der Gefahr des Missbrauches bewusst gegen die Möglichkeit von Massen-Umkategorisierungen gewandt; stattdessen wurde TaxonKatBot für solche Fälle aktiviert. --TETRIS L 11:26, 21. Jun. 2017 (CEST)

Falls man so was einführt, bin ich dafür, dass man Änderungen die nur die Kategorien betreffen 1)in der Beobachtungsliste ausblenden kann 2)kein E-Mail bekommt (bzw. einstellen kann), wenn man die E-Mail-Funktion für beobachtete Seiten aktiviert hat. 3)Ich finde solche Edits sollten nicht zum Editcount zählen, weil sie Erfahrung vortäuschen bzw. schnelle Sichterrechte/Stimmberechtigung ermöglichen.  — Johannes Kalliauer - Diskussion | Beiträge 18:29, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:27, 19. Jun. 2017 (CEST)
3.  Pro -- X:: black ::X (Diskussion) 12:29, 19. Jun. 2017 (CEST)
4.  Pro --Aristeas (Diskussion) 17:45, 20. Jun. 2017 (CEST)
5.  Pro --  Sir Gawain Disk. 20:38, 20. Jun. 2017 (CEST)
6. 
   
   

"Diff" über viele Versionen

Was ist das Problem?

Wenn ich auf high-traffic-Diskussionsseiten nach 48 oder mehr Stunden Abwesenheit alle Änderungen abrufen will, ist das aus mehreren Gründen umständlich. a) Bei mehr als 50 Edits in der Zwischenzeit muss ich in der Versionsgeschichte auf tieferen Seiten die Version meines letzten Aufrufs suchen. b) In der Diff-Anzeige witd nur die rechte Hälfte des Bildschirms genutzt, um die neuen Beiträge anzuzeigen.

Wen betrifft das Problem besonders?

Alle Leser von High-Traffic-Diskseiten, Admins

Lösungsvorschlag

Es gibt bereits ein Snark-Tool, das Diffs in einer Spalte mittels Farbcode darstellt. Wirklich wichtig wäre deshalb ein Link im Kopf der Versionsgeschichte, mit dem man automatisch den Diff seit der letzten aufgerufenen Version anklicken kann.

Vorschlagende Person

h-stt !? 21:54, 1. Jun. 2017 (CEST)

Diskussion

Das gibt es schon: Du musst in Deiner eigenen Bearbeitungsliste beim entsprechenden Edit auf "Versionen" (vor den Anzahl Zeichen) gehen (und nicht auf den bearbeiteten Artikel selbst); damit kommst Du in die Versionsgeschichte, und alle Bearbeitungen seit Deinem letzten Besuch werden farblich gekennzeichnet. --ProloSozz (Diskussion) 12:39, 5. Jun. 2017 (CEST)

@ProloSozz: das Problem bestand darin, dass wenn es viele Versionen seit dem letzten Besuch gibt, man weit runter scrollen und sich durch mehrere Seite der Versionsgeschichte durchklicken muss, bis man die letzten farblich gekennzeichnete Version findet. Gewünscht wurde ein Link, der immer auf den Unterschied Versionen des des letzten Besuch → aktueller Version verweist. (So hatte ich dies zumindest bei Tech-on-Tour verstanden). -- Michael Schönitzer (WMDE) (Diskussion) 16:24, 5. Jun. 2017 (CEST)

Danke für die Klarstellung, was gemeint ist und was nicht (resp. was schon vorhanden ist und was noch gewünscht ist) ... :) --ProloSozz (Diskussion) 23:48, 5. Jun. 2017 (CEST)

Unterstützung

1.  Pro H-stt (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 13:17, 19. Jun. 2017 (CEST)
3.  Pro @Ziko:(nicht signierter Beitrag von Ziko (Diskussion | Beiträge) 16:27, 21. Jun. 2017‎)
4.  Pro -- Freddy2001 ^DISK 12:04, 24. Jun. 2017 (CEST)
   
   

Ausnahmen von der Throttle für Account-Anmeldungen pro IP

Was ist das Problem?

Bei Editathlons müssen oft viele User hinter einer IP neue Accounts anmelden

Wen betrifft das Problem besonders?

Editathlon-Orgas, Admins

Lösungsvorschlag

Neues Benutzerrecht: IP-Throttle exempt, das von jedem Admin temporär vergeben werden kann.

Vorschlagende Person

h-stt !? 22:20, 1. Jun. 2017 (CEST)

Diskussion

@H-stt: Wahrscheinlich suchst du Limit-Ausgenommene/Benutzerkonten-Ersteller (noratelimit). Kann dir ein Bürokrat geben: "Darüber hinaus können Bürokraten nach einem Antrag auf den Adminanfragen Limit-Ausgenommener-Rechte an Benutzer erteilen." Zur massenhaften Account-Erstellung siehe auch: mediawikiwiki:Help:Mass account creation. -- Reise Reise (Diskussion) 12:13, 11. Jun. 2017 (CEST)

Nein, das meine ich nicht. Ich bin Admin, ich kann auf einem Editathlon beliebig viele Accounts für andere anlegen. Aber ich kann nicht die IP des Veranstaltungsorts für 24 von der Anmelde-Begrenzung freischalten, damit sich die Teilnehmer selbst anmelden können. Das will ich aber können und nicht nur für mich und Admins, sondern ich will dieses Recht auch noch jedem anderen Benutzer temporär übertragen können. Grüße --h-stt !? 18:29, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro H-stt (Einreichende Person)
2.  Pro --FNDE 15:47, 20. Jun. 2017 (CEST) macht Sinn
3.  Pro Michi 19:19, 21. Jun. 2017 (CEST)
4.  Pro -- Freddy2001 ^DISK 12:04, 24. Jun. 2017 (CEST)
   
   

WP:Templatetiger wieder nutzbar machen

Was ist das Problem?

Die Datengrundlage von Templatetiger (im Folgenden: TT) wird seit Dezember 2015 nicht mehr aktualisiert (siehe [1]), bei anderen Sprachen/Projekten scheint das monatlich zu funktionieren, bei deWP offensichtlich trotz aller Bemühungen des Maintainers, Benutzer:Kolossos, nicht.

Ganz abgesehen davon sollte mM ein Tool wie TT eigentlich zur Core-Funktionalität der MediaWiki-Software gehören und auch nicht auf Dumps, sondern auf Live-Daten aufbauen.

Wen betrifft das Problem besonders?

Alle Benutzer, die Vorlagen für welche Zwecke auch immer auswerten wollen

Lösungsvorschlag

Im ersten Schritt Kolossos einen aktuellen Dump und dann in regelmäßigen Abständen neue Dumps zur Verfügung stellen, mittelfristig auf tagesaktuelle oder Live-Daten umstellen und/oder als Funktion in MW integrieren

Vorschlagende Person

Mabschaaf 12:48, 2. Jun. 2017 (CEST)

Diskussion

• Ich begrüße die Anregung von Mabschaaf, und Kolossos, der ja angepingt sein müsste und sonst direkt zu kontaktieren wäre, möge sich äußern, ob eine externe Hilfe überhaupt möglich wäre, und inwieweit die datengenerierende Software portabel ist, auf privater lokaler Hardware läuft oder innerhalb der LabsTools. Bis auf die sehr großen enWP und deWP gibt es häufgere Updates; könnte ein Ressourcenproblem sein.
• Die generelle zeitnahe Vorlagenauswertung (Direkteinbindung im Haupt-/Inhaltsnamensraum; sind ja auch Milliarden von Untervorlagen und andere Beteiligte mit aktuellen Parameterwerten) ist aus Performancegründen kaum live zu erreichen, aber vielleicht synchronisiert mit dem Dump-Zyklus für alle Wikis. Wäre ein eigenes neues Labs-Projekt. So sekundenaktuell genau braucht selbst die Vorlagenwerkstatt diese Infos nicht; aber monatlich wäre schon nett.
  • Dabei bitte die #invoke mit ihren Parametern im Hinterkopf behalten; wobei die bei uns nicht im Hauptnamensraum vorkommen.

LG --PerfektesChaos 15:20, 2. Jun. 2017 (CEST)

Siehe auch Wikipedia:Umfragen/Technische Wünsche 2017/Suchen#Suche bestimmter Werte in Vorlagen ermöglichen. Nicht ganz das selbe, aber je nach Einsatzzweck eine adäquate Alternative. –Schnark 09:30, 3. Jun. 2017 (CEST)

PS: Ich sehe gerade, dass der Vorschlagende diesen Hinweis ganz bestimmt nicht braucht, aber als Anmerkung für die Allgemeinheit lasse ich es trotzdem stehen. –Schnark 09:32, 3. Jun. 2017 (CEST)

Hab grad denselben Wunsch nochmal gepostet, ich "merge" ihn nun hierher.

Problem: Der Templatetiger ist bzw. wäre das Werkzeug, das einem die Möglichkeit bietet nachzuschauen, wie eine Vorlage eigentlich in der Wiki-Realität verwendet wird (z.B. welche Parameter wo und wie gesetzt werden). Das Problem dabei ist, dass die Daten, die im Templatetiger abrufbar sind, nicht aktuell sind (momentan sind sie vom Dezember 2015!). Bei Vorlagen-Umprogrammierungen ist es jedoch oft unabdingbar, aktuelle Daten auszuwerten, um entweder die Vorlage so umzuschreiben, dass die bisherigen Anwendungsfälle auch in Zukunft so funktionieren, oder um diejenigen Vorlageneinbindungen aufzustöbern, die im Zuge der Umprogrammierung im Artikel verändert werden müssen. (Zugegebenmaßen gibt es einen schmutzigen Hack, um an aktuelle Daten zu kommen.)

Zusätzlich scheint es mir wünschenswert, dem Tiger ein Interface zu verpassen, das einem Nutzer das Herummanipulieren direkt in der URL gemäß Wikipedia:Technik/Labs/Tools/templatetiger#URL-Parameter erspart.

Vorschlag: Laut Benutzer:Kolossos, der den Templatetiger entwickelt hat, gibt es ein Problem bei der Beschaffung des nötigen Dumps. Wenn man dumptechnisch zu einer Lösung kommt, wär Teilwunsch 1 nahezu erledigt (Daten zwar nicht live, aber "liver"). Die Lösung zu Teilwunsch 2 stelle ich mir in meinen Träumen ähnlich vor wie das Petscan-Formular.

Anmerkungen:

• Phabricator – Bug/Feature: 120767
• entspricht in nicht unwesentlichem Ausmaß einem meiner Wünsche aus 2013 und 2015

… «« Man77 »» (A) wie Autor 19:18, 3. Jun. 2017 (CEST)

Das Problem für den dt. Dump besteht in Benutzer_Diskussion:PerfektesChaos/Archiv5#Vorlage:NaturGeoTabelle_DE.2FZeile. Ich nutze für den Templatetiger halt die Vorarbeit des checkwiki von User:BGWhite. An Monsterartikeln wie Liste_der_Geotope_im_Landkreis_Bayreuth hängt sich halt das Pearl-Skript auf, wobei das wohl hauptsächlich auf die Verwendung von Variablen zurückzuführen zu sein scheint. Wenn man das also lösen könnte und mit Entwickler wie BgWhite nicht mit unfreundlichem Ton wieder vergrault, könnte es klappen mit dem dt. Dump.

Der engliche Dump ist wirklich eine Größenordnung heftiger. Da bräuchte ich wohl etwas wie Vorsortierung, wobei ich damit Probleme in der Cloud habe https://phabricator.wikimedia.org/T124822 . Eine Lösung dafür könnte auch recht sinnvoll sein, auch weil man von der engl. WP ganz gut dann Wikidata füttern könnte. --Kolossos 21:53, 3. Jun. 2017 (CEST)

(P.S.: Der PHP-Code des Templatetigers ist aus meiner heutigen Sicht ziemlich schrecklich und ich würde ihn gerne mit Python/Pandas mal neuschreiben [2]. Ich sehe aber nicht, dass ich dazu mal Zeit haben werde. --Kolossos 22:04, 3. Jun. 2017 (CEST))

Unterstützung

1.  Pro Mabschaaf (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 15:28, 19. Jun. 2017 (CEST)
3.  Pro тнояsтеn ⇔ 12:47, 20. Jun. 2017 (CEST)
4.  Pro … «« Man77 »» (A) wie Autor 14:07, 20. Jun. 2017 (CEST)
5.  Pro --Horgner (Diskussion) 14:19, 20. Jun. 2017 (CEST)
6.  Pro –Queryzo ?! 14:46, 20. Jun. 2017 (CEST)
7.  Pro --XanonymusX (Diskussion) 14:59, 20. Jun. 2017 (CEST)
8.  Pro DCB (Diskussion • Bewertung) 15:19, 20. Jun. 2017 (CEST)
9.  Pro --PerfektesChaos 23:31, 20. Jun. 2017 (CEST)
   
   

Whitelist für Weblinks in Kommentaren von Edits und Logbucheinträgen

Was ist das Problem?

In den Kommentaren von Bearbeitungen und Einträgen in den Logbüchern sind ausschließlich Links in der Form [[…]] erlaubt, um Spam zu vermeiden. Leider schließt das auch Links wie https://de.wikipedia.org/w/index.php?title=Wikipedia:Umfragen/Technische_Wünsche_2017/Wartung&action=history aus.

Wen betrifft das Problem besonders?

Benutzer, die sich mit der Versionsgeschichte und/oder den Logbüchern beschäftigen

Lösungsvorschlag

Es sollte eine globale Whitelist – optional mit der Möglichkeit von lokalen Ergänzungen – geben, auf der zumindest folgende Domains stehen:

• *.wikimedia.org
• *.wikipedia.org
• *.wikiquote.org
• *.wikibooks.org
• *.wikiversity.org
• *.wiktionary.org
• *.wikinews.org
• *.wikisource.org
• *.wikivoyage.org
• *.wikispecies.org
• *.wikidata.org
  Anmerkungen

 

Vorschlagende Person

Morten Haan 🍱 Wikipedia ist für Leser da • Skin-Entwurf 18:00, 2. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Morten Haan (Einreichende Person)
2.  Pro --FNDE 15:49, 20. Jun. 2017 (CEST)
3. 
   
   

Fehlkategorisierung durch #ifexist-Bug

Was ist das Problem?

Auf Spezial:Linkliste werden störenderweise auch Seiten aufgelistet, die Vorlagen enthalten, die #ifexist verwenden.

Wen betrifft das Problem besonders?

Lösungsvorschlag

Zusätzliche Funktion neben "Vorlageneinbindungen verbergen | Links verbergen | Weiterleitungen verbergen" auf Spezial:Linkliste

Anmerkungen

• Phabricator – Bug/Feature: 14019
  Vorschlagende Person

… «« Man77 »» (A) wie Autor 19:29, 3. Jun. 2017 (CEST)

Diskussion

Es gibt zahlreiche Tools, die die Linkliste auswerten (u.a. Missing Topic Tool und das Petscan-Tool). Wenn diese beispielsweise die Verlinkung Spezial:Linkliste/Autonome Gemeinschaft Aragonien überprüfen, so bekommen sie über 200 fehlende Links auf Autonome Gemeinschaft Aragonien heraus. Nur ... in den Artikel in denen angeblich der Rotlink stehen soll, steht dieser nicht. Siehe Beispiel Arrés. Leider ist der Lösungsvorschlag #1 oben nicht zielführend. Vielleicht ist es besser die Funktion #ifexist zu deaktivieren bis der Fehler behoben ist. --Atamari (Diskussion) 00:27, 5. Jun. 2017 (CEST)

@Man77: Hallo, ein kleiner Hinweis: Bei der Abstimmung (ab 19. Juni) wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird. Wenn die Hinweise in der Diskussion für deinen Wunsch hilfreich sind, wäre es wichtig, dass du sie oben – z. B. unter „Lösungsvorschlag“ – ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:54, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Man77 (Einreichende Person)
2.  Pro --Atamari (Diskussion) 12:28, 19. Jun. 2017 (CEST)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:30, 19. Jun. 2017 (CEST)
4.  Pro –Queryzo ?! 22:39, 20. Jun. 2017 (CEST)
5.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
   
   

Werkzeug zum Auffinden fehlerhaft gesetzter Koordinaten

Was ist das Problem?

Alleine diese Sprachversion der Wikipedia hat mehrere hunderttausend Koordinaten in ihren Artikeln eingebunden, aber fehlerhaft gesetzte Koordinaten lassen sich nur mit Zufall finden. Es gibt Hilfsmittel, um formal unplausible Koordinaten (zB. 87 Bogensekunden) oder nicht definierte Regions-Codes (zB. DE-MUC) zu finden, aber damit hat es sich auch schon. Sind Koordinaten "nur" um 100 km daneben, aber formal in Ordnung, fällt das mitunter jahrelang keinem auf.

Ich wünsche mir, dass mithilfe der der Verknüpfungen zwischen Openstreetmap (OSM) und dem Wikipedia-Universum Koordinaten auffindbar werden, die nicht in der Region liegen, in der sie laut region-Parameter liegen müssten (Szenario A). In einem weiteren Schritt könnten mithilfe von Wikidata-Informationen auch "Ausreißer" auf tieferen Verwaltungsstufen gefunden werden (Szenario B). Damit ließen sich nicht alle fehlerhaften Koordinaten finden, aber zumindest ein Teil.

Wen betrifft das Problem besonders?

Nachnutzer, die sich auf unsere Koordinaten verlassen

Lösungsvorschlag

Ich fürchte, das ist Zukunftsmusik, und ich weiß ehrlich gesagt nicht, wie gut Daten aus OSM für Bots und Tools und co abgreifbar sind. Aber mal als Gedankenexperiment für Szenario A:

• Beispielartikel Estadio Nacional de Chile, gelegen laut Vorlagenparameter in der Región Metropolitana de Santiago (CL-RM)
• Navigation nach Openstreetmap zur im Artikel hinterlegten Koordinate: [3]
• Dort kann Mensch, wenn er dem Browser das Ausführen von Skripten erlaubt, rechts auf ein Fragezeichen klicken, dann auf die fragliche Stelle auf der Karte, und man bekommt eine Liste "Umschließende Objekte".
• man geht die einzelnen Treffer durch, beim Treffer "Región Metropolitana de Santiago" ([4]) ist eingetragen als Wert für ISO3166-2 "CL-RM".
• Ergebnis der Prüfung: Koordinate ist plausibel.

Szenario B:

• Beispielartikel Estadio Nacional de Chile, gelegen laut Wikidata-Item Q594994 in der Verwaltungseinheit Q201076 (Ñuñoa)
• Schritt 2 und 3 wie bei Szenario A
• Suche nach einem Treffer bei "umschließende Objekte", bei dem als Wikidata-ID eben jenes Q201076 hinterlegt ist: Fund bei [5]
• Ergebnis: Daten sind plausibel.

Nicht unproblematisch ist, dass diese Verknüpfungen noch lange nicht überall vorhanden sind. Es wäre aber sehr toll, wenn eine solche Prüfung dort möglich wäre, wo die nötigen Daten vorhanden sind, und dass sich daraus Fehlerlisten generieren lassen.

Vorschlagende Person

… «« Man77 »» (A) wie Autor 20:07, 3. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Man77 (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:07, 19. Jun. 2017 (CEST)
3.  Pro тнояsтеn ⇔ 12:54, 20. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 15:20, 20. Jun. 2017 (CEST)
5.  Pro --Noobius2 (Diskussion) 16:08, 20. Jun. 2017 (CEST)
6.  Pro --Claell (Diskussion) 19:24, 20. Jun. 2017 (CEST)
7.  Pro --Kenny McFly (Diskussion) 19:48, 21. Jun. 2017 (CEST)
   
   

Editiermöglichkeit bei noch nicht gesichteten Versionen, ohne alles sichten zu müssen

Was ist das Problem?

Besteht eine noch nicht gesichtete Version eines Artikels, so kann erst dann sinnvoll weiter (resp. etwas von den ungesichteten Teilen nicht betroffenes) editiert werden, wenn die ungesichtete Version zuerst gesichtet wird. Manchmal will man aber keine Sichtung durchführen (und diese anderen überlassen). In solchen Fällen sollte es möglich sein, eine weitere Änderung anzufügen, die entweder auch ungesichtet bleibt, oder dann zwar als "von einem Sichter geschrieben" gekennzeichnet ist, aber dann erst nach der Sichtung der zuvor ungesichteten Bereiche erscheint; oder sie erscheint sofort und die ungesichteten Änderungen bleiben ungesichtet.

Wen betrifft das Problem besonders?

Sichter (mit automatischen Sichterrechten)

Lösungsvorschlag

Temporär (für den zu bearbeitenden Artikel) Sichterrechte abschalten wäre eine Möglichkeit (das eröffnet aber dann keine als "von Sichter geschriebene" Anfügungen, die nach Sichtung automatisch hervortreten würden).

Anmerkungen

Mir ist klar, dass damit ggf. "Verwerfungen in der Gesamthistory" entstehen könnten, wenn ungesichtete Änderungen verworfen würden. Wie dies ggf. zu vermeiden ist, wäre zu klären.

Vorschlagende Person

ProloSozz (Diskussion) 12:57, 5. Jun. 2017 (CEST)

Diskussion

NB: in ein ähnliches Kapitel fallen Probleme, wenn man die letzte (ungesichtete) Änderung nicht so umsetzen will, wie das geschrieben wurde. Man muss dann die Version sichten, obwohl man das eigentlich nicht will, und dann gleich fast alles (abgesezen von den springenden Details) wieder auf die vorangegangene Version zurückeditieren. Besonders mühsam ist das, wenn mehrere Versionen ungesichtet sind, von denen man aber nicht alle sichten will. Dazwischenliegende zu verwerfen, wenn danach noch welche kommen, die "sichtbar" wären, ist auch nicht wirklich möglich. --ProloSozz (Diskussion) 12:57, 5. Jun. 2017 (CEST)

@ProloSozz: Sicherheitshalber der Hinweis: Bei der Abstimmung (ab 19. Juni) wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird. Wenn deine Ergänzung für deinen Wunsch wichtig ist, solltest du sie oben beim Wunsch selbst noch ergänzen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:58, 8. Jun. 2017 (CEST)

Du meinst, als separaten Wunsch noch einreichen? Ich ging davon aus, dass das ein Teil des Themas hier ist und dann nur bei der Umsetzung zu berücksichtigen wäre ... Ich schaue mir das aber nochmal genauer an. Danke für den Hinweis ... :) --ProloSozz (Diskussion) 11:01, 9. Jun. 2017 (CEST)

@ProloSozz: Meiner Meinung nach kannst du das schon hier in diesem Wunsch unterbringen, aber eben nicht in der Diskussion, sondern z. B. unter „Was ist das Problem?“, denn die Diskussion wird bald ausgeblendet und dann sehen die Abstimmenden deine Ergänzung nicht mehr. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 11:05, 9. Jun. 2017 (CEST)

Ich verstehe das Problem nicht. Man kann doch ohne weiteres ungesichtete Artikel weiter bearbeiten. --тнояsтеn ⇔ 12:56, 20. Jun. 2017 (CEST)

Aber die Änderungen werden erst dann angezeigt, wenn alle Änderungen gesichtet wurden. --Blik (Diskussion) 16:44, 20. Jun. 2017 (CEST)

Ich denke technisch könnte es machbar sein, wenn die neue Änderung in einem anderen Abschnitt ist, als die zu sichtende Änderung. Ich schätze den Aufwand als ziemlich groß; ob sich das wirklich lohnt? Die heutige Lösung hat sogar etwas gutes, sie zwingt einen Autor mit Sichterrechten dazu sich mit den Änderungen zu befassen und so bleiben weniger zu sichtende Änderungen übrig.--Avron (Diskussion) 18:59, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:10, 19. Jun. 2017 (CEST)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:31, 19. Jun. 2017 (CEST)
4.  Pro --Blik (Diskussion) 16:44, 20. Jun. 2017 (CEST)
5.  Pro --Claell (Diskussion) 19:25, 20. Jun. 2017 (CEST)
6.  Pro mauriceKA (Diskussion) 13:28, 23. Jun. 2017 (CEST)
7.  Kontra -- Nichtich (Diskussion) 23:08, 23. Jun. 2017 (CEST)
8. 
   
   

Zusammenfassungszeile (mit hohen Hürden) nachträglich editierbar machen

Was ist das Problem?

Es kommt immer wieder mal vor, daß man in der Eile irgendwelche Fehler in der Zusammenfassungszeile hinterläßt. Diese sollten bereinigt werden können.

Wen betrifft das Problem besonders?

Prinzipiell zwar alle, die beim editieren etwas in der Zusammenfassungszeile hinterlassen (und das sollten eigentlich alle Schreiberlinge sein); im Detail aber v.a. jene, die dort vielleicht unachtsam sind, oder bei denen sich im nachhinein herausstellt, daß da etws nicht ganz so hinterlassen wurde, wie es hätte sein sollen ...

Lösungsvorschlag

Zusammenfassungszeilen sollten nachträglich korrigierbar sein; womöglich mit Admingenehmigung auf einer separaten Seite, wo man so einen Änderungswunsch anmelden müßte (vom Abarbeitungsprozedere wie bei SLAs: Wunsch eintragen, und ein Admin setzt das dann um. Falls der abarbeitende Admin die Änderung nicht für sinnvoll oder angebracht hält, kann er sie auch zurückweisen; ggf. zur Nachbearbeitung). Es soll in der Zusammenfassungszeile nachträglich nicht beliebig herumgeschreibselt werden können (d.h. die Hürden müssen erheblich sein, sonst könnte das ausarten); es sollte aber dennoch für "Normalsterbliche" nicht (so gut wie) unmöglich sein.

Anmerkungen

Zusammenfassungszeilen sollen statisch bleiben und eigentlich nicht geändert werden – manchmal wäre es aber dennoch sinnvoll, eine (kleine) Änderung anbringen zu können.

Vorschlagende Person

ProloSozz (Diskussion) 10:00, 6. Jun. 2017 (CEST)

Diskussion

Hallo ProloSozz, nur um nochmal sicherzugehen, ist mit der Statuszeile die Zusammenfassungszeile gemeint? Wenn ja, würde ich vorschlagen das in einem Wunsch anzupassen, damit keine Missverständnisse entstehen. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 12:50, 7. Jun. 2017 (CEST)

Jup, danke für den Hinweis; ist nachgetragen ... :) --ProloSozz (Diskussion) 13:20, 7. Jun. 2017 (CEST)

Hallo ProloSozz, wir haben im Team über diesen Wunsch gesprochen, mit dem Ergebnis, dass er den Rahmen des Projekts „Technische Wünsche“ übersteigt: Änderungen an der Zusammenfassungszeile würden die für Wikipedia zentrale Grundannahme anrühren, dass Revisionen unveränderlich sind, und selbstverständlich müssten alle einer solch tiefgreifenden Änderung zustimmen (Communities, Wikimedia Foundation, Architecture Commitee). Aus diesem Grund verschiebe ich deinen Wunsch in die Rubrik “Wünsche außerhalb des Projektrahmens”. -- Viele Grüße, Charlie Kritschmar (WMDE) (Diskussion) 15:05, 15. Jun. 2017 (CEST)

Tja, dann wird dem wohl so sein. Andere Frage: ließe sich allenfalls eine "Anmerkung zu einer Zusammenfassungszeile" einrichtein? Ich stelle mir das so vor, dass bei der Zusammenfassungszeile ein "Flag" gesetzt werden kann, wenn noch eine Zusatzbemerkung zur Zusammnfassungszeile zu beachten wäre (die aber auf einer anderen Seite stehen kann); sowas wie "Bitte Bemerkung beachten", auf das man dann klicken kann. Dann kann man zwar die Zusammenfassungszeile auch nicht editieren, aber sinnvoll mit einer Bemerkung ergänzen, die dann nur einen Bezug zur entsprechenden Zusammenfassungszeile hat. Das könnte dann z.B. in einem "Zusammenfassungszeilennamensraum" gelegt werden, der für den Artikel nur dann vorhanden ist, wenn es Korrekturen gab. Das soll ja sonst nicht irgendwie in die Quere kommen. Wie gesagt: die Idee ist, mißlungene Zusammenfassungen zu bereinigen; da wäre eine Kommentierung immerhin besser als gar nix, wenn nicht geändert werden können soll. --ProloSozz (Diskussion) 15:35, 15. Jun. 2017 (CEST)

@ProloSozz: Könntest du den Titel und Inhalt deines Wunsches dahingehend abändern, da die Diskussion zur Abstimmung eingeklappt wird damit klar wird, worüber abgestimmt wird. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 14:24, 17. Jun. 2017 (CEST)

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:13, 19. Jun. 2017 (CEST)
3.  Pro beispielsweise eine Möglichkeit, die Zusammenfassungszeile eigener Änderungen innerhalb eines engen Zeitfensters (z.B. 5 Minuten) zu korrigieren, dann könnte man wenigstens sofort bemerkte Tippfehler ausbessern. -- Karl432 (Diskussion) 22:03, 19. Jun. 2017 (CEST)
4.  Pro--grim (Diskussion) 15:49, 20. Jun. 2017 (CEST)
5.  Pro --FNDE 15:51, 20. Jun. 2017 (CEST)
6.  Pro -- Peter Gröbner -- 16:57, 20. Jun. 2017 (CEST) innerhalb eines engen Zeitfensters (z.B. 5 Minuten) wie Karl432
7.  Pro -- ebenso, man vertippt sich immer wieder einmal --Keuk (Diskussion) 19:04, 20. Jun. 2017 (CEST)
8.  Pro --FriedhelmW (Diskussion) 20:43, 20. Jun. 2017 (CEST)
9.  Pro --Avron (Diskussion) 18:48, 21. Jun. 2017 (CEST)
10.  Pro --Jossi (Diskussion) 13:37, 22. Jun. 2017 (CEST)
11.  Pro … «« Man77 »» (A) wie Autor 21:22, 22. Jun. 2017 (CEST)
12.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
13.  Pro -- Freddy2001 ^DISK 12:05, 24. Jun. 2017 (CEST)
    
    

Anzahl geänderter Zeichen auch im Versionsdirektvergleich ("Versionsunterschied") angeben

Was ist das Problem?

In der Versionsgeschichte wird bei jeder Änderung die Anzahl geänderter Zeichen (mehr in grün, weniger in rot) angegeben. Vergleicht man nun zwei Versionen direkt, so wird diese zahl nicht genannt. Dies wäre besonders dann nützlich, wenn nur Absatzmarken o.ä. eingefügt wurden (und somit nur einige wenige Zeichen), daraus aber eine "größere Änderung" angezeigt wird, da die Absätzei nicht mehr übereinstimmen.

Wen betrifft das Problem besonders?

Jeden, der Versionen vergleicht und sehen möchte, wieviel verändert wurde.

Lösungsvorschlag

In der Titelzeile der Versionen beim Versionsvergleich auch die Zahlen der Anzahl geänderter Zeichen anfügen (am besten auch noch die Gesamtzahl Zeichen der jeweiligen Version).

Anmerkungen

Beispiel: hier wurde wesentlich weniger bearbeitet, als es auf den ersten Blick den Anschein macht; aufgrund der Absatztrennung ist das aber schwer erkennbar. Um die effektive Anzahl geänderter Zeichen zu sehen, muß in die Versionsgeschichte gewechselt werden.

Vorschlagende Person

ProloSozz (Diskussion) 11:08, 6. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro ProloSozz (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:18, 19. Jun. 2017 (CEST)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:32, 19. Jun. 2017 (CEST) Und am besten auch beim "Änderungen zeigen" während einer Bearbeitung
4.  Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)
   
   

Fehlende gegenseitige Verlinkung feststellen

Was ist das Problem?

Es gibt zahlreiche Fälle, in denen eine gegenseitige Verlinkung von Artikeln erwartet wird, der Gegenlink jedoch in der Praxis unterbleibt. Beispielsweise wird häufig versäumt, vorhandene bzw. neue Filmartikel in den Biografien der Beteiligten einzutragen oder zu verlinken. Um dann einen Schauspielerartikel zu aktualisieren und ergänzen, rufe ich die „Links auf diese Seite“ auf und vergleiche sie mit den im Artikel vorhandenen Links, denn der Schauspieler ist üblicherweise in den Filmartikeln verlinkt. Dieser Vergleich ist jedoch oft recht mühsam und könnte automatisiert unterstützt werden.

Allgemein wäre ein solches Tool auch bei der gegenseitigen Verlinkung von Listenartikeln und Sachartikeln hilfreich. Die Sachartikel erhalten oft einen Siehe-auch-Link zum übergeordneten Listenartikel.

Wen betrifft das Problem besonders?

Alle Artikelbearbeiter.

Lösungsvorschlag

Das gewünschte kleine Tool vergleicht die Liste der Links auf den fraglichen Artikel mit der Liste der vom Artikel ausgehenden Links und gibt als Ergebnis aus:

• die Liste der eingehenden und von hier nicht erwiderten Links
• die Liste der ausgehenden und von dort nicht erwiderten Links
• der Vollständigkeit halber auch die Liste der gegenseitigen Links.
  Anmerkungen

Falls es das Tool schon gibt, bin ich für einen Hinweis dankbar.

Vorschlagende Person

Sitacuisses (Diskussion) 17:46, 8. Jun. 2017 (CEST)

Diskussion

Danke für den Vorschlag! Die Ausgestaltung könnte sich beispielsweise an der Prüfung der Einbindung von Vorlagen orientieren. --Bwbuz (Diskussion) 22:53, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Sitacuisses (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:20, 19. Jun. 2017 (CEST)
3.  Pro --FNDE 15:52, 20. Jun. 2017 (CEST)
4.  Pro Iva 20:14, 20. Jun. 2017 (CEST)
5.  Pro Conny 22:48, 20. Jun. 2017 (CEST).
6.  Pro Looperz (Diskussion) 02:45, 22. Jun. 2017 (CEST)
7. 
   
   

Mehr Sperrmöglichkeiten gegen besonders massiven Vandalismus

Was ist das Problem?

Als aktives Mitglied in der Vandalismusbekämpfung habe ich erweiterte Rechte, mit denen ich aufgrund massiv negativen Verhaltens besonders weitreichende Gegenmaßnahmen durchführen muss, damit diese wirksam sind. Oft werde ich dazu gezwungen, mehr Bearbeitungsfunktionen zu unterbinden, als dies nötig wäre: Wenn ich als Administrator ein Benutzerkonto sperren will, habe ich nur wenige Möglichkeiten. Ich kann bspw. nicht nur das Hochladen bei bestimmten Konten oder IP-Adressbereichen untersagen, bei IP-Adressbereichs-Sperren nicht nur die Anlage von Benutzerkonten unterbinden oder die Sperre nur auf bestimmte User Agents beschränken. Dies führt manchmal zu so massiven Einschränkungen in bestimmten Regionen oder für bestimmte Internetprovider, was dann sogar bis in die Presse gelangt. Dabei möchte ich doch nur den Vandalismus verhindern und gar nicht so viele gut handelnde Personen einschränken oder gar behindern, habe aber manchmal aufgrund nicht ausreichender Sperrmöglichkeiten keine wirklich andere Wahl.

Wen betrifft das Problem besonders?

Admins und insbesondere CheckUser und Stewards

Lösungsvorschlag

Weitere Sperrmöglichkeiten werden eingeführt.

Vorschlagende Person

—DerHexer (Disk., Bew.) 22:10, 8. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro DerHexer (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:23, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 15:21, 20. Jun. 2017 (CEST)
4.  Pro --FNDE 15:53, 20. Jun. 2017 (CEST)
5.  Pro Zabia (Diskussion) 17:21, 20. Jun. 2017 (CEST)
6.  Pro --  Sir Gawain Disk. 20:43, 20. Jun. 2017 (CEST)
7.  Pro Conny 22:49, 20. Jun. 2017 (CEST).
8.  Pro Michi 19:22, 21. Jun. 2017 (CEST)
9.  Pro, siehe auch #Benutzersperren flexibler gestalten (Punkt 3). --19:43, 21. Jun. 2017 (CEST)
10.  Pro Hört sich für mich im Prinzip vernünftig an, wobei mir unklar ist, was diese „weiteren Sperrmöglichkeiten“ sein sollen. --Furfur ^{⁂ Diskussion} 23:38, 21. Jun. 2017 (CEST)
11.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:34, 22. Jun. 2017 (CEST)
12.  Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)
13.  Pro --ArthurMcGill (Diskussion) 09:27, 23. Jun. 2017 (CEST)
14.  Pro KPFC 💬 15:20, 23. Jun. 2017 (CEST)
15. 
    
    

VisualFileChange für die de.Wikipedia

Was ist das Problem?

Die Wartung von Dateien und die Sichtung von Neuuploads ist hier im lokalen Wiki wesentlich komplizierter und zeitaufwändiger als auf Commons. Das liegt vor allem daran, dass VisualFileChange hier nicht verfügbar ist.

Wen betrifft das Problem besonders?

Alle die Wartungsaufgaben im Datei-Namensraum wahrnehmen

Lösungsvorschlag

VisualFileChange für die lokale Wikipedia anpassen und für Nutzer mit Sicherrechten im Dateibereich freischalten. In einem zweiten Schritt könnte der Nutzen dieses Tools für weiter Wiki-Bereiche evaluiert werden.

Vorschlagende Person

Martin K. (Diskussion) 16:20, 10. Jun. 2017 (CEST)

Diskussion

Martin, d. h. anders als Cat-a-lot (worüber ich überrascht war) ist es nicht per Nutzerskript benutzbar? Was natürlich genau wie bei der anderen Lösung auch nur ein ziemlicher Hack wäre. — Speravir – 00:46, 11. Jun. 2017 (CEST)

@Speravir: Ehrlich gesagt habe ich das noch nicht ausprobiert. Ich glaube aber nicht, dass das funktioniert, weil die Lizenzbausteine und Vorlagen hier lokal sich doch sehr von denen auf Commons unterscheiden. Und die meisten Aktionen in VisualFileChange sowie die Informationen in der Bildübersicht basieren ja auf den in der Bilddetailseite verwendeten Vorlagen bzw. direkt auf der Commons-API. // Martin K. (Diskussion) 14:45, 12. Jun. 2017 (CEST)

Ja, da dürftest Du Recht haben. — Speravir – 17:41, 12. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 15:22, 20. Jun. 2017 (CEST)
3.  Pro -- Freddy2001 ^DISK 12:05, 24. Jun. 2017 (CEST)
   
   

Wiedervorlagefunktion von Artikeln auf einen wählbaren Zeitpunkt

Was ist das Problem?

Gerade Artikel im Sport müssen regelmäßig beobachtet und gewartet werden. Es wäre wünschenswert, dass man Artikel auf einen bestimmten Zeitpunkt "legen" könnte und diese dann auf der Beo auftauschen würden mit einer Markierung "WV" (o.ä.). Ich benutzte ein Tool (ich glaube, von Schnark), das ganz gut funktioniert hat, wo aber die Einträge bei Änderung des Browsers verloren gingen oder andernorts nicht sichtbar waren. Daher lege ich mir die Artikel jetzt im Outlook-Kalender auf Termin, würde mir aber eine Anwendung in der WP selbst wünschen.

Antworten auf die Fragen von Johanna Strodt (WMDE).

1) Ich möchte diese Wiedervorlage selbst einstellen können und zwar - ob ich überhaupt eine möchte und wenn ja, wann.

2) Bei Outlook trage ich die Artikel im Kalender ein. Wenn ich einen Artikel erstelle, lege ich mir diesen auf einen bestimmten Zeitpunkt, dann wird mir der Artikel angezeigt, ich schaue nach, ob Aktualisierungen notwendig sind, dann lege ich das Datum weiter vor.

3) Wenn ich an einen Artikel erinnert wurde, kontrolliere ich, ob der Stand aktuell ist, trage diesen ggf. nach und aktualisiere das Datum in der Infobox (bei Radsportlern).

Alles klar?   -- Nicola - Ming Klaaf 11:10, 15. Jun. 2017 (CEST)

Ich freue mich über die positive Resonanz :) Ich hatte diesen Vorschlag in anderen Zusammenhängen schon mehrfach gemacht, da kam nie eine Resonanz, deshalb bin ich jetzt umso erfreuter. Gruß, -- Nicola - Ming Klaaf 22:35, 23. Jun. 2017 (CEST)

Wen betrifft das Problem besonders?

Autoren von Artikeln, die regelmäßig aktualisiert werden müssen.

Vorschlagende Person

 Nicola - Ming Klaaf 18:18, 10. Jun. 2017 (CEST)

Diskussion

Hallo Nicola, danke für deinen Wunsch! Aktuell behandelt dein Wunsch eher eine konkrete Lösung, was schon mal sehr hilfreich ist. Damit alle Abstimmenden und das Team das Problem genau verstehen, um das es geht, wäre es super, wenn du die Situation noch genauer beschreiben könntest, in der du Unterstützung durch eine (wie auch immer geartete) neue Funktion brauchst. Denn es ist denkbar, dass im Falle einer Umsetzung die Lösung eine andere ist. Einige Fragen, um es konkreter zu machen, sind:

• In welchen Fällen möchtest du an Artikel erinnert werden?
• Wie gehst du zzt. mithilfe von Outlook vor? Kannst du skizzieren, welche Schritte dir dabei wichtig sind?
• Wenn du an einen Artikel erinnert wurdest, was wären dann deine nächsten Schritte?

Die Diskussionen werden bald ausgeblendet, daher solltest du die Ergänzung direkt bei „Was ist das Problem?“ vornehmen.

Im selben Sinne möchte ich dich bitten, den Titel des Wunsches zu ändern, weg von einer konkreten Lösung und hin zu einer Zusammenfassung des Problems. Ideal wäre es, wenn du Wunsch und Wunschtitel noch heute umformulieren könntest. Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:53, 15. Jun. 2017 (CEST)

@Nicola: Danke! :) So wie ich das verstehe, ist es dir wichtig, dass du erinnert wirst, aber das müsste nicht zwingend über die Beobachtungsliste geschehen, oder? Falls ich richtig liege, kannst du den Titel noch etwas breiter formulieren, beispielsweise „Wiedervorlagefunktion von Artikeln auf einen wählbaren Zeitpunkt“? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:29, 15. Jun. 2017 (CEST)

Kann ich :) -- Nicola - Ming Klaaf 16:34, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Nicola (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:29, 19. Jun. 2017 (CEST) - geniale Idee
3.  Pro -- X:: black ::X (Diskussion) 14:34, 19. Jun. 2017 (CEST)
4.  Pro -- ^Thomas 11:20, 20. Jun. 2017 (CEST)
5.  Pro --Adnon (Diskussion) 15:04, 20. Jun. 2017 (CEST)
6.  Pro DCB (Diskussion • Bewertung) 15:23, 20. Jun. 2017 (CEST)
7.  Pro --Eingangskontrolle (Diskussion) 15:51, 20. Jun. 2017 (CEST)
8.  Pro --FNDE 15:55, 20. Jun. 2017 (CEST) sehr coole Idee
9.  Pro --Blik (Diskussion) 16:47, 20. Jun. 2017 (CEST) ... dass da vorher noch niemand dran gedacht hat…
10.  Pro -- Peter Gröbner -- 16:59, 20. Jun. 2017 (CEST)
11.  Pro --Abubiju (Diskussion) 17:14, 20. Jun. 2017 (CEST)
12.  Pro --Andropov (Diskussion) 17:41, 20. Jun. 2017 (CEST)
13.  Pro --Gnom (Diskussion) 18:15, 20. Jun. 2017 (CEST)
14.  Pro --h-stt !? 18:31, 20. Jun. 2017 (CEST)
15.  Pro --Nuhaa (Diskussion) 18:38, 20. Jun. 2017 (CEST)
16.  Pro --  Sir Gawain Disk. 20:45, 20. Jun. 2017 (CEST)
17.  Pro --jcornelius  11:43, 21. Jun. 2017 (CEST)
18.  Pro wäre mir auch beim Nachsichten eine große Hilfe. Silke (Diskussion) 15:38, 21. Jun. 2017 (CEST)
19.  Pro --Carolus requiescat (Diskussion) 17:24, 21. Jun. 2017 (CEST)
20.  Pro --Avron (Diskussion) 18:51, 21. Jun. 2017 (CEST) für einige Sonderthemen sicherlich interessant
21.  Pro --Kenny McFly (Diskussion) 19:55, 21. Jun. 2017 (CEST)
22.  Pro --Pelz (Diskussion) 23:08, 21. Jun. 2017 (CEST)
23.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:34, 22. Jun. 2017 (CEST)
24.  Pro --Jossi (Diskussion) 13:40, 22. Jun. 2017 (CEST)
25.  Pro --GodeNehler (Diskussion) 19:38, 22. Jun. 2017 (CEST)
26.  Pro … «« Man77 »» (A) wie Autor 21:23, 22. Jun. 2017 (CEST)
27.  Pro --ArthurMcGill (Diskussion) 09:28, 23. Jun. 2017 (CEST)
28.  Pro --DianeAnna (Diskussion) 13:14, 23. Jun. 2017 (CEST)
29.  Pro --Atamari (Diskussion) 14:58, 23. Jun. 2017 (CEST)
30.  Pro -- Nichtich (Diskussion) 23:10, 23. Jun. 2017 (CEST)
31.  Pro -- Freddy2001 ^DISK 12:06, 24. Jun. 2017 (CEST)
    
    

Projektseite Wikipedia:Sprachen/WP-Status wieder regelmäßig aktualisieren.

Was ist das Problem?

Der Quelltext der Projektseite Wikipedia:Sprachen/WP-Status enthält Daten zur Anzahl der aktiven Benutzer und der Anzahl der Artikel für die einzelnen Wikipedia-Sprachversionen, einschließlich der Inkubator-Versionen. Die Projektseite Wikipedia:Sprachen liest diese Daten aus und baut sie in die Tabelle im Abschnitt „Alle Wikipedias“ ein. Bis einschließlich 30. Sepember 2014 wurden diese Daten in der Projektseite Wikipedia:Sprachen/WP-Status durch den MerlBot regelmäßig automatisch aktualisiert. Seit dem gibt es nur wenige, händisch erfolgte Aktualisierungen zu einzelnen Sprachen. Die meisten Daten sind daher sehr veraltet.

Wen betrifft das Problem besonders?

Die Personen, die sich auf der Projektseite Wikipedia:Sprachen über die Größe (und indizartig auch über die Struktur und Aktualität) der einzelnen Sprachversionen informieren möchten.

Lösungsvorschlag

Die Daten sollen direkt aus https://stats.wikimedia.org/ (https://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm bzw. aus den Summaries, verlinkt in https://stats.wikimedia.org/EN/Sitemap.htm) auf Wikipedia:Sprachen/WP-Status eingebunden werden. -- ergänzt aus der Diskussion, Johanna Strodt (WMDE) (Diskussion) 22:38, 18. Jun. 2017 (CEST) und bearbeitet von --X:: black ::X (Diskussion) 08:47, 19. Jun. 2017 (CEST)

Ein Bot soll die Projektseite Wikipedia:Sprachen/WP-Status wieder regelmäßig warten. Eventuell lässt sich der zur Zeit außer Betrieb befindliche MerlBot über die Right to fork policy der Wikimedia Tool Labs ersetzen, oder – wenn es gar nicht anders geht – über die Abandoned tool policy übernehmen (siehe auch Punkt #3 des Wunsches 7 „Digitales Erbe“ in der Rubrik „Sonstiges“). -- gestrichen nach Diskussion, Johanna Strodt (WMDE) (Diskussion) 22:38, 18. Jun. 2017 (CEST)

Vorschlagende Person

X:: black ::X (Diskussion) 13:08, 11. Jun. 2017 (CEST)

Diskussion

@X:: black ::X: Danke für deinen Wunsch! Über https://stats.wikimedia.org/ kannst du auf die Informationen zugreifen. Wenn du möchtest, dass ein Bot die Aktualisierung von Wikipedia:Sprachen/WP-Status wieder übernimmt, müsstest du das unter Wikipedia:Bots/Anfragen anfragen, weil Bots grundsätzlich Aufgabe der Community sind, und somit nicht ins Projekt „Technische Wünsche“ fallen. Darum verschiebe ich deinen Wunsch in die Rubrik „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 19:38, 16. Jun. 2017 (CEST)

@X:: black ::X: - Verschoben. -- Johanna Strodt (WMDE) (Diskussion) 19:41, 16. Jun. 2017 (CEST)

Hallo Johanna Strodt (WMDE), Danke für den Hinweis auf https://stats.wikimedia.org/. Da Wikipedia:Sprachen die Zahlen ohnehin von Wikipedia:Sprachen/WP-Status einbindet, kam mir die Idee, ob es möglich ist, die dort eingebundenen statistischen Daten direkt aus https://stats.wikimedia.org/DE/TablesWikipediansEditsGt5.htm und den Summaries (verlinkt in https://stats.wikimedia.org/EN/Sitemap.htm) einzubinden (oder vonwoaus auch immer man diese Daten am technisch elegantesten einbindet). Das würde viel Arbeit ersparen, da man die Daten nur in stats.wikimedia.org aktualisiert werden müssten, und alles andere über die Einbindungen erfolgen würde (mindestens für die Wikipedias außerhalb des Inkubators; falls über Unterseiten von https://stats.wikimedia.org/wikispecial/DE/TablesWikipediaINCUBATOR.htm oder auf andere Weise möglich, gerne auch für die Inkubator-Wikipedias). Viele Grüße --X:: black ::X (Diskussion) 17:56, 17. Jun. 2017 (CEST)

@X:: black ::X: Hallo! Weil es jetzt schon recht spät ist, war ich so frei, deinen Vorschlag im Wunsch selbst zu ergänzen. Weil es damit nicht mehr um einen Bot geht, werde ich deinen Wunsch gleich wieder in die Umfrage schieben. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 22:38, 18. Jun. 2017 (CEST)

@ Johanna Strodt (WMDE) danke für die Rückverschiebung. --X:: black ::X (Diskussion) 00:51, 19. Jun. 2017 (CEST)

Mir ist aufgefallen, dass https://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm mehr Sprachversionen enthält als https://stats.wikimedia.org/DE/TablesWikipediansEditsGt5.htm (https://stats.wikimedia.org/FR/TablesWikipediansEditsGt5.htm enthält wiederum weniger Sprachversionen als die beiden anderen). Falls es nicht möglich sein sollte, die Daten direkt aus der Datenquelle für alle Sprachversionen zu extrahieren, ist eine Einbindung aus der englischsprachigen Version vermutlich die beste Wahl. --X:: black ::X (Diskussion) 00:51, 19. Jun. 2017 (CEST)

@X:: black ::X: Okay, danke!

Unterstützung

1.  Pro X:: black ::X (Einreichende Person)
2.  Pro --Jossi (Diskussion) 13:42, 22. Jun. 2017 (CEST)
3. 
   
   

Automatisches speichern des Inhalts externer Links ins Internet Archive (archive.org)

Was ist das Problem?

Man sagt zwar gern "Das Internet Vergisst nie", doch leider stimmt das nicht immer. Immer wieder sterben Webseiten oder werden so umgebaut, dass Links nicht mehr funktionieren. Dies ist in der Wikipedia besonders bei Quellen ein Problem. Regelmäßig müssen "Tote Links" ersetzt werden. Teilweise sind dann die originalen Quellen nicht mehr auffindbar. Wenn man Glück hat, hat das Internet Archive aber eine Kopie der Seite gespeichert. Auf diese Seite kann man dann verlinkt werden. Bei umgebauten Seite, auf denen alte Links nicht mehr funktionieren kann die archivierte Seite helfen den neuen Link zu finden. (z.B. durch Suche nach der Überschrift mit der Suchfunktion der Seite). Problem ist, dass nicht alle Seiten die in der Wikipedia verlinkt werden im Internet Archive landen.

Wen betrifft das Problem besonders?

Autoren, welche tote Links ersetzen aber auch Leser der Wikipedia, welche auf diese toten Links stoßen.

Lösungsvorschlag

Bei jedem Speichern einer Änderung, sollte der Artikel automatisch nach externen Links durchsucht werden. Diese Links sollen dann automatisch im Internet Archive gespeichert werden. Damit wird der Inhalt der Seite mit dem aktuellen Stand konserviert und ist dann im Todesfall der Webseite oder bei Löschung des Inhalts (z.B. auch durch Zensur) auch weiterhin über das internet Archive verfügbar.

(Technisches Detail dazu: Es genügt der Aufruf der URL https://web.archive.org/save/<Quellen-URL> um die Seite zu archivieren)

Vorschlagende Person

Ubahnverleih (Diskussion) 14:11, 11. Jun. 2017 (CEST)

Diskussion

Soweit ich weiß, macht dies derzeit schon ein Bot, der die RC beobachtet automatisch. -- Freddy2001 ^DISK 12:07, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Ubahnverleih (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:38, 19. Jun. 2017 (CEST)
3.  Pro -- Karl432 (Diskussion) 22:04, 19. Jun. 2017 (CEST)
4.  Pro  _hugarheimur 09:16, 20. Jun. 2017 (CEST) Sehr gute Idee. Ich glaube, die französischsprachigen Kollegen haben schon etwas ähnliches.
5. -- ^Thomas 11:21, 20. Jun. 2017 (CEST)@Z thomas: Pro
6.  Pro --Horgner (Diskussion) 14:17, 20. Jun. 2017 (CEST) Unbeding, sowas wünsche ich mir schon lange!
7.  Pro DCB (Diskussion • Bewertung) 15:23, 20. Jun. 2017 (CEST)
8.  Pro --Eingangskontrolle (Diskussion) 15:55, 20. Jun. 2017 (CEST) Aber nicht nach jedem Abspeichern, sondern nur beim Setzen des Links
9.  Pro --FNDE 15:57, 20. Jun. 2017 (CEST)
10.  Pro Zabia (Diskussion) 17:23, 20. Jun. 2017 (CEST)
11.  Pro --Claell (Diskussion) 19:26, 20. Jun. 2017 (CEST)
12.  Pro Iva 20:16, 20. Jun. 2017 (CEST)
13.  Pro --  Sir Gawain Disk. 20:45, 20. Jun. 2017 (CEST)
14.  Pro --Wikifreund (Diskussion) 00:17, 21. Jun. 2017 (CEST) archive.org kann dennoch Inhalte löschen.
15.  Pro --MSchnitzler2000 (Diskussion) 00:41, 21. Jun. 2017 (CEST)
16.  Pro --Drahreg01 (Diskussion) 06:37, 21. Jun. 2017 (CEST)
17.  Pro --Nightflyer (Diskussion) 12:59, 21. Jun. 2017 (CEST)
18.  Pro Conny 13:41, 21. Jun. 2017 (CEST).
19.  Pro -- Silke (Diskussion) 15:36, 21. Jun. 2017 (CEST)
20.  Pro --Avron (Diskussion) 18:49, 21. Jun. 2017 (CEST) Nicht unbedingt bei allen Links aber wünschenswert bei Einzelnachweisen
21.  Pro Michi 19:22, 21. Jun. 2017 (CEST)
22.  Pro Die Idee ist ja genial. --MGChecker – (📞| 📝| ) 19:42, 21. Jun. 2017 (CEST)
23.  Pro --Kenny McFly (Diskussion) 19:56, 21. Jun. 2017 (CEST)
24.  Pro Looperz (Diskussion) 02:43, 22. Jun. 2017 (CEST)
25.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:35, 22. Jun. 2017 (CEST)
26.  Pro, mit von den anderen genannten Limitierungen … «« Man77 »» (A) wie Autor 21:25, 22. Jun. 2017 (CEST)
27.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:08, 23. Jun. 2017 (CEST)
28.  Pro --ArthurMcGill (Diskussion) 09:30, 23. Jun. 2017 (CEST)
29.  Pro KPFC 💬 15:30, 23. Jun. 2017 (CEST)
30.  Pro -- Nichtich (Diskussion) 23:10, 23. Jun. 2017 (CEST)
    
    

Hilfe beim Überprüfen von Datenquellen

Was ist das Problem?

Das Prüfen von Datenquellen wie Denkmallisten, die regelmäßig fortgeschrieben werden ist mühselig und fehleranfällig, da die Quellen oft sehr groß sind.

Wen betrifft das Problem besonders?

Autoren

Lösungsvorschlag

Hilfe, die einem zeigt, welche Einträge in den Datenquelle neu oder sogar anders sind.

Anmerkungen

Bei Denkmallisten ist der Identifikator die Denkmal-ID, die eindeutig ist.

Vorschlagende Person

 ^Thomas 19:36, 11. Jun. 2017 (CEST)

Diskussion

Hallo Thomas, vielen Dank für deinen Wunsch! Könntest du noch etwas genauer erläutern was mit Datenquellen gemeint ist und ein Beispiel nennen? Das würde uns helfen den Wunsch etwas besser zu verstehen. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 20:22, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro Conny 13:42, 21. Jun. 2017 (CEST).
3.