Wikipedia:Verbesserungsvorschläge/Archiv/2016/September

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Verbesserungsvorschläge/Archiv/2016/September#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Archiv/2016/September#Thema_1

„Interessentenliste“ für Rotlinks möglich?

Wem unter uns Autoren ist es nicht schon mal passiert, dass man ohne es zu wissen parallel mit einem anderen Benutzer den gleichen Artikel zur Veröffentlichung vorbereitete? Mir ist das im letzten Monat nach langer Zeit mal wieder passiert. Und heute war ich knapp schneller, als ein anderer Benutzer, der sich für das gleiche Thema interessierte. Solche Fälle mögen Ausnahmen darstellen, aber ich frage mich, ob es nicht technisch realisierbar wäre, eine Art „Interessentenliste“ für Rotlinks zu erstellen?

Meine (naiven?) Vorstellungen: Man klickt auf einen Rotlink und neben dem „Erstellen“-Button steckt eine weiterer Reiter namens „Reservieren“ o. ä. Der Benutzer interessiert sich für das Thema und kann im Bedarfsfall ein Interesse an der Artikelerstellung bekunden. Ist der Rotlink irgendwo im Artikelnamensraum verlinkt, taucht eine Ziffer ähnlich bei Meldungen/Mitteilungen im Seitenkopf auf, mit der Anzahl der Nutzer, die sich für eine Artikelerstellung interessieren. Ein Popup-Menü öffnet sich, wenn man über die Ziffer fährt – „Benutzer Lieschen Müller und Benutzer Manuel Mustermann interessieren sich für das Thema seit X Tagen“. Positiv wäre, das unnötige Doppelarbeit in Zukunft verhindert werden könnte. Die Nutzer treten miteinander in Kontakt und profitieren evtl. sogar von der Vorrecherche eines anderen, der keine Zeit für die Artikelerstellung hat. Die Gefahr bestünde natürlich, dass sich Nutzer reihenweise ihre Lieblingslemmata sichern. Man könnte solch eine Interessensbekundung auch zeitlich befristen (4-6 Wochen?), wenn das überhaupt technisch umsetzbar ist. Grüße, --César (Diskussion) 18:17, 4. Sep. 2016 (CEST)

Es würde doch schon reichen, auf der Benutzerseite einen Link auf den geplanten Artikel zu setzen, mit einem kleinen Kommentar. Grüße -- FriedhelmW (Diskussion) 18:26, 4. Sep. 2016 (CEST)

Der Vorschlag ist mE unpraktikabel. Die meisten, die sich To-Do-Lists oder ähnliches anlegen, sammeln Rotlinks, aber klicken sich nicht bis zu ihnen durch. Damit würde ein solch von dir vorgeschlagenes Kommentar auf der Diskussionsseite wohl eher unbemerkt bleiben. --César (Diskussion) 18:37, 4. Sep. 2016 (CEST)

Ich meine nicht die Diskussionsseite sondern die Benutzerseite. Mit "Links auf diese Seite" weiß man dann sofort Bescheid. -- FriedhelmW (Diskussion) 18:53, 4. Sep. 2016 (CEST)

Tut mir leid, da hatte ich mich verlesen. Halte ich aber auch für unpraktikabel. Schon bei Verschiebungen im Filmbereich wird oft von langjährigen Autoren vergessen auf diese Seite zu gucken und die Links anzupassen. --César (Diskussion) 19:03, 4. Sep. 2016 (CEST)

Zur technischen Realisierung gäbe es zwei Schienen:

1. weltweit = MediaWiki-Software
   • Da würde ich schwarz sehen; Situation ist zu selten und eine Entwicklungslinie über eine zusätzliche Datenbanktabelle würde man kaum anpacken wollen.
   • Technisch machbar.
2. lokal = deutschsprachige Wikipedia
   • Wir könnten sowas über unsere newarticletext per sofort einführen.
   • Es müsste eine Tabelle über Seitennamen geführt werden, und wenn jemand für diesen Seitennamen etwas erstellen möchte, könnte eine fette Kiste mit einem spezifischen Hinweis (Link zum Benutzer) angezeigt werden.
   • Lua würde sich für die Realisierung empfehlen.
   • Auch hier glaube ich nicht, dass sich jemand den Pflege- und Betreuungs- und Entwicklungsaufwand antun würde.

Das größere Problem würde darin liegen, dass sowas überhaupt nicht greift.

• Im Januar sieht jemand (Benutzer-A) den redlink und überlegt sich, dafür mal einen Artikel schreiben zu wollen.
• Anfang Februar hatte man genug Material beisammen und Benutzer-A
  • legt eine Reservierung an
  • beginnt im BNR einen zehn Bildschirmseiten langen Artikel vorzubereiten.
• Ende Januar sieht Benutzer-B den redlink und überlegt sich, einen Artikel schreiben zu wollen.
  • B klickt natürlich nicht sinnlos auf ein redlink.
  • Es hätte auch keine Erkenntnisse gebracht; weder gab es eine Reservierung noch wurde irgendwo hin verlinkt.
• Anfang Februar hat B in seinem BNR einen fünf Bildschirmseiten langen Artikel fertiggestellt.
  • Nun soll er in den ANR verschoben werden.
  • Dabei kommt heraus, dass dort drei Stunden vorher eine Reservierung eingetragen wurde.
