Wikipedia:Umfragen/Technische Wünsche 2017/Wartung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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

[Quelltext bearbeiten]
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:

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.

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch werden künftig hier dokumentiert.

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)[Beantworten]

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)[Beantworten]
  5. Pro DestinyFound (Diskussion) 10:49, 19. Jun. 2017 (CEST)[Beantworten]
  6. Pro 22:40, 19. Jun. 2017 (CEST)@KPFC:(unvollständig signierter Beitrag von KPFC (Diskussion | Beiträge) 22:40, 19. Jun. 2017 (CEST))[Beantworten]
  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![Beantworten]
  8. Pro --Itti 07:08, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Momel ♫♫♪ 07:29, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro -- Barnos (Post) 07:53, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Innobello (Diskussion) 08:09, 20. Jun. 2017 (CEST)[Beantworten]
  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?)[Beantworten]
  13. Pro --Kritzolina (Diskussion) 08:56, 20. Jun. 2017 (CEST)[Beantworten]
  14. Pro --:-) LG -- Benutzerin:Reisen8Benutzerin Diskussion:Reisen8Wikiliebe?! 09:00, 20. Jun. 2017 (CEST)[Beantworten]
  15. Pro --MatthiasGutfeldt (Diskussion) 09:59, 20. Jun. 2017 (CEST)[Beantworten]
  16. Pro Arieswings (Diskussion) 10:03, 20. Jun. 2017 (CEST)[Beantworten]
  17. Pro --emha db 10:11, 20. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Z thomas Thomas 11:14, 20. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Laury (Diskussion) 13:01, 20. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Alraunenstern۞ 14:40, 20. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Eingangskontrolle (Diskussion) 15:35, 20. Jun. 2017 (CEST)[Beantworten]
  22. Pro Zabia (Diskussion) 17:12, 20. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Andropov (Diskussion) 17:24, 20. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Gnom (Diskussion) 17:44, 20. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Aristeas (Diskussion) 17:46, 20. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Anima (Diskussion) 18:32, 20. Jun. 2017 (CEST)[Beantworten]
  27. ProSargoth 18:54, 20. Jun. 2017 (CEST)[Beantworten]
  28. Pro --WvB 19:54, 20. Jun. 2017 (CEST)[Beantworten]
  29. Pro --Leserättin (Diskussion) 20:46, 20. Jun. 2017 (CEST)[Beantworten]
  30. ProQueryzo ?! 22:36, 20. Jun. 2017 (CEST)[Beantworten]
  31. Pro --jcornelius Benutzer Diskussion:Jcornelius 11:39, 21. Jun. 2017 (CEST) (JA! Bitte! Endlich!)[Beantworten]
  32. Pro --Schelmentraum (Diskussion) 13:22, 21. Jun. 2017 (CEST)[Beantworten]
  33. Pro -- Silke (Diskussion) 15:26, 21. Jun. 2017 (CEST)[Beantworten]
  34. Pro --Carolus requiescat (Diskussion) 17:20, 21. Jun. 2017 (CEST)[Beantworten]
  35. Pro  — Johannes Kalliauer - Diskussion | Beiträge 19:28, 21. Jun. 2017 (CEST) Bin dienstlich (Universitätsassistent) zur geschlechterneutralen Sprache (per Verordnung) verpflichtet.[Beantworten]
  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?[Beantworten]
  37. Pro --HHill (Diskussion) 13:10, 22. Jun. 2017 (CEST)[Beantworten]
  38. Pro --DianeAnna (Diskussion) 23:25, 22. Jun. 2017 (CEST)[Beantworten]
  39. Pro --ArthurMcGill (Diskussion) 09:19, 23. Jun. 2017 (CEST)[Beantworten]
  40. Pro mauriceKA (Diskussion) 13:21, 23. Jun. 2017 (CEST)[Beantworten]
  41. Pro --Daniel749 Disk. (STWPST) 22:22, 23. Jun. 2017 (CEST)[Beantworten]
  42. Pro -- Nichtich (Diskussion) 23:03, 23. Jun. 2017 (CEST)[Beantworten]
  43. Pro --Chiborg (Diskussion) 23:10, 23. Jun. 2017 (CEST)[Beantworten]
  44. Pro --Querstrebe (Diskussion) 11:37, 24. Jun. 2017 (CEST)[Beantworten]
  45. Pro -- Freddy2001 DISK 11:59, 24. Jun. 2017 (CEST)[Beantworten]
  46. Pro --Skrippek (Diskussion) 16:34, 24. Jun. 2017 (CEST)[Beantworten]
  47. Pro--BohunkaNika (Diskussion) 18:05, 24. Jun. 2017 (CEST)[Beantworten]
  48. Pro --KEO144000 (Diskussion) 18:42, 24. Jun. 2017 (CEST)[Beantworten]
  49. Pro --Augustine14 (Diskussion) 12:35, 25. Jun. 2017 (CEST)[Beantworten]
  50. Pro Extragroßes Pro – der wichtigste Wunsch in dieser Umfrage. --Mushushu (Diskussion) 16:34, 25. Jun. 2017 (CEST)[Beantworten]
  51. Kontra --Lemke, Martin (Diskussion) 08:06, 26. Jun. 2017 (CEST)[Beantworten]
  52. Pro --DomenikaBo (Diskussion) 15:35, 26. Jun. 2017 (CEST)[Beantworten]
  53. Pro --Incabell (Diskussion) 17:40, 27. Jun. 2017 (CEST)[Beantworten]
  54. Pro --MannMaus (Diskussion) 18:55, 27. Jun. 2017 (CEST) Beim "Koch" bin ich einverstanden, beim "Kameramann" hoffe ich schon lange auf eine Lösung.[Beantworten]
  55. Pro--Thilo Parg (Diskussion) 12:11, 28. Jun. 2017 (CEST)[Beantworten]
  56. Pro --Kein Einstein (Diskussion) 14:52, 28. Jun. 2017 (CEST)[Beantworten]
  57. Pro --Thomas Obermair 4 (Diskussion) 16:25, 28. Jun. 2017 (CEST)[Beantworten]
  58. Pro -- @Matthiasb: (unvollständig signierter Beitrag von Matthiasb (Diskussion | Beiträge) 01:15 Uhr, 29. Jun. 2017) Letztlich erfordert dies Alias-Bezeichnungen für alle infrage kommenden Kategorien, was technisch nicht allzu schwer umzusetzen sein sllte, aber ich sehe die Problematik, daß die Anlage dieser Aliasbezeichnungen (> 30.000) an einigen wenigen Benutzern hängen bleiben wird.
  59. Pro --Ak ccm (Diskussion) 10:30, 29. Jun. 2017 (CEST)[Beantworten]
  60. Kontra Josara (Diskussion) 16:39, 29. Jun. 2017 (CEST)[Beantworten]
  61. Pro Countess Sofia (Diskussion) 23:04, 29. Jun. 2017 (CEST)[Beantworten]
  62. Pro --Eisbaer44 (Diskussion) 11:12, 30. Jun. 2017 (CEST)[Beantworten]
  63. Kontra Shoeper (Diskussion) 17:26, 30. Jun. 2017 (CEST)[Beantworten]
  64. Pro --Häuslebauer (Diskussion) 17:58, 30. Jun. 2017 (CEST)[Beantworten]
  65. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  66. Kontra Unwichtig und ohne Nutzen. --Fixuture (Diskussion) 19:36, 1. Jul. 2017 (CEST)[Beantworten]
  67. ProDerHexer (Disk.Bew.) 21:34, 1. Jul. 2017 (CEST)[Beantworten]
  68. Pro Möglichkeit für Alias-Namen schaffen und jeweils passende Anzeige in Abhängigkeit von gesetzter Kategorie Mann/Frau --Mabschaaf 22:51, 1. Jul. 2017 (CEST)[Beantworten]
  69. Kontra resp. Abwartend --ProloSozz (Diskussion) 00:28, 2. Jul. 2017 (CEST) Der (postulierte) Mehrwert ist v.a. feministisch-psychologischer Natur; wenn, dann muß auch zwischen "nur mask." und "mask. & fem." unterschieden werden können; nicht nur zw. "mask." und "fem.". Deutsch ist historisch nun mal eine Sprache, in der die mask. Form i.d.R. (auch) die allg. Form ist. Ich fürchte eine künstliche Trennung. Eine "Köchin unter Köchen" zu finden erachte ich nicht als Problem; einen "Koch unter Köchinnen" jedoch als inkonsistent und "irgendwie nicht ganz koscher" resp. auf ein strukturelles Zuordnungsproblem hindeutend (auch wenn nicht vorhanden). Zudem: eine "Köchin" kann in einer "Kategorie Köchin" (nur Damen) sein, aber auch in einer "Kategorie Koch" (Damen & Herren). Ein Koch hingegen kann nicht in einer "Kategorie Köchin" sein; eine Kategorie soll zudem nicht unterschiedliche Bezeichnungen haben, je nachdem, welches Element daraus man betrachtet.[Beantworten]
  70. Pro --Neigschmeckter (Diskussion) 12:51, 2. Jul. 2017 (CEST)[Beantworten]
  71. Pro --Entbert (Diskussion) 16:11, 2. Jul. 2017 (CEST)[Beantworten]
  72. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:59, 2. Jul. 2017 (CEST) Kategorien sollten imho so angezeigt werden, wie sie auch heißen. Ein Artikel zu einer Köchin befindet sich nun mal in der Kategorie:Koch und genau das sollte dort dann auch stehen. Auf jeden Fall muss so eine Regeländerung zuvor in einem MB geklärt werden.[Beantworten]
  73. Pro -- Michi 23:09, 2. Jul. 2017 (CEST)[Beantworten]
  74. Pro Ich bin zwar grundsätzlich dafür, aber betrachte dieses Anliegen weder als besonders dringend, noch als besonders wichtig. --Mewa767 (Diskussion) 01:52, 3. Jul. 2017 (CEST)[Beantworten]

