Vor genau zwei Jahren hatte der Autor dieser Umfrage (Raymond) zum ersten Mal die Community gefragt: Was für technische Wünsche habt ihr? Wo klemmt es, was wird dringend an technischer Unterstützung benötigt? Der Hintergrund war damals Widerstand „der Community“ gegen „von oben“ verordnete neue Features, weil manches im Betastadium als Standard aktiviert oder einfach als unnötig erachtet wird.
In den vergangenen zwei Jahren hat sich vieles getan. Aus der Top-20-Wunschliste wurden folgende Wünsche erfüllt:
Warnhinweis oder automatisches Einfügen von fehlendem <references />-Tag
Wikisyntax, um Permalinks und Difflinks als Wikilink angeben zu können
Verbesserung der Verschlüsselung von https-Verbindungen mittels Perfect Forward Secrecy
eine Spezialseite, die die von einem Benutzer neu angelegten Seiten ausgibt
Möglichkeit zur Suche im Quelltext
Tabellen in einer Form bearbeiten können, wie man es seit einigen Jahrzehnten aus Office-Programmen kennt
In den Zielgerade befinden sich die Wünsche:
„CatScan-Funktionalität“ in die Software integrieren
Möglichkeit, eine Kategorie auf neue Artikel hin zu beobachten
An der Realisierung weiterer Wünsche wird aktuell gearbeitet.
Ziel dieser Umfrage soll eine (priorisierte!) Liste von technischen Wünschen sein. Die Topwünsche werden vom Bereich Software-Entwicklung bei Wikimedia Deutschland gesichtet und angegangen. WMF-Entwicklungsteams, andere Chapter und freiwillige Entwicklerinnen und Entwickler sind herzlich eingeladen, sich an der Umsetzung einzelner Wünsche zu beteiligen.
Ausdrücklich erwünscht sind hier auch die Wünsche aller Schwesterprojekte. Falls ein Wunsch sehr projektspezifisch ist, bitte mit dem Projektnamen kennzeichnen.
Hier können genannt werden (bitte jeweils mit kurzer(!) Erklärung, für welchen Autorenkreis der Bug / das Feature von Bedeutung ist):
offene Bugs/Featurewünsche im Phabricator (ehemals Bugzilla).
Tools vom ToolLabs, die in MediaWiki integriert werden sollten, damit Abhängigkeiten von externen Servern gelöst werden
Gadgets/Helferlein/Tools, die aktuell defekt sind oder dringend modernisiert werden müssen
frei formulierte Wünsche
Das Team von Wikimedia Deutschland wird während des Sammelns von Wünschen für Rückfragen und Formulierungshilfen zur Verfügung stehen.
Wünsche, die bereits Realität oder in der Entwicklung sind[Quelltext bearbeiten]
Wenn jemand der Meinung ist, dass sein Wunsch zu unrecht hierher verschoben wurde weil die existierende/geplante Entwicklung noch nicht seinen Vorstellungen entspricht oder er missverstanden wurde, bitte den Wunsch diesbezüglich genauer formulieren und zurück verschieben!
An den Empfänger. Der Nutzen: manche Benutzer rufen ihre E-Mail-Konten nur selten ab, da sie normalerweise nur wenige E-Mails empfangen oder ein eigenes E-Mail-Konto nur für die Wikipedia besitzen. Eine Echo-Benachrichtigung wäre ein in diesem Fall hilfreicher Hinweis, doch mal wieder nach dem Posteingang zu schauen. -- hgzh23:40, 21. Sep. 2015 (CEST)[Beantworten]
Nachdem diese Umfrage den Nachfolger der alten von dir verlinkten Top 20-Liste bestimmen sollte und diese weiter abgearbeitet wird, ist der Wunsch hier überflüssig. -- Michi15:39, 21. Sep. 2015 (CEST)[Beantworten]
Damit kann man aber nur den Link stylen, nicht die ganze Zeile (oder andere Elemente in der Zeile). Außerdem ist das Stylen des Artikelnamensraums etwas umständlich (=Style für alles und alle anderen Namensräume dann wieder mit dem Standard überschreiben). Auch wenn ich das jetzt erstmal als Notbehelf einsetze: Eine Namensraum-Klasse am li wünsche ich mir trotzdem. --FeddaHeiko☺01:15, 22. Sep. 2015 (CEST)[Beantworten]
Suche: der Parameter incategory sucht nur in der angegebenen Kategorie, nicht in den Unterkategorien. Eine Funktionalität die einen Teilbaum durchsucht fehlt heute. Für Wikipedia vielleicht nicht so wichtig, aber für Commons um so mehr.--Avron (Diskussion) 14:54, 20. Sep. 2015 (CEST)[Beantworten]
Hilfsmittel zur Linksetzung: Man müsste im Editionsmodus durch bloßes Anklicken von Wörtern (oder Namen) angezeigt bekommen ob der Begriff/Name schon existiert bzw. welche Varianten dazu existieren. Das arbeiten mit mehreren Fenstern kostet immer sagenhaft viel Zeit. --Konrad Stein (Diskussion) 13:12, 22. Sep. 2015 (CEST)[Beantworten]
Wenn man ein Wort markiert und das Kettensymbol der Werkzeugleiste anklickt, dann wird einem doch neben Linkvorschlägen bereits angezeigt, ob die Seite bereits existiert oder nicht. Funktioniert sowohl im Wikitext-Editor als auch mit dem VisualEditor. --Schnark09:27, 23. Sep. 2015 (CEST)[Beantworten]
Wenn ich ein Wort markiere und das Kettensymbol klicke wird ein interner Link erzeugt (eckige Doppelklammern), ganz unabhängig davon ob ein entsprechender Artikel existiert oder nicht – und Vorschläge werden auch nicht angezeigt. Mache ich da was falsch oder sind da Einstellungen zu treffen? Dank für Hinweise --Konrad Stein (Diskussion) 12:22, 25. Sep. 2015 (CEST)[Beantworten]
Danke, ich habe es gerade ausprobiert und das geht schon in die richtige Richtung. Wenn ich aber einen Namen wie den des Komponisten "Sorge" verlinken will, aber dessen Vornamen gerade nicht präsent habe, bzw die WP-Form Georg Andreas Sorge nicht kenne, dann hilft es nicht sehr. Eine Suchfunktion wie intitle:Sorge wäre da sehr praktisch. Vielleicht ist das hier der falsche Ort - wo könnte ich diesen Wunsch denn besser platzieren? Vielen Dank jedenfalls, von --Konrad Stein (Diskussion) 17:40, 25. Sep. 2015 (CEST)[Beantworten]
Wiedervorlage: Ich wünsche mir eine Möglichkeit, einen Token (zB an meiner Beobachtungsliste) zu setzen, durch den ich an oder nach einem vorbestimmten Datum auf den markierten Artikel aufmerksam gemacht werde. Wie oft trägt man etwas ein, von dem schon klar ist, dass es zu einem bestimmten Datum überholt sein wird oder zumindest sein kann. Ich behelfe mir mit einer Liste außerhalb der WP, das wäre aber ein nützliches Feature für alle. Grüße --h-stt!?16:25, 19. Sep. 2015 (CEST)[Beantworten]
Ist vermutlich auch ein alter Hut: Ich möchte nur einen Eintrag in meine Beo von dem Abschnitt von LDs, den ich auch bearbeitet habe, nicht von den ganzen Tagesdiskussionen. Geolinamente et malleo✎20:43, 21. Sep. 2015 (CEST)[Beantworten]
Möglichkeit, einen Artikel zeitlich begrenzt in die Beobachtungsliste aufnehmen zu können, also z.B. für "7 Tage beobachten", wobei die Zeit nach Möglichkeit selbst festlegbar sein sollte. --Tobias1983Mail Me10:31, 26. Sep. 2015 (CEST)[Beantworten]
Ok DANKE, zeigt wieder auf das ein "Portal der Tools" fehlt. Aber: kann man so eine Funktion nicht als Gadget einer Kategorie-Seite einbinden. Außerdem kann man nicht auf allen Rechnern Programme installieren (fehlende Admin-Rechte), trotzdem wäre es wünschenswert auf einem Schlag die ganze Kategorie als Download zu starten. Gerne noch mit einer Checkbox, dass man die Lizenzen von den Bildern trennt. --Atamari (Diskussion) 14:22, 21. Sep. 2015 (CEST)[Beantworten]
Es is technisch nicht möglich das eine Webseite von sich aus mehre Dateien herunterlädt. Mann müsste die Datei also als Zip-Archiv zum Download bereitstellen das geht das geht nicht als Gadget o.ä. sondern muss tief in die Software verdrahtet werden und ist vermutlich auch aus Performancesicht schwer (da kann ich mich aber irren). Der Imker muss übrigens nicht installiert werden, er kann auch ohne Admin-Rechte heruntergeladen und gestartet werden – vorausgesetzt Java ist installiert (Java ist recht verbreitet). -- Michi14:52, 21. Sep. 2015 (CEST)[Beantworten]
Dass das eine oder andere technisch nicht möglich, kann ich verstehen. Wegen den fehlenden Admin-Rechte habe ich eben sogar ein "Test" gemacht; es war nicht möglich (Unable to access jarfile). Java ist installiert in Version 7. Aber nun weis ich ja, das ich an Rechnern, an dem ich einen vollständigen Zugriff habe, mir mit diesem Tool behelfen kann. --Atamari (Diskussion) 15:03, 21. Sep. 2015 (CEST)[Beantworten]
Das liegt dann aber nicht an fehlenden Admin-Rechten, sondern an irgendwas anderem… Hast du das Zip ganz entpackt? Der Fehler klingt danach, dass du es nur geöffnet und dann die Exe-Datei geöffnet hast. -- Michi16:05, 26. Sep. 2015 (CEST)[Beantworten]
Ich hätte gerne die Möglichkeit, nur einen Artikel, ohne die zugehörige Diskussionsseite, beobachten zu können. Und umgekehrt. Das wäre z.B. praktisch, wenn man den Kurier beobachten will, um auf dem laufenden zu sein, aber sich nicht für die umseitigen Diskussionen interessiert. Oder wenn man bei einem Meinungsbild oder einer Adminkandidatur die zugehörige Diskussion verfolgen will, ohne ständig angezeigt zu bekommen, wenn jemand abstimmt. --RookJameson (Diskussion) 10:36, 21. Sep. 2015 (CEST)[Beantworten]
erledigtErledigt Eigene beobachtete Kategorien-Kombinationen mit CatScan auf dem aktuellsten Stand halten: Es ist ja leider nicht möglich die Kategorien so zu beobachten, dass mann immer weiß wann mal ein neuer Artikel dazukommt. Wie wäre es denn, wenn man ein Feature einrichtet, dass die jeweils gewünschten Eingaben bei CatScan berücksichtigt, und das folgende Ergebnis dann mit der Beobachtungsliste des jeweiligen Benutzers vergleicht. Unstimmigkeiten könnten dann vielleicht farblich unterlegt werden oder so. Auf diese weise wäre es dann immer allen, egal wann, möglich ihren Beobachtunsbereich auf "Updates" hin zu überprüfen, denk ich.--Eddgel (Diskussion) 10:45, 27. Sep. 2015 (CEST)[Beantworten]
Oja, danke, das ist schonmal ganz gut, auch wenn es jetzt etwas gewöhnungsbedürftig nach klickibunti aussieht. Diesen Punkt kann man schonmal streichen.--Emergency doc (D) 01:36, 2. Okt. 2015 (CEST)[Beantworten]
Die Angabe "User:Contribs" (rechts unter Werkzeuge auf Benutzerseiten) sollte nach "User:Beiträge" umbenannt werden. So ist es für viele, gerade aber auch für Neulinge besser zu verstehen und anzuwenden. Wie geschrieben nur eine Kleinigkeit.--Eddgel (Diskussion) 07:39, 3. Okt. 2015 (CEST)[Beantworten]
Ich hab das auch. Wenn man Benutzerseiten anschaut, steht rechts im Kasten "Werkzeuge" als dritter Punkt "User:Contribs" und linkt auf die Beitragsliste. Ich glaub, das kommt irgendwie von PDDs monobook, das ich benutze. --Hareinhardt (Diskussion) 22:44, 3. Okt. 2015 (CEST)[Beantworten]
@Eddgel: Da kann ich dir leider nicht helfen, ich bin mit einem leicht modifizierten Vector unterwegs. Ich denke, du müsstest einfach mal die von dir verwendeten Skripte einzeln abschalten und schauen, welches Skript der Übeltäter ist. Dann sollte es nicht so schwierig sein, in das Skript die richtige Übersetzung einzupflegen.--Cirdan±14:26, 10. Okt. 2015 (CEST)[Beantworten]
listPageOptions@PerfektesChaos bietet eine Möglichkeit zum Ausfiltern von Aktivitäten mit bestimmten Bearbeitungskommentaren an; hier würde sich die Suche nach dem HotCat-Link anbieten. Ob eine Bearbeitung aber tatsächlich nur eine Kategorie verändert hatte oder das lediglich im BK so behauptet wird, lässt sich nur aufwändig feststellen und hätte als weltweit verkomplizierende Software-Option kaum eine Chance. --PerfektesChaos11:22, 4. Okt. 2015 (CEST)[Beantworten]
Beobachtungsliste nach (Ober-)Kategorien (z.B. Bearbeitungen an Biographien oder an Orten o.ae.), ggf. entsprechende Kategorien durch Nutzer im BNR festlegbar (mit logischer Verknüpfung (Kategorie: Person vs. Kategorie: nicht Person), --MachtaUnix (Diskussion) 01:47, 23. Sep. 2015 (CEST)[Beantworten]
Es gibt zumindest Möglichkeiten, den Inhalt bestimmter Kategorien als Namensliste den beobachteten Seiten hinzuzufügen. Eine automatische Mitbeobachtung ganzer Kategoriebäume mit Unterkategorien könnte leicht zu 50.000 beobachteten Seiten führen und würde das System sprengen. Eine praktikable Alternative sind „Änderungen an verlinkten Seiten“ (links unter „Werkzeuge“) von einer Redaktionsseite oder einem Oberbegriff aus. --PerfektesChaos11:22, 4. Okt. 2015 (CEST)[Beantworten]
Möglichkeit Bots (oder vielleicht sogar Benutzer) individuell von der Beo auszublenden. Weil ich z.B. Beobachtunglistenflutungsbot, Kategorienschubsbot und Aka (sorry ;) ) nicht sehen mag, dafür aber Dateientlinkerbot und Kaputterweblinkbot. -- Hareinhardt (Diskussion) 22:53, 24. Sep. 2015 (CEST)[Beantworten]
listPageOptions@PerfektesChaos bietet unzählige Möglichkeiten zum Ausfiltern von Bearbeitern an, die sich in jede beliebige Komplexität steigern lassen. Es gibt Benutzer, die ich auch nicht sehen möchte, und die auf genau diese Weise bei mir nicht mehr in Erscheinung treten. --PerfektesChaos11:22, 4. Okt. 2015 (CEST)[Beantworten]
Mir ist es beim Bedienen per Tablet schon häufiger passiert, dass ich aufgrund der eng nebeneinander stehenden Verlinkungen der Beo versehentlich auf "Kommentarlos zurücksetzen" geklickt habe, was bekanntlich direkt einen Revert auslöst. Offenbar bin ich nicht der einzige dem das passiert. Evtl. wäre hier eine Sicherheitsabfrage o.ä. sinnvoll. --Sakra (Diskussion) 12:43, 30. Sep. 2015 (CEST)[Beantworten]
Sowas meine ich mal gesehen zu haben, allerdings gibt es mit WP:LT/wikishootme bereits eine deutlich ausgereiftere Lösung. Wenn du dort den Umkreis auf eine große Zahl setzt, kannst du wahrscheinlich auch alle Bilderwünsche in Deutschland anzeigen lassen.--Cirdan±11:25, 1. Okt. 2015 (CEST)[Beantworten]
JavaScript-Repository: Anlegen einer Sammlung von JavaScript-Funktionen z.B. im Gadget-Namensraum um es Einsteigern in JavaScript einen Baukasten für das Erstellen eigener Benutzerskripte zu ermöglichen. Auch bestehende Benutzerskripte könnten dadurch profitieren, wenn wichtige Funktionen zentral gewartet werden, womit neue Gadgets viel schneller als getestet freigegeben werden können. Mögliche Java-Script-Funktionen in so einen Repository könnten sein:
Schaltfläche im Bearbeitungsfenster um eine benutzerdefinierte JS-Funktion aufzurufen
An wikitext angepasstes Regexp-Replace dass im Default Kommentare, nowiki, syntaghighlight, code,... ignoriert, und eventuell auch Vorlagen rekursiv durcharbeitet. Ein mittelfristiges Ziel könnte hier sein, dass man wikitext-taugliche sed-ähnliche Skripte mit Hilfe JavaScript erstellen kann.
Funktionen und Objekte die derzeit schon häufig in immer wieder ähnlicher Form von den meistgenutzten Userskripts verwendet werden. Frohes Schaffen — Boshomi☕⌨☺14:01, 21. Sep. 2015 (CEST)[Beantworten]
Das ist keine Software-Aufgabe, sondern es bedarf der Manpower und langjährig eingearbeiteter Fachleute, um sowas über ein Jahrzehnt pflegen und erneuern zu können. Du kannst ja mal WP:TWS#Obsoletes auf MediaWiki:Gadget-* aufarbeiten. Das können regelmäßig nur die Original-Autoren; nach deren Ausscheiden gibt es nur selten einen nachfolgenden Maintainer. Ohne Maintainer ist das Repository völlig wertlos; wir haben schon längst eines, das allmählich vergreist und in das wir auch keine größeren Neubauten mehr aufnehmen. Und da es keine Zuständigkeiten gibt und keine über fünf Jahre im Voraus zugewiesen werden können, ist das Utopie.
Für die Kern-Software von MediaWiki gibt es weltweit einige Dutzend Leute, die sich damit auskennen; für die Hunderte von Komponenten in Drumherum jeweils ein, zwei oder null Leute, die darin eingearbeitet wären.
Ein „Baukasten für das Erstellen eigener Benutzerskripte“ für „Einsteiger in JavaScript“ ist völliger Nonsens. Entweder man erlernt das Programmieren allmählich bzw. kann es von vornherein; oder man wird nix zusammenbringen. Das ist kein copy&paste irgendwelcher Zeilen. Vorbilder kann sich jeder auf WP:HX abgucken; und uralte Zombies neben brandaktuellen Techniken finden.
Ich verwende auch gleichartige Code-Sequenzen aus meinen früheren Skripten in Neuentwicklungen erneut; aber wenn diese schon zwei Jahre alt sind, dann haben sich längst Rahmenbedingungen geändert und ich bin etwas schlauer geworden, und die Neuprogrammierung erhält keine Kopie 1:1, sondern schon wieder eine zukunftsträchtigere Weiterentwicklung.
„Schaltfläche im Bearbeitungsfenster um eine benutzerdefinierte JS-Funktion aufzurufen“ könnte vielerlei meinen. Benutzerdefinierte JS-Funktionen lassen sich aber nicht einfach aufrufen; sie müssen vorher schon geladen gewesen sein und eine global zugängliche Schnittstelle haben, damit so etwas funktionieren könnte. Kaum eine ausgereifte Vorstellung von Programmierung und Performance; kaum ein Benutzer in Sicht, der eine solche Wackelkonstruktion hinterher auch bedienen könnte.
@PerfektesChaos: Manpower ist genau das Problem. Nur für LUA müsste man dich mindestens fünffach klonen, und du hättest immer noch genug zu tun. Dabei ist LUA nur eines von vielen Feldern die du beackerst, und all den anderen freiwilligen Programmieren die hier regelmäßig tätig sind, geht es kaum anders. Neue freiwillige Programmierer zu finden ist schwierig, denn zu den technischen Skills die hier notwendig sind, braucht es auch noch ein umfangreiches Wissen über die Wikipedia und die Fähigkeit mit der Community umzugehen.
Ziel des Vorschlags zur Nutzung eines Namensraums für js ist es, wichtige Skripte die derzeit im BNR liegen in einen Bereich zu heben, wo sie zum einen von versierten Freiwilligen und zum anderen auch von professionenellen Mediawiki-Programmieren editiert werden können. Der Leitgedanke wären Opensource-Repositories wo es auch eine Aufteilung zwischen jenen gibt die einen Batch einreichen und jenen die das Commiten.
Programmiersprachen werden um so produktiver je umfangreicher ein gut strukturiertes und dokumentiertes Set an Libraries zur Verfügung steht.
Derzeit kann eine kleine API-Änderung dutzende wichtige Userskripts ausschalten. Ist der Ersteller nicht erreichbar, müsste man das Skript klonen. Pech für alle die nur sporadisch Online sind, und nicht mitbekommen, dass das Skript dann wo anders liegt. Lägen die Skripts zentral könnte ein Commiter offensichtliche Änderungsnotwendigkeiten praktisch gleichzeitig mit dem Ausrollen der API-Änderung fixen. Frohes Schaffen — Boshomi☕⌨☺16:41, 12. Okt. 2015 (CEST)[Beantworten]
Möglichkeit, aus abgeschlossenen Löschdiskussionen sich den gelöschten Artikel anzusehen, erstens um die Argumente nachvollziehen zu können und zweitens um abschätzen zu können welche und wie viele Arbeiten nötig wären um den Artikel auf akzeptables Niveau zu bringen. Möglichkeit der Verschiebung in BNR reicht nicht weil man schon vorher überlegen muss ob man sich überhaupt engagiert. Falls ein Link zum gelöschten Artikel nicht gewünscht ist, wäre auch ein spezielles Layout (z.B. Löschdiskussion links, Artikelanzeige rechts) denkbar. -- Gerd Fahrenhorst (Diskussion) 09:15, 27. Sep. 2015 (CEST)[Beantworten]
@Gerd Fahrenhorst: Meinst du, dass der gelöschte Artikel auch für nicht-Admins einsehbar sein soll? Je nach Löschgrund kann es sein, dass die Seite gar nicht mehr angezeigt werden darf (wegen personenbezogener Infos, Beleidigungen, etc). Bei Löschungen wegen mangelnder Relevanz oder Qualität wäre das aber kein Problem. Eine einfache Lösung wäre, soche Artikel gar nicht zu löschen, sondern nur aus dem Artikelnamensraum auf eine "Müllhalde" zu verschieben. Das kann die Community einfach machen, wenn das gewünscht ist. -- Daniel Kinzler (WMDE) (Diskussion) 11:28, 30. Sep. 2015 (CEST)[Beantworten]
Bei Löschung wegen personenbezogener Infos, Beleidigungen u.ä. kann es so bleiben wie bisher, das interessiert mich nicht; allerdings werden in solchen Fällen üblicherweise nur einzelne Versionen der Seite versteckt und nicht der ganze Artikel gelöscht. Aber in anderen Fällen möchte ich die Löschdiskussion gerne verstehen, und dazu muss man (als nicht-Admin) irgendwie den gelöschten Artikel lesen können. Ein anderer Fall ist, dass der Artikel vor vielen Jahren gelöscht wurde wegen z.B. damals mangelnder Relevanz, dass aber inzwischen die Relevanz gegeben sein mag; da macht es einen Riesenunterschied, ob ich für ein Wiedereinstellen auf Grundlage des alten Artikels etwa bei einem Unternehmen lediglich aktuelle belegbare Umsatz-/Beschäftigtenzahlen eintragen müsste oder der alte Artikel völlig unbrauchbar war. Das wüsste ich gerne VORHER, bevor ich mich für ein Engagement entscheide und um eine Verschiebung in meinen BNR bitte. Und was nützt eine Müllhalde oder ein Jungfischbecken, wenn niemand weiß wo der gelöschte Artikel zu finden ist? Daher mein Wunsch: Link aus der Löschdiskussion auf den gelöschten Artikel. -- Gerd Fahrenhorst (Diskussion) 10:00, 4. Okt. 2015 (CEST)[Beantworten]
@Gerd Fahrenhorst: Ich sehe hier das technische Problem (noch) nicht. Du könntest vorschlagen, dass alle Artikel, die nicht wegen URV und anderen Gründen dauerhaft gelöscht und damit unsichtbar gehalten werden müssen, nicht gelöscht sondern in ein dem Jungfischbecken ähnliches Archiv verschoben werden. Den Link könnte man dann entweder in der Löschdiskussion eintragen, er ist aber natürlich auch aus dem Verschiebungslogbuch ersichtlich, wenn man auf den Rotlink in der Löschdiskussion klickt (Benutzer:XYZ verschob den Artikel [[Gelöschter Artikel]] nach [[Ablage/Gelöschter Artikel]]). Ich bezweifel allerdings, dass du dafür eine Mehrheit finden wirst.
Man könnte natürlich auch allen Benutzern das Recht geben, in gelöschte Versionen zu schauen. Dann müssten aber zumindest alle Beleididungen und in Bezug auf Datenschutz/Persönlichkeitsrechte problematische Artikel nicht nur gelöscht, sondern von den Oversightern versteckt werden. Das geht natürlich, aber die Frage ist, ob der Aufwand den Nutzen rechtfertigt. Wenn dich ein Artikel interessiert, kannst du recht problemlos und „auf dem kurzen Dienstweg“ um Wiederherstellung bitten und kein Admin wird dir böse sein, wenn du dann zwei Tage später wieder einen SLA stellst, weil der Artikel doch nichts taugt.--Cirdan±18:33, 4. Okt. 2015 (CEST)[Beantworten]
Mein Wunsch ist weiterhin, Löschdiskussionen nachvollziehen zu können, sofort (=ohne Hilfe anderer) und ohne spezielles Know-How. URV etc muss natürlich berücksichtigt werden. - Realisierungsvorschlag: 1. der löschende Admin wird beim Löschen gefragt, ob der Artikel normal gelöscht oder dauerhaft versteckt werden soll. 2. Zum Eintrag in die Löschdiskussion wird entsprechend eine Vorlage mit Link zum gelöschten Artikel und eine Vorlage mit Hinweis auf dauerhafte Löschung bereitgestellt. -- Gerd Fahrenhorst (Diskussion) 07:46, 5. Okt. 2015 (CEST)[Beantworten]
@Gerd Fahrenhorst: Gut, dann habe ich jetzt verstanden, was du machen möchtest. Das ist aber kein technisches Problem, sondern etwas, was man schon mit der aktuell vorhandenen Software genauso handhaben könnte, wie ich oben beschrieben habe: Entweder wird der Artikel so wie jetzt gelöscht, oder er wird aus dem ANR in eine Sammelstelle geschoben. In beiden Fällen wird das in der Löschdiskussion vermerkt und ggf. der Link auf den Artikel in der Sammelstelle gesetzt.
Vorher müsstest du aber wohl ein Meinungsbild oder zumindest eine Umfrage starten, wo du diese redaktionelle Änderung zur Abstimmung bzw. Diskussion stellst. Insbesondere müsste wohl geklärt werden, ob diese Sammelstelle öffentlich einsehbar ist und wie sie strukturiert sein soll.
Wenn das geklärt ist, kann der von dir vorgeschlagene Prozess für die Administratoren über ein einfaches userseitiges JavaScript-Helferlein (semi-)automatisiert werden. Dessen Entwicklung ist erst dann sinnvoll, wenn die Community der von dir vorgeschlagenen Veränderung im Bereich Löschkandidaten zustimmt.--Cirdan±12:06, 5. Okt. 2015 (CEST)[Beantworten]
(Wikidata) Einführung von Schablonen in Wikidata. Für jedes Item kann dann eine Schablone festgelegt werden, die dann die vorhandenen Daten hübsch formatiert. In etwa so wie Reasontor oder die Botartikel in einigen Wikipedias. Wenn man hier in Wikipedia keinen Artikel findet, es aber ein Wikidata-Item mit Schablone gibt, wird dieses angeboten, zusammen mit der Möglichkeit, bei einer Neuanlage diesen Stub zum weiteren Ausbau zu einem enzyklopädischen Artikel zu übernehmen. --Schnark09:29, 25. Sep. 2015 (CEST)[Beantworten]
Persönliche Spielwiese, die für Neulinge leicht erreichbar ist. In anderssprachigen WP gibt es nach dem Login ganz oben neben dem Link zur eigenen Seite einen Rotlink sandbox (en), brouillon (fr) oder prove (it). Dies fehlt auf deutsch. Bei WP-Einführungskursen muss ich jeweils umständlich erklären, wie sie eine Benutzerunterseite anlegen können. Plus, dass sie sich die Adresse merken müssen, weil sie nicht leicht wieder auffindbar ist. Oder wurde dieser Vorschlag schon mal diskutiert? Habe nix gefunden... --Hadi (Diskussion) 15:00, 29. Sep. 2015 (CEST)[Beantworten]
Vielen Dank für die erfreulichen technischen Antworten! Kann mir nun jemand sagen, wie/wo die Einführung einer solchen persönlichen Spielwiese entschieden werden kann? Muss ich das irgendwo zur Diskussion stellen? Wenn ja, wo? Danke --Hadi (Diskussion) 19:04, 30. Sep. 2015 (CEST)[Beantworten]
Neugestaltung der "Bearbeiten" Seite: Ich verbringe einen Gutteil meiner Wikizeit auf der Bearbeitungsseite. Die hat sich seit einer gefühlten Ewigkeit nicht mehr verändert. Wir haben inzwischen einen für Gelegenheitsnutzer recht guten VisualEditor, aber auf der normalen Bearbeitungsseite scheint der Einzug von html5 spurlos vorübergegangen zu sein. Vor einer Neugestalltung sollte man sich von Beginn an überlegen, welche Zielgruppen vor allem von VE unterstützt werden sollte, und welche Zielgruppen durch eine besser unterstützte direkte Wikitext-Bearbeitung am meisten gedient ist.
Für Leute wie mich die viel Zeit auf den Bearbeitungsseiten verbringen und durch die langen Wege auch viel Zeit dort verlieren, könnte durch eine konzeptionell neu gestalte Wikitext-Bearbeitung viel unproduktiv verbrachte Zeit in produktiv nutzbare Zeit umgewandelt werden. Abgesehen von einer Neuaufteilung des zur Verfügung stehenden Platzes könnten eine Reihe von Hintergrund-Funktionen viel Zeit bringen, die etwa "intelligente" Kontext-Menues ermöglichen. Frohes Schaffen — Boshomi☕⌨☺17:13, 23. Sep. 2015 (CEST)[Beantworten]
@Boshomi: Ich kann mir leider nicht vorstellen, was du mit „Neugestaltung“ und „Neuaufteilung“ meinst und befürchte, dass dein Wunsch so weder von den Benutzern verstanden werden kann, die hier später abstimmen, noch von den Entwicklern. Du sprichst von „HTML5“, aber welche HTML5-Features meinst du? Du sprichst von „langen Wegen“, nennst aber keine Beispiele. Bitte formuliere deinen Text um und teile ihn in mehrere, möglichst konkrete Wünsche auf. Das wäre super hilfreich. --Thiemo Mättig (WMDE)12:12, 30. Sep. 2015 (CEST)[Beantworten]
@Thiemo Mättig (WMDE): Ich habe das absichtlich etwas offen gelassen, da ich mir nicht als der große Spezialist für optimale GUI-Gestalltung empfinde. Ich sehe da aber viel Entwicklung im Bereich der IDEs (ACE, codenvy, ChromeDevEditor, uva...). Ziel sollte es sein, dass Autoren mit möglichst geringen Aufwand das Gewünschte erreichen. Einige mögliche Funktionen
Klammerergänzung (Automatisch schließende Klammern setzen, wenn eine öffnende eingetragen wird)
Befindet sich der Cursor zwischen 2 eckigen Klammerne [[]] könnte man in einem weiteren Schritt gleich die Textvervollständigung aus dem bekannten Suchfeld laden,
Bei geschwungenen Klammern könnte man templatepar-basierend gleich die Parameter vorschlagen,
Tag-Vorschlag wie bei so manchen html oder xml-Editoren
@Boshomi: Die Beispiele sind sehr hilfreich, vielen Dank dafür. Dennoch kann dein Beitrag in dieser Form unmöglich zur Abstimmung gestellt werden. Er ist so weder für die Benutzer verständlich, die hier später abstimmen sollen, noch für die Entwickler, die das umsetzen. Bitte formuliere deinen Wunsch um, teile ihn auf und werde wesentlich konkreter. Stell dir dabei immer eine Frage: Welche Bedingung muss erfüllt sein, um den Wunsch als erledigt abzuhaken? Wenn es dir um kürzere Wege geht, nenne den Wunsch bitte „kürzere Wege im Wikitext-Editor“ und nenne ganz konkrete Beispiele. Wenn es dir um ein Kontextmenü geht, eröffne bitte einen Wunsch „Formatierungs-Kontextmenü im Wikitext-Editor“. Wenn es dir um Auto-Formatierungen geht, eröffne bitte einen entsprechenden Wunsch. Danke. --Thiemo Mättig (WMDE)10:22, 8. Okt. 2015 (CEST)[Beantworten]
) 22:20, 20. Sep. 2015 (CEST)
Ziehe den Wunsch zurück --FeddaHeiko ☺ 15:31, 23. Sep. 2015 (CEST)
• hugarheimur 20:59, 21. Sep. 2015 (CEST)
Sir Gawain Disk. 20:42, 20. Sep. 2015 (CEST)
14:01, 21. Sep. 2015 (CEST)