• Selbst wenn die zeitlichen Abläufe sich nicht so überschnitten hätten, ist B nicht dazu verpflichtet, vorher und täglich auf redlinks zu klicken; noch muss irgendwer wissen, dass sowas einmal jährlich eine wertvolle Info liefern würde, noch war B verpflichtet, vor der Arbeit im BNR eine Reservierung anzulegen oder muss sowas auch nur gewusst haben.

Kurzum: Eine solche Überschneidung kann technisch nicht sinnvoll abgewendet werden ohne massiven Verwaltungsaufwand und Nachschulung aller Autoren und zusätzlicher Hürden für Erstautoren; und damit illusorisch.

VG --PerfektesChaos 20:06, 4. Sep. 2016 (CEST)

Man könnte die Regel umsetzen "wer schreibt ohne zu reservieren, hat im Zweifelsfall Pech gehabt und darf die Zusammenführung machen". Aber sowas ist unrealistisch - ein solches MB wird keine Chance haben.

Bei eindeutigem Lemma: Entwurf im BNR anlegen mit eindeutigem Namen, Verlinkung auf Ziellemma. So lässt sich über "was verlinkt auf diese Seite" der Entwurf finden, und wenn "Benutzer:blub/Caracas.2C_eine_Liebe" auf "Caracas, eine Liebe" verlinkt, dann könnte das ein Artikelentwurf sein (...). Bei nicht eindeutigem Lemma hilft das nicht, aber da versagt auch jede technische Umsetzung.

Noch eine Alternative: Als Stub anlegen, auf der Diskussionsseite weitere Pläne ankündigen. --mfb (Diskussion) 20:29, 4. Sep. 2016 (CEST)

Änderung von „Suchen & Ersetzen“

Wäre es möglich, die Funktion „Suchen & Ersetzen“ so zu konfigurieren, dass sie nicht innerhalb von Dateinamen „sucht und ersetzt“ oder nur wenn man das explizit möchte? LG -- Metrophil 19:28, 21. Sep. 2016 (CEST)

Meinst du den wikEd? -- FriedhelmW (Diskussion) 19:36, 21. Sep. 2016 (CEST)

Es gibt auch ein Suchen und Ersetzen in der erweiterten Bearbeitungsleiste ("Assistenten zum Einfügen von Links und Tabellen sowie die Funktion „Suchen und Ersetzen“ aktivieren"). Da diese Funktion keinerlei Kenntnisse über die verschiedenen Bestandteile des Wikitext kennt, wird das wohl schwierig. Die Schwierigkeit ist halt den Wikitext zu interpretieren und zu sagen, was Dateinamen sind, was Wikilinks sind. Es kann aber auch Situationen geben, wo eine solche Ersetzung erwünscht ist. Dies kommt wohl auf den aktuellen Ersetzungsfall an. Der Umherirrende 22:01, 21. Sep. 2016 (CEST)

@Metrophil: Ich halte diesen Wunsch so oder so im Allg. für sehr fragwürdig. Falls es mal solch eine Situation geben sollte (die da wäre?) ein Dateiname ist dann immer noch in den allermeisten Fällen einzigartig (also für eine Massenersetzung alles andere als maßgebend und einfach händisch zu korr.). Evtl. suchst du ja etwas anderes, wenn du sagst was du konkret möchtest. Mir würde da z.B. eine Bindestrich oder andere Sonderzeichen-Ersetzungen einfallen, für die es dann tatsächlich Tools gibt die dies unterscheiden können, s. WP:WPSK) ↔ User: Perhelion 22:53, 21. Sep. 2016 (CEST)

Hierfür gibt es fertige Tools. Eine Möglickkeit ist der [[Benutzer:TMg/autoFormatter|Autoformatter von TMg] (erledigt eine ganze Menge an Syntaxkorrekturen + zusätzliche Benutzerdefinierte Regexp) eine weitere Möglichkeit ist Benutzer:Boshomi/ARreplace. Dieses Tool setzt auf AutoFormatter auf, wobei auf die Syntaxkorrekturen verzichtet wird, und nur die Ersetzungsfunktion ausgebaut ist (Möglichkeit automatisch die Zusammenfassungszeile gleich mitzubefüllen. Beide Tools zeigen unmittelbar mit der Verwendung auch gleich das Diff an, wenn man autoFormatter/autoDiffb und Schnark/Diff aktiviert hat.

Beispiel für die Einbindung: https://meta.wikimedia.org/wiki/User:Boshomi/global.js (Autoformatter und Schnark/Diff habe ich über Fliegelflagel aktiviert) Frohes Schaffen — Boshomi ⌨   23:39, 21. Sep. 2016 (CEST)

Man kann einfach den VisualEditor verwenden. Dort gibt es eine wesentlich komfortablere Suchen-und-Ersetzen-Funktion, und es besteht keine Gefahr, dass diese versehentlich Dateinamen oder andere Syntax mitverarbeitet. --Schnark 08:52, 22. Sep. 2016 (CEST)

class="mobileonly"

... als Gegenteil zu class="nomobile", für die unterschiedliche Gestaltung von Portalseiten je nach mobil oder nicht. --Reinhard Müller (Diskussion) 19:09, 21. Sep. 2016 (CEST)

... oder eine andere Möglichkeit, in Portalseiten einen individuellen "style" bei mobil und nicht-mobil unterschiedlich zu machen, z.B. in der Standard-Ansicht in 2 Spalten ausgerichtet und in der Mobil-Ansicht einspaltig. --Reinhard Müller (Diskussion) 15:29, 26. Sep. 2016 (CEST)