# Pro --Momel ♫♫♪ 18:08, 18. Aug. 2017 (CEST) grundsätzlich: nicht auf die lange Bank schieben! wie lange soll denn noch diskutiert werden, was überfällig ist? Sehe gerade, dass ich schon abgestimmt hatte.[Beantworten]

Korrekte Größenangaben in Versionsgeschichten nach Import

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro --Thomas Obermair 4 (Diskussion) 16:26, 28. Jun. 2017 (CEST)[Beantworten]
  2. Pro -- hgzh 19:27, 29. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Shoeper 17:29, 30. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Drahreg01 (Diskussion) 21:57, 1. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:24, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Thomas Wozniak (HSP) (Diskussion) 11:52, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --C21H22N2O2 (V • T • E) 14:26, 19. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- Karl432 (Diskussion) 21:52, 19. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Barnos (Post) 07:54, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Eingangskontrolle (Diskussion) 15:37, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --emha db 10:14, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro -- Peter Gröbner -- 16:54, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro -- --Keuk (Diskussion) 18:47, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Holder (Diskussion) 20:05, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro --  Sir Gawain Disk. 20:32, 20. Jun. 2017 (CEST)[Beantworten]
  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)
    ... Einspruch: 1. wie erwähnt: wegen rechtlicher Probleme (UHRV etc.) gelöschte Versionen bleiben "für Normalsterbliche blind" und nur für Admins einsehbar. 2. Hier geht es nicht um die Wiederherstellung eines gelöschten Artikels, sondern um die Wiederherstellung einer alten History eines zuvor gelöschten Artikels, NACHDEM eine Neuanlage initiiert wurde. History und alte Versionen sind zwar einsehbar, aber werden erst bei Neuanlage reaktiviert und für das "Fußvolk" (ohne Anmeldung) sichtbar. --ProloSozz (Diskussion) 00:45, 2. Jul. 2017 (CEST)[Beantworten]
  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.[Beantworten]
    ... UHRV-Problemversionen bleiben sowieso blind und nur für Admins einsehbar. --ProloSozz (Diskussion) 00:45, 2. Jul. 2017 (CEST)[Beantworten]
  15. Pro --Uranus95 (Diskussion) 10:15, 21. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Schelmentraum (Diskussion) 13:25, 21. Jun. 2017 (CEST)[Beantworten]
  17. Pro Michi 19:16, 21. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Kenny McFly (Diskussion) 19:31, 21. Jun. 2017 (CEST)[Beantworten]
  19. Pro --ArthurMcGill (Diskussion) 09:21, 23. Jun. 2017 (CEST)[Beantworten]
  20. Pro --KEO144000 (Diskussion) 18:47, 24. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Christian (Diskussion) 20:03, 24. Jun. 2017 (CEST)[Beantworten]
  22. Pro -- - Majo Senf - Mitteilungen an mich 23:55, 24. Jun. 2017 (CEST)[Beantworten]
  23. Pro -- Raphael Vogel Reden 10:31, 26. Jun. 2017 (CEST)[Beantworten]
  24. Pro -- Chstdu (Diskussion) 15:25, 26. Jun. 2017 (CEST)[Beantworten]
  25. Pro --DomenikaBo (Diskussion) 15:37, 26. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Thomas Obermair 4 (Diskussion) 16:27, 28. Jun. 2017 (CEST)[Beantworten]
  27. Kontra --Gr1 (Diskussion) 16:43, 28. Jun. 2017 (CEST) geht nicht (primär wegen URV-Problematik)[Beantworten]
    ... UHRV-Problematik bleibt untangiert, da nur einzelne Versionen betreffend, die weiterhin nur für Admins einsehbar bleiben --ProloSozz (Diskussion) 00:45, 2. Jul. 2017 (CEST)[Beantworten]
  28. Neutral --W!B: (Diskussion) 12:02, 29. Jun. 2017 (CEST) ebenfalls nur für read-only (einsehen). alte versionen können auch als nachimport wiedergestellt werden, in der LP unter administrativer aufsicht (bei begründeten fällen, etwa, wenn sich die RK geändert haben, oder man doch texte aus wegen qualitätsmängeln gelöschen artikeln verwendet). sicher aber nicht automatisch.[Beantworten]
    ... Dies kann nur von Admins gemacht werden; ein Editor ist auf einen "kooperativen Admin" angewiesen, schon allein, um überhaupt erkennen zu können, ob der alte Artikel ggf. völlig unbrauchbar sein könnte etc. Diese Admin-Abhängigkeit soll vermieden werden. --ProloSozz (Diskussion) 00:45, 2. Jul. 2017 (CEST)[Beantworten]
  29. Pro --Anima (Diskussion) 13:48, 30. Jun. 2017 (CEST)[Beantworten]
  30. Pro --Hartmann Linge (Diskussion) 13:53, 30. Jun. 2017 (CEST)[Beantworten]
  31. Pro -- Shoeper 17:31, 30. Jun. 2017 (CEST)[Beantworten]
  32. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  33. Pro --Hanekomi (Diskussion) 01:57, 2. Jul. 2017 (CEST)[Beantworten]
  34. Pro --Opihuck 15:53, 2. Jul. 2017 (CEST)[Beantworten]
  35. Pro --Devotus (Diskussion) 21:15, 2. Jul. 2017 (CEST)[Beantworten]
  36. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:04, 2. Jul. 2017 (CEST) Wie soll ich bei einem gelöschten Artikel den Löschgrund erkennen, ohne sehen zu können, wie der Artikel aussah? Diese Admin-Abhängigkeit ist unnötig. Bisherige gelöschte Artikel sollten unberührt bleiben, da die Überprüfung sehr aufwändig wäre. Stattdessen sollte man eine weitere Löschmöglichkeit mit [Sichtbarkeit=aktive Sichter] einführen.[Beantworten]

