Wikipedia:Umfragen/Technische Wünsche 2017/Wünsche außerhalb des Projektrahmens

In diese Rubrik finden sich Vorschläge,

• die nicht primär technisch lösbar sind, sondern z.B. Regeln der Wikipedia Gemeinschaft betreffen und Sache der Communitys sind
• wenn ohne weitere Analyse schon klar ist, dass der Wunsch aus rechtlichen Gründen nicht umsetzbar ist
• wenn ohne weitere Analyse schon klar ist, dass der Wunsch (derzeit) technisch nicht machbar ist
• wenn ohne weitere Analyse schon klar ist, dass der Wunsch viel zu umfangreich ist (wobei versucht werden soll, aus diesen Wünschen im Vorfeld Wünsche zu zimmern, die wiederum im Rahmen sind)

Wünsche in dieser Rubrik werden nicht zur Abstimmung gestellt. Die Ideen sollten jedoch nicht verloren gehen! Projekte, die z.b. zu spät eingereicht wurden, können hier gesammelt werden - es erfolgt dann eine Benachrichtigung rechtzeitig zur nächsten Umfrage.

einfaches Erstellen von Tabellen

Was ist das Problem?

Das Erstellen, Warten und ergänzen von Tabellen in Wikisyntax (wikitable) ist unübersichtlich und umständlich. Vorlagen wie sie z. B. in diversen Kulturdenkmallisten genutzt werden, sind nutzerfreundlicher. Für Neulinge oder nicht autoren ist es schwierig, sich in die struktur der Tabelle reinzudenken. Der "Umbau" (das Verschieben einer Spalte innerhlab der Tabelle) einer Tabelle ist aufwändig. Wenn beispielsweise bei Liste der Ehrengräber in Berlin die Spalte mit den Grabbilder an die letzte Stelle gesetzt werden soll, muss jeder Zeileneintrag extra angefasst und erweitert werden, gleiches gilt, wenn einen weitere Spalte hinzukommen soll.

Wen betrifft das Problem besonders?

Autoren, die mit Tabellen arbeiten

Lösungsvorschlag

Bereitstellen eines Tools, das es nutzerfreundlich ermöglicht, Tabellen zu erstellen und zu bearbeiten, so wie man es auch üblichen Tabellenbearbeitungsprogrammen kennt (Spalten verschieben, einfügen, entfernen ggf. Inhalte verketten).

In der Regel haben Tabellenn den selben Inhalt und Aufbau: X Spalten für Text, Datumsangaben, Bilder und gleichaufgebaute Links (z. B. zu commons oder externen Datenbanken). Der Nutzer muss nur festlegen, wieviel Spalten er benötigt, wie diese zu bezeichnen sind.

Anmerkungen

[Vorschlag wurde überarbeitet] Bei Tabellen, die in mehreren Artikeln genutzt werden (z. B. Denkmallisten) haben sich Tabellenvorlagen bewährt. Dabei müssen in der Vorlage nicht alle Felder ausgefüllt bzw. im Artikel eingetragen sein, diese werden nur genutzt wenn, sie mit Inhalt gefüllt sind. Möglicherweise ist dies ein Weg, um die Tabellenerstellen zu vereinfachen. Falls sich die syntax ändern wird und jemand bestehende klassische Liste in diese Syntax wandeln möchte, kann über Migrationsregeln der Inhalt aus den bisherigen Tabellen übernommen werden

Vorschlagende Person

 ^Thomas 22:54, 4. Jun. 2017 (CEST)

Diskussion

• Ich habe nicht so restlos verstanden, worauf du abzielst.
• Tabellenvorlagen für den "Einmalgebrauch" – so etwas gibt es nicht.
  • Wenn Tabellenvorlagen erstellt werden, dann sind die nicht zum Wegwerfen, sondern sie sollen möglichst oft in möglichst viele gleichartige Artikel eingebunden werden.
  • Sollte man sich irgendwann für Veränderungen im Layout entscheiden, dann will man nur die eine Vorlage oder das Paket aus zwei/drei Vorlagen zentral mit einem Edit anpassen und das soll sich einheitlich auf alle zugehörigen Artikel auswirken.
• Derartige Tabellenvorlagen sind technisch äuerst simpel herzustellen; die Vorlagenwerkstatt kann weiterhelfen, wenn man weiß, was man will.
• Die Herausforderung liegt darin, sich innerhalb der Community und der beteiligten Anwendungsgebiete auf eine präzise Systematik zu einigen, so dass das ggf. für Hamburger Ortsteile, Züricher Gassen, Linzer Viertel und bayerische Dörfer passt.
• Ein Tool braucht man nicht dazu; ich wüsste nicht, wie du und ein Tool miteinander kommunizieren wolltet, oder wie ein Tool von vornherein alle Designwünsche glaskugeln soll.
• Es gibt unendlich viele Lösungswege und Zielsetzungen; es ist eine Frage der inhaltlichen Konzeption und der Abstimmung zwischen allen Autoren der Fachgebiete – nicht irgendwelcher Techniken, Programmierung oder Tools.
• „Migrationshilfen“ müssten individuell nach Kenntnis der Lösung und Analyse eines eventuell schon vorhandenen Artikelbestandes erstellt werden; ein fertiger Baukasten wäre überfordert.

VG --PerfektesChaos 15:13, 8. Jun. 2017 (CEST)

@Z thomas: Hallo, das klingt für mich so, als sei dieser Wunsch ein Kandidat für Wünsche außerhalb des Projektrahmens, weil er Absprachen in der Community betrifft und nicht Änderungen an der Software. Falls dem nicht so ist, kannst du den Wunsch wieder zurück schieben und am besten auch noch mal im Wunsch selbst genauer ausformulieren, was du meintest – gerade in Bezug auf die Hinweise von PerfektesChaos. Ich hoffe, das ist okay für dich. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:18, 9. Jun. 2017 (CEST)

@Z thomas: meinst du einen Import- exportfilter für Wikitabellen? --Atamari (Diskussion) 15:34, 9. Jun. 2017 (CEST)

Hallo @PerfektesChaos: da ich meinen wunsch nicht ordentlich formuliert habe, ist es nicht verständlich. Ich habe ihn überarbeitet und versucht die Idee in Richtung Vorlagennutzung zu entfernen. Ich will, dass man Tabellen einfach erstellen und bearbeiten kann... :-) danke für deine hinweise.

@Johanna Strodt (WMDE), Atamari: ich denke, dass es schon ein softwarewunsch ist, aber da er blöd formulieret ist, ist er nicht zu verstehen. ihc hoffe, dass die überarbeitung hilft.

@Atamari: ich weiß nicht genau, was du damit meinst. aber vielleicht hast du mich verstanden und mein überarbeiter wunsch zielt in diese richtung. gruß -- ^Thomas 19:17, 11. Jun. 2017 (CEST)

Unterstützung

Digitales Erbe

Was ist das Problem?

Nach mehr als zehn Jahre mit der Wikipedia und Nutzen zahlreicher Tools und Scripte sowie die dritte Auflage der große Umfrage identifiziere ich drei große Cluster bei den technischen Wünschen:

1. "Richtige" Wünsche, also neue oder erweiterte Funktionen.
2. Wünsche, die aber schon irgendwie realisiert worden sind. Nur ist es dem Autor dies nicht bekannt. Dies ist ein Kommunikationsproblem. Wie mache ich den breiten Publikum, dem Leser und den Autor die diversen Hilfsmittel bekannt?
3. Wünsche, das altere Tools oder Scripte wieder laufen. Es kommt immer mal wieder vor, das Autoren von Tools oder Scripte längere Zeit nicht mehr aktiv sind. Entweder haben sie einfach Urlaub oder ihre Lebenssituation hatte sich verändert, zum Beispiel sind ihrer berufliche Herausforderungen so gestiegen, dass sie für die Wikipedia keine Zeit mehr haben.

Wen betrifft das Problem besonders?

Das Problem betrifft alle.

Lösungsvorschlag

Die Eintrag unter "Sonstiges" soll besonders Punkt #2 und Punkt #3 in den Vordergrund stellen. Es sind keine Punkte, bei dem sich die Programmierer die Ärmel hoch krempeln.

Punkt #2:

Die Tools die vorhanden sind sollten möglichst alle zentral erfasst werden. Mit einem Ampelsystem sollte die Nutzbarkeit für den Profi und Anfänger bewertet werden. Das ordnungsgemäße Funktionieren soll zeitnah "überwacht" werden. Der Hauptansprechpartner (also Entwickler) sollte benannt sein. Eine zentrale Anlaufstelle für Bugmeldungen sollte existieren (ich habe schon oft Bugmeldungen geschrieben, bei denen ich bis heute keine Rückmeldung bekommen habe). Die Seite Einstellungen/Helferlein sollte gepflegt werden (nicht funktionierende oder schlecht beschriebene Tools können entfernt werden). Auch sollten hilfreiche Tools (auch einfachste css-scripte) mit der Seite Einstellungen/Helferlein realisiert werden.

Punkt #3:

Jeder Entwickler eines Tools oder scripts sollte sich bewußt sein, dass ihm mal was passieren kann. Je sinnvoller ein Tool ist und häufig genutzt wird, sollte er weitere Personen benennen und einweisen, die ordnungsgemäße Funktionieren des Tools zu jeder Zeit sicherstellen können. Ich will dies mal als "Digitales Erbe" bezeichnen. Es ist nicht so, dass dann jemand anderes etwas wegnimmt. Wir haben bestimmt alle schon erlebt, dass das eine oder andere ausgefallen ist. Wenn wir Glück haben, ist es nach ein paar Minuten wieder funktionsfähig. Manchmal müssen wir Tage warten. Aber es gibt Tools - die laufen schon mehrere Monate nicht mehr. Ich denke es wäre sinnvoll mit dem Projekt/Team „Technische Wünsche“ langfristig hier vernünftige Strategien zu entwickeln.

Vorschlagende Person

Atamari (Diskussion) 14:46, 7. Jun. 2017 (CEST)

Diskussion

@Atamari: wow. Vielen Dank für diesen Beitrag! Eigentlich sollte dieser Text woanders veröffentlicht werden - es ist weit mehr, als die Beschreibung eines technischen Wunsches & anhand dieses Textes liese sich vieles gut diskutieren. Ich gehe mal durch die Punkte durch, die du genannt hast, und versuche dabei zu formulieren, wie was auf der Wunschliste einen Platz haben könnte und wofür wir eher andere Orte suchen sollten:

Punkt #1: Neue/Erweiterte Funktionen, Wissen, dass es diese gibt, vorhandende Tools wieder zum Laufen bringen/Fehler zu beheben:

Der Kernauftrag der Wunschliste. Wobei ich zu Tools wieder zum Laufen zu bringen ergänzen würde: Mit der Wunschliste versuchen wir eher, nicht ein konkretes Tool (also: eine (externe) Lösung) im Blick zu haben, sondern die Funktionalität selbst & wie diese Funktionalität nach Möglichkeit integriert werden kann in die Software, damit mehr Menschen die Funktionalität finden & nutzen können. Wobei trotzdem auch mal ein Tool eine Lösung sein kann: Z.b., wenn die gewünschte Funktionalität anders nicht oder nur mit erheblichem Aufwand bereit gestellt werden kann, oder wenn jemand in seiner Freizeit einen technischen Wunsch mit einem Tool erfüllt, das super läuft, gewartet wird und z.B. in der Seite eingebunden ist oder über die eigenen Einstellungen aktiviert werden kann. Trotzdem würden wir Tools immer eher als die Ausnahme sehen, also wenn z.b. 2 von 10 Wünschen über Tools erfüllt werden, fände ich das ok, aber nicht, wenn es das ist, was hauptsächlich gemacht wird. Ganz generell würde ich im Bereich "Tools, Scripts" die Rolle des Technische Wünsche Teams eher darin sehen, freiwillige Entwickler mehr zu unterstützen. "Nebenbei" lief das immer wieder mal, in diesem Jahr gibt es das zum ersten Mal in geplant - konkret heißt das: einen Platz auf der Top-Liste für die Beratung eines ehrenamtlichen Entwicklers zu reservieren, der das eigene Projekt weiterentwickeln oder etwas Neues machen will, eine wöchentliche IRC-Sprechstunde einrichten (kommt bald ...), wo Entwickler von uns drin sitzen & bei Fragen weiterhelfen & vermutlich Workshops auf dem Hackathon & der Wikicon anbieten.

Punkt #2: Das ist im Endeffekt zum großen Teil das, was Geolina hier: #Verbessertes_Auffinden_und_Handling_von_Tools_und_Skripten beschreibt. Die dortigen Anmerkungen von PerfektesChaos und deine hier beschreiben dabei die Einschränkungen, die dann diskutiert werden müssten: Welche Scripte könnten darüber zugänglich gemacht werden, weil sie z.b. gewartet werden, der Entwickler ansprechbar ist etc.?. Letztendlich wäre dieser Wunsch noch mehr als andere ein sehr enges Zusammenarbeitsprojekt mit der Community, weil gemeinsam Richtlinien festgelegt werden müssten & ehrenamtliche Entwickler den "Store" am Ende auch nutzen müssten :-) Für die Abstimmung ab dem 19. Juni sollten wir schauen, dass dieser Wunsch nur einmal auf der Liste ist. Da Geolina die Erste war, würde ich vorschlagen, ihren stehen zu lassen & deine Anmerkung von "Tools bis zentrale Bugsammelstelle" da mit unterzubringen. Zum Teil mit der Pflege der eigenen Einstellungen: Das könnte in den Wunsch nicht mit rein, weil es wiederum etwas ist, was in der Zuständigkeit der Community liegt.

Punkt #3: Jetzt habe ich schon soviel geschrieben, dabei ist das hier der Punkt, über den ich am Meisten nachgedacht habe ;) - international ist das seit dem letzten Jahr viel Thema gewesen, daraus entstanden sind 2 Policys für Tools, die auf Tool Labs liegen: Die "verwaiste Tools Policy" und die Die "Recht auf Forken Policy". Darüber hinaus wurde ein Kommitee gegründet, dass sich um Zugang-Anfragen zum Code von verwaisten Tools auf Basis dieser Regelungen kümmert. Ausgangsbasis waren u.a. die Probleme, die du hier beschreibst. Mit den Regelungen soll gewährleistet werden, dass wichtige Werkzeuge weitergeführt werden können, wenn die ursprünglichen Entwickler nicht mehr aktiv sind oder länger nicht erreichbar sind. Dafür müssen Tools unter einer freien Lizenz stehen (must do), und der Source Code sollte öffentlich zugänglich sein (Empfehlung). Das ist erstmal ein Riesen-Schritt, so blöd das klingt ... . Die Frage ist, was darüber hinaus an Strategie wichtig wäre? Ansonsten würde ich vorschlagen, dass wir dazu z.B. eine Wikicon Diskussion machen könnten. Den Wunsch hier würde ich dann vor der Abstimmung rausnehmen und in "Wünsche außerhalb des Projektrahmens" verschieben - der abstimmbare Teil im Sinne der Wunschliste wäre dann in Geolinas Wunsch, für den Rest sollten wir in einem anderen Rahmen weiterdiskutieren. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 16:58, 10. Jun. 2017 (CEST)

Die Punkte 1-3 sind eine Hilfe zum Clustern der Probleme, eine Art Einleitung. Ja, Punkt #1 ist die Hauptaufgabe dieser Wunschliste. Punkt #2 - sicherlich wird dies häufiger geäuert. Geolina soll die Patein des Wunsches sein. Punkt #3 ist ein organisatorisches Problem und wurde auch im Lokal K (bei Tech on Tour) von mir angesprochen. Ich habe das jetzt hier unter "sonstiges" aufgenommen - auch wenn es kein richtiger Wunsch für die Wunschliste ist, sondern mehr eine Strategieerweiterung. --Atamari (Diskussion) 17:33, 10. Jun. 2017 (CEST)

@Atamari:: Wollen wir das nicht beide zusammen einreichen? Ich wäre sehr froh, wenn Du Deine Anmerkungen ergänzen würdest und Dich als Mitautor / Pate einsetzt. das wäre mir wirklich sehr recht. --Geolina ^{mente et malleo} ✎ 10:47, 11. Jun. 2017 (CEST)

Ich weis nicht, ob ich noch relevante Sätze geschrieben habe - aber ich habe den Teil in deinem Vorschlag eingebaut. Punkte #1 und #2 sind hier Einleitung, hier geht es um den Punkt #3 "Digitales Erbe". Schön, dass sich Birgit Müller dazu schon Gedanken gemacht hatte. --Atamari (Diskussion) 13:41, 11. Jun. 2017 (CEST)

@Atamari: hab den Wunsch jetzt hierhin geschoben, der abstimmbare Teil befindet sich ja in Geolinas Wunsch. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 14:23, 12. Jun. 2017 (CEST)

Unterstützung

Einheitliches Layout von Tabellen

Was ist das Problem?

Ich bebildere die Wikipedia mit Fotos von Kulturdenkmalen und Naturschutz. Dazu trage ich die Bilder und evtl. den Link auf die Kategorie in Commons in die entsprechenden Tabellen ein.
Beispiele:

• Liste der Geotope im Kreis Nordfriesland
• Liste der FFH-Gebiete in Schleswig-Holstein
• Liste der EU-Vogelschutzgebiete in Schleswig-Holstein
• Liste der Naturdenkmale in Ludwigshafen am Rhein
• Liste der Naturschutzgebiete im Kreis Bergstraße
• Liste der Kulturdenkmale in der Aacher Altstadt
• Liste der Baudenkmäler in Wolfratshausen
• Liste der Baudenkmale in Lüneburg
• Liste der Baudenkmäler in Hagen
• Liste der Kulturdenkmäler in Neustadt an der Weinstraße (Kernstadt)
• Liste der Kulturdenkmale in Wyk auf Föhr
• Liste des monuments historiques de Wissembourg
• Liste der Baudenkmäler in Stilfs
• Llista de monuments de Santanyí

Der unterschiedliche Aufbau ist IMHO für die Betrachter und die Bearbeiter verwirrend und lenkt vom Wesentlichen (Inhalt) ab.

Wen betrifft das Problem besonders?

Benutzer von Wikipedia, Fotografen und Ersteller von Tabellen zum Thema Denkmäler und Naturschutz.

Anmerkungen

Am Besten wäre es, wenn man für die Unzahl von Tabellen zum Thema Natur- und Denkmalschutz eine einheitliche Darstellung finden würde.

Vorschlagende Person

F. Riedelio (Diskussion) 11:49, 6. Jun. 2017 (CEST)

Diskussion

Hallo @F. Riedelio: Danke für den Wunsch. Ich bin mir aber leider nicht sicher, ob er hier am richtigen Platz ist, da man ihn wohl nicht durch eine Technische Änderung durch die Softwareentwickler lösen würde sondern sich die Wikipedia Community auf ein Format einigen müsste – oder habe ich dich falsch verstanden? -- Michael Schönitzer (WMDE) (Diskussion) 13:49, 6. Jun. 2017 (CEST)

Hallo @Michael Schönitzer (WMDE):,

vielen Dank für die schnelle Antwort.

Dass mit den technischen Wünschen Probleme gemeint sind, die nur durch Entwickler gelöst werden können, war mir leider nicht bewusst.

Dass sich die Wikipedia Community länderübergreifend auf ein Format einigt habe ich kaum Hoffnung ;-(

--F. Riedelio (Diskussion) 17:49, 6. Jun. 2017 (CEST)

Unterstützung

Die zwangsweise Einfügung von Zeilenumbrüchen in den Vorlagen Literatur und Internetquelle durch die Verwendung von WSTM beenden.

Was ist das Problem?

Durch die Zeilenumbrüche werden die Vorlagen in die Länge gezogen und die zu editierenden Texte dadurch unnötig und unübersichtlich verlängert. Gerade bei der Verwendung von vielen Vorlagen in einem Artikel kann das ganz schön nerven. Es gibt Editoren, die die Zeilenumbrüche in ihren Artikeln nicht wünschen.

Wen betrifft das Problem besonders?

Editoren

Lösungsvorschlag

Das WSTM soll nur Zeilenumbrüche anwenden, wenn sie vorher schon in dem Artikel verwendet wurde und soll keine zwangsweise neu erzeugen.

Vorschlagende Person

Ulanwp (Diskussion) 23:03, 1. Jun. 2017 (CEST)

Diskussion

WSTM = WikiSyntaxTextMod, oder? Dann gehört Dein Wunsch/Deine Beschwerde nicht hierher, sondern auf die zu diesem Skript gehörende Diskussionsseite, wo dir der Skriptautor PerfektesChaos dann mit Sicherheit auch eine kompetente Antwort gibt. — Speravir – 20:23, 2. Jun. 2017 (CEST)

Info: Wurde auf der zugehörigen Seite angefragt: Spezial:Diff/166197782 --Crazy1880 20:53, 12. Jun. 2017 (CEST)

@Ulanwp: Danke für deinen Wunsch! Weil es hierbei um ein Skript geht, ist das nichts, was das Team Technische Wünsche bearbeiten kann. Insofern genau richtig, dass du Perfektes Chaos direkt angeschrieben hast. Ich verschiebe diesen Wunsch in die Rubrik „Wünsche außerhalb des Projektrahmens“. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 10:40, 15. Jun. 2017 (CEST)

Unterstützung

Echte Stylesheets für Vorlagen und Metaseiten

Was ist das Problem?

Aktuell können Autoren ihre Vorlagen, Bausteine und Metaseiten nur mit Hilfe von Inline-Styles formatieren, die direkte in den Wiki-Text geschrieben werden. Das macht nicht nur die Quelltexte ziemlich unleserlich, sondern verhindert auch viele Formatierungsmöglichkeiten, die mit normalen StyleSheets möglich sind:

• So ist es z.B. nicht möglich responsiv auf verschieden Bildschirmgrößen zu reagieren. Das verhindert dier Erstellung von Bausteinen und Seiten, die auf kleinen AUflösungen genauso funktionieren, wie auf großen.
• Es ist kaum/nicht möglich, das Aussehen auf RollOver und Status reagieren zu lassen.
• Die Formatierung von Unterelementen (z.B. Links auf einer farbigen Fläche) ist nur mit redundanten zusätzlichen HTML-Elementen möglich.

Inline-Styles sind bei anderen Webseiten und Redaktionssystemen aus gutem Grund ziemlich verpönnt. Sie verhindern nicht nur einen klare Trennung von Aussehen und Inhalt, sondern machen den Code auch sehr schlecht pflegbar, weil Formatierungsänderungen nicht nur einmal zentral, sonder zig-mal an verschiedenen Stellen gemacht werden müssen.

Die aktuelle vorhandene Beschränkung auf Inline-Styles ist auch der Grund dafür, dass die Formatierung der Hauptseite bei jedem einzelnen Aufruf mit der globalen Common.css ausgeliefert werden müssen, weil es schlicht keine andere Möglichkeit gibt.

Wen betrifft das Problem besonders?

• Direkt: alljene, die Bausteine, Vorlage, Portale und Metaseiten erstellen oder warten
• Indirekt: alle Nutzer, die bisher auf kleinen Auflösungen und mobilen Endgeräten nur unzureichend formatierte Seiten angezeigt bekommen.

Lösungsvorschlag

Die Schaffung einer Möglichkeit echte Stylesheets in Vorlagen und Metaseiten zu verwenden (inline in einem <style>-Block oder extern in einer CSS-Datein), würde die Möglichkeiten der Vorlagenbauer und Portalgestalter erheblich erweitern und so die Entwicklung besserer, einfacherer und vorallem Vorlagen für alle ermöglichen. Dieser Wunsch würde also die Voraussetzung für eine einfachere Lösung vieler Probleme schaffen.

Anmerkungen

Auf Phabricator gibt es bereits einen entsprechenden RfC. Dieser Ansatz könnte geprüft, forciert und schnellst möglich hier implementiert werden.

Vorschlagende Person

Martin K. (Diskussion) 23:45, 10. Jun. 2017 (CEST)

Diskussion

@Martin Kraft: Nach Rücksprache mit dem Team kann ich berichten: An diesem Projekt arbeitet die Wikimedia Foundation schon seit Längerem, und das ist aufgrund der Komplexität und der Besonderheiten von Wikitext extrem schwer. Es gibt dort mehrere Leute, die das Projekt unbedingt voranbringen wollen, aber bislang scheiterte es immer an den Besonderheiten von Wikitext. Wikitext 2.0 kann hier hoffentlich Abhilfe schaffen. Leider können wir als Team „Technische Wünsche“ dieses komplexe Thema nicht lösen. Darum verschiebe ich deinen Wunsch nach Wünsche außerhalb des Projektrahmens. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:57, 15. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Ich habe gerade erst gesehen, dass diese Sache hier gelandet ist - was ich nicht so ganz verstehe. Sind die technischen Wünsche nicht auch dazu da, solche Sachen, die schon ewig irgendwo rumdümpeln, zu beschleunigen?

Auch verstehe ich nicht ganz, was das mit WikiText zu tun haben soll? Es geht hier doch bloß um CSS, also etwas was allein bei der Frontendausgabe eine Rolle spielt. Rein technisch ist das doch eigentlich trivial: Man legt einfach in einen bestimmten (ggf. geschützten Namespace) eine CSS-Datei an und bindet sie bei beider Ausgabe einer bestimmten Vorlage ein. An welchem Punkt genau soll es denn da Probleme mit dem Wikitext-Parse geben? Für CSS ist der doch eh nicht zuständig?!

Ich würde Dich bitten, das wieder in die Abstimmung zu verschieben. Und sei es nur um der WMF klar zu machen, dass es hier wirklich Handlungsbedarf gibt. // Martin K. (Diskussion) 21:21, 18. Jun. 2017 (CEST)

Hi Martin!

Die Foundation weiß, dass es da Handlungsbedarf gibt. Das Ticket, das du erwähnst (phab:T133410) wurde von James Forrester, dem Product Manager für "Reading", angelegt. Wenn ich das dort richtig lese, hat das "Reading Infrastructure" Team hat das als Ziel für Q3 ins Auge gefasst (das amerikanische dritte Quartal läuft gerade und geht bis ende Juni). Man rennt da also offene Türen ein. Wenn du wissen möchtest, wieso das so lange dauert, schau dir die Subtasks an. Wenn dich die technischen Details interessieren, frage am besten auf Phabricator.

Das mit "Wikitext 2.0" bezieht sich auf die Möglichkeit, Styles für ein Template zu definieren, die dann nur für dieses Template gelten, und nicht für den Rest der Seite. Das ist mit CSS ohnehin nicht einfach, und ohne "Balanced Templates" (phab:T114445) nicht machbar. Auch daran wird gearbeitet, aber das ist ein dickes Brett, das es zu bohren gilt. Zu dem Für- und Wider und all den Optionen und Dingen, die es zu bedenken gilt, empfehle ich die Lektüre der Diskussion an phab:T483.

Du hast schon Recht, dass technische Wünsche auch dafür da sind, liegengebliebene Features wieder anzuschubsen. Aber das hier ist nicht liegengeblieben, es wird aktiv daran gearbeitet (letzter Commit war am 8. Juni, vor kurzen hatten wir einen RFC zu den technischen Details, phab:T155813). Was also bringt es, das zur Abstimmung zu bringen? -- Daniel Kinzler (WMDE) (Diskussion) 13:57, 19. Jun. 2017 (CEST)

Unterstützung

Möglichkeit zur optionalen Ergänzung eines Kommentars in der Vorlage:Webarchiv

Was ist das Problem?

Bei dieser Vorlage gibt es, wenn ich es richtig gesehen habe, anders als bei ähnlichen Vorlagen wie z. B. Vorlage:Internetquelle nicht die Möglichkeit, sprich keinen Parameter, um einen ergänzenden Kommentar anzubringen. Dies kann jedoch gerade bei komplexeren Archivalien durchaus notwendig und somit sinnvoll sein. Es wäre auch ggf. auch ratsam, auch über die Möglichkeit zur Einbindung weiterer Parameter bspw. aus Vorlage:Internetquelle nachzudenken.

Wen betrifft das Problem besonders?

Alle Benutzer der Vorlage:Webarchiv

Vorschlagende Person

Erdic (Diskussion) 19:43, 10. Jun. 2017 (CEST)

Diskussion

Das gehört doch nicht in die Technischen Wünsche, sondern in die Vorlagendiskussion und/oder die Vorlagenwerkstatt. — Speravir – 00:11, 11. Jun. 2017 (CEST)

@Erdic: Aus dem von Speravir genannten Grund verschiebe ich deinen Wunsch hierhin nach „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 14:26, 15. Jun. 2017 (CEST)

Unterstützung

Genaue Angabe der Anzahl der Beobachter einer Seite wenn geringer als 30

Was ist das Problem?

Es gibt nur größer als 30, dann ist es die genaue Zahl, z.B. 43 oder 77, und weniger als 30 dann sehr ungenau, weil pauschal, weniger als 30 kann 0 oder 29 sein.

Es wurde richtigerweise darauf hingewiesen, dass eine genaue Zahl an Beobachtern die Gefahr birgt, dass diese Seiten gezielt vandaliert werden. Daher wie von Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ vorgeschlagen, die Anzeige der Beobachter an den Status "Aktiver Sichter" koppeln.

Wen betrifft das Problem besonders?

Betrifft alle Benutzer

Vorschlagende Person

Buchbibliothek (Diskussion) 19:00, 29. Mai 2017 (CEST)

Diskussion

Das wurde damals absichtlich eingeführt, um gezielten Vandalismus an (fast) unbeobachteten Seiten zu verhindern. --Flominator 08:30, 30. Mai 2017 (CEST)

Aha, das ist ja interessant und vollkommen plausibel. Dennoch, vielleicht die 30 auf 20 oder 15 herabsetzen? Gruß--Buchbibliothek (Diskussion) 10:11, 30. Mai 2017 (CEST)

Oder man stellt es so ein, dass nur aktive Sichter die genaue Zahl sehen können. Denn wer aktiver Sichter ist, vandaliert wahrscheinlich sowieso nicht mehr. Und noch ne andere Frage: sollte man diese Beobachter irgendwie filtern? Es gibt viele inaktive Benutzer, die aber noch Seiten auf der BEO haben, dise "toten Beobachter" werden aber trotzdem erfasst. Interessanter wäre die Zahl, der aktiven Beobachter. --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 11:51, 30. Mai 2017 (CEST)

Das eine wurde im Wikipedia:Meinungsbilder/Erweiterung der Sichterrechte abgelehnt, die Zahl der aktiven Beobachter entspricht je nach Definition der Zahl in der Zeile darunter „Anzahl der Beobachter dieser Seite, die die letzten Bearbeitungen besucht haben“, die nur angezeigt wird, wenn die Zahl groß genug ist. (Beispiel) –Schnark 12:06, 30. Mai 2017 (CEST)

Letztendlich also nix für Technische Wünsche, sondern eine reine Konfigurationsänderung. --Schniggendiller Diskussion 17:55, 30. Mai 2017 (CEST)

Als aktiver Sichter hat man eine Möglichkeit herauszubekommen wie viele Sichter es sind: Einfach unangemeldet bearbeiten und als Sichter sieht man auf der Seite "Seiten mit ungesichteten Versionen" beispielsweise "[Artikel] (Versionen) (-367)‎ (sichten) (46 Tage) (von 16 aktiven Benutzern beobachtet)" --DWI (Diskussion) 12:21, 31. Mai 2017 (CEST)

Die Definition von aktiv ist aber in den beiden Fällen unterschiedlich (besuchte Bearbeitungen vs. Benutzer, die sich im letzten Jahr angemeldet haben - grob ausgedrückt). Der Umherirrende 17:21, 31. Mai 2017 (CEST)

@Buchbibliothek: Danke für deinen Wunsch! Mit Beginn der Abstimmung werden die Diskussionen zu den einzelnen Wünschen in dieser Umfrage eingeklappt, damit klar ist, dass man seine Stimme für den Wunsch abgibt und nicht beispielsweise für Vorschläge in den Kommentaren. Wenn in den Kommentaren gute Ideen oder Ergänzungen für den Wunsch stehen, wäre es daher sinnvoll, sie in der Beschreibung des Wunsches zu ergänzen. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:58, 9. Jun. 2017 (CEST)

Wie bereits oben verlinkt wurde die Kopplung der Anzeige der Beobachter an den Status „Aktiver Sichter“ bereits in einem Meinungsbild abgelehnt. Diese Entscheidung kann natürlich revidiert werden, aber nicht in einer einfachen Umfrage, sondern nur in einem erneuten Meinungsbild. Aus technischer Sicht gibt es nichts zu tun, da die Möglichkeit die exakte Zahl anzuzeigen prinzipiell existiert. Eine Abstimmung über diesen Wunsch hier halte ich daher nicht für zielführend. –Schnark 10:01, 10. Jun. 2017 (CEST)

Danke für die Hinweise, hätte nicht gedacht, dass das Thema so vielschichtig ist. Gruß--Buchbibliothek (Diskussion) 10:16, 10. Jun. 2017 (CEST)

@Buchbibliothek: Angesichts der Vorgeschichte dieses Wunsches, wie von Schnark beschrieben, verschiebe ich ihn in die Rubrik „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:56, 15. Jun. 2017 (CEST)

Unterstützung

Bearbeitungskommentare checken

Was ist das Problem?

Meiner Einschätzung nach sind viel schlechte Erfahrungen und Irritationen bei Neulingen darauf zurückzuführen, dass sie nicht versehen warum sie revertiert wurden. Das ist zum einen darauf zurückzuführen, dass sie selbst keinen Bearbeitungskommentar und keine Belege angeben und andererseits die jenigen, die sie revertieren das auch nicht (oder nur mit kryprischen Kürzeln) tun. Das sorgt auf beiden Seiten für viel Frust und überflüssige Arbeit und hat sicher auch schon dem ein oder anderen die Mitarbeit verleidet.

Es wäre daher wünschenswert, wenn für jeden bei jedem Edit klar wäre, was der andere eigentlich will oder eben nicht. Und dafür gibt es ja die Bearbeitungskommentare.

Wen betrifft das Problem besonders?

• Direkt: Neulinge und wenige erfahrene Autoren
• Indirekt: Alle Autoren

Lösungsvorschlag

Es sollte bei Speichern von ANR-Edits (in beiden Editoren) angezeigt werden ob ein Bearbeiungskommentar angegeben wurde, oder keiner oder nur der Blankotext da steht. In letzteren Fällen sollten ein Warnhinweis angezeigt werden, der die Autoren nochmal zur Eingabe eines Bearbeitungskommentars auffordert und im folgende Möglichkeite lässt:

• Zurück um Kommentar einzugeben
• Trotzdem weiter ohne Kommentar
• Wählen aus einer Liste verständlicher Standardkommentare (Rechtschreibung, Wikilinks, etc)

Bei Reverts sollten generell solche Standardfloskeln angeboten werden, so dass man schnell, verständlich und ohne Kürzel angeben kann, was nicht stimmt (z.B. "keine Quelle") und was jetzt zu tun ist.

Des weiteren könnte man bei diesem Schritt auch prüfen ob ein längerer Abschnitt hinzugefügt wurde und ob dabei Belege verwendet wurden. Wenn das nicht der Fall ist kann man auch darauf im Speichern-Dialog hinweisen.

Das Ganze sollte natürlich so kurz und prägnant wie möglich sein.

Vorschlagende Person

Martin K. (Diskussion) 20:21, 11. Jun. 2017 (CEST)

Diskussion

• Gibt es schon seit vielen Jahren per Häkchen auf Spezial:Einstellungen #mw-prefsection-editing.
• Die Nutzung ist freiwillig.
• Es gibt seit über einem Jahrzehnt keinen Community-Konsens, dies verpflichtend für IP und/oder angemeldete Benutzer zu machen.

VG --PerfektesChaos 20:11, 12. Jun. 2017 (CEST)

Ok, das war mir bisher nicht bekannt, aber...

• Freiwilligkeit bringt hier nichts, weil es das Problem nicht löst. Weder bei den Neulingen, die diese Einstellung nicht kennen, noch bei den Bestandsautoren, die sie revertieren,
• Dass diese Einstellung für alle Seiten gilt und nicht nur für den ANR macht sie de facto unbrauchbar: Niemand hat lust zu jedem Diskussionsbeitrag und jeder Vorlage-Code-Änderung ellenlange Begründungen zu schreiben. Logisch dass das so von der Community nicht akzeptiert wird.
• Außerdem fehlt das Feature, einfache Standard-Kommentare per Klick auszuwählen – was mMn eine Grundlage für eine breite Akzeptanz dieser Regelung wäre.
• Und die Usability lässt auch ziemlich zu Wünschen übrig. Idealerweise sollte das ohne Server-Request gecheckt und dann direkt über der Kommentarzeile angezeigt werden. Es hat schließlich niemand Lust erst ewig auf so ein Feedback zu warten und dann auch noch selbst runter zuscrollen.

Natürlich hast Du insofern recht, dass es für die Einführung so einer Regelung eines entsprechenden Community-Konsenses bedürfte. Aber dafür müsste erst mal klar sein, wie diese Funktionaität genau aussehen könnte. Und idealerweise gibt es dann eine fertige Beta-Funktion/ein Helferlein das man dann testen kann um fundiert abzustimmen. // Martin K. (Diskussion) 20:53, 12. Jun. 2017 (CEST)

• Freiwilligkeit bringt hier nichts
  • Mit dieser Einstellung wirst du dich hier um jeden zweiten Laternenpfahl am Straßenrand wickeln.
• Die Community hat deine Ansichten jetzt wohl bald ein Jahrzehnt lang immer abgelehnt.
  • Grund ist, dass sie eine zusätzliche Barriere für die Erstbearbeitung und die Newbies schaffen.
  • Leseprobe.
• Wer zum allerersten Mal einen Artikel bearbeiten will, muss eine Vielzahl von Dingen auf einmal erlernen.
  • Die Änderung muss inhaltlich sinnvoll und richtig sein.
  • Idealerweise enthält die Änderung gleich auch einen Beleg.
  • Ist meine Ergänzung eigentlich relevant? Wollen „die“ das überhaupt wissen?
  • Man muss sich erstmal trauen.
  • Die ganzen Knöpfe und Software-Bedienung und Formatierung.
  • Darf ich unangemeldet bearbeiten? Müsste ich mich jetzt nicht doch vorher registrieren lassen?
  • Die Community war regelmäßig der Ansicht, dass das für den Anfang schon schwer genug ist, und dass alle weiteren Umstände nach und nach und mit wachsender Erfahrung und Gewöhnung zu erlernen sind.
• Du forderst, dass bei Benutzern mit aktiviertem JavaScript das Abspeichern der (ANR)-Änderung verweigert werden soll, wenn jetzt nicht noch in einem weiteren Menü aus einer Liste unverständlicher Phrasen eine ausgewählt würde.
  • Die Community hat sich entschieden, hier keine zusätzlichen Hürden zu errichten; maximal einmalig zu warnen und zur Angabe einer Zusammenfassung aufzufordern.
  • Was ohne aktives JavaScript passieren soll, lässt deine Forderung im Unklaren. Soll auf PHP-Ebene die Abspeicherung komplett blockiert werden? Oder wird dann unbeanstandet gespeichert?
• Es müsse eine Auswahlliste angeboten werden.
  • Die bieten gängige Browser von selbst an.
  • Firefox listet die häufigsten verwendeten Eingaben als Pop-Up auf, die in das mit diesem Identifizierer gekennzeichnete Formularfeld eingegeben wurden; zunächst die Texte, die mit den bislang getippten Buchstaben beginnen, danach diejenigen, die das als Wort enthalten.
  • Auf k erhalte ich als Auswahlmenü etwas wie:
    • k
    • katupdate
    • katfix
    • katsort
    • katupdate tk k
  • Die gängigen Aktivitäten sind auf H:ZQ mit Ein- bis Zwei-Buchstabenkürzeln zusammengestellt. Wer guten Willens war, hat das in den letzten anderthalb Jahrzehnten mit einem t / lf / kat / ü / tk hinbekommen.
  • Alle im vorgeschlagenen Auswahlmenü zu zeigenden Standardtexte dürften schon seit anderthalb Jahrzehnten abgekürzt vorliegen; und das halbe Dutzend davon, das man selbst aktiv zu schreiben pflegt, lässt sich auch merken. Wenn nicht, tippt man halt mal drei Worte. Der genau auf die Situation passende Standardtext wird sowieso nie angeboten, wenn man ihn mal bräuchte. Es gäbe Hunderte.
  • Der BK hat begrenze Länge; die automatische Rücksetz-Meldung frisst schon reichlich Bytes und irgendwann ist dann irgendwo Schluss; mehr als ein paar Schlagworte sind nicht anzufügen, auch abgekürzt.
• Dürfe nur im ANR, nicht in anderen Namensräumen angewendet werden.
  • Die häufigsten Nicht-ANR-Seiten sind Diskussionen und vergleichhbare Plattformen. Hier kann aw getippt werden und der Kas ist gegessen.
  • Wo behauptete „ellenlange Begründungen“ außerhalb des ANR erforderlich wären, ist nicht nachvollziehbar.
  • Auch sonst langt ein simples + oder senf als Zusammenfassung.
  • t und lf sind universell anwendbar.
  • Deshalb macht die Notwendigkeit, außerhalb des ANR mal eine Taste für irgendein k zu drücken, diese Einstellung auch nicht „de facto unbrauchbar“ wie behauptet.
  • Nebenbei schützt sie auch vor versehentlich zu schnellem Abspeichern, wenn man erst seinen Text in der Vorschau liest, zum Schluss ZQ ausfüllt, und erst danach die wirksame Speicherung freigegeben wird – und das in allen Namensräumen.
• Allgemein fällt bei diesen „Technischen Wünschen“ auf, dass reihenweise Sachen vorgetragen werden, die keine neuartigen technischen Ideen sind, sondern uralte Vorstellungen, die es deshalb nicht gibt, weil sie keinen Community-Konsens haben, und nicht weil noch keiner auf die Idee kam. Etliches bedenkt auch die Nebenwirkungen und Konsequenzen jenseits der Technik nicht; insbesondere wenn wesentliche Veränderungen und gar verpflichtend für alle Benutzer gefordert werden. Grundsätzlich scheitert regelmäßig der Versuch, eine soziale oder kommmunikative Problematik (hier: „Bestandsautoren revertieren zu oft“; Bestandsautoren geben bei Newbies/IP keine Begründung an) an den Beteiligten vorbei durch technische Mittel lösen zu wollen; es wären dann die zu hastig revertierenden Bestandsautoren anzusprechen. Ob das helfen würde, ist wieder eine andere Frage; aber ob das Tool dabei was hilft und dass jemand fremde Beiträge aller Art, egal ob mit Zusammenfassung, von IP oder sonstwem, aus „seinen“ Artikeln systematisch wieder revertiert, wird JavaScript nicht lösen können.

VG --PerfektesChaos 14:04, 14. Jun. 2017 (CEST)

@Martin Kraft: Ich möchte das mit dem Meinungsbild auch bestätigen. Was ich ergänzen möchte, ist dass wir ohne Meinungsbild auch nicht an einem Prototypen oder einer Beta-Version arbeiten können, weil die Wahrscheinlichkeit, dass die Funktion dann nicht zum Einsatz kommt, zu hoch ist. Da wir hier ohne positives Meinungsbild nichts machen können, verschiebe ich diesen Wunsch nach „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 19:45, 15. Jun. 2017 (CEST)

Aus dieser Diskussion mitnehmen ließe sich meiner Meinung nach, dass die Liste der Abkürzungen in Hilfe:Zusammenfassung und Quellen#Abkürzungen eine sehr gute Sache ist, aber erst einmal gefunden werden muss. Auf der Bearbeitungsseite gibt es den Link „Zusammenfassung und Quellen“, aber in der Versionsgeschichte – in der man die Abkürzungen in Zusammenfassungen anderer Bearbeiter liest, fehlt ein Link auf Hilfe:Zusammenfassung und Quellen#Abkürzungen. Eine Versionsgeschichte enthält oben eine graue Box, in der die allermeisten Elemente eines Bearbeitungs-Bulletpoits erläutert werden, die Zusammenfassung und ihre Abkürzungen aber nicht. Der Vorhandene „Hilfe“ Link fürt zu Hilfe:Versionen (von wo aus man sich dann durchklicken müsste). Ich halte es daher für sinnvoll, in den Versionsgeschichte-Seiten einen Link zu Hilfe:Zusammenfassung und Quellen#Abkürzungen oder Hilfe:Zusammenfassung und Quellen anzubringen. --X:: black ::X (Diskussion) 13:30, 16. Jun. 2017 (CEST)

Lösungsvorschlag

Ein hilfreier erster Schritt wäre m.E.: keine Abkürzungen verwenden.
Dadurch kann der Autor simpel verstehen, was ein QS(sic.!)-Bearbeiter aussagen will. ;-) Abkürzungen und Wiki-Slang könnte man in vielen Fällen sogar automatisch in Normalmensch-lesbare Texbausteine übersetzen.
Das Ganze ist m.E. ein Werte-Problem. WP lässt zu, dass "Bestandsautoren" die Arbeit von anderen Autoren abwerten und sich dabei rüder Methoden bedienen. Gruss, --Markus (Diskussion) 08:19, 21. Jun. 2017 (CEST)