Redirectfunktion für Kategorien ermöglichen

[Quelltext bearbeiten]
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)[Beantworten]

Vorschlagende Person

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

Unterstützung
  1. Pro Wheeke (Einreichende Person)
  2. Pro DestinyFound (Diskussion) 10:51, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:26, 22. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Lemke, Martin (Diskussion) 07:52, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --DomenikaBo (Diskussion) 15:38, 26. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:28, 28. Jun. 2017 (CEST)[Beantworten]
  8. Kontra Benutze stattdessen HotCat. Die HotCat-Vorschläge könnten verbessert werden. --Fixuture (Diskussion) 19:38, 1. Jul. 2017 (CEST)[Beantworten]

Änderungen in Versionen leichter auffinden.

[Quelltext bearbeiten]
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.

Wird eine Leerzeile oder eine Überschrift hinzugefügt (oder entfernt) und in dem Inhalt eine kleine Änderung vorgenommen, kann man sie in dem Vergleich nicht finden, da der ganze Abschnitt als geändert markiert wird.

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

Der Vergleich sollte das Einfügen (bzw. Löschen) von Leerzeilen oder Überschriften berücksichtigen.

Vorschlagende Person

Zabia (Diskussion) 13:13, 29. Mai 2017 (CEST) Zabia (Diskussion) 13:13, 29. Mai 2017 (CEST) Ergänzungen von Mewa767 (Diskussion) 04:01, 3. Jul. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Zabia (Einreichende Person)
  2. Pro --FNDE 12:27, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Johamar (Diskussion) 17:15, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Aristeas (Diskussion) 17:48, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Avron (Diskussion) 17:17, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Pelz (Diskussion) 22:57, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Furfur Diskussion 23:27, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Jossi (Diskussion) 13:00, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:27, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro --GodeNehler (Diskussion) 19:33, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro«« Man77 »» (A) wie Autor 21:14, 22. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro -- Freddy2001 DISK 12:01, 24. Jun. 2017 (CEST)[Beantworten]
  14. Pro --MBxd1 (Diskussion) 18:12, 24. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Wrev (Diskussion) 22:38, 25. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Klaus Eifert (Diskussion) 00:45, 26. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Lemke, Martin (Diskussion) 08:11, 26. Jun. 2017 (CEST)[Beantworten]
  18. Pro --DomenikaBo (Diskussion) 15:40, 26. Jun. 2017 (CEST)[Beantworten]
  19. Pro -- Michael (Diskussion) 12:32, 27. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Thomas Obermair 4 (Diskussion) 16:29, 28. Jun. 2017 (CEST)[Beantworten]
  21. Pro -- Shoeper 17:34, 30. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  23. Pro --Opihuck 15:55, 2. Jul. 2017 (CEST)[Beantworten]
  24. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:06, 2. Jul. 2017 (CEST)[Beantworten]

Rückgängigmachen erschweren

[Quelltext bearbeiten]
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)[Beantworten]

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)[Beantworten]

Vorschlagende Person

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

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.ä.[Beantworten]
  3. Pro --C21H22N2O2 (V • T • E) 14:27, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro--grim (Diskussion) 15:37, 20. Jun. 2017 (CEST)[Beantworten]
  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.[Beantworten]
  7. Pro Weil ich immer versehentlich raufklicke. --Kenny McFly (Diskussion) 19:34, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:28, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro mauriceKA (Diskussion) 13:23, 23. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Lemke, Martin (Diskussion) 07:59, 26. Jun. 2017 (CEST) Diesen Vorschlag unterschreibe ich mit vollem Herzen![Beantworten]
  11. Pro --Wheeke (Diskussion) 09:48, 26. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Thomas Obermair 4 (Diskussion) 16:30, 28. Jun. 2017 (CEST)[Beantworten]
  13. Kontra --Gr1 (Diskussion) 16:38, 28. Jun. 2017 (CEST) Besser wäre: Wikipedia:Umfragen/Technische_Wünsche_2017/Bearbeiten#Sicherheitsabfrage_bei_Funktion_kommentarlos_zur.C3.BCcksetzen.[Beantworten]
  14. Kontra --Häuslebauer (Diskussion) 18:00, 30. Jun. 2017 (CEST) Häufig sorgt erst ein Revert für die notwendige Bereitschaft sich konstruktiv auf der Diskussionsseite über die Änderung auszutauschen.[Beantworten]
  15. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST) Es sollte "kommentarloses zurücksetzen" abgeschafft werden, alle was Rückgängig gemacht wird, muss begründen werden, auch Vandalismus.[Beantworten]
  16. Neutral Stattdessen sollte es mMn einen zusätzlichen Button "contest" bzw "anfechten", "anzweifeln", "diskutieren", "bestreiten" oÄ geben, der dann automatisch einen Diskussionsseiteneintrag nach spezifizierter Vorlage erstellt. Der Nutzer muss dann bloß noch seine Bedenken und Argumente hinzufügen und kann das ganze dann abspeichern, was dann auch den entsprechenden Editor anpingt. --Fixuture (Diskussion) 19:42, 1. Jul. 2017 (CEST)[Beantworten]
  17. Kontra --Opihuck 15:57, 2. Jul. 2017 (CEST)-- wie Häuslebauer[Beantworten]
  18. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:11, 2. Jul. 2017 (CEST) "kommentarlos zurücksetzen" und "zurücksetzen" brauche ich beide. zudem kann man Diskussionen auch per EW in der Zusammenfassungszeile führen</ironie>[Beantworten]
  19. Pro Der Kern der Idee ist richtig, der Funktionsmechanismus muss noch besser durchdacht werden. --Mewa767 (Diskussion) 02:16, 3. Jul. 2017 (CEST)[Beantworten]

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)[Beantworten]

Unterstützung
  1. Pro KPFC (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 22:22, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Carolus requiescat (Diskussion) 17:21, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Freddy2001 DISK 12:02, 24. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- SuPich [Diskussion] [Beiträge] um 14:33, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:30, 28. Jun. 2017 (CEST)[Beantworten]
  7. ProSDKmac (Disk., Bew.) 02:31, 30. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:13, 2. Jul. 2017 (CEST)[Beantworten]

Zusätzlichen Button "Zum Artikel" nach dem Sichten

[Quelltext bearbeiten]
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)[Beantworten]

Vorschlagende Person

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

Unterstützung
  1. Pro Hlambert63 (Einreichende Person)
  2. Pro ProloSozz (Diskussion) 11:24, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro Zabia (Diskussion) 17:15, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --GodeNehler (Diskussion) 19:34, 22. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- Freddy2001 DISK 12:02, 24. Jun. 2017 (CEST)[Beantworten]
  6. Pro --DomenikaBo (Diskussion) 15:41, 26. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:30, 28. Jun. 2017 (CEST)[Beantworten]
  8. Abwartend Notwendig wäre meiner Meinung nach, dass man von der Spezialseite, auf die man nach dem Sichten in bestimmten Fällen kommen kann, per Link (und nicht nur per „Zurück“-Schaltfläche des Browsers) auf die gesichtete Seite zurückgelangen kann, auch dann, wenn man die Ausführung von Scripten nicht gestattet. --X:: black ::X (Diskussion) 13:26, 2. Jul. 2017 (CEST)[Beantworten]
    @X:: black ::X: Genau das sollte ja eigentlich gemeint sein ... :) --ProloSozz (Diskussion) 17:07, 2. Jul. 2017 (CEST)[Beantworten]

Bessere Mobile Versionsgeschichte

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro KPFC (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 15:04, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 22:22, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Freddy2001 DISK 12:02, 24. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:31, 28. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  7. Pro Auch in der App. --Fixuture (Diskussion) 19:43, 1. Jul. 2017 (CEST)[Beantworten]

Verlinkungsfehler anzeigen

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Zabia (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 11:32, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 22:23, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Wrev (Diskussion) 22:41, 25. Jun. 2017 (CEST)[Beantworten]
  5. Pro --DomenikaBo (Diskussion) 15:42, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:31, 28. Jun. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Zabia (Einreichende Person)
  2. Kontra --Lemke, Martin (Diskussion) 08:19, 26. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Thomas Obermair 4 (Diskussion) 16:32, 28. Jun. 2017 (CEST)[Beantworten]

Option, Nur jeweils letzte Bearbeitungsversion eines Artikels in den Benutzerbeiträgen anzeigen und frühere (desselben bearbeiteten Artikels) ausblenden

[Quelltext bearbeiten]

Titel ergänzt --ProloSozz (Diskussion) 17:14, 2. Jul. 2017 (CEST)[Beantworten]

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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 11:48, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --FNDE 15:34, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Zabia (Diskussion) 17:16, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:32, 28. Jun. 2017 (CEST)[Beantworten]
  6. Pro Wäre neben der Watchlist recht nützlich (aber eben nur wenn man den Titel dieses Vorschlags invertiert). --Fixuture (Diskussion) 19:46, 1. Jul. 2017 (CEST)[Beantworten]
    Idealerweise sollte auch die inverse Liste angezeigt werden können; hier geht es darum, zu erkennen, bei welchen Artikeln man nicht mehr "letzter Bearbeiter" war; d.h. wo sonstwer später noch etwas geändert hat. --ProloSozz (Diskussion) 17:14, 2. Jul. 2017 (CEST)[Beantworten]
  7. Pro Wie Vorredner. --Sitacuisses (Diskussion) 13:33, 2. Jul. 2017 (CEST)[Beantworten]
  8. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:20, 2. Jul. 2017 (CEST)[Beantworten]

Direkte Auflistung von existierenden Artikeln in anderen Sprachen

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 12:00, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Noobius2 (Diskussion) 16:04, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Zabia (Diskussion) 17:17, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Boehm (Diskussion) 08:07, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:29, 22. Jun. 2017 (CEST)[Beantworten]
  7. Pro --GodeNehler (Diskussion) 19:35, 22. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  9. Pro -- Nichtich (Diskussion) 23:03, 23. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Wrev (Diskussion) 22:44, 25. Jun. 2017 (CEST)[Beantworten]
  11. Pro --DomenikaBo (Diskussion) 15:44, 26. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Thomas Obermair 4 (Diskussion) 16:32, 28. Jun. 2017 (CEST)[Beantworten]
  13. Pro // Martin K. (Diskussion) 12:32, 30. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Hartmann Linge (Diskussion) 13:55, 30. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Hanekomi (Diskussion) 01:57, 2. Jul. 2017 (CEST)[Beantworten]
  16. Pro --Mewa767 (Diskussion) 03:09, 3. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]

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[Beantworten]
Ergänzend ausformuliert von (und mit unterstützend):
ProloSozz (Diskussion) 12:12, 5. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Grosswardeyn (Einreichende Person)
  2. Pro ProloSozz (Einreichende Person)
  3. Pro --WeiterWeg (Diskussion) 18:49, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:33, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Hanekomi (Diskussion) 01:57, 2. Jul. 2017 (CEST)[Beantworten]
  6. Pro Das Anliegen ist wohl leicht zu lösen. --Mewa767 (Diskussion) 02:00, 3. Jul. 2017 (CEST)[Beantworten]

Nutzer sollten gelöschte Artikel einsehen können

[Quelltext bearbeiten]
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)[Beantworten]

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)[Beantworten]
  3. Pro --C21H22N2O2 (V • T • E) 14:28, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --FNDE 15:40, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Noobius2 (Diskussion) 16:05, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Blik (Diskussion) 16:41, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Holder (Diskussion) 20:06, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Uranus95 (Diskussion) 10:18, 21. Jun. 2017 (CEST)[Beantworten]
  9. Pro Michi 19:18, 21. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro mauriceKA (Diskussion) 13:25, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --KEO144000 (Diskussion) 19:03, 24. Jun. 2017 (CEST)[Beantworten]
  13. Pro aber nur für Stubs u. ä. -- SuPich [Diskussion] [Beiträge] um 14:35, 26. Jun. 2017 (CEST)[Beantworten]
  14. Pro --DomenikaBo (Diskussion) 15:45, 26. Jun. 2017 (CEST)[Beantworten]
  15. Pro -- Michael (Diskussion) 12:28, 27. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Thomas Obermair 4 (Diskussion) 16:33, 28. Jun. 2017 (CEST)[Beantworten]
  17. Kontra --Gr1 (Diskussion) 16:44, 28. Jun. 2017 (CEST) geht nicht, wegen URV-Inhalte, WP:BIO, Wiedereinstellen unerwünschter Inhalte, ...[Beantworten]
  18. Kontra --W!B: (Diskussion) 12:10, 29. Jun. 2017 (CEST) klare sache, dann können wir uns das löschen ja gleich sparen, das ergibt für nahezu jeden frei einsehbare inhalte, die wir anbieten, von denen wir uns aber distanzieren. obskure vorstellung. der andre vorschlag schränkt ja auf sichter ein, und die müssen was von qualtät verstehen.[Beantworten]
  19. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  20. Kontra Per Gr1 & W!B. Stattdessen sollte aber der Artikelersteller den Artikelinhalt nach Löschung per privater Nachricht zugeschickt bekommen (zB falls er den Inhalt auf eine andere Seite laden möchte) und auf Seiten gelöschter Artikel sollte ein Button für einen Eintrag im Deutsche Pendant zu en:Wikipedia:Requests for undeletion zu finden sein. --Fixuture (Diskussion) 19:51, 1. Jul. 2017 (CEST)[Beantworten]
  21. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:23, 2. Jul. 2017 (CEST) Der andere Vorschlag beschränkte sich auf aktive Sichter und auf Artikel, die wegen Relevanz/Qualität/Vandalismus gelöscht wurden. Dieser Vorschlag würde Löschungen unsinnig machen und URV-Inhalte verbreiten.[Beantworten]
  22. Kontra Die Artikel sollten nur wegen mangelnder Relevanz bzw. Unsinnigkeit (Vandalismusartikel) gelöscht werden. Wenn die Admins sich beim Löschen wirklich nur auf diese Fälle beschränken würden, gäbe es diesen Antrag vermutlich nicht. --Mewa767 (Diskussion) 02:25, 3. Jul. 2017 (CEST)[Beantworten]