Unterstützung

Kurz- und Langfassungen

Was ist das Problem?

Viele Artikel sind sehr umfangreich und oft auch zu fachspezifisch für Laien. Wenn sich ein Leser schnell informieren will, sind solche Artikel oft nicht mehr brauchbar. Die Einleitung hingegen ist zu wenig.
Nachtrag und Hinweise betreffend Diskussion: * Es geht dabei nicht um kindergerechte Artikel. * Die Intention ist keinesfalls, dass Artikel unter Verlust von Informationen gekürzt bzw. umgeschrieben oder Informationen aus der Wikipedia ausgelagert werden.

Wen betrifft das Problem besonders?

Leser, welche sich schnell informieren wollen und/oder Laien in diesem Fachbereich sind.

Lösungsvorschlag

Ein Button, mit welchem man zwischen einer kurzen sowie leicht lesbaren Version und der ausführlichen Version hin- und herschalten kann.
Nachtrag: Andere Lösungen wie zusätzlicher Reiter oder ein hervorgehobener Zusammenfassungs-Block nach der Einleitung wären ebenfalls denkbar.

Vorschlagende Person

Schaffnerlos (Diskussion) 12:54, 29. Mai 2017 (CEST)

Diskussion

Interessante Idee, vieleicht aber zu umfangreich, da man zahlreiche Artikel doppelt schreiben müsste. Bessser wäre es die Artikel so umzuschreiben, das Laien sie (v.a. auch unter der Benutzung von WIkilinks für Vorerklärungen) verstehen bzw in die Materie einsteigen können. Eine zweite Option wäre, wenn man bei besonders gefragten (wissenschaftlichen) Artikel unter Weblinks auch Erklärtexte/Viedos/etc speziell für Anfänger verlinkt. Ansonsten gibt es ja auch Wikibooks/Wikiversity. --Cedrichoyer (Diskussion) 15:07, 29. Mai 2017 (CEST)

So eine ähnliche Idee gab es mal vor 7 Jahren Wikipedia:Meinungsbilder/Kinderseiten (abgelehnt). Die Problembeschreibung ist vollkommen korrekt, ich glaube aber nicht dass das die Lösung dafür ist. --DWI (Diskussion) 11:45, 31. Mai 2017 (CEST)

Bin ich voll dafür, habe gerade das gleiche Problem hier angesprochen: https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#viele_Fachartikel_unverst.C3.A4ndlich Wobei es nicht nur um kurz oder lang geht, sondern auch um Laienniveau und Fachniveau. --2.246.106.12 16:14, 1. Jun. 2017 (CEST)

@Schaffnerlos: Hallo und danke für deinen Vorschlag! Ich möchte kurz darauf hinweisen, dass bei der Abstimmung (ab 19. Juni) die Diskussion eingeklappt wird, damit klar ist, worüber abgestimmt wird. Wenn Hinweise aus der Diskussion für deinen Wunsch hilfreich sind, wäre es also wichtig, dass du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:59, 10. Jun. 2017 (CEST)

Hallo Schaffnerlos, ich habe zu deinem Wunsch noch mal Rücksprache gehalten: Leider geht er über den Rahmen des Projekts „Technische Wünsche“ hinaus, weil er primär die Inhalteerstellung betrifft. Denn bevor eine technische Lösung dafür erstellt werden könnte, müsste in der Community erst mal darüber abgestimmt werden, ob leicht lesbare Versionen überhaupt gewünscht sind. Ich verschiebe den Wunsch darum morgen in die Rubrik Wünsche außerhalb des Projektrahmens. Dort kannst du weiter darauf zugreifen, wenn du die die Informationen noch an anderer Stelle benötigst (z. B. für ein Meinungsbild). -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:15, 14. Jun. 2017 (CEST)

Verschoben -- Johanna Strodt (WMDE) (Diskussion) 19:48, 15. Jun. 2017 (CEST)

Unterstützung

Wikipedia-HTML-Seiten ohne die linke Spalte mit Überschift "Wikipedia, Die freie Enzyklopädie" usw. anzeigen.

Was ist das Problem?

Gesucht ist eine Möglichkeit, die Spalte auszublenden. Die meisten Links in dieser Spalte interessieren mich nur sporadisch (z.B. andere Sprachen). Mit schlechten Augen habe ich gern große Schrift, und die linke Spalte nimmt nur sinnlos Platz weg. Auch als Werbung für Wikipedia geht das nicht durch, das ließe sich auch weniger nervig und eleganter machen.

Wen betrifft das Problem besonders?

Leute mit sub-optimale Sehschärfe.

Lösungsvorschlag

Per Button expandiern oder komprimieren, ein vertkaler Button braucht nicht viel Platz. Oder ein Slider.

Vorschlagende Person

Rdengler (Diskussion) 21:27, 30. Mai 2017 (CEST)

Diskussion

Guter Punkt. Ich denke es wird sicher Verfechter der Spalte geben, aber man sollte sich zumindest über den Inhalt der Spalte Gedanken machen. Ich meine wer benutzt so häufig den Button Von A bis Z oder Letzte Änderungen oder gar Buch erstellen. Also klar es gibt sicher Nutzer, aber die "Allgemeine" Sidebar sollte Einträge enthalten die die Allgemeinheit interessieren und nicht ganz kleine Nieschen. Ausserdem gibts an der Linken Seite (Eben diese Sidebar) 'Knöpfe', dann welche oben Rechts (Beobachtungsliste und co), dann gibts welche an der Seite selber (Artikel, Diskussion, ...). Sprich ein wenig durcheinander alles in allem. Klar es ist alles "historisch gewachsen" wie man so schön sagt. Aber vielleicht kann man hier allgemein etwas "aufräumen". --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 22:07, 30. Mai 2017 (CEST)

Grundsätzlich ist der Inhalt der linken Leiste nicht „fest verdrahtet“ in der Software. Was dort für Links stehen und in welcher Reihenfolge, kann (von Admins) gesteuert werden Das wäre dann aber eine Entscheidung, die die Community treffen müsste … Gruß --Schniggendiller Diskussion 22:51, 31. Mai 2017 (CEST)

• @Rdengler: Hallo! Ich möchte kurz darauf hinweisen, dass die Diskussion bei der Abstimmung (ab 19. Juni) eingeklappt wird, damit klar ist, worüber abgestimmt wird. Wenn dir in der Diskussion Hinweise gegeben wurden, die für deinen Wunsch hilfreich sind, wäre es also wichtig, dass du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – noch ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 16:03, 10. Jun. 2017 (CEST)

• @Rdengler: Kennst Du die mobile Version der Wikipedia? Für „Leute mit sub-optimaler Sehschärfe“ dürfte die doch wesentlich besser zu nutzen sein, als die Desktop-Version?! Wäre das nicht schon eine Lösung für Deinen Wunsch? // Martin K. (Diskussion) 18:33, 13. Jun. 2017 (CEST)

@Rdengler: Wie Martin K. schon schreibt, gibt es mit der mobilen Version der Wikipedia bereits Seiten ohne die linke Spalte, die man ja auch am Desktoprechner nutzen kann. Insofern liest es sich für mich so, als sei dein Wunsch schon erledigt, weshalb ich ihn ihn heute (Do, 15. Juni) gegen 18.00 nach Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche verschiebe. Falls du damit nicht einverstanden bist, gib mir bitte ein Zeichen. In dem Fall wäre es gut, wenn du im Wunsch selbst (also nicht in der Diskussion) noch mal ergänzt, was du dir über das hinaus, was die mobile Version schon bietet, noch wünschst. -- Beste Grüße und vielen Dank, Johanna Strodt (WMDE) (Diskussion) 09:52, 15. Jun. 2017 (CEST)

Verschoben -- Johanna Strodt (WMDE) (Diskussion) 19:49, 15. Jun. 2017 (CEST)

Unterstützung

Kurzversion von langen Artikeln

Was ist das Problem?

Mit zunehmender Länge werde Artikel für kurzes Informieren unbrauchbarer.

Wen betrifft das Problem besonders?

Leser und Schreiber von Wikipedia

Lösungsvorschlag

Ab einer gewissen Länge eines Artikels, sollte es die Aufforderung an Autoren geben, parallel eine Kurz-Version des Artikels zu erstellen bzw. pflegen.

Anmerkungen

Als Vision wäre auch ein Schieber denkbar, bei dem man einstellen kann, welche Länge eines Artikels man lesen möchte.

Vorschlagende Person

Rewo (Diskussion) 22:10, 11. Jun. 2017 (CEST)

Diskussion

@Rewo: Was genau ist an diesem Wunsch "technisch"? Und wieso postest Du das eigentlich gleich in drei verschiedenen Kategorien 1, 2, 3? // Martin K. (Diskussion) 22:35, 11. Jun. 2017 (CEST)

Die Vision wäre ein verstellbarer Schieber, durch den sich je nach Stellung die Länge eines Artikels ändert. Als erster Schritt dahin wäre die Möglichkeit einer Kurz-Version von langen Artikeln wünschenswert. Es sind drei unterschiedliche Thematiken, die ich anspreche! Hier (Punkt 3) geht es um die reine Länge eines Artikels. In Punkt 2 geht es um die Verständlichkeit von Artikeln. Und Punkt 1 ist sowieso was ganz anderes, dort geht es um das Suchen auf Seiten. Rewo (Diskussion) 23:28, 11. Jun. 2017 (CEST)

Ja, aber wie genau soll das denn technisch realisiert werden?

Es gibt zwar mittlerweile einiges an Software zur künstlichen Textgenerierung. Generell steckt diese Technoogie aber noch ziemlich in den Kinderschuhen. Ein Software, die die Informationen eines bestehenden langen Textes so stufenlos auf eine vorgegebene Textlänge kondensiert, dass jeweils ein gut lesbarer Text mit den wichtigsten Inhalten rauskommt, ist meiner Einschätzung heute noch Zukunftsmusik. Und angesichts der erheblichen Vorbehalte, die es hier-zu-wiki Bot-generierten Artikeln gegenüber gibt, ist es zudem fraglich ob die Community das überhaupt akzeptieren würde, wenn es möglich wäre.

Etwas anderes wären natürlich manuell erstellte Kurzversionen. Allerdings wäre das keine technische Lösung, sondern müsste von irgendwem geschrieben werden. Was wiederum die Pflegeaufwände erheblich erhöhen würde - und das bei stagnierender/schwindender Autorenzahl. // Martin K. (Diskussion) 14:38, 12. Jun. 2017 (CEST)

Technisch geht es um die grundsätzliche Möglichkeit von mehreren Artikel zu einem Thema, die gut sichtbar miteinander verknüpft sind. Rewo (Diskussion) 23:09, 12. Jun. 2017 (CEST)

Hallo Rewo, danke für deine beiden Wünsche zu kürzeren bzw. einfacheren Versionen von Artikeln. Du beschreibst ein paar technische Lösungsansätze für deine Probleme, insofern ist es verständlich, dass du sie hier als Technische Wünsche einreichst. Allerdings greifen beide Wünsche tief in das Thema Inhalte ein und da endet der Rahmen des Projekts „Technische Wünsche“. Selbst wenn es eine technische Lösung gäbe, müsste also zuerst unbedingt eine Klärung innerhalb der Community erfolgen, ob eine solche neue Inhaltsform überhaupt gewünscht ist. Darum verschiebe ich deine Wünsche morgen in die Rubrik Wünsche außerhalb des Projektrahmens. Damit sind sie nicht gelöscht und du kannst weiterhin darauf zugreifen, z. B. für ein Meinungsbild. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:19, 14. Jun. 2017 (CEST)

Verschoben -- Johanna Strodt (WMDE) (Diskussion) 19:52, 15. Jun. 2017 (CEST)

Unterstützung

Einfache Version von Artikeln

Was ist das Problem?

Bei bestimmten Fachgebieten, vor allem bei mathematischen Themen, beinhalten Artikel sehr viele theoretische Ausdrucksformen. Selbst als vorgebildete Person hat man von solchen Artikeln meist nicht viel Nutzen.

Wen betrifft das Problem besonders?

Leser von Artikeln mathematischer und anderer Fachgebiete

Lösungsvorschlag

Hierfür sollte es die Möglichkeit der Aufforderung an die Schreiber geben, eine einfache Version des Artikels zu erstellen, die auch von Personen verstanden werden, die nicht Experten auf diesem Gebiet sind.

Vorschlagende Person

Rewo (Diskussion) 22:25, 11. Jun. 2017 (CEST)

Diskussion

Das ähnelt sehr dem obigen Wunsch #Kurz- und Langfassungen. — Speravir – 23:29, 12. Jun. 2017 (CEST)

Hallo Rewo, kurze Info: Ich habe bei deinem anderen Wunsch einen Kommentar hinterlassen, der auch diesen Wunsch betrifft. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 11:23, 14. Jun. 2017 (CEST)

Verschoben -- Johanna Strodt (WMDE) (Diskussion) 19:54, 15. Jun. 2017 (CEST)

Unterstützung

Bei Verschiebungen sollen alle Links auf die Ursprungsseite automatisch zu Links auf die neue Seite umgewandelt werden (also keine bloße Weiterleitung).

Was ist das Problem?

Jeder kennt das Problem: Man will eine Seite verschieben, und wenn diese noch besonders häufig verlinkt ist, steht man vor dem lästigen Problem, idealiter alle diese Links auf das neue Lemma „umbiegen“ zu müssen, damit man nicht erst über den Zwischenschritt einer Weiterleitung zum richtigen (neuen) Lemma gelangt.

Wen betrifft das Problem besonders?

Jeden aktiven Nutzer

Lösungsvorschlag

Automatische Synchronisierung (?) oder aber, wenn das partout nicht möglich ist, Bot (idealiter beide Lösungen global wirksam).

Vorschlagende Person

Erdic (Diskussion) 17:38, 10. Jun. 2017 (CEST)

Diskussion

Automatisches Umbiegen in den Artikeln ist analog zu Wikipedia:Umfragen/Technische_Wünsche_2017/Bearbeiten#Weiterleitungslinks_auf_Kapitel_warten nicht ohne Weiteres möglich, da natürlich die Versionsgeschichten davon betroffen sind und nicht einfach von der Software selbst editiert werden können. Ein Bot kann das aber recht einfach erledigen. --FNDE 20:15, 11. Jun. 2017 (CEST)

• Zum Umgang mit entstehenden Weiterleitungsseiten nach Verschiebungen gibt es langjährige und differenzierte Projektregeln; siehe WP:WL.
• Der Vorschlag ignoriert das völlig; in dieser pauschalen Form ist das unerwünscht.
• Insbesondere ist nicht erwünscht, die voll funktionsfähige WL-Form in womöglich Tausenden von Edits und Beo-Flutung gerade von in diesem thematischen Umfeld tätigen Autoren zu ändern; von der ebenfalls unerwünschten Vermüllung der Versionsgeschichte mit automatischen nicht erforderlichen Edits mal abgesehen.
• Inhaltlich kann die automatisch ausgelöste Veränderung fehlerhaft sein; etwa weil ein Lemma geteilt wurde oder eine BKS-Situation durch Aufgliederung in unterschiedliche Zielseiten im Einzelfall geklärt werden muss.
• Es kann auch perspektivische Gründe im Sinne zukünftiger Lemmateilung und Neuanlage inhaltlicher Seiten geben, wodurch diese automatischen Veränderungen nicht sinnvoll wären.
• Genauso kann es sein, dass nur die gebräuchlichste Schreibung oder hübscheste Klammerlemmatisierung durch Verschiebung prominent dargestellt werden soll. Der Geschmack kann sich aber bald ändern, und eine Woche später wird zurückverschoben und Tausende verlinkender Artikel werden wieder automatisch umgeschrieben.
• In konkret benannten und durch MB und langjährige Diskussionen herausgearbeiteten Fällen kann es sinnvoll sein, falsche oder irritierende Schreibweisen und die Weiterleitungsseite komplett zu eliminieren.
  • Das kann man bei größeren Stückzahlen an AWB/Bots delegieren.
• Welcher Account mit welchen (Sichter-)Rechten den Edit an den verlinkenden Seiten vornehmen soll, erläutert der Vorschlag auch nicht. Oder ist die Vorstellung, dass die auf diese Weise generierten Tausende von unerwünschten Edits dem Editcount des verschiebenden Benutzers gutgeschrieben werden sollen?

VG --PerfektesChaos 10:43, 12. Jun. 2017 (CEST)

Hallo Erdic, danke für deinen Wunsch! Wir haben im Team darüber gesprochen und sind zu dem Schluss gekommen, dass dieser Wunsch den Rahmen des Projekts „Technische Wünsche“ überschreitet. Der Grund dafür ist, dass eine Software-Lösung für dieses Problem in den Inhalt der Seiten eingreifen würde – und für die Inhalte liegt die Hoheit klar bei der Community. Zumal es passieren könnte, dass die Software Änderungen vornimmt, die unerwünscht oder sogar falsch sind, wie ja auch von PerfektesChaos angemerkt. Wie FNDE und PerfektesChaos schon schreiben, wäre das eine Aufgabe für einen Bot. Dieser sollte durch die Community betrieben werden. Aus diesen Gründen verschiebe ich deinen Wunsch morgen in die Rubrik Wünsche außerhalb des Projektrahmens, wo er weiterhin einsehbar bleibt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 13:40, 14. Jun. 2017 (CEST)

Verschoben -- Johanna Strodt (WMDE) (Diskussion) 19:57, 15. Jun. 2017 (CEST)

Unterstützung

Maximale Zeitperiode von Änderungen in beobachteten Seiten

Was ist das Problem?

Die maximale wählbare Zeitperiode der angezeigten Änderungen in von mir beobachteten Seiten ist zZ auf 30 Tage beschränkt. In der Folge kann ich Änderungen an von mir beobachteten Seiten nicht anzeigen lassen und nachvollziehen.

Wen betrifft das Problem besonders?

Alle die Seiten beobachten.

Lösungsvorschlag

Erhöhung der maximalen wählbaren Zeitperiode der angezeigten Änderungen in von mir beobachteten Seiten, z.B. auf 10 oder 20 Jahre.

Vorschlagende Person

Kellerpm (Diskussion) 18:59, 30. Mai 2017 (CEST)

Diskussion

Hallo Kellerpm, vielen Dank für deinen Wunsch! Die Anzeige der Änderungen der von dir beobachteten Seiten werden über die Daten aus den "Letzten Änderungen" zur Verfügung gestellt, wo die Änderungen an allen Seiten eines Wikis angezeigt werden. Dort gibt es das Limit 30 Tage für die Einsicht in die letzten Änderungen. Dies hat zum einen datenschutzrechtliche Gründe, hat aber auch damit zu tun, dass sich bei einem größeren Zeitraum zuviele Einträge in den letzten Änderungen sammeln würden. Bei großen Wikis wie der deutschsprachigen Wikipedia würde eine größere Zeitspanne die letzten Änderungen nicht mehr gut nutzbar machen, da es die Liste quasi "fluten" würde. Die Einträge auf der Beobachtungsliste stellen sozusagen die personalisierte Auswahl der "letzten Änderungen" dar und wegen der Abhängigkeit von den "letzten Änderungen" kann folglich keine längere Zeitspanne eingestellt werden, als es in den "letzten Änderungen" möglich ist. Ich würde daher deinen Wunsch morgen (Donnerstag, den 15.) in die Rubrik "Wünsche außerhalb des Projektrahmens" umziehen, wo wir Wünsche sammeln, die vom Technik-Team nicht lösbar sind. Ich hoffe, dass es noch den einen oder anderen Wunsch in dieser Sammlung gibt, der für dich eine hilfreiche Verbesserung wäre! Die Abstimmung beginnt am Montag, den 19. Juni um 10 Uhr. Herzliche Grüße, --Birgit Müller (WMDE) (Diskussion) 11:47, 14. Jun. 2017 (CEST)

PS., Kellerpm, der Wunsch ist jetzt hierhin verschoben. LG, --Birgit Müller (WMDE) (Diskussion) 09:34, 16. Jun. 2017 (CEST)

Unterstützung

Standardmäßige Generierung eines Beitragslinks zur Signatur

Was ist das Problem?

Gerne rege ich an, für die Signaturfunktion auch die Generierung eines Links zu Spezial:Beiträge bei der Signaturausgabe zu erwägen. Ich denke, dies könnte gerade bei komplexeren Diskussions- und insbesondere Konfliktsituationen durchaus hilfreich sein, um sich schnellstmöglich einen Überblick über die letzten Edits eines interessierenden Users zu verschaffen. So wäre unmittelbar von der Signatur aus die Möglichkeit gegeben, einen Eindruck vom Editierverhalten des signierenden Accounts zu erhalten. Zugleich könnte diesbezüglich auch über eine z. B. in den Einstellungen zu aktivierende Abwahloption nachgedacht werden, sodass es bei der dezidierten Abwahl dieser Funktion wie gehabt lediglich bei der Generierung des Benutzerseiten- und Benutzerdiskussionsseitenlinks im Rahmen der Signatur bliebe.

Wen betrifft das Problem besonders?

Sämtliche Projektbeteiligten

Vorschlagende Person

Erdic (Diskussion) 01:53, 11. Jun. 2017 (CEST)

Diskussion

Hallo @Erdic: Danke für diesen Wunsch! Hierüber müsste die Community zunächst abstimmen, ob es gewollt ist, dass das standardmäßig angezeigt wird. Die technische Umsetzung wäre dann gar nicht so kompliziert und bräuchte möglicherweise gar kein (oder nur sehr wenig) Zutun vom Team der Softwareentwicklung. Darum verschiebe ich diesen Wunsch nach „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 18:50, 16. Jun. 2017 (CEST)

Unterstützung

Bei Vorlage "All Coordinates" Anzeige von Koordinaten auch in verlinkten Artikeln und Listen

Was ist das Problem?

In Listenartikeln und Kategorien kann man über die Vorlage "All Coordinates" die Anzeige aller mit Koordianten versehender Einträge/Artikel ermöglichen. so werden z. B. in Liste der Baudenkmale in Fürstenberg/Havel oder Liste der Kulturdenkmale in der Neustadt (Dresden, E–J) alle mit Koordinaten versehenen Kulturdenkmäler angezeigt. Viele Denkmallisten sind aufgrund der Größe in Unterlisten zerlegt, diese muss oft willkürlich geschehen, so dass die Gesamtheit zerschnitten ist. Die Unterlisten sind in Sammel- oder "Metalisten" wie z. B. Liste der Kulturdenkmale in Dresden oder Liste der Bau- und Bodendenkmale im Landkreis Oberhavel zusammengefasst. Da die Vorlage nur für den jeweiligen Artikel die Koordinaten anzeigt, ist es nicht möglich, die Gesamtheit von kommunalrechtlichen oder geografischen Einheiten anzuzeigen.

Wen betrifft das Problem besonders?

Autoren, die Listen erstellen; Leser, die sich Einträge mit Koordinaten anzeigen lassen wollen

Lösungsvorschlag

Beim Hinterlegen der Vorlage kann der Autor angeben bis zu welcher Tiefe die verlinkten Listen oder Artikel anzuzeigen sind. Der Leser muss in dem Fall die Möglichkeit zu wählen, ob er nur die Koordinaten des von ihm betrachteten Artikels sehen will oder auch verlinkte.

Anmerkungen

Um nicht alle möglichen verlinkten Artikel angezeigt zu bekommen, sollte die Anwendung nur auf Tabellenabschnitte innerhalb des Artikel abzielen. Derzeit ist dies über die Kategorien möglich, jedoch nicht aus dem Artikel heraus.

Vorschlagende Person

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

Diskussion

Den Umweg über die Kategorie könnte ich jetzt schon anbieten: [1] (lange Ladezeit!) --тнояsтеn ⇔ 13:49, 2. Jun. 2017 (CEST)

danke. das stimmt. setzt aber voraus, dass der leser die kats kennt und nutzt. aber auch da ist die vorlage nur auf die kat beschränkt, inhalte von unterkats werden nicht angezeigt, oder. gruß -- ^Thomas 14:45, 2. Jun. 2017 (CEST)

Wenn es Unterkategorien gibt, geht das schon. Mit den Links "+1,+2,++". Beispiel: [2] (Kategorie:Berg in den Alpen). Die Unterkategorien lassen sich in der Liste links durch auf- und zuklappen ein- und ausblenden. --тнояsтеn ⇔ 14:56, 2. Jun. 2017 (CEST)

@Thgoiter: Danke. Ich hab deinen Hinweis mal bei den Anmerkungen mit aufgenommen. -- ^Thomas 17:16, 7. Jun. 2017 (CEST)

Hallo Thomas, wenn ich das richtig verstehe geht es hier um die Veränderung einer Vorlage? Das ist etwas was die Community macht und entscheidet. Du könntest diesen Wunsch z.B. in der Vorlagenwerkstatt oder auf der Diskussionsseite der Vorlage einreichen. Wenn dem so ist, würde ich deinen Wunsch morgen nach Wünsche außerhalb des Projektrahmens verschieben, wo er weiterhin einsehbar bleibt. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 18:32, 15. Jun. 2017 (CEST)

@Z thomas: Ist nun verschoben.

Unterstützung

Wiki-Banner auf dem Desktop neben dem Inhalt platzieren

Was ist das Problem?

Der Banner über dem Inhaltsbereich wirkt oft ablenkend und führt beim Laden zum Verspringen der Inhalte.

Wen betrifft das Problem besonders?

Alle Autoren

Lösungsvorschlag

Bei großen Bildschirmen wäre es sinnvoll, die Banner nicht über sondern in einer Seitenspalte hochkant rechts neben dem Inhalt dargestellt werden. Das wäre zum einen weniger invasiv, würde aber andererseits mehr Möglichkeiten für inhaltliche Gestaltung bieten.

Vorschlagende Person

Martin K. (Diskussion) 12:09, 11. Jun. 2017 (CEST)

Diskussion

@Martin Kraft: Danke für den Wunsch! Wo und wie ein Banner angezeigt wird, liegt im Ermessen der Person, die die Banner erstellt. Sprich: Grundsätzlich kann man Banner bei Central Notice jetzt schon darstellen, wie man möchte. Aber es kommt natürlich auf die Inhalte des Banners an, ob das Sinn ergibt. Auf jeden Fall ist eine Banneranzeige an anderer Stelle nichts, was wir für alle entscheiden können. Daher verschiebe ich diesen Wunsch in die Rubrik „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 19:19, 16. Jun. 2017 (CEST)

@Martin Kraft: Verschoben.

Unterstützung

Aktive Sichter können eigene Unterseiten löschen, die sie selbst angelegt haben

Was ist das Problem?

Ich benutze meine Unterseiten recht intensiv zur Vorbereitung von Artikeln, muss aber einen Admin bitten, diese zu löschen. Ich fände es wünschenswert, dass man als "Inhaber" der Unterseite dieses selbst machen könnte.

Wen betrifft das Problem besonders?

Benutzer, die intensiv Artikel auf ihren Unterseiten anlegen.

Vorschlagende Person

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

Diskussion

Das sollte aus Sicherheitsgründen auf selbst im eigenen BNR angelegte Seiten beschränkt bleiben. Nicht, dass man einen öffentlichen Artikel verschiebt und dann in seinem BNR löscht. --Sitacuisses (Diskussion) 00:56, 11. Jun. 2017 (CEST)

Genau; ich erlaube mir mal, die Überschrift entsprechend anzupassen, und hofffe, dass das auch Nicola recht ist. Gestumblindi 19:13, 11. Jun. 2017 (CEST)

So war es gemeint :) -- Nicola - Ming Klaaf 19:50, 11. Jun. 2017 (CEST)

Alternativ oder Zusätzlich könnte man auch das Verschieben aus dem eigenen Benutzerraum ohne Weiterleitung erlauben. --Gruß Michael Hoefler50 Diskussion 21:34, 11. Jun. 2017 (CEST)

• Au prima, dann muss ich ja nur meine Haupt-Benutzerseite auf Unterseite verschieben, dann kommt die doofe Disku mit, dann lösche ich die Unterseite mit Disk, und auf die entstandene WL lege ich frische Haupt-Benutzerseite nebst Disku an.
  • Auch dass eine Seite mal selbst angelegt wurde, schützt nicht: Artikelentwurf im BNR auf neu angelegter Seite, dann in den ANR, dann bearbeiten das andere; das gefällt mir aber nicht was die aus „meinem“ Artikel gemacht haben, also schiebe ich zurück in meinen BNR und lösche meinen Artikel selbst.
• Mal im Ernst: Der Vorschlag bedarf einer weltweiten gravierenden Software-Änderung zur Definition eines neuen Rechtes, dieses nur für einen einzelnen Namensraum und dort die Unterseiten, und das für „aktive Sichter“ – diese gibt es aber kaum woanders als in der deWP. Der Vorschlag liegt weit außerhalb der Realisierungsmöglichkeiten von WMDE, ist international chancenlos und bedarf außerdem eines vorherigen MB.
  • Die Missbrauchs- und Sicherheitsprobleme dieses Vorschlags sind nicht hinreichend reflektiert worden. Das ist nicht abstimmungsfähig.
  • Ein ernsthafter Bedarf für eine derartige Rechtegewährung vorbei an der etablierten Prozedur besteht ohnehin nicht.
• Tipp: Mach eine Unterseite /Baustelle oder eine Serie /Baustelle1, /Baustelle2, /Baustelle3 auf, und kopiere die saubere Endversion auf eine frische Seite im ANR – dann kommt dort die VG mit den Experimenten und anfänglichen Irrtümern nicht mit; und auf die Baustellen-Unterseiten schreibst du wieder die nächsten Texte. So machen das viele, die intensiv Artikel auf ihren Unterseiten anlegen. Es entsteht keinerlei Löschbedarf.
• Oder du entwickelst wie ich von der Festplatte aus, mit Schnarks oder meinem Tool zur Seitenvorschau der Festplatten-Textdatei, und hinterlässt während der Entwicklung überhaupt keine Spuren im öffentlichen Wiki.

VG --PerfektesChaos 10:49, 12. Jun. 2017 (CEST)

@Nicola, kennst du den Lukebot? →Benutzer:Luke081515Bot/Warteschlange dort kann man Entwürfe aus dem BNR in den ANR verschieben lassen, ohne, dass eine Weiterleitung entsteht, die gelöscht werden müsste.

Alternativ zu deinem Wunsch könnte ich mir vorstellen, dass auch normale Benutzer diese Funktion erteilt bekämen, wenn man ohne WL zumindest aus dem eigenen BNR verscheiben könnte, wäre dein Problem doch auch gelöst, oder?

@PC, wäre das technisch machbar? Also anstelle von „Sichter können eigene Seiten löschen“ die Funktion, „Sichter können eigene Unterseiten ohne Weiterleitung verschieben“.

Ich würde das auch als nützlich ansehen, da es viele SLA-Abarbeitungen von Verschieberesten ersparen und somit die Admins etwas entlasten würde. --Liebe Grüße, Lómelinde Diskussion 13:27, 12. Jun. 2017 (CEST)

• Also, alles, was Normalbenutzern erweiterte Rechte zusprechen soll, bedarf erstmal eines MB.
• Ausführung einer Softwarefunktion an bestimmte Benutzer zu koppeln bedarf weiterhin einer weltweit für alle mit MediaWiki betriebenen Wikis wirksamen Software-Änderung. Davon muss die Welt überzeugt sein.
  • Benutzern kann kein einzelnes Recht zugeordnet werden, sondern Benutzer müssen in eine neue Benutzergruppe aufgenommen werden, die einen bestimmten Rechteumfang hätte.
  • Weder eine Definition des Rechtes noch eine weltweite Definition der neuen Benutzergruppe gibt es bislang. Dies ist bereits heute äußerst umfangreich und damit unübersichtlich, und man ist international sehr widerstrebend, was die Einrichtung neuer Strukturen angeht, für die es keinen nachgewiesenen weltweiten Bedarf gibt.
  • Die Vorschläge sind relativ kompliziert, was wann mit welcher Seite geschehen darf, wenn in ihrer Versionsgeschichte dies und das war und nicht war. Sowas ist überhaupt nicht beliebt, weil sicherheitsmäßig schwer auf Lückenlosigkeit zu prüfen; auch Importe sind zu bedenken.
• Ein wirkicher Bedarf für den Vorschlag ist nicht zu sehen.
  • Es gibt mindestens drei organisatorische Alternativen, die ohne Löschungen oder weiterleitungslose Verschiebungen auskämen.
  • Wenn jemand nach Entlastung der Admins zu rufen hätte, dann wären das Admins, die mit der Abarbeitung der SLA nicht hinterherkämen. Danach sieht es nicht aus.
• Weiterleitungslose Verschiebungen durch Normalbenutzer eröffnen genau die gleichen Manipulationsmöglichkeiten wie Löschungen, da die Kette unterbrochen wird und nicht mehr nachvollziehbar ist, weil der Verschiebungseintrag zu Beginn der Versionsgeschichte fehlt.

VG --PerfektesChaos 19:13, 12. Jun. 2017 (CEST)

Ja stimmt es war nur so eine spontane Eingebung. Wirklich schlimm, oder sagen wir zeitaufwändig, ist so ein SLA-Edit nun auch nicht. --Liebe Grüße, Lómelinde Diskussion 19:54, 12. Jun. 2017 (CEST)

@Nicola: Vielen Dank für den Wunsch! Leider wäre, wie PerfektesChaos ja schon ausführlich beschrieben hat, ein solcher Wunsch sehr aufwändig umzusetzen und bedürfte auf jeden Fall eines Meinungsbildes. Daher verschiebe ich den Wunsch nach „Wünsche außerhalb des Projektrahmens“. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 21:04, 16. Jun. 2017 (CEST)

@Nicola: Ich habe diesen Wunsch verschoben, s.o.

Unterstützung