Benutzersperren flexibler gestalten

[Quelltext bearbeiten]
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 – (📞| 📝| Bewertung) 17:12, 30. Mai 2017 (CEST)[Beantworten]

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)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 22:25, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- X:: black ::X (Diskussion) 09:05, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro--grim (Diskussion) 15:42, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --FNDE 15:43, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Michi 19:19, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:29, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro«« Man77 »» (A) wie Autor 21:16, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --DomenikaBo (Diskussion) 15:45, 26. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Thomas Obermair 4 (Diskussion) 16:34, 28. Jun. 2017 (CEST)[Beantworten]
  14. Pro -- hgzh 19:28, 29. Jun. 2017 (CEST)[Beantworten]
  15. ProDerHexer (Disk.Bew.) 21:46, 1. Jul. 2017 (CEST)[Beantworten]

Überarbeite das Prinzip privater Missbrauchsfilter

[Quelltext bearbeiten]
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 – (📞| 📝| Bewertung) 17:27, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro MGChecker (Einreichende Person)
  2. Pro --Thomas Obermair 4 (Diskussion) 16:34, 28. Jun. 2017 (CEST)[Beantworten]

Kategorisierung automatisieren

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Rævhuld (Einreichende Person)
  2. Pro --FNDE 15:44, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro--grim (Diskussion) 15:47, 20. Jun. 2017 (CEST)# (Klassisches Machine learning. Kommt vllt. in 20-30 Jahren.)[Beantworten]
  4. Pro --Noobius2 (Diskussion) 16:07, 20. Jun. 2017 (CEST)[Beantworten]
  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.[Beantworten]
  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)[Beantworten]
  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.[Beantworten]
  8. Kontra Möglicherweise nicht realisierbar. --Suriyaa Kudo · Archiv (Diskussion) 13:33, 22. Jun. 2017 (CEST)[Beantworten]
  9. Kontra -- - Majo Senf - Mitteilungen an mich 23:58, 24. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Lemke, Martin (Diskussion) 08:51, 26. Jun. 2017 (CEST) Im Sinne eines interaktiven Vorschlagwerkzeugs[Beantworten]
  11. Pro --Thomas Obermair 4 (Diskussion) 16:34, 28. Jun. 2017 (CEST)[Beantworten]
  12. Kontra und meine erfahrung auf commons: die tools schlagen nur schrott oder viel zu hochgegriffene kategorien, zu oft auch mehrfach ober- mit unterkategorien vor, die kann man sich durchwegs sowieso sparen, oder wir müssen noch viel mehr ausmisten: den commons-kuddelmuddel brauchen wir soweiso nicht. bitte nur nichts für anfänger leichter machen: eintragen ist viel leichter als aufspüren von fehleinsortierungen. dass unser kategoriensystem das gegenteil von automatisch ist, nämlich feinst-handverlesen, ist unsere eigentliche stärke. assoziativ-begriffswolken gibts andernorts. wir haben ein projekt mit kategorien-spezialisten und zahlreiche fachprojekte, die jederzeit gerne helfen (und sowieso im hintergrund nachkategorisieren). --W!B: (Diskussion) 13:23, 29. Jun. 2017 (CEST)[Beantworten]
  13. Neutral Siehe dazu: en:Wikipedia:HotCat. --Fixuture (Diskussion) 19:53, 1. Jul. 2017 (CEST)[Beantworten]
  14. Pro --ProloSozz (Diskussion) 17:18, 2. Jul. 2017 (CEST) Auch wenn der Vorschlag ungeschickt formuliert sein mag: die Idee dahinter wäre schon sehr nützlich. Dabei geht es wohl nicht um "Bot-Arbeit", sondern um strukturelle Unterstützung.[Beantworten]

Cat-a-lot in der Wikipedia

[Quelltext bearbeiten]
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

Z thomas Thomas 11:19, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:27, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- X:: black ::X (Diskussion) 12:29, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Aristeas (Diskussion) 17:45, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --  Sir Gawain Disk. 20:38, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --KEO144000 (Diskussion) 19:07, 24. Jun. 2017 (CEST)[Beantworten]
  7. Pro --DomenikaBo (Diskussion) 15:48, 26. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Adnon (Diskussion) 07:10, 28. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 16:36, 28. Jun. 2017 (CEST)[Beantworten]
  10. Kontra Defacto ist die Verwendung von Cat-a-lot schon jetzt möglich (man muß nur wissen wie), aber das ist mMn flächendeckend gar nicht wünschenswert und sollte Benutzern vorbehalten bleiben, die wissen was sie tun, weil sie wissen warum sie es tun. Letztendlich gibt es dazu sowieso Alternativen wie z.B. AWB. --Matthiasb – (CallMyCenter) 01:25, 29. Jun. 2017 (CEST)[Beantworten]
  11. ProDerHexer (Disk.Bew.) 21:48, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro -- Kai Kemmann (Diskussion) - Verbessern statt löschen - 00:05, 12. Apr. 2021 (CEST)[Beantworten]

"Diff" über viele Versionen

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro H-stt (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 13:17, 19. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  5. Pro --DomenikaBo (Diskussion) 15:49, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:36, 28. Jun. 2017 (CEST)[Beantworten]
  7. Neutral Ist doch bereits möglich. Einfach in den Einstellungen die Anzahl der Diffs in der Versionsgeschichte per Default auf 500 setzen und dann auswählen. Allerdings wäre ein Button "Zeige Diff aller Änderungen seit dem letzten Besuch" (oÄ) sehr nützlich. --Fixuture (Diskussion) 19:57, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:25, 2. Jul. 2017 (CEST) wäre hilfreich[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro H-stt (Einreichende Person)
  2. Pro --FNDE 15:47, 20. Jun. 2017 (CEST) macht Sinn[Beantworten]
  3. Pro Michi 19:19, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Freddy2001 DISK 12:04, 24. Jun. 2017 (CEST)[Beantworten]
  5. Pro --DomenikaBo (Diskussion) 15:49, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:36, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --W!B: (Diskussion) 13:30, 29. Jun. 2017 (CEST) klingt sinnvoll und erscheint einem kollaborativen projekt angemessen.[Beantworten]
  8. ProDerHexer (Disk.Bew.) 21:49, 1. Jul. 2017 (CEST)[Beantworten]

WP:Templatetiger wieder nutzbar machen

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Mabschaaf (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 15:28, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro тнояsтеn 12:47, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro«« Man77 »» (A) wie Autor 14:07, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Horgner (Diskussion) 14:19, 20. Jun. 2017 (CEST)[Beantworten]
  6. ProQueryzo ?! 14:46, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --XanonymusX (Diskussion) 14:59, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro DCB (DiskussionBewertung) 15:19, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --PerfektesChaos 23:31, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Kein Einstein (Diskussion) 14:50, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Thomas Obermair 4 (Diskussion) 16:37, 28. Jun. 2017 (CEST)[Beantworten]

[Quelltext bearbeiten]
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 daSkin-Entwurf 18:00, 2. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Morten Haan (Einreichende Person)
  2. Pro --FNDE 15:49, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --KEO144000 (Diskussion) 19:12, 24. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:37, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- hgzh 19:29, 29. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Shoeper 17:50, 30. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Fixuture (Diskussion) 19:59, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --Drahreg01 (Diskussion) 22:03, 1. Jul. 2017 (CEST)[Beantworten]
  9. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:31, 2. Jul. 2017 (CEST) aber bitte nicht für externe Domains. Die oben vorgeschlagene minimale Liste ist schon gut so[Beantworten]

Fehlkategorisierung durch #ifexist-Bug

[Quelltext bearbeiten]
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

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

Unterstützung
  1. Pro Man77 (Einreichende Person)
  2. Pro --Atamari (Diskussion) 12:28, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --C21H22N2O2 (V • T • E) 14:30, 19. Jun. 2017 (CEST)[Beantworten]
  4. ProQueryzo ?! 22:39, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:38, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro -- hgzh 19:29, 29. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Mabschaaf 22:54, 1. Jul. 2017 (CEST)[Beantworten]

Werkzeug zum Auffinden fehlerhaft gesetzter Koordinaten

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Man77 (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:07, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro тнояsтеn 12:54, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro DCB (DiskussionBewertung) 15:20, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Noobius2 (Diskussion) 16:08, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Claell (Diskussion) 19:24, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Kenny McFly (Diskussion) 19:48, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --DomenikaBo (Diskussion) 15:51, 26. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Incabell (Diskussion) 17:44, 27. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 16:39, 28. Jun. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:10, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --C21H22N2O2 (V • T • E) 14:31, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Blik (Diskussion) 16:44, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Claell (Diskussion) 19:25, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro mauriceKA (Diskussion) 13:28, 23. Jun. 2017 (CEST)[Beantworten]
  7. Kontra -- Nichtich (Diskussion) 23:08, 23. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Wrev (Diskussion) 22:50, 25. Jun. 2017 (CEST)[Beantworten]
  9. Pro --DomenikaBo (Diskussion) 15:52, 26. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 16:39, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro --Hanekomi (Diskussion) 01:57, 2. Jul. 2017 (CEST)[Beantworten]
  13. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:37, 2. Jul. 2017 (CEST) jupp[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
    Nachbemerkung: ausschließlich ein enges Zeitlimit (von 3-9 Minuten) behagt mir nur bedingt, wäre aber sicher eine Option, wenn Fehler sofort erkannt werden. Oft kommt es aber vor, daß Fehler erst viel später bemerkt werden; auch die sollten noch bereinigbar sein. Ich denke dabei z.B. an ein später auf Antrag wieder freischaltbares Zeitfenster (o.e. Dauer), das z.B. im Voraus angemeldet und von einem Admin freigeschaltet werden müßte; der Admin kontrolliert dann auch, daß die Änderungen nur Korrekturen sind o.ä. --ProloSozz (Diskussion) 19:13, 2. Jul. 2017 (CEST)[Beantworten]
  2. Pro -- X:: black ::X (Diskussion) 14:13, 19. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  4. Pro--grim (Diskussion) 15:49, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --FNDE 15:51, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Peter Gröbner -- 16:57, 20. Jun. 2017 (CEST) innerhalb eines engen Zeitfensters (z.B. 5 Minuten) wie Karl432[Beantworten]
  7. Pro -- ebenso, man vertippt sich immer wieder einmal --Keuk (Diskussion) 19:04, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --FriedhelmW (Diskussion) 20:43, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Avron (Diskussion) 18:48, 21. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Jossi (Diskussion) 13:37, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro«« Man77 »» (A) wie Autor 21:22, 22. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  13. Pro -- Freddy2001 DISK 12:05, 24. Jun. 2017 (CEST)[Beantworten]
  14. Pro -- - Majo Senf - Mitteilungen an mich 23:59, 24. Jun. 2017 (CEST)[Beantworten]
  15. Pro mit (kleinem) Zeitfenster --Mushushu (Diskussion) 16:33, 25. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Wrev (Diskussion) 22:51, 25. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Klaus Eifert (Diskussion) 00:54, 26. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Lemke, Martin (Diskussion) 08:55, 26. Jun. 2017 (CEST)[Beantworten]
  19. Pro --DomenikaBo (Diskussion) 15:52, 26. Jun. 2017 (CEST)[Beantworten]
  20. Pro --MannMaus (Diskussion) 19:01, 27. Jun. 2017 (CEST)[Beantworten]
  21. Pro -- Density Disk. 20:37, 27. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Thomas Obermair 4 (Diskussion) 16:39, 28. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Innobello (Diskussion) 09:37, 29. Jun. 2017 (CEST) mit engem Zeitfenster[Beantworten]
  24. Pro -- Nicola - Ming Klaaf 09:47, 29. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  26. Pro -- Mboesch (Diskussion) 11:33, 1. Jul. 2017 (CEST)[Beantworten]
  27. Pro 3 Minuten Zeitfenster für Editierungen Kontra alles über 9 Minuten. --Fixuture (Diskussion) 20:01, 1. Jul. 2017 (CEST)[Beantworten]
  28. Pro --Drahreg01 (Diskussion) 22:05, 1. Jul. 2017 (CEST)[Beantworten]
  29. Pro --Mabschaaf 22:55, 1. Jul. 2017 (CEST)[Beantworten]
  30. Pro --Hanekomi (Diskussion) 01:57, 2. Jul. 2017 (CEST)[Beantworten]
  31. Pro --Sitacuisses (Diskussion) 13:47, 2. Jul. 2017 (CEST)[Beantworten]
  32. Pro Eigene Einträge sollten innerhalb einer begrenzten Zeit leicht korrigierbar bleiben. --Mewa767 (Diskussion) 02:33, 3. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro ProloSozz (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:18, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --C21H22N2O2 (V • T • E) 14:32, 19. Jun. 2017 (CEST) Und am besten auch beim "Änderungen zeigen" während einer Bearbeitung[Beantworten]
  4. Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Klaus Eifert (Diskussion) 00:56, 26. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:40, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --Sitacuisses (Diskussion) 13:49, 2. Jul. 2017 (CEST)[Beantworten]

Fehlende gegenseitige Verlinkung feststellen

[Quelltext bearbeiten]
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

Benutzer:Hgzh hat ein entsprechendes Tool geschrieben und mich am 29. Juni darauf aufmerksam gemacht. Vielen Dank dafür! --Sitacuisses (Diskussion) 12:09, 30. Jun. 2017 (CEST)[Beantworten]

Vorschlagende Person

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

Unterstützung
  1. Pro Sitacuisses (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:20, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --FNDE 15:52, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Iva 20:14, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Conny 22:48, 20. Jun. 2017 (CEST).[Beantworten]
  6. Pro Looperz (Diskussion) 02:45, 22. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Wrev (Diskussion) 22:53, 25. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Thomas Obermair 4 (Diskussion) 16:40, 28. Jun. 2017 (CEST)[Beantworten]
  9. Pro --W!B: (Diskussion) 13:42, 29. Jun. 2017 (CEST) (mir sind zwar die kriterien nicht klar, wann "eine gegenseitige Verlinkung von Artikeln erwartet wird", aber alles, was die vernetzung fördert, ist gut. wahrscheinlich wird man eine sammlung von bedingungen erarbeiten müssen, über die ein bot eine wartungslste erstellt. jedes "link nur in eine richtung vorhanden" erfassen geht sicherlich nicht, weil oberbegriffe nicht auf alle unterbegriffe linken. man denke schlicht an Deutschland.)[Beantworten]
    An Bot-Aktionen und Wartungslisten dachte ich weniger. Die jeweiligen Kriterien für gegenseitige Verlinkung sollte der aktuelle Benutzer im Kopf haben, ich möchte ihm nur ein kleines Hilfsmittel an die Hand geben, wie es Hgzh nun mit Page conjunction dankenswerterweise geschrieben hat. Deutschland auf diese Weise abzuarbeiten war nicht mein Plan, eher schon Biographien, Filmartikel und Schutzgebietslisten. --Sitacuisses (Diskussion) 12:43, 30. Jun. 2017 (CEST)[Beantworten]

Mehr Sperrmöglichkeiten gegen besonders massiven Vandalismus

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro DerHexer (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:23, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 15:21, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --FNDE 15:53, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Zabia (Diskussion) 17:21, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --  Sir Gawain Disk. 20:43, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Conny 22:49, 20. Jun. 2017 (CEST).[Beantworten]
  8. Pro Michi 19:22, 21. Jun. 2017 (CEST)[Beantworten]
  9. Pro @MGChecker: (nicht signierter Beitrag von MGChecker (Diskussion | Beiträge) 21. Juni 2017, 19:43 Uhr) , siehe auch #Benutzersperren flexibler gestalten (Punkt 3). --19:43, 21. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  11. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:34, 22. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Konfressor (Diskussion) 21:39, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro --ArthurMcGill (Diskussion) 09:27, 23. Jun. 2017 (CEST)[Beantworten]
  14. Pro KPFC💬 15:20, 23. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Klaus Eifert (Diskussion) 00:58, 26. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Incabell (Diskussion) 17:45, 27. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Gr1 (Diskussion) 16:48, 28. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Thomas Obermair 4 (Diskussion) 16:50, 28. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Karl-Heinz (Diskussion) 09:33, 29. Jun. 2017 (CEST)[Beantworten]
  20. Pro -- hgzh 19:30, 29. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Anima (Diskussion) 12:14, 30. Jun. 2017 (CEST)[Beantworten]
  22. Pro // Martin K. (Diskussion) 12:29, 30. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  24. Pro --Whisker (Diskussion) 21:47, 1. Jul. 2017 (CEST)[Beantworten]
  25. Pro --Boehm (Diskussion) 10:05, 2. Jul. 2017 (CEST)[Beantworten]
  26. ProGhilt (Diskussion) 10:01, 4. Jul. 2017 (CEST)[Beantworten]

VisualFileChange für die de.Wikipedia

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 15:22, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Freddy2001 DISK 12:05, 24. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Lemke, Martin (Diskussion) 09:15, 26. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:50, 28. Jun. 2017 (CEST)[Beantworten]

Wiedervorlagefunktion von Artikeln auf einen wählbaren Zeitpunkt

[Quelltext bearbeiten]
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? ein lächelnder Smiley  -- Nicola - Ming Klaaf 11:10, 15. Jun. 2017 (CEST)[Beantworten]

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)[Beantworten]
Wen betrifft das Problem besonders?

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

Anmerkungen

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch werden künftig hier dokumentiert.

Vorschlagende Person

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

Unterstützung
  1. Pro Nicola (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:29, 19. Jun. 2017 (CEST) - geniale Idee[Beantworten]
  3. Pro -- X:: black ::X (Diskussion) 14:34, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Z thomas Thomas 11:20, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Adnon (Diskussion) 15:04, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro DCB (DiskussionBewertung) 15:23, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Eingangskontrolle (Diskussion) 15:51, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --FNDE 15:55, 20. Jun. 2017 (CEST) sehr coole Idee[Beantworten]
  9. Pro --Blik (Diskussion) 16:47, 20. Jun. 2017 (CEST) ... dass da vorher noch niemand dran gedacht hat…[Beantworten]
  10. Pro -- Peter Gröbner -- 16:59, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Abubiju (Diskussion) 17:14, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Andropov (Diskussion) 17:41, 20. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Gnom (Diskussion) 18:15, 20. Jun. 2017 (CEST)[Beantworten]
  14. Pro --h-stt !? 18:31, 20. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Nuhaa (Diskussion) 18:38, 20. Jun. 2017 (CEST)[Beantworten]
  16. Pro --  Sir Gawain Disk. 20:45, 20. Jun. 2017 (CEST)[Beantworten]
  17. Pro --jcornelius Benutzer Diskussion:Jcornelius 11:43, 21. Jun. 2017 (CEST)[Beantworten]
  18. Pro wäre mir auch beim Nachsichten eine große Hilfe. Silke (Diskussion) 15:38, 21. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Carolus requiescat (Diskussion) 17:24, 21. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Avron (Diskussion) 18:51, 21. Jun. 2017 (CEST) für einige Sonderthemen sicherlich interessant[Beantworten]
  21. Pro --Kenny McFly (Diskussion) 19:55, 21. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Pelz (Diskussion) 23:08, 21. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:34, 22. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Jossi (Diskussion) 13:40, 22. Jun. 2017 (CEST)[Beantworten]
  25. Pro --GodeNehler (Diskussion) 19:38, 22. Jun. 2017 (CEST)[Beantworten]
  26. Pro«« Man77 »» (A) wie Autor 21:23, 22. Jun. 2017 (CEST)[Beantworten]
  27. Pro --ArthurMcGill (Diskussion) 09:28, 23. Jun. 2017 (CEST)[Beantworten]
  28. Pro --DianeAnna (Diskussion) 13:14, 23. Jun. 2017 (CEST)[Beantworten]
  29. Pro --Atamari (Diskussion) 14:58, 23. Jun. 2017 (CEST)[Beantworten]
  30. Pro -- Nichtich (Diskussion) 23:10, 23. Jun. 2017 (CEST)[Beantworten]
  31. Pro -- Freddy2001 DISK 12:06, 24. Jun. 2017 (CEST)[Beantworten]
  32. Pro --DomenikaBo (Diskussion) 15:54, 26. Jun. 2017 (CEST)[Beantworten]
  33. Pro --Thomas Obermair 4 (Diskussion) 16:50, 28. Jun. 2017 (CEST)[Beantworten]
  34. Pro --Ak ccm (Diskussion) 00:34, 29. Jun. 2017 (CEST)[Beantworten]
  35. Pro --Flo Beck (Diskussion) 12:53, 29. Jun. 2017 (CEST)[Beantworten]
  36. Pro --Hartmann Linge (Diskussion) 13:59, 30. Jun. 2017 (CEST)[Beantworten]
  37. Pro --Häuslebauer (Diskussion) 18:06, 30. Jun. 2017 (CEST) Ebenfalls sinnvoll, um bei wenig beobachteten Artikel ein paar Tage / Wochen auf Feedback zu Vorschlagen zu waren, es dann aber zwischenzeitlich nicht zu vergessen[Beantworten]
  38. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  39. Pro Für "Artikelerinnerungen". Popups und/oder Benachrichtigungen über Artikel − am besten mit einstellbarem Kommentar − zu einstellbaren Zeitpunkten oder in einstellbaren Intervallen. Das wäre auch nützlich wenn man einen Artikel editiert hat und später nachschauen möchte wie die eigenen Edits im Artikel weitergeführt werden ohne den Artikel gleich auf die Watchlist setzen zu müssen. --Fixuture (Diskussion) 20:08, 1. Jul. 2017 (CEST)[Beantworten]
  40. ProDerHexer (Disk.Bew.) 21:58, 1. Jul. 2017 (CEST)[Beantworten]
  41. Pro --Drahreg01 (Diskussion) 22:09, 1. Jul. 2017 (CEST)[Beantworten]
  42. Pro -- Platte ∪∩∨∃∪ 23:05, 1. Jul. 2017 (CEST)[Beantworten]
  43. Pro --Neigschmeckter (Diskussion) 12:55, 2. Jul. 2017 (CEST)[Beantworten]
  44. Pro --Sitacuisses (Diskussion) 14:00, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

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)[Beantworten]

Vorschlagende Person

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

Unterstützung
  1. Pro X:: black ::X (Einreichende Person)
  2. Pro --Jossi (Diskussion) 13:42, 22. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Thomas Obermair 4 (Diskussion) 16:51, 28. Jun. 2017 (CEST)[Beantworten]

[Quelltext bearbeiten]
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)

Anmerkungen

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch werden künftig hier dokumentiert.

Vorschlagende Person

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

Unterstützung
  1. Pro Ubahnverleih (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 14:38, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Karl432 (Diskussion) 22:04, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro  hugarheimur 09:16, 20. Jun. 2017 (CEST) Sehr gute Idee. Ich glaube, die französischsprachigen Kollegen haben schon etwas ähnliches.[Beantworten]
  5. --Z thomas Thomas 11:21, 20. Jun. 2017 (CEST)@Z thomas:Pro[Beantworten]
  6. Pro --Horgner (Diskussion) 14:17, 20. Jun. 2017 (CEST) Unbeding, sowas wünsche ich mir schon lange![Beantworten]
  7. Pro DCB (DiskussionBewertung) 15:23, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Eingangskontrolle (Diskussion) 15:55, 20. Jun. 2017 (CEST) Aber nicht nach jedem Abspeichern, sondern nur beim Setzen des Links[Beantworten]
  9. Pro --FNDE 15:57, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro Zabia (Diskussion) 17:23, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Claell (Diskussion) 19:26, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro Iva 20:16, 20. Jun. 2017 (CEST)[Beantworten]
  13. Pro --  Sir Gawain Disk. 20:45, 20. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Wikifreund (Diskussion) 00:17, 21. Jun. 2017 (CEST) archive.org kann dennoch Inhalte löschen.[Beantworten]
  15. Pro --MSchnitzler2000 (Diskussion) 00:41, 21. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Drahreg01 (Diskussion) 06:37, 21. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Nightflyer (Diskussion) 12:59, 21. Jun. 2017 (CEST)[Beantworten]
  18. Pro Conny 13:41, 21. Jun. 2017 (CEST).[Beantworten]
  19. Pro -- Silke (Diskussion) 15:36, 21. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Avron (Diskussion) 18:49, 21. Jun. 2017 (CEST) Nicht unbedingt bei allen Links aber wünschenswert bei Einzelnachweisen[Beantworten]
  21. Pro Michi 19:22, 21. Jun. 2017 (CEST)[Beantworten]
  22. Pro Die Idee ist ja genial. --MGChecker – (📞| 📝| Bewertung) 19:42, 21. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Kenny McFly (Diskussion) 19:56, 21. Jun. 2017 (CEST)[Beantworten]
  24. Pro Looperz (Diskussion) 02:43, 22. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:35, 22. Jun. 2017 (CEST)[Beantworten]
  26. Pro, mit von den anderen genannten Limitierungen … «« Man77 »» (A) wie Autor 21:25, 22. Jun. 2017 (CEST)[Beantworten]
  27. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 01:08, 23. Jun. 2017 (CEST)[Beantworten]
  28. Pro --ArthurMcGill (Diskussion) 09:30, 23. Jun. 2017 (CEST)[Beantworten]
  29. Pro KPFC💬 15:30, 23. Jun. 2017 (CEST)[Beantworten]
  30. Pro -- Nichtich (Diskussion) 23:10, 23. Jun. 2017 (CEST)[Beantworten]
  31. Pro --Mushushu (Diskussion) 16:36, 25. Jun. 2017 (CEST)[Beantworten]
  32. Pro --Wrev (Diskussion) 22:55, 25. Jun. 2017 (CEST)[Beantworten]
  33. Pro --Klaus Eifert (Diskussion) 01:01, 26. Jun. 2017 (CEST)[Beantworten]
  34. Pro --DomenikaBo (Diskussion) 15:55, 26. Jun. 2017 (CEST)[Beantworten]
  35. Pro // Martin K. (Diskussion) 19:34, 26. Jun. 2017 (CEST)[Beantworten]
  36. Pro --Kein Einstein (Diskussion) 14:51, 28. Jun. 2017 (CEST)[Beantworten]
  37. Pro --Gr1 (Diskussion) 16:49, 28. Jun. 2017 (CEST)[Beantworten]
  38. Pro --Thomas Obermair 4 (Diskussion) 16:51, 28. Jun. 2017 (CEST)[Beantworten]
  39. Pro --Ak ccm (Diskussion) 00:37, 29. Jun. 2017 (CEST) Für Einzelnachweise sehr praktisch; klappt aber wahrscheinlich nicht, wenn die robots.txt der zu archivierenden Website das nicht zulässt.[Beantworten]
  40. Pro --Matthiasb – (CallMyCenter) 01:27, 29. Jun. 2017 (CEST) Auf alle Fälle.[Beantworten]
  41. Pro --Stobaios 16:52, 29. Jun. 2017 (CEST)[Beantworten]
  42. Pro --theredmonkey 11:26, 30. Jun. 2017 (CEST)[Beantworten]
  43. Pro -- Shoeper 17:56, 30. Jun. 2017 (CEST)[Beantworten]
  44. Pro --Berlinschneid (Diskussion) 01:17, 1. Jul. 2017 (CEST)[Beantworten]
  45. Pro Und zeitgleich sollte auch der Zeitpunkt des Abspeicherns in Verbindung mit der URL und dem entsprechenden Artikel gespeichert werden. Wenn die Seite dann down ist kann ein Bot den externen Link mit genau dieser Version (Archivlink dieses Zeitpunkts) ersetzen. --Fixuture (Diskussion) 20:11, 1. Jul. 2017 (CEST)[Beantworten]
  46. Pro --Whisker (Diskussion) 21:48, 1. Jul. 2017 (CEST)[Beantworten]
  47. ProDerHexer (Disk.Bew.) 21:59, 1. Jul. 2017 (CEST)[Beantworten]
  48. Pro --Mabschaaf 22:56, 1. Jul. 2017 (CEST)[Beantworten]
  49. Pro --alexscho (Diskussion) 23:43, 1. Jul. 2017 (CEST)[Beantworten]
  50. Pro --Linopolus (Diskussion) 11:09, 2. Jul. 2017 (CEST)[Beantworten]
  51. Pro --Andrea014 (Diskussion) 11:55, 2. Jul. 2017 (CEST) wenn gesichert wäre, dass Links auf illegale Seiten oder solche mit illegalen Inhalten davon ausgenommen wären.[Beantworten]
  52. Pro --Neigschmeckter (Diskussion) 13:02, 2. Jul. 2017 (CEST)[Beantworten]
  53. Pro --Entbert (Diskussion) 16:08, 2. Jul. 2017 (CEST)[Beantworten]

Hilfe beim Überprüfen von Datenquellen

[Quelltext bearbeiten]
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

Z thomas Thomas 19:36, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro Conny 13:42, 21. Jun. 2017 (CEST).[Beantworten]
  3. Pro --Eisbaer44 (Diskussion) 11:14, 28. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:52, 28. Jun. 2017 (CEST)[Beantworten]