Erstellen von Listen mit Fotowünschen

Was ist das Problem?

Vor allem im Bereich der Denkmallisten (Bau-, Kultur- und Naturdenkmale) gibt es zahlreiche Liste mit unterschiedlichen Bebilderungsstand. Um die Einträge mit fehlender Bebilderung zu ermitteln, muss jede Liste einzeln geöffnet und die fehlenden Einträge ermittelt werden.

Wen betrifft das Problem besonders?

Regional- und Themenportale

Lösungsvorschlag

Erstellen von Listen aus einer bestimmten Kategorie in der die Einträge mit fehlenden Fotos zusammengestellt werden.

Vorschlagende Person

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

Diskussion

@Z thomas: Hallo und danke für diesen Wunsch! Wir haben ihn im Team besprochen und leider haben wir softwareseitig zzt. keine gute Möglichkeit, das Problem zu lösen. Machbar wäre es über einen Bot, aber das wäre eine Communityaufgabe, weshalb ich auf Wikipedia:Bots/Anfragen verweise und den Wunsch nach „Wünsche außerhalb des Projektrahmens“ verschiebe. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 21:30, 16. Jun. 2017 (CEST)

@Z thomas: Ping: Ich habe diesen Wunsch verschoben, s.o.

Unterstützung

Helferlein (commons) pflegen

Was ist das Problem?

Auf den Helferlein (commons) sind einige Tools eingebunden, die nicht funktionieren oder veraltet sind. Die Pflege und Wartung sollte verbessert werden. Auch die Kommunikation der neuen Tools, die als „Helferlein“ eingebunden sind ist nahezu Null. Als nicht-funktionierender Link (sehr vermisst) kann ich beispielsweise „Kategoriehelferlein/CatScan V2.0β“ nennen -> funktioniert nicht mit dieser Einbindung. Zu diesen „Helferlein“ existiert auch keine Diskussionsseite und kein verantwortlicher Bearbeiter. Ist so etwas wie eine BlackBox (leider).

Wen betrifft das Problem besonders?

Alle, eigentlich nicht nur auf commons.

Lösungsvorschlag

Pflege, pflege... und nochmals Pflege.

Vorschlagende Person

Atamari (Diskussion) 00:45, 6. Jun. 2017 (CEST)

Diskussion

Warum fragst du nicht direkt auf Commons nach? Am besten auch konkret, welche Helferlein bei dir nicht funktionieren. — Speravir – 19:24, 7. Jun. 2017 (CEST)

Warum liest du nicht den oben stehenden Text. Ein Beispiel habe ich genannt, ein weiteres Beispiel ist der Gadget-ImageAnnotator der seit Wochen nicht fehlerfrei funktioniert. Nur leider meldet sich auf der Disk keiner. --Atamari (Diskussion) 16:08, 11. Jun. 2017 (CEST)

Hallo Atamari, die Einbindung von Helferlein in die Liste der persönlichen Einstellungen wäre Community-Sache, & das anpassen können nur Admins. Zur Pflege von Helferlein: Wartung aller Commons-Helferlein hätte als Wunsch kein richtiges Ende & würde in die Verantwortung der eigentlichen Erbauer der Helferlein reingehen. Daher würde ich vorschlagen, deinen Wunsch auf eines der beiden genannten Beispiele einzugrenzen und darin die 3 für dich kritischen Bugs zu beschreiben. Also: „Fehler im ImageAnnotator beheben“ als Titel, die drei schmerzvollsten Bugs als Problembeschreibung. Zu bedenken wäre, dass so ein Wunsch immer nur in Zusammenarbeit mit dem eigentlichen Entwickler des Helferleins umgesetzt werden könnte. Was meinst du? Liebe Grüße, --Birgit Müller (WMDE) (Diskussion) 10:57, 14. Jun. 2017 (CEST)

@Birgit Müller (WMDE): Hilfreich ist das alles nicht, vor allem hilft das den Benutzern wenig, für die gerade das einfache System der Helferlein (=> App-Store) gemacht worden ist. Gerade mit der Behandlung von Bugs hackt es gewaltig, meist weis man nicht wo man am Besten die Meldung hinschreibt. Wenn man schon eine gute Stelle zum Melden gefunden hatte – Wird nicht reagiert. Das ist mein größte Frust in den letzten Monaten. Beispiel ImageAnnotator: Ich Benutzer Diskussion:Hoo man#Bugmeldung (zu dem ImageAnnotator) hatte Hoo man gebeten eine Fehlermeldung im Phabricator zu formulieren. Dann erfahre ich, dass Phabricator falsch ist. Frust. Also setzte ich eine Meldung auf der Gadgetseite ab, keiner meldet sich, keine Rückfrage. Frust. Dass ganze Fehlermanagment ist einfach Mist. Sehr schlecht für die sich noch weniger auskennen. Auch Magnus Manske meldet sich nach meinem Hilferuf nicht. Frust. --Atamari (Diskussion) 11:13, 14. Jun. 2017 (CEST)

@Atamari: ja, ich weiß :( - nur, das Technische Wünsche Team kann nicht das Problem lösen, wenn Programmierer von Gadgets, Scripts ... nicht auf Bugmeldungen reagieren. Die Projekte machen Leute in ihrer Freizeit, mit mal mehr und mal weniger Zeit dafür. Ein wichtiger Ansatz der Wunschliste ist ja, Funktionen, die schon als Gadget bekannt & beliebt sind, in die Software zu integrieren, um genau dieses Problem etwas kleiner zu machen. Sollte es ein Wunsch wie der "App Store" in die Topwünsche schaffen (& wenn dann bei der genaueren Analyse keine "nicht machbar" Probleme auftauchen), gäbe es darüber hinaus dann die Möglichkeit, Nutzern dadurch klarer zu vermitteln, welche Helferlein gewartet sind und wie Kontakt aufgenommen werden kann, indem man dort nur gewartete Gadgets "einstellt", bei denen die Betreuer auch ansprechbar sind. Bei allen anderen Scripts wäre es dann klarer, dass diese eher "auf eigenes Risiko" zu nutzen sind. Bei dem allgemeinen "Helferlein pflegen"-Wunsch hier würde es nicht weiterhelfen, darüber abzustimmen, weil das Entwicklerteam da leider nix machen kann ... . Würde ihn daher in die Rubrik Wünsche außerhalb des Projektrahmens verschieben. LG, --Birgit Müller (WMDE) (Diskussion) 19:46, 14. Jun. 2017 (CEST)

@Atamari: Wunsch ist jetzt hierhin verschoben. LG, --Birgit Müller (WMDE) (Diskussion) 22:09, 16. Jun. 2017 (CEST)

Unterstützung

Es sollte ein Programm geben, mit dem ich auf der Spezialseite „Benutzerbeiträge“ gezielt nach von einem Nutzer verfasstem Text suchen kann (ähnlich wie bei WikiBlame; das funktioniert aber bei Spezialseiten wie „Benutzerbeiträge“ nicht).

Was ist das Problem?

Nehmen wir an, ich suche gezielt nach einer bestimmten Äußerung eines Nutzers. Ich weiß, wer diese Äußerung getätigt hat, aber ich weiß nicht mehr, wann, wo und in welchem Zusammenhang er dies getan hat. Das ist sicherlich schon vielen hier passiert. Wie kommt man nun an das Zitat heran?

Wen betrifft das Problem besonders?

Jeden aktiven Nutzer

Lösungsvorschlag

Dafür wäre doch ein „Beitragsscanner“ – wie das bereits für normale Seiten bestehende WikiBlame – großartig! (idealiter global wirksam)

Vorschlagende Person

Erdic (Diskussion) 17:34, 10. Jun. 2017 (CEST)

Diskussion

Das geht mit der Suchfunktion, dafür brauch man aber etwas Erfahrung mit regulären Ausdrücken. Beispiel für deinen Beitrag: klick. Beste Grüße --FNDE 20:21, 11. Jun. 2017 (CEST)

@Erdic: Danke für diesen Wunsch! Wir haben ihn im Team besprochen, leider mit dem Ergebnis, dass es nicht möglich ist, diesen Wunsch als integrierte Softwarelösung umzusetzen. Daher verschiebe ich den Wunsch in die Rubrik „Wünsche außerhalb des Projektrahmens“. Du kannst Spezial:Beiträge aber mit einem Benutzerskript durchsuchen, das du hier findest: https://de.wikipedia.org/wiki/Benutzer:TMg/filterContributions. Man kann damit allerdings nur nach den Zusammenfassungszeilen suchen, nicht nach den inhaltlichen Äußerungen. Oder du nutzt die Suchfunktion, wie von FNDE kommentiert. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 22:24, 16. Jun. 2017 (CEST)

@Erdic: Hallo, ich habe deinen Wunsch hierhier verschoben, s. meinen Kommentar oben. -- Johanna Strodt (WMDE) (Diskussion) 22:24, 16. Jun. 2017 (CEST)

Unterstützung

Es sollte eine Möglichkeit geben, direkt anzuzeigen, von wem ein Textabschnitt wann in einen Artikel eingefügt worden ist, ohne die gesamte History einzeln durchackern zu müssen

Was ist das Problem?

Es ist manchmal sinnvoll, sehen zu können, wer einen bestimmten Text(abschnitt) geschrieben hat.

Wen betrifft das Problem besonders?

Jene, die Querverbindungen zwischen Texterstellung und Schreiberlingen nachgehen

Lösungsvorschlag

Man sollte einen (kurzen) Text "selektieren" (oder in ein Textfeld eingeben) können, und dann sollte angezeigt werden: "der Textabschnitt ... wurde am ... von ... eingefügt".

Anmerkungen

Könnte als unnötig erachtet werden; bisher muß man die gesamte History durchgehen, bis man den Text eher per Zufall gefunden hat

Vorschlagende Person

ProloSozz (Diskussion) 02:30, 19. Jun. 2017 (CEST)

Diskussion

NB: inspiriert duch Vorschlag von Erdic gleich obendran.

Ist auch hilfreich für Stammautoren: "ich hatte doch mal 'xy' eingefügt - wann war das?" und "wann wurde das von wem gelöscht?". Sozusagen eine qualifizierte Volltextsuche in den Änderungen. Gruss, --Markus (Diskussion) 08:40, 21. Jun. 2017 (CEST)

Unterstützung

Assistent zum Auslesen von Daten aus Online-Datenbanken

Was ist das Problem?

Für viele Artikel sind Infoboxen oder andere Vorlagen erforderlich, welche größenteils aus Datenbankeinträgen bestehen. Diese jedes Mal manuell einzugeben ist sehr monoton, zeitintensiv und fehleranfällig. In anderen Sprachversionen gibt es bereits Bots die eigenständig auf Basis dieser Daten Artikel erstellen. Bekanntestes Beispiel dürfte wohl der lsjbot sein. Dies soll allerdings nicht geschehen; Artikel sollen auch weiterhin von Menschen geschrieben werden. Allerdings wäre so ein Assistent ein guter Helfer, der einem solche Arbeiten erspart bzw. zu mindestens vereinfacht.

Wen betrifft das Problem besonders?

Hauptsächlich betroffen sind tendenziell kürze Artikel (Stubs) aus den Themen Astronomie (z.B. Asteroiden, Kometen), Biologie (z.B. sämtliche Lebenwesen), Geografie/Geologie (z.B. sämtliche Ortschaften) und Chemie. Natürlich gehen auch Medien, Bauwerke, Verkehrsobjekte, Sportler, technische Geräte, Organisationen usw. Problem hierbei ist jedoch das sich nicht alle Datenbanken gleich gut für das Auslesen und Einfügen eignen und daher einige Themen mehr in Frage als andere kommen. Es ist daher ratsam sowas erstmal für ein paar bestimmte Themen zu testen.

Lösungsvorschlag

Die Bedienung sollte relativ einfach zu handhaben sein. Grundsätzlich sollte das nach folgenden Muster ablaufen:

1. Es gibt eine Seite wo der Benutzer den Link oder die ID der Datenbank einträgt. Alternativ ginge auch eine Suche nach dem Namen des Objekts.
2. Die Datenbankdaten werden abgerufen
3. Die für die Vorlage relevanten Werte werden in Variablen gespeichert
4. Die Variablen werden in die dementsprechenden Felder der Vorlage eingesetzt.
5. Übersetzung und Fehlerkorrektur durch standardisierte Abfragen (Komma/Punktsetzung, Formatierung, Rundung usw. der Werte) wird falls erforderlich durchgeführt
6. Der Code kann kopiert werden und es kann manuell weiter bearbeitet werden
   Anmerkungen

Die Benutzung geschieht auf eigene Gefahr. Die Verantwortung und Kontrolle muss der Ersteller/Bearbeiter des Artikels trotzdem übernehmen. Auch müsste bei einer Vorlage bzw. Tabelle nicht Schluss sein. Man könnte z.B. ein bis zwei standardisierte Einleitungssätze sowie eine vorgefertigte Weblinkliste für bestimmte Themen auf Basis von Datenbank/Suchwerten erstellen.

Vorschlagende Person

Noobius2 (Diskussion) 00:46, 30. Mai 2017 (CEST)

Diskussion

Für viele der aufgezählten Themen klingt Wikidata nach dem Weg zur Lösung. Astroiten wie https://www.wikidata.org/wiki/Q154334 haben gute Daten in Wikidata hinterlegt. ChristianKl (Diskussion) 18:17, 2. Jun. 2017 (CEST)

Eine Synchronisation mit Wikidata ist hierbei wohl der richtige Ansatz. So könnte man erstmal die Daten in Wikidata aufnehmen und dann automatisiert in die Tabellen exportieren. Problematisch wirds dann nur wenn die Einträge nicht deckungsgleich sind. Dann vielleicht doch lieber beides getrennt generieren.--Noobius2 (Diskussion)

Hallo Noobius2, vielen Dank für den Wunsch! Eine generische Lösung für alle Datenbanken ist leider nicht möglich, dazu gibt es viel zu viele unterschiedliche Datenbanken, die verschiedene Datenmodelle benutzen. Zur Idee, die Daten in Wikidata zu importieren & über Wikidata in die Infoboxen bringen: Das wäre ein guter Weg, aber auch hier ist wichtig: "Magisch" bzw. generisch ist das nicht möglich, da Datenbanken zu unterschiedlich sind. Falls du eine Anfrage für Daten aus einer speziellen Datenbank im Themenfeld x hast, könnten wir anbieten, den Kontakt zur Wikidata Community herzustellen, die die Hoheit über Datenimporte & die damit verbundenen Fragen hat & wo sich ggf jemand finden lässt, der für eine spezielle Datenimport-Anfrage einen Bot baut. Auf Wikipedia-Seite müsste dann entsprechend die Infobox-Templates umgebaut werden. Das wäre Sache der Wikipedia-Community, die entscheidet, welche Daten wie in der Infobox dargestellt werden sollen. Ich würde daher diesen Wunsch in den kommenden Tagen in die Rubrik "Wünsche außerhalb des Projektrahmens" verschieben, wo wir Wünsche sammeln wollen, die z.B. Probleme betreffen, die nicht in erster Linie technisch zu lösen sind oder die technisch zu komplex oder nicht machbar sind. Wenn eine spezielle Datenbank-Anfrage & Interesse an der Vermittlung zur Wikidata-Community besteht, gerne Bescheid sagen. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 14:05, 10. Jun. 2017 (CEST)

Eine generische Lösung für alle Datenbanken ist auch nicht möglich, deswegen schlug ich ein schrittweises hinzufügen und erweitern vor - je nach Nachfrage, Erfolg und Umsetzbarkeit. Konkrete Datenbaken die mir gerade einfallen sind z.B. das Geographic Names Information System (und weitere Geosysteme), Encyclopedia of Life, JPL Small-Body Database, weltfussball.de/fussballdaten.de und vergleichbare Sportdatenbanken, Allmusic, IMDb, fernsehserien.de, handelsregister und das Archiv der Deutschen Nationalbibliothek. Die ersten 3 wären schon mal ein guter Anfang und Einstieg finde ich. Die Infobox muss meiner Ansicht nach nicht umgebaut werden. Der relevante Inhalt mit den Daten die in der Infobox stehen wird ja nur eingefügt und als Kopiervorlage zur Verfügung gestellt ohne das sich dabei der eigentliche Code der Infobox verändert. Also für machbar halte ich es schon - aber eben nur wenn man immer phasenweise die Module hinzufügt und nicht direkt versucht alle Datenbanken zu erfassen. Da sich aber die Vorhaben hier mehr an das Wikipediasystem und konkrete Änderungen in diesem richten, finde ich eine Verschiebung auch sinnvoll - vielleicht auch in andere Projekte (Wikidata,da der Import ja wichtig ist).--Noobius2 (Diskussion)

Hallo Noobius2, noch etwas mehr Hintergrund (weil ich gerade nicht sicher bin, ob wir uns richtig verstanden haben): Datenimporte aus Datenbanken nach Wikidata werden heute schon gemacht und es geht auch, diese Daten in die Infoboxen in der Wikipedia einzubinden. Der Datenimport nach Wikidata erfolgt jeweils mit spezifischen Programmen/Bots/Tools für spezifische Datenbanken und Daten, die von der Wikidata-Community gebaut werden. Auf Wikipedia-Seite müssen dann die jeweiligen Infobox-Vorlagen schon erweitert werden, so dass sie Wikidata überhaupt nutzen können. Ein Beispiel für eine Vorlage, die für die Nutzung von Wikidata-Daten angepasst wurde: Vorlage:Infobox_Software. Die Hoheit sowohl für den Datenimport nach Wikidata als auch für die Dateneinbindung via Infobox haben auf beiden Seiten die Communities. D.h., das Technische Wünsche Team kann da "technisch" nicht weiterhelfen, es wäre also, je nach Sichtweise, ein Wunsch, den wir in die Rubrik: "Wünsche, die bereits erfüllt oder in Arbeit sind" (weil Datenimporte verschiedener Datenbanken über Wikidata in Wikipedia schon machbar sind) oder "Wünsche außerhalb des Projektrahmens" verschieben würden (weil Datenimporte Community-Sache sind), die nicht Teil der Abstimmung sind. Wie bekommt man dann die Daten? Auf Wikidata gibt es diese Seite hier: d:Wikidata:Partnerships_and_data_imports. Du könntest dich dort mit einer konkreten Anfrage an die Community wenden: Für Themenfeld x in der Wikipedia Daten aus Datenbank Y. Empfehlung wäre, erst mal eine Datenbankanfrage zu machen, weil eben für jede Datenbank ein Programm geschrieben werden muss, dass zu dem Datenmodell dieser Datenbank passt. Wenn die Wikidata-Community diese Anfrage angehen will, würden die Daten aus Datenbank X in Wikidata importiert werden. Dann müsste man (zumindest) mit den Leuten diskutieren, die in der Wikipedia in dem Themenfeld aktiv sind, wo die Daten in die Infoboxen sollen - vermutlich bieten sich dazu Redaktionen an. Wenn das positives Feedback bekommt, müsste man in der Wikipedia-Community jemanden finden, der sich mit Vorlagenprogrammieren auskennt, und bitten, die Vorlage entsprechend zu erweitern. Zusätzlich könntest du in Wikidata schauen, ob Daten von Datenbanken, die du nützlich fändest, schon da sind, dann spart man sich die Import-Anfrage. Den Kontakt zur Wikidata Community können wir gerne herstellen, auch ohne dass der Wunsch in die Topliste gewählt wird. Alles was technisch zu machen ist (Datenimport und Vorlagenerweiterung) und die damit verbundenen Entscheidungen, welche Daten wohin können, liegen ohnehin in der Hand der Communities. Von daher würde ich den Wunsch vor dem Voting rausnehmen und entsprechend in die Rubrik "Wünsche außerhalb des Projektrahmens" verschieben. Liebe Grüße, --Birgit Müller (WMDE) (Diskussion) 21:23, 16. Jun. 2017 (CEST)

Gut ich dachte an eine externe Lösung für eine Kopiervorlage ohne dabei die Wikipedia-internen Vorlagen anzurühren (eine modifizierte Kopie sozusagen). Danke für den Tipp das werde ich mal nachschauen:). Ich erwarte auch nicht dass das ohne Absprache mit der Community geschieht, eine vorheriges Meinungsbild o.ä. setzte ich bei so einem Vorhaben eigentlich voraus. Vielen Dank nochmal für die ausführliche Erklärung und Hilfestellung. Gut dann kann das jetzt verschoben werden und ich werde da nochmal nachschauen und mich gegebenenfalls nochmal melden. Vielen Dank nochmal. --Noobius2 (Diskussion) 22:15, 16. Jun. 2017 (CEST)

@Noobius2: danke dir! Wunsch ist jetzt hierher verschoben. LG & ein schönes WE, --Birgit Müller (WMDE) (Diskussion) 22:28, 16. Jun. 2017 (CEST)

Unterstützung

Reflist und Reflist-talk

Was ist das Problem?

Einfügen von Referenzen verkompliziert und schlecht gestaltet. Insbesondere auf Diskussionsseiten (Reflist-talk), aber auch im Artikel (Reflist). Diese Funktionen gibt es im englischen Wikipedia, aber nicht im Deutschen!

Wen betrifft das Problem besonders?

Diejenigen die auf einer Diskussionsseite Artikel verlinken.

Lösungsvorschlag

Einführung von Reflist und Reflist-talk.

Vorschlagende Person

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

Diskussion

Verstehe ich das richtig, dass Du willst, dass die Vorlagen en:Template:Reflist und en:Template:Reflist-talk auch in der De-Wikipedia verfügbar sind? Dann bist du hier falsch damit. Das wäre eine Community-Entscheidung und gehört zunächst nach Wikipedia:WikiProjekt Vorlagen/Werkstatt. Lies dir aber vorher die sachkundigen Antworten vom Perfekten Chaos in Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2014/2#Englische Vorlagen {{efn|}} und {{math|}} durch (ist zwar länger, aber reflist kommt vor).
Übrigens kann man eine mehrspaltige Darstellung der Referenzen seit einiger Zeit völlig ohne Vorlage erreichen, siehe Hilfe:Einzelnachweise#Mehrspaltige Darstellung aller Einzelnachweise. — Speravir – 22:05, 1. Jun. 2017 (CEST)

Hallo Rævhuld, wie Speravir schon gesagt hat, sind Vorlagen Hoheitsgebiet der Community und fallen somit nicht in unseren Aufgabenbereich. Ich würde dann morgen deinen Wunsch nach Wünsche außerhalb des Projektrahmens verschieben, wo man ihn dann noch weiter einsehen kann. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 18:56, 15. Jun. 2017 (CEST)

@Rævhuld: Wie angekündigt ist der Wunsch jetzt hierhin verschoben, s. Charlies Kommentar. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 22:31, 16. Jun. 2017 (CEST)

Unterstützung

Diskussionsseiten einrichten

Was ist das Problem?

Ziemlich kompliziert die wichtigsten Funktionen zu finden / hereinzukopieren. Wenn man eine Diskussionsseite einrichtet, wie z.B. Talk:2016_Orlando_nightclub_shooting, dann muss es a) von einem Experten erstellt werden und b) auch dann nimmt es viel Zeit in Anspruch.

Wen betrifft das Problem besonders?

Diskussionsseiten

Lösungsvorschlag

Eine automatische Einrichtung von einer Diskussionsseite. Möglicherweise auch durch Ausfüllung eines Formulars, die dann ein Mensch ausfüllen kann. Inhalten sollten vor allem folgendes sein: Automatisch archivieren, die verschiedenen Archive und Einbindung in die verschiedene Wikiprojekte. Bei lebenden Personen dann auch diese Vorlage automatisch einbinden.

Vorschlagende Person

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

Diskussion

Darf man bei deinem Lösunsvorschlag noch Vorlage:Artikel über lebende Person hinzufügen? --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 11:14, 30. Mai 2017 (CEST)

Vielen Dank. Habe es in meinem Vorschlag eingebunden.--Rævhuld (Diskussion) 16:32, 30. Mai 2017 (CEST)

Einbindung von Wikiprojekt-Bausteinen sind schon jetzt möglich, aber von der Community nicht gewünscht, also nichts technisches, sondern nur was für ein MB. Archivierung braucht man bei der ersten Einrichtung einer Diskussionsseite ohnehin nicht, erst wenn die so stark genutzt wird, dass sich eine Archivierung auch lohnt. Die erstmalige Einrichtung einer normalen Artikeldiskussionsseite ist eigentlich denkbar einfach, man muss einfach nur seine Anmerkung/Frage etc. dorthin schreiben und speichern. --Orci Disk 16:37, 30. Mai 2017 (CEST)

@Rævhuld: Hallo und danke für diesen Wunsch! Es wäre toll, wenn du noch etwas detaillierter die Situation beschreiben könntest, in der du dem Problem begegnest. Beispielsweise: Wann legst du Diskussionsseiten an und mit welchem Ziel? Wie gehst du dabei vor und was ist dabei zu kompliziert? Das hilft allen, die später abstimmen, den Wunsch besser zu verstehen, und erhöht somit deine Chancen darauf, gewählt zu werden. :) -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:12, 10. Jun. 2017 (CEST)

Hallo Rævhuld, wie Orci schon angemerkt hat, ist dein Wunsch eher etwas für ein Meinungsbild, da die Entscheidung über eine solche Funktion bei der Community liegt. Wenn du weiter keine Einwände hast, würde ich morgen (Freitag) deinen Wunsch nach Wünsche außerhalb des Projektrahmens verschieben, wo du ihn danach noch weiter einsehen kannst. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 19:03, 15. Jun. 2017 (CEST)

@Rævhuld: Der Wunsch ist jetzt nach „Wünsche außerhalb des Projektrahmens“ verschoben, wie von Charlie oben angekündigt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 22:35, 16. Jun. 2017 (CEST)

Unterstützung

Fehlergenerierende doppelte URL-Kodierung in der Vorlage:GeoTemplate vermeiden.

Was ist das Problem?

Wenn ich in einer GeoHack-Seite, deren Seitentitel Nicht-ASCII-Zeichen – zum Beispiel einen Umlaut – enthält die Sprache „Deutsch“ (URL-Parameter language=de) angewählt habe und dann im Abschnitt „Globale Anwendungen“ unter Bullet-Point „OpenStreetMap“ auf den Link „Weitere Openstreetmap-Karten“ klicke, wird in der GeoHack-Seite, auf die ich dann gelange, das Nicht-ASCII-Zeichen im Seitentitel URL-kodiert ausgegeben.

Beispiel:
Klicke in der Seite Düsseldorf auf die als Link ausgestalteten Geo-Koordinaten in der oberen rechten Ecke. In der Geohack-Seite auf die Du dann gelangst, erscheint der Seitentitel „Düsseldorf“. Klicke nun in dieser Seite auf den Link „Weitere Openstreetmap-Karten“. In der Geohack-Seite auf die Du dann gelangst, erscheint der Seitentitel „D%C3%BCsseldorf“, es sollte aber Düsseldorf dort stehen.

Die Ursache des Probelms liegt in der Vorlage:GeoTemplate, die der GeoHack verwendet, wenn er auf die Sprache „Deutsch“ eingestellt ist. In der englischsprachigen Version dieser Vorlage (siehe: en:Template:GeoTemplate) besteht dieses Problem nicht. Klickt man in der deutschspachigen Geohack-Seite „Düsseldorf“ auf den Sprachen-Link „English“ und in der dann erscheinenden GeoHack-Seite im Abschnitt „Global services“ bei dem Tabelleneintrag „OpenStreetMap“ auf den Link „more maps“, dann bleibt der Seitetitel jeweils „Düsseldorf“, sogar dann, wenn man anschließend auf den Sprachen-Link „Deutsch“ klickt.

Die deutschsprachige Vorlage:GeoTemplate bedient sich bei der Generierung des URL für den Link „Weitere Openstreetmap-Karten“ der Parserfunktion [[Vorlage:Fullurl|fullurl]], deren Funktionsweise aber völlig unzureichend dokumentiert ist, siehe die [[Vorlage Diskussion:Fullurl|Diskussionsseite]]. Daher ist der Fehler für Laien nicht behebbar.

Wen betrifft das Problem besonders?

Alle Nutzer des GeoHack in der deutschen Sprachversion, die die „weiteren Openstreetmap-Karten“ nutzen möchten.

Lösungsvorschlag

Den Quellcode der Vorlage:GeoTemplate so ändern, dass der URL des durch sie erzeugten Links nicht doppelt URL-kodiert ist.

Anmerkungen

Zur Problembeschreibung siehe auch [[Vorlage Diskussion:Fullurl]], Abschnitte „[[Vorlage Diskussion:Fullurl#Doppelte URL-Kodierung in fullurl bei Einbindungen innerhalb der fullurl-Parserfunktion|Doppelte URL-Kodierung in fullurl bei Einbindungen innerhalb der fullurl-Parserfunktion]]“ und „[[Vorlage Diskussion:Fullurl#fullurl versus fullurle|fullurl versus fullurle]]“

Vorschlagende Person

X:: black ::X (Diskussion) 15:16, 11. Jun. 2017 (CEST)

Diskussion

Der hier beschriebene Teil des eigentlichen Problems (nicht die fullurl-Dokumentation) ist behoben, weiteres dazu unter Vorlage Diskussion:GeoTemplate#Fehlergenerierende, doppelte URL-Kodierung durch die Parserfunktion fullurl – vielen Dank an alle Beteiligten, insbesodere тнояsтеn.

Hallo X:: black ::X, ist der Wunsch jetzt für dich behoben? Es scheint mir auch, als würde es sich hier um eine Vorlagenbearbeitung handeln, die in der Hoheit der Community liegt. Da kann dir die Vorlagenwerkstatt wahrscheinlich am besten helfen. Wenn du keine Einwände hast, würde ich Freitag deinen Wunsch nach Wünsche außerhalb des Projektrahmens verschieben, wo du ihn weiter einsehen kannst. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 20:06, 15. Jun. 2017 (CEST)

Hallo Charlie Kritschmar (WMDE), ja, das hier geschilderte Problem ist behoben (alles weitere auf Vorlage Diskussion:GeoTemplate). Das Problem mit der Dokumentation der Parserfunktionen fullurl: habe ich in Wikipedia:Verbesserungsvorschläge#Dokumentation der Parserfunktionen fullurl und fullurle eigenständig thematisiert (war hier Nebenwunsch). In sofern keine Einwände gegen eine Verschiebung. Viele Grüße --X:: black ::X (Diskussion) 22:46, 15. Jun. 2017 (CEST)

Unterstützung

Einrichtung von Benutzerseiten

Was ist das Problem?

Es ist ziemlich schwierig eine vernünftige Diskussionsseite einzurichten! Wirklich schwierig! Und das Layout ist auch nicht gut.

Wen betrifft das Problem besonders?

Frischlinge.

Lösungsvorschlag

Beim erstellen erscheint ein formular, das man dann ausfüllen kann. Wichtige Elemente:

• Kontakt (Diskussion, E-Mail)
• Beiträge
• Erstellte Artikel
• Projekte
• Grundinformationen für die Nutzer*innen! Alles andre ist ja wie man mit dem Nutzer in Kontakt tritt, aber es wäre auch schön, wenn man ganz einfach auf seiner Benutzerseite die wichtigsten Seiten angezeigt bekommen:
• Relevanzkriterien
• Wo kann ich Hilfe bekommen (generelle Fragen, Mobbing, Sokkenpuppen)
  Vorschlagende Person

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

Diskussion

Hallo Rævhuld, danke für den Vorschlag. Was wären wichtige Elemente, die eine vernünftige Diskussionsseite deiner Meinung nach enthalten sollte? Könntest du das oben noch ergänzen? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 12:01, 30. Mai 2017 (CEST)

@Johanna Strodt (WMDE): Ich finde die Seite von Benutzerin:Fiona B. hat eine schöne Struktur.--Rævhuld (Diskussion) 16:19, 30. Mai 2017 (CEST)

Um was soll es denn hier gehen? Um Benutzerseiten, um Benutzerdiskussionsseiten oder allgemein um Diskussionsseiten? Da gehen gerade die Begriffe durcheinander. Was auf keinen Fall sein sollte, ist eine besondere Aufforderung an Neulinge, Informationen über sich anzugeben, die bekommt man ansonsten kaum noch weg, auch wenn der Benutzer sich später nach WP:ANON entscheiden sollte, das doch nicht zu wollen. --Orci Disk 16:26, 30. Mai 2017 (CEST)

Hallo @Rævhuld, auf Meta gibt es zum Beispiel die Vorlage User info, die üblicherweise von Wikimedia-Mitarbeitern genutzt wird. Vergleichbares könnte man auch in der deutschsprachigen Wikipedia basteln: Eine Vorlage, mit der man ganz einfach seine Benutzerseite erstellt, indem man in ein „Formular“, also zum Beispiel …

{{Vorlage:Benutzerseite
|layout=1
|kontakt=…
|beiträge=…
|…=…
|hilfe=1
|Unterstützung=
# {{Pro}} [[User:Rævhuld|Rævhuld]] (Einreichende Person)
#
<!--Bitte hier abstimmen -->
}}

… einträgt, was man über sich sagen möchte. (Mit hilfe=1 kann dazu ein Block mit einer Hilfe-Übersicht gepackt werden.) Man könnte auch mehrere Layouts (1, 2, 3, …) basteln, sodass sich ein Nutzer das für ihn passende aussuchen kann. Die Idee ist jedenfalls realisierbar, ich hätte Lust, daran mitzwirken. (Es geht doch um die Benutzerseite, oder?) —Rübenkopf 09:08, 31. Mai 2017 (CEST)

Das wäre dann aber Vorlagen-Bastelei und nichts, was technisch an der Software geändert werden müsste. --Orci Disk 11:55, 31. Mai 2017 (CEST)

Vielen Dank! Genau an so etwas habe ich gedacht!--Rævhuld (Diskussion) 13:44, 31. Mai 2017 (CEST)

Nun heißt es aber hier "technische Wünsche". Und da Vorlagen sind für mich ziemlich technisch. Ich kann nicht programmieren. Ich dachte dabei ging es unter anderem auch? Für die Skribenten Möglichkeiten eröffnen?--Rævhuld (Diskussion) 13:44, 31. Mai 2017 (CEST)

Nein, hier geht es um Probleme, die Änderungen an der MediaWiki-Software bedürfen. Vorlagen können aber mit der bestehenden Software erstellt werden. Wenn man mit der Erstellung einer Vorlage nicht weiter kommt, könnte die Vorlagenwerkstatt helfen. Bitte beachte aber auch, dass die de-WP-Community allgemein deutlich kritischer gegenüber Vorlagen eingestellt ist als z.B. den en-WP. --Orci Disk 20:27, 31. Mai 2017 (CEST)

Hallo Rævhuld, es wäre gut, wenn du die Hinweise aus dieser Diskussion noch in deinen Wunsch selbst einarbeiten könntest, denn die Diskussion wird mit Beginn der Abstimmung (19. Juni) ausgeblendet und dann gehen die Klärungen verloren. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:56, 7. Jun. 2017 (CEST)

Hallo Rævhuld, ist dein Anliegen soweit für dich geklärt? Dann würde ich deinen Wunsch morgen nach Wünsche außerhalb des Projektrahmens verschieben, da es sich nicht um einen technischen Wunsch handelt, der Änderungen an der Mediawiki-Software bedarf. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 19:36, 15. Jun. 2017 (CEST)

Unterstützung

Aggressive Nutzer*innen

Was ist das Problem?

Wenn man hier Artikel bearbeitet, kann man schon an eine*n Nutzer*in oder gar an Nutzer*innen geraten, die ziemlich aggressives Auftreten besitzen. Es wäre schön, wenn man dann Hilfe bekommen könnte.

Wen betrifft das Problem besonders?

Editierer.

Lösungsvorschlag

Eine einfach zu findene Funktion, die man benutzen kann, um diesen Nutzer*innen zu melden! Und dann mit einem visuellen Editor, womit man ganz einfach die verschiedene Passagen in der Meldung zeigen kann!

Vorschlagende Person

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

Diskussion

Hallo Rævhuld, es gibt schon Seiten auf denen man Nutzer und Nutzerinnen melden kann. Ob da weiterer Bedarf ist müsstest du mit der Community klären. Wenn ich das richtig verstehe und du keine Einwände hast, würde ich Freitag deinen Wunsch nach Wünsche außerhalb des Projektrahmens verschieben, wo du ihn weiter einsehen und drauf verlinken kannst, z.B. für ein Meinungsbild. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 19:51, 15. Jun. 2017 (CEST)

Beim Mediatorentreffen wurde deutlich, dass ein hier geschidertes Verhalten leider nicht selten ist. Man könnte die Idee hier vielleicht mit einem Bewertungstool umsetzen: Jeder Autor kann den Beitrag eines anderen bewerten mit h=1..5 (wenig hilfreich..voll geholfen) und zusätzlich mit f=1..5 (verletzend..sehr freundlich). Bei 1 würde der Vorgang an einen Admin weitergeleitet, genauso wenn ein Autor mehrere 2 oder viele 3 bekommt.

Wenn ein Autor viele 5 oder sehr viele 4 bekommt, wäre das vielleicht einen Orden wert :-)

Vielleicht wäre das ein Weg, unsere Kutur zu verbessern? Gruss, --Markus (Diskussion) 09:29, 22. Jun. 2017 (CEST)

Unterstützung

Diskussionsseiten Layout und Funktionsumfang wie im englischen Wikipedia.

Was ist das Problem?

Diskussionsseiten Layout und Funktionsumfang wie im englischen Wikipedia fehlt im deutschen.

Wen betrifft das Problem besonders?

Diskussionsseiten

Lösungsvorschlag

Übernehmen.

Vorschlagende Person

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

Diskussion

@Rævhuld: Danke für den Wunsch! Könntest du noch genauer beschreiben, was dir fehlt? Und deckt sich dein Wunsch möglicherweise mit diesem: Trennung der Communityfunktionen von Mediawiki? Dann wäre es sinnvoll, dass newt713 und du euren Wunsch gemeinsam einreicht und den anderen aus der Umfrage entfernt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:51, 10. Jun. 2017 (CEST)

Hallo Rævhuld, ein Layout wäre wahrscheinlich auch etwas, dass durch eine Vorlage gelöst werden würde. So eine Entscheidung liegt in der Hand der Community und könnte z.B. in der Vorlagenwerkstatt erfragt werden. Wenn ich deinen Wunsch richtig verstehe, würde ich morgen (Freitag) nach Wünsche außerhalb des Projektrahmens verschieben, wo du ihn danach noch weiter einsehen kannst. Wenn nicht, wäre es hilfreich wenn du bis dahin anhand der Fragen von Johanna deinen Wunsch noch etwas genauer erläutern könntest. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 19:11, 15. Jun. 2017 (CEST)

Unterstützung

Stubs einführen

Was ist das Problem?

Es ist nicht möglich Stubs im deutschen Wikipedia zu erstellen.

Wen betrifft das Problem besonders?

Wikipedialeser und Wikipediakleinbearbeiter.

Lösungsvorschlag

Eine Stubsvorlage (muss verdeutscht werden) einführen.

Anmerkungen

Das Prinzip hinter Wikipedia ist doch, dass man hier alles Relevante finden sollte. Es ist doch schön, wenn man einen Artikel vorfindet, der alles komprimiert aufführt. Dann können, frei nach dem Wikiprinzip, Nutzer den Artikel ausbauen - müssen nicht bei Null anfangen. Falls nicht, dann steht wenigstens etwas; auch wenn es komprimiert ist, oft brauchen Nutzer eben keinen vollen Artikel, sondern wollen nur das Relevanteste erfahren.

Vorschlagende Person

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

Diskussion

Die Wiedereinführung von Stubs erfordert keine technischen Änderungen. Deshalb ist hier, bei den Technischen Wünschen, eigentlich nicht der richtige Ort, um das zu diskutieren. Es gab vor über 11 Jahren mal ein Meinungsbild, das dazu führte, dass Stub-Kennzeichnung und -Kategorien abgeschafft wurden. Wikipedia:Stubs schreibt "Es ist grundsätzlich durchaus möglich, die meisten Themen in nur zwei oder drei Sätzen sinnvoll abzuhandeln, allerdings müssen dies gute, aussagekräftige Sätze sein.". In der Praxis ist das aber eher selten. Du könntest ein neues Meinungsbild starten. Die Anforderungen, die an neu erstellte Artikel gestellt werden, sind in den letzten 11 Jahren aber wohl eher noch gestiegen. Vermutlich hätte ein Meinungsbild zur Wiedereinführung von Stubs keinen Erfolg. -- Reise Reise (Diskussion) 09:07, 31. Mai 2017 (CEST)

Ich beziweifle, ob Stubs wirklich noch unerwünschter sind als damals. Die Frage ist doch: was will ein Artikel, und was will ein Stub? Ein Stub will nicht viel mehr als den Leser nicht ganz im Regen stehen lassen mit "in der WP existiert das Thema nicht". Ein Stub hat aber wesentlich tiefere Ansprüche als ein Artikel und ist meist nicht viel mehr als ein Anhaltspunkt für jene, die keine Ahnung haben, was mit einem Begriff gemeint ist. Das ist aber dann meist auch hinreichend, damit der anhungslose Leser eine einigermassen neutrale Erklärung erhalten kann, womit viel Zeit gewonnen wäre, nicht extern suchen zu müssen. Insofern haben Stubs durchaus ihre Berechtigung; und eine Vorlage würde verihndern, dass sowas gleich einer LD zugeführt würde. Viel mehr als eine entsprechende Vorlage müsste dazu nicht erstellt werden; und natürlich müsste das Prozedere Anerkennung finden. --ProloSozz (Diskussion) 12:33, 5. Jun. 2017 (CEST)

Kannst du ja gerne bezweifeln. Ich wollte nur darauf hinweisen, dass das kein technischer Wunsch ist und deshalb eigentlich nicht hier hin gehört. Die Frage ist eher: „Was will die Community?“ Starte(t) doch einfach ein neues Meinungsbild, um zu erfahren, ob das Prozedere Anerkennung findet. -- Reise Reise (Diskussion) 20:40, 14. Jun. 2017 (CEST)

Hallo Rævhuld, da dieser Wunsch, soweit ich das verstehe und wie von Reise Reise angemerkt, keine technische Umsetzung benötigt, sondern ein Meinungsbild von der Community, würde ich ihn morgen (Freitag) nach Wünsche außerhalb des Projektrahmens verschieben. Bitte melde dich hier nochmal, falls ich was übersehen habe. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 19:23, 15. Jun. 2017 (CEST)

Ich würde den durchaus hier drin lassen, auch wenn es nur um einen politische Angelegenheit geht. Möglicherweise könnte auch die Kennzeichnung von Stubs auf technischer Ebene erfolten. Im Rahmen dieses Projekts das Theman zu diskutieren ist sicher nicht falsch und der richtige Zeitpunkt, eine solche Diksussion anzustoßen. --ProloSozz (Diskussion) 12:51, 16. Jun. 2017 (CEST)

@ProloSozz: Meiner Einschätzung nach wäre es eher kontraproduktiv das hier stehen zu lassen, obwohl es definitiv kein technischer Wunsch im Sinne dieser Umfrage ist. Die Community reagiert erfahrungsgemäß eher ungehalten, wenn sie etwas deplaziert oder unausgegohren zur Abstimmung vorgelegt bekommt. Eine Abstimmung am falschen Ort (und hier soll ja bald abgestimmt werden) birgt die Gefahr einem eigentlich sinnvollen Anliegen zu schaden, weil es dann ggf. als „schon mal abgelehnt“ gebranntmarkt ist.

Wenn Du eine Diskussion zu diesem Thema anstoßen willst, wäre ein Artikel im WP:Kurier und/oder die Eröffnung einer WP:Projektdiskussion (ggf. gefolgt von einer WP:Umfrage oder eine WP:Meinungsbild) der richtige Weg. Und falls dann die Einführung beschlossen und eine Kennzeichung notwendig würde, lies sich das problemlos in der Vorlagenwerkstatt realisieren. // Martin K. (Diskussion) 13:02, 16. Jun. 2017 (CEST)

@Martin Kraft:Dem kann und will ich nicht widerprechen. Auch wenn Stubs nicht unbedingt eine technische Lösung erfordern, erachte ich die Diskussion darum nicht unbedingt als fehlplaziert, da möglicherweise das Thema mithilfe einer "technischen Lösung" umgesetzt werden könnte. Eine entsprechende Kennzeichnungsvorlage ist ja prinzipiell ja eigentlich auch eine "technsiche Lösung", aber nicht im Sinne davon, wie hier zuerst technisch daran gearbeitet werden muß, um einen Vorschlag umzusetzen. Ich würde das Kapitel aber eher in "Sonstiges" unterbringen (und nicht hier in "Wartung"); und in "Sonstiges" dürften dann allenfalls auch Vorschläge auftauchen, die eben doch keine "technische Erfordernis" darstellen. Wenn bei der Themenformulierung darauf hingewiesen wird, daß das v.a. eine politische Frage ist (und allenfalls höchst bedingt (auch) eine "technischen Lösung" erfordert), könnte das eine Art "Meinungsbild durch die Hintertür" ergeben, das dann ggf. als Vorabklärung verwertbar wäre. Auch wenn das wohl formal nicht ganz im Sinne des Erfinders (der Technischen Wünsche 2017) sein mag, wäre es ev. besser, als das Thema gar nicht aufzuwerfen. Wenn sich die Leser und Benutzer schon mit Erweiterungen befassen (und die Fühler dafür ausgestreckt haben), kann man sie gleich abholen; sonst könnte das wieder versanden und die Beurteilng wäre so punktuell, daß sie nicht wirklich repräsentativ wäre. --ProloSozz (Diskussion) 12:04, 17. Jun. 2017 (CEST)

Hallo ProloSozz, vielen Dank für deinen Beitrag. Ich habe den Wunsch trotz deiner Einwände verschoben, da wir für dieses Projekt festgelegte Kriterien haben die ein Wunsch erfüllen muss um von uns umgesetzt zu werden. Diese zu ändern, wie du es vorschlägst, ist eventuell etwas, was man für die nächste Umfrage diskutieren kann. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 15:17, 17. Jun. 2017 (CEST)

Ich befürworte die Verwendung von Kurzartikeln und die Idee der iterativen Verbesserung.
Auch wenn in Zürich mal stand: "Zürich ist die Hauptstadt der Schweiz" - wurde daraus inzwischen "Zürich ist die grösste Stadt der Schweiz" und ein recht informativer Artikel. Gruss, --Markus (Diskussion) 09:41, 22. Jun. 2017 (CEST)

Unterstützung

„Fußnoten-Tooltip“-Helferlein für die Vorlagenkombination FN und FNZ

Was ist das Problem?

Ein angemeldeter Benutzer kann in den Einstellungen auf der Registerkarte „Helferlein“ im Abschnitt „Lesehilfen“ den „Fußnoten-Tooltip“ aktivieren, der beim Überfahren eines Referenzlinks im Artikeltext (Einzelnachweisnummer in Eckigen Klammern) die zugehörige Fußnote im Tooltip anzeigt, ohne dass es notwendig würde, ans Ende des Artikeltextes zu springen. Dieses Fußnoten-Tooltip-Lesehilfen-Helferlein funtioniert jedoch nicht bei den Fußnoten, die auf der Kombination der Vorlagen FN und FNZ basieren.

Wen betrifft das Problem besonders?

Alle Leser, die Arikel lesen, in denen die Vorlagenkombination FN und FNZ verwendet wird.

Lösungsvorschlag

Entweder das Fußnoten-Tooltip-Lesehilfen-Helferlein so umprogrammieren, dass es auch bei Fußnoten funktioniert, die auf der Kombination der Vorlagen FN und FNZ basieren, oder für Fußnoten, die auf der Kombination der Vorlagen FN und FNZ basieren ein separates, äquivalentes Helferlein programmieren.

Anmerkungen

Mit Schnarks popuprefs tritt dieses Problem nicht auf. (Ergänzung von Speravir)

Vorschlagende Person

X:: black ::X (Diskussion) 23:32, 11. Jun. 2017 (CEST)

Diskussion

Hallo X:: black ::X, reicht dir die vorgeschlagene Lösung von Speravir? Wenn ja, würde ich Freitag deinen Wunsch nach Wünsche außerhalb des Projektrahmens verschieben wo schon erledigte oder nicht erfüllbare Wünsche geparkt werden. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 20:19, 15. Jun. 2017 (CEST)

Hallo Charlie Kritschmar (WMDE), das Skript Benutzer:Schnark/js/popuprefs enthält die von mir gewünschte Funktion (und reicht mir insofern aus). Schade, dass es  – im Gegensatz zum Fußnoten-Tooltip-Lesehilfen-Helferlein – nicht in Spezial:Einstellungen vorhanden und anwählbar ist und dort (beim Fußnoten-Tooltip-Lesehilfen-Helferlein) nicht wenigstens ein Hinweis auf diese alternative Möglichkeit mit zusätzlicher Funtionalität vorhanden ist; so wird es wohl leider ein Script für Insider bleiben. Bleibt zu hoffen, dass die Bearbeitung des Wunsches Verbessertes Auffinden und Handling von Tools und Skripten in der Rubrik „Sonstiges“ diesbezüglich weiterhilft (ist auch Thema im Wunsch Digitales Erbe). Viele Grüße --X:: black ::X (Diskussion) 12:39, 16. Jun. 2017 (CEST)

Hallo X:: black ::X, das wäre in der Tat wirklich schade. Vielleicht kann dir hier geholfen werden? Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 15:25, 17. Jun. 2017 (CEST)

Unterstützung

Anordnung der Untertitel in der Vorlage:Mehrere Bilder

Was ist das Problem?

Wenn ich bei der Nutzung der Vorlage:Mehrere Bilder mich bezüglich der Anordnung der Bilder gegen eine einheitliche Höhe entscheide (z. B. weil ich ein sehr hoch und ein sehr breitformatiges Bild habe und das ganze nicht zu groß werden soll) und ich den beiden Bildern mittels Untertitel1 und Untertitel2 Untertitel zuweise, stehen diese Untertitel nicht nebeneinander, sondern der Untertitel des weniger hohen Bildes rutscht nach oben. Meiner Meiung nach sähe es aber in einigen Fällen besser aus, wenn beide Untertitel unten nebeneinander platziert wären.

Wen betrifft das Problem besonders?

Leser von Artikeln, in denen die Vorlage:Mehrere Bilder eingebunden ist.

Lösungsvorschlag

Die Vorlage so programmieren, das eine Einstellungspotion geschaffen wird, deren Aktivierung dafür sorgt, dass die Untertitel nebeneinander am unteren Rand stehen und nicht der Untertitel des weniger hohen Bildes nach oben rutscht (z. B. in dem man wahlweise einstellen kann, dass die Untertitel an der Innenseite des unteren Randes des äußeren Rahmens fixiert werden statt an der Außenseite des unteren Randes des inneren Rahmens).

Vorschlagende Person

X:: black ::X (Diskussion) 23:51, 11. Jun. 2017 (CEST)

Diskussion

Hallo X:: black ::X, für den Vorlagenwunsch am Besten die Diskussionsseite der Vorlage selbst nutzen oder sonst auch in der WP:Vorlagenwerkstatt nachfragen - die Vorlagen werden von Wikipedianern gemacht und betreut, das wäre keine Aufgabe für das Technische Wünsche Team. Ich würde diesen Wunsch daher vor der Abstimmung noch nach Wikipedia:Umfragen/Technische_Wünsche_2017/Wünsche_außerhalb_des_Projektrahmens verschieben. Liebe Grüße, --Birgit Müller (WMDE) (Diskussion) 21:46, 16. Jun. 2017 (CEST)

@X:: black ::X: Hierhin umgezogen - LG, --Birgit Müller (WMDE) (Diskussion) 18:41, 18. Jun. 2017 (CEST)

Lómelinde hat eine Möglichkeit geschaffen, die Untertitel nebeneinader unter den Bildern zu platzieren, wofür ich Ihr sehr herzlich danke. Nebenbei hat sie auch noch ein Problem mit über den Rand hinausragenden Bildern bei vertikaler Darstellung gelöst (siehe: Wikipedia:WikiProjekt Vorlagen/Werkstatt#Vorlage:Mehrere Bilder – Anordnung der Untertitel, wer sich dazu berufen und fähig fühlt, darf gerne den Code noch mal prüfen und ausprobieren, ob noch Fehler darin sind). --X:: black ::X (Diskussion) 15:56, 3. Jul. 2017 (CEST)

Unterstützung

Abstände zwischen Vorlagen bei Einbindung vereinheitlichen

Was ist das Problem?

Derzeit trifft man oft auf Artikel wie Star Wars, bei denen besonders bei eingebundenen Vorlagen im Fußbereich die Abstände zwischen diesen uneinheitlich sind, und das sieht nicht so toll aus, wie ich finde. Konkret wäre dies hier einmal der Abstand zwischen dem Kasten zur Sprechversion zum darüber liegenden Text sowie zur darunter befindlichen Navibox „Filme und Serien aus dem Star-Wars-Universum“ im Vergleich zum Abstand zwischen letzterer und dem Lesenswert-Hinweis.

Wen betrifft das Problem besonders?

Vorschlagende Person

Erdic (Diskussion) 21:58, 30. Mai 2017 (CEST)

Diskussion

Hallo Erdic, ich bin mir nicht sicher, aber das klingt nach etwas, was die Community entscheiden und leicht ändern kann? Korrigiere mich bitte wenn ich da was übersehe. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 18:48, 8. Jun. 2017 (CEST)

Ich weiß es nicht, aber ich weiß, dass das Thema bereits mehrfach auf den einschlägigen Seiten (Vorlagen-, Technikwerkstatt) angesprochen wurde – und bislang vergeblich. Ist übrigens nicht nur auf de-WP ein Problem... Gruß--Erdic (Diskussion) 19:01, 8. Jun. 2017 (CEST)

Das ist ziemlich sicher immer ein Problem der Vorlagenerstellung, genauer der Vereinheitlichung von Außenabständen. Möglicherweise liegt es im Einzelfall auch an ungewollten Zeilenumbrüchen. — Speravir – 02:00, 14. Jun. 2017 (CEST)

@Erdic: Es tut mir sehr Leid, dass dein Wunsch bisher leider nicht umgesetzt werden konnte, aber da er leider nicht technisch ist fällt er nicht in den Bereich der technischen Wünsche dir wir bearbeiten können. Ich würde ihn dann am Freitag nach Wünsche außerhalb des Projektrahmens verschieben wo du ihn dann noch weiter einsehen und verlinken kannst. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 20:00, 15. Jun. 2017 (CEST)

@Charlie Kritschmar (WMDE): Danke, aber, dass mein Wunsch „nicht technisch“ sei, kann ich leider nicht recht nachvollziehen. Mir erscheint er vielmehr hundertprozentig technisch, denn es geht doch um die Frage nach der allgemeinen Anpassung von Zeilenabständen, und hier insbesondere zwischen Vorlagen bzw. Bausteinen, also eine durchweg technische Standardisierung. Insofern würde ich gerne vor der geplanten Verschiebung meines Wunsches höflich Klärung erbitten. Dank und Gruß--Erdic (Diskussion) 22:40, 15. Jun. 2017 (CEST)

Noch einmal: Weil es ein Problem der Vorlagenprogrammierung ist und damit nicht im Umfang der Technischen Wünsche. — Speravir – 23:37, 15. Jun. 2017 (CEST)

@Erdic: Hallo, kurz von mir in Vertretung von Charlie: Gemeint war: „Weil dein Wunsch das Thema Vorlagen betrifft, fällt er nicht in den Bereich der technischen Wünsche, die wir bearbeiten können.“ Vorlagen sind natürlich auch Technik, aber wie Speravir schon schreibt, sind sie kein Inhalt des Projekts Technische Wünsche, sondern liegen in der Hand der Community. Ich hoffe, das konnte die Frage klären. @Speravir: Hast du vielleicht einen Tipp für Erdic, wie er das Thema am besten adressieren kann? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 10:21, 16. Jun. 2017 (CEST)

Darauf sollte Erdic eigentlich schon einige Male hingewiesen worden sein (da er sich zu diesem Thema auch schon in den Fragen zur Wikipedia gemeldet hat): die Vorlagenwerkstatt. — Speravir – 18:48, 16. Jun. 2017 (CEST)

Da die Abstände z.Z. in allen Vorlagen als Inline-Styles definiert werden, müsste eine Vereinheitlichung natürlich auch in den jeweiligen Vorlagen umgesetzt werden – was eher eine Community-Sache als eine Aufgabe von WMDE ist.

Allerdings wäre so eine Vereinheitlichung wesentlich einfacher und dauerhafter zu erreichen, wenn man sich bei der Erstellung/Wartung von Vorlagen aus einen projektweiten Baukasten von GUI-Elementen bedienen könnte, in dem dann auch zentral die Abstände von solchen Kästen am Artikelende definiert wären. // Martin K. (Diskussion) 12:30, 16. Jun. 2017 (CEST)

@Erdic: Bitte entschuldige meine unklare Ausdrucksweise und danke an Johanna für die Korrektur und Speravir für die Hilfestellung. Konnte dein Anliegen geklärt werden? Wenn ja, würde ich noch dein okay abwarten um ggfs. weitere Dinge zu klären und sonst Sonntag deinen Wunsch verschieben. Viele Grüße --Charlie Kritschmar (WMDE) (Diskussion) 14:58, 17. Jun. 2017 (CEST)

Unterstützung

Leiste mit Sonderzeichen sollen auch ohne eingeschaltetes Scripting sichtbar sein

Was ist das Problem?

Editiert man mit aktiviertem Scripting, so erscheint unterhalb des Editier-Fensters resp. der Zusammenfassungszeile eine Liste (resp. Zeile) mit mehreren häufig genutzten Sonderzeichengruppen (incl. Umlaute, ß, Anführungsstriche/Guillemets in verschiedenen Variationen, Funktionsbefehlen, Lautschriften, etc.). Da kann man mit eingeschaltetem Scripting draufklicken, und das Zeichen wird im Editierfenster direkt eingfügt. Hat man Scripting ausgeschaltet, erscheint die Zeile überhaupt nicht. Es wäre aber nützlich, wenn die Buchstaben erscheinen würden, um die Zeichen zur Verfügung zu haben (aber ohne darauf klicken zu können/müssen, um sie einzufügen; copy/paste reicht aus ohne Scripting).

Wen betrifft das Problem besonders?

Alle Editierer, die ohne Scripting unterwegs sind und dennoch Sonderzeichen nutzen wollen, die auf der Tastatur nicht direkt auf eine vorhandene Taste gelegt sind.

Lösungsvorschlag

Auch wenn man Scripting abgeschaltet hat, soll eine Zeile mit (denselben) Sonderzeichen erscheinen. Auf die muss man aber nicht klicken können, und sie werden auch nicht automatisch eingefügt. Aber man kann per copy/paste das Zeichen holen und im Text manuell einfügen. Das ist auf jeden Fall besser, als die Zeichen gar nicht zur Verfügung zu haben oder sie anderswo abholen zu müssen; oder warten zu müssen, weil der Rechner mit eingeschaltetem Scripting langsam wird. Ob das Popup-Menü auch ohne Scripting umgesetzt werden kann, bleibe an dieser Stelle dahingestellt; allenfalls müßte man in den eigenen Prefs jene Zeilen sichtbar schalten, die man üblicherweise nutzen will.

Anmerkungen

Es gibt viele Gründe, ohne Scripting unterwegs zu sein; gerade auf etwas schwachbrüstigen Rechnern sind Scripts CPU-belastende Ressourcenfresser, die den Prozessorventilator hochdrehen, was Krach macht, und zudem wird der Rechner lahm. Ohne Scripting kann man das vermeiden.

Vorschlagende Person

ProloSozz (Diskussion) 03:12, 16. Jun. 2017 (CEST)

Diskussion

Die hier ursprünglich vorhandene Diskussion über die Behandlung von Nachzüglern und weitere Verfahrensfragen wurde ausgelagert, da nicht direkt zum Thema des Wunsches.

Unterstützung

Nicht angemeldeten Benutzern (IPs) danken

Was ist das Problem?

Man sollte – irgendwie – auch nicht angemeldeten Benutzern (IPs) für eine Bearbeitung danken können.

Wen betrifft das Problem besonders?

Angemeldete Benutzer können nicht danken, IPs erhalten keinen Dank.

Vorschlagende Person

Gnom (Diskussion) 18:20, 10. Jun. 2017 (CEST)

Diskussion

Ich finde das eine gut Idee, insbesondere IP's für Bearbeitungen danken. Vielleicht fühlen sich einige IP's dadurch ermutigt öfters mitzuarbeiten und sich ggf. auch anzumelden. Außerdem bekommt die IP dadurch erstes feedback, und ich denke eine IP wird Artikel, die sie bearbeitet hat öfters besuchen, und damit auch das feedback mitbekommen. Dafür wäre es sinnvoll den Dank in der Versionsgeschichte sichtbar zu machen (z.B. hinter der bearbeitenden Person / IP).--GodeNehler (Diskussion) 19:10, 10. Jun. 2017 (CEST)

Die Schwierigkeit dahinter ist doch, dass man sich überhaupt nicht sicher sein kann, sich bei der richtigen Person zu bedanken. Das dürfte sicherlich auch der (Haupt-?) Grund sein, warum das bisher für IPs nicht umgesetzt wurde. — Speravir – 00:19, 13. Jun. 2017 (CEST)

Man könnte vielleicht ein kurzes Zeitfenster (30 Minuten? 1 Stunde?) nach einem IP-Edit zulassen, in dem es möglich wäre, dem unangemeldeten Benutzer per Danken-Feature (darum geht's Gnom wohl, denn einen Dank auf die IP-Diskussionsseite setzen könnte man ja technisch jetzt schon) zu danken. So wäre es auch bei dynamischen IPs noch wahrscheinlich genug, dass der Benutzer immer noch unter dieser IP unterwegs ist. Ausserdem sollte der Dank auch nur während eines gewissens Zeitfensters (1 Tag?) angezeigt werden. Gestumblindi 02:10, 14. Jun. 2017 (CEST)

Hallo Gnom, vielen Dank für den Wunsch! Eine Möglichkeit zu haben, IPs zu danken, hatte es 2015 schon einmal in die Topliste geschafft. Wir mussten die Umsetzung des Wunsches leider ablehnen, da eine IP nicht genau einer Person zuzuordnet werden kann, und die Herauforderungen in Bezug auf technische Implementierung, Sicherheits- und produktbezogene Fragen immens komplex sind & das sehr viel Problematisches mit sich bringen würde. Es wäre ansich eine sehr schöne Funktion, aber es ist leider jetzt schon klar, dass wir das nicht machen könnten ... . Ich würde daher den Wunsch morgen gerne verschieben in die Rubrik für Wünsche, die das Technik-Team nicht lösen kann & daher nicht in die Abstimmung gehen sollte: Wikipedia:Umfragen/Technische_Wünsche_2017/Wünsche_außerhalb_des_Projektrahmens - LG, --Birgit Müller (WMDE) (Diskussion) 16:45, 15. Jun. 2017 (CEST)

Wenn das so ist, möchte ich Gnom nochmals auf die Möglichkeit hinweisen, einen Dank auf die Diskussionsseite eines nicht angemeldeten Benutzers zu setzen. Diskussionsseiten dynamischer IPs werden m.W. standardmässig nach kurzer Zeit wieder gelöscht, aber man könnte sie ja etwa einen Tag oder so stehen lassen. Gestumblindi 18:16, 15. Jun. 2017 (CEST)

Liebe Birgit Müller (WMDE), ist deine Nachricht als Hinweis auf ein engültiges "Wontfix" (wenn ja, ist das auch so dokumentiert?) oder als ist das ein "Schaffen wir im Rahmen der Technischen Wünsche nicht"? Im zweiten Fall sollte man doch zumindest darüber abstimmen können, damit klar wird, dass hier nach wie vor nach einer Lösung gesucht wird. Oder sehe ich das falsch? Gruß, --Gnom (Diskussion) 10:07, 16. Jun. 2017 (CEST)

Hallo Gnom, "Können wir im Rahmen der Technischen Wünsche nicht machen" plus erhebliche Bedenken zur Möglichkeit der Umsetzung an sich. Wenn, dann müsste die WMF das angehen, wobei da vermutlich dieselben Bedenken vorhanden sind - zumindest sprechen bisherige Gespräche dazu dafür. Allerdings (soweit ich weiß), gibt es von der WMF dazu nirgendwo ein Statement, wo es heißt, aus Gründen xyz wird ein Danke für Anons (momentan oder künftig) nicht umgesetzt. Von daher könnte man schon darüber abstimmen lassen - & ggf. bei Erfolg des Wunsches die WMF noch um eine Einschätzung bitten. Generell würde ich das Weiterreichen von umfangreichen Projekten, die wir selbst nicht umsetzen können, jedoch als eher gering vom Erfolg einschätzen, außer, das ist zufällig ohnehin schon in der Planung. Kurz gesagt: Ob die WMF ebenfalls sagt: Können wir nicht machen, ist nicht final klar, wobei wir davon ausgehen würden, dass sie das ebenso problematisch einschätzen und ein Weiterreichen von Vorschlägen generell wenig Chancen hat, weil die WMF-Teams natürlich ihre eigenen Roadmaps haben. Also entscheide du ob rein oder raus :-) LG, --Birgit Müller (WMDE) (Diskussion) 12:41, 16. Jun. 2017 (CEST)

P.S.: Ich noch mal - @Gnom:, könntest du mir bis Sonntagnachmittag Bescheid geben? Ich schau dann nochmal hier rein. Sollten wir diesen Wunsch in die Abstimmung geben, müsste transparenterweise in die Anmerkungen, dass der Wunsch nicht im Rahmen der Technische Wünsche umgesetzt werden kann. Merci und viele Grüße! --Birgit Müller (WMDE) (Diskussion) 18:06, 16. Jun. 2017 (CEST)

Technische Infos zwischendurch:

1. IP-Erreichbarkeit und Zuordnung:
   • IP kann sich dynamisch nach einer halben Stunde geändert haben; denselben Adressat sieht man nie wieder.
   • Unter derselben dynamisch zugeteilten IP könnte rein theoretisch eine Stunde später ein völlig anderer Mensch einen WP-Artikel lesen wollen und bekommt ein fehlgeleitetes Dankeschön, was irritiert.
   • Hunderte von Menschen, die auch öfters mal in einem Wiki etwas nachschlagen wollen, können sich ein und dieselbe IP teilen.
   • Nur ein Dank, der binnen weniger Minuten nach einem Edit abgesendet wurde, und etwa eine Stunde nach dem betreffenden Edit wieder vernichtet werden würde, käme hier überhaupt in Frage.
   • Wer anonym, also ausdrücklich ohne Registrierung eine Seite bearbeitet (nur darum kann es bei Danke gehen), der hat sich dafür entschieden, anonym zu bleiben und nicht kontaktiert zu werden. Dann kann man auch nicht versuchen, das irgendwie zu durchbrechen (nebenbei: Angemeldet ist man anonymer als per IP editierend).
2. Server und Registrierung
   • Etwa 99 % der Wiki-Zugriffe (gefühlte Datenanalyse, mag jemand die letzte Statistik rauskramen) sind anonyme Nur-Lesezugriffe auf Artikel usw.
   • Die Vorstellung ist ja, dass beim Wiederbesuch der gleichen IP auf irgendeiner Seite die Dankesmeldung angezeigt werden soll, und das auch beim Nur-Lesen.
   • Die Auslieferung von anonymen Nur-Lese-Seiten, also 99 % der Anfragen, erfolgt über ein eigenes Server-Netz, die eine eigene und ggf. etwas träger im Cache hinterlegte Seitenstruktur nutzen.
   • Wer angemeldet eine Seite abruft, der wird auf ein exklusiveres Server-Netz geleitet. Früher mal war das wohl sogar ein eigenes Rechenzentrum, womöglich auf anderem Kontinent, aber heute wohl im selben Gebäude. Gleichwohl sind die anonymen Server für den Massen-Lese-Bedarf, der kleine Zirkel zur Bedienung angemeldeter Benutzer und die Abarbeitung von Seitenveränderungen unterschiedliche Maschinen mit anderer Optimierung.
   • Im Benutzerkonto angemeldeter Benutzer – eine eigene Datenbanktabelle – werden die Echo-Nachrichten und damit auch die Danke-Nachrichten dauerhaft hinterlegt, zumindest bis zu einer Maximalzahl.
   • Der Vorschlag läuft darauf hinaus, dass eine neue Datenbank eingerichtet werden solle, in der für die Dauer einer Stunde oder dergleichen die IP-Adressen der Dankes-Adressaten hinterlegt werden sollen.
     • Für den Fall, dass eine der mickrigen Handvoll der noch nicht abgearbeiteten Danke-Nachrichten einem Besucher der Milliarden von Massen-Nur-Lesen-Besuche zugeordnet werden könne, solle das Massen-Server-Netzwerk bei jedem Seitenabruf überprüfen, ob diese IP-Adresse dort aus der letzten Stunde noch einen Eintrag habe.
     • Das ist wegen miserabler Trefferquote nicht zu vermitteln.
   • Aus Datenschutzgründen (NSA, China, Türkei) registrieren die Server die aktuell genutzte IP-Adresse eines Besuchers erst in dem Moment, in dem auf speziellen Servern die Veränderung einer Seite usw. abgespeichert wird; die Server, die den Nur-Lese-Zugriff abwickeln, kennen sicherheitshalber die vollständige momentane IP-Adresse überhaupt nicht und können sie deshalb nicht mit dem Eintrag in der gewünschten Zwischendurch-Datenbank vergleichen.
     • Nur zur Abwehr aktueller Massenangriffe werden für einige Minuten die IP-Adressen der letzten Lesezugriffe gelogt; das überschreibt sich permanent selbst und soll nicht von Unbefugten ausgespäht werden können.
     • Für Zwecke der Bannerwerbung wird zeitweise die IP-Adresse dahingehend ausgewertet, aus welchem Staat ein Zugriff erfolgt, und dies und nur dies an den antwortenden Server übermittelt. Dies wurde vor einiger Zeit sicherheitsmäßig verschärft.
     • Die IP-Adresse selbst ist nur für einen Server-Administrator sichtbar, nicht für die seitengenerierenden Wiki-Server; ausgenommen beim Schreiben. Den seitengenerierenden Servern ist eine Art Firewall vorgelagert, die die Abwicklung der Kommunikation vornimmt, und die Anfrage nur gefiltert an die Wiki-Seiten dringen lässt.

Eine Realisierung ist nicht trivial, nicht innerhalb der MediaWiki-Software selbst möglich und hätte massive Änderungen in der Sicherheitsarchitektur und im Schutz gegen Ausspähung durch Regierungen und Firmen zur Folge, nebst Performance-Einbußen. Darauf wird sich kaum jemand einlassen, insbesondere nicht für einen wackligen Dank während einer Stunde, von dem ungewiss ist, ob er nach zwei Stunden oder jemals noch ankommen würde. Wegen des krassen Missverhältnisses zwischen Aufwand, Sicherheitsrisiken einerseits und der minimalen Erfolgschancen für ein mageres Winke-Winke, das hin und wieder noch ankäme, ist das Unterfangen aussichtslos.

VG --PerfektesChaos 20:25, 16. Jun. 2017 (CEST)

Ich könnte mir ja sogar vorstellen, dass die Bedankungen sogar einfach an einem zentralen Ort hinterlegt werden, also, dass man einfach eine Statistik erstellt: "Heute wurde nicht angemeldeten Benutzern X mal gedankt." Gruß, --Gnom (Diskussion) 05:58, 17. Jun. 2017 (CEST)

Gab es nicht mal eine Benutzerseite, auf der man quasi stellvertretend allen IPs danken konnte? --Flominator 17:53, 17. Jun. 2017 (CEST)

Find ich gut! wo? --Markus (Diskussion) 09:52, 22. Jun. 2017 (CEST)

Unterstützung

Besseres Auffinden UND Nutzerfreundlichkeit der Tools

Was ist das Problem?

Es gibt zahlreiche Tools, die diverse Abfragen Projektübergreifend ausführen (Wikidata, Commons, WP) und Daten auswerten können. Die teilweise mächtigen Funktionen der Tools sind zu wenig bekannt. Darüber hinaus sind die Tools nicht intuitiv und damit nutzerfreundlich zu bedienen.

Wen betrifft das Problem besonders?

Autoren, die Artikel warten

Lösungsvorschlag

Dokumentation der Tools; Nutzerfreundliches Softwaredesign

Anmerkungen

betroffen sind vor allem die Tools Petscan, SPARQL und Autolist

Hinweis: Dieser Wunsch überschneidet sich mit dem Wunsch: Verbessertes Auffinden und Handling von Tools und Skripten

Vorschlagende Person

 ^Thomas 14:12, 31. Mai 2017 (CEST)

Diskussion

Dokumentiert ist per WP:PetScan mindestens dieses; ansonsten erordern SPARQL & Co. auf der einen Seite und mächtige projektübergreifende Abfragen auf der anderen Seite sehr fortgeschrittene Kenntnisse über die Datenorganisation; technisch wie inhaltlich. Da mal eben mit drei Häkchen anklicken die geniale Analyse aufs Smartphone zu zaubern wird nicht laufen. VG --PerfektesChaos 02:59, 1. Jun. 2017 (CEST)

Dass das Tool dokumentiert ist, ist lobenswert. Allerdings stellt sich häufiger das Problem, dass man ein Problem hat aber gar nicht weiß, mit welchem Tool sinnvollerweise zu arbeiten ist. Mit einem gut dokumentierten Trabi kann man auch auf die Rennstrecke, womöglich gibt es jedoch bessere Lösungen. -- 32X 20:42, 11. Jun. 2017 (CEST)

Hallo Z thomas, für den Teil zum "besseren Auffinden" würde ich vorschlagen, mit dem Wunsch von Geolina zusammen zu gehen, der in den Anmerkungen verlinkt ist. Zur Nutzerfreundlichkeit von Tools: So wie hier beschrieben, hat der Wunsch kein richtiges Ende & Tools werden von unterschiedlichen Leuten gebaut, und liegen dann auch in der Hand der Erbauer/Community. Was man machen könnte: Den Nutzerfreundlichkeitsteil des Wunsches auf das dir wichtigste Tool zu spezifizieren. Also z.b.: "Petscan nutzerfreundlicher machen" & in der Problembeschreibung dann aufzählen, was mit Petscan nicht intuitiv ist. Wobei der Disclaimer bei so einem Wunsch immer wäre: Das geht nur in Zusammenarbeit mit dem Programmierer des Tools. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 16:30, 12. Jun. 2017 (CEST)

Hallo Z thomas, falls du nochmal reinschaust: Da der machbare Teil des Wunsches "Besseres Auffinden" in dem Wunsch von Geolina ebenfalls vorkommt & der andere Teil dieses Wunsches so nicht realisierbar ist, würde ich ihn heute noch zu den Wünschen außerhalb des Projektrahmens verschieben. Der Wunsch zur besseren Nutzerfreundlichkeit und Dokumentation von Tools ansich wäre nur mit einer oben beschriebenen Eingrenzung und unter Vorbehalt machbar, da Tools in der Regel von der Community geschrieben werden. Ping mich, falls du gerade hier bist, dann können wir das eben auch zusammen zurechtschneidern! LG, --Birgit Müller (WMDE) (Diskussion) 22:25, 18. Jun. 2017 (CEST)

Hallo @Birgit Müller (WMDE): verdammt. entschuldige, das ist mir durchgerutscht. mir rennt grad die zeit davon... verzeih bitte das wort "euch", das ich gleich nutzen werde, das klingt so furchtbar. wenn ich das richtig verstehe sind Petscan und Autolist nicht von euch programmiert sondern laufen über den "toolserver". SPARQL ist durch euch programmiert. ich hätte da gern einfach eine intuitive nutzerführung. und das was petscan und autolist können, sollte in der wp-software ebenfalls intuitiv integriert sein. hilft dir das? wenn nicht, verschieb ihn...

ich ärger mich grad über mich selbst, weil mir der wunsch am herzen liegt, ich deine frage übersehen hab und nun keine zeit mehr habe. tut mir leid. :-( liebe grüße -- ^Thomas 22:41, 18. Jun. 2017 (CEST)

Hi Z thomas, kein Ding :-) - kurze Rückfrage: SPARQL ist eine Programmiersprache und kein Tool im eigentlichen Sinne. Bei uns wird SPARQL für den Wikidata-Query-Service benutzt - meinst du das damit? Falls mit SPARQL wirklich der Query-Service gemeint war, wäre das vermutlich der einfachste Fokus für diesen Wunsch, weil "aus eigenem Haus" :-) - und du müsstest dich schlicht für eine Sache entscheiden - LG, --Birgit Müller (WMDE) (Diskussion) 23:18, 18. Jun. 2017 (CEST)

Morgen, Z thomas, sehr schade! - Konnte diese Entscheidung leider nicht für dich fällen. Denn zur nächsten Umfrage ... - lieben Gruß, --Birgit Müller (WMDE) (Diskussion) 08:25, 19. Jun. 2017 (CEST)

Guten morgen @Birgit Müller (WMDE): so ist es dann leider... noch kurz zur beantwortung. mit SPARQL meinte ich den Wikidata-Abfrage-Service. nun ist es wohl zu spät. liebe grüße -- ^Thomas 08:33, 19. Jun. 2017 (CEST)

noch mal @Birgit Müller (WMDE): :-) -- ^Thomas 08:35, 19. Jun. 2017 (CEST)

Z thomas, gib mir noch schnell eine Problembeschreibung: Was am Wikidata Query Service ist nicht nutzerfreundlich? Was würde es besser machen? - bis 9:30 kann ichs wieder zurückschieben, dann müsste ich andere Dinge tun ... :-) LG --Birgit Müller (WMDE) (Diskussion) 08:55, 19. Jun. 2017 (CEST)

Hi Z thomas, also jetzt ist es leider zu spät ... Aber ich könnte mir denken, dass ein Zugänglichmachen des Wikidata Query Service für nicht SPARQL-Experten perspektivisch ohnehin geplant ist (falls es u.a. das ist, was du meinst?), von daher ... - wenn es bei der nächsten Umfrage noch nicht passiert ist: Gerne nochmal einreichen! Wir haben hier diese Seite: Wikipedia:Technische_Wünsche/Wunschparkplatz, wo Leute Wünsche "parken" können - dann gibts ne Benachrichtigung bei der nächsten Umfragerunde. LG, --Birgit Müller (WMDE) (Diskussion) 09:45, 19. Jun. 2017 (CEST)

Hier eine Lösung für Wikidata-Queries - bitte auf Deutsch übersetzen! Gruss, --Markus (Diskussion) 10:01, 22. Jun. 2017 (CEST)

Unterstützung