Wikipedia:Umfragen/Technische Wünsche 2022 Themenschwerpunkte

Seit 2019 wählen die deutschsprachigen Communitys etwa einmal pro Jahr einen neuen Themenschwerpunkt für das Projekt Technische Wünsche. Das Projektteam geht dann im Laufe von zwei Jahren verschiedene technische Probleme innerhalb dieses Schwerpunkts an. Die nächste Umfrage Technische Wünsche soll im Januar 2022 auf dieser Seite stattfinden.

Konzept

In welchem Bereich sind technische Verbesserungen dringend nötig?

Die Wahl der Themenschwerpunkte dient als Stimmungsbild, in welchem Bereich dringend technische Verbesserungen nötig sind.

Die Themenschwerpunkte sind allgemein gehalten und so formuliert, dass man sie auch ohne technische Expertise gut verstehen kann. Das soll ermöglichen, dass viele Menschen mitentscheiden, worauf der Fokus der technischen Entwicklungen gelegt werden soll. In den Umfragen 2019 und 2020 haben jeweils über 1000 Personen abgestimmt und hoffentlich werden es 2022 noch mehr. Zum Vergleich: Im alten Umfragemodell lag die höchste Beteiligung bei 450 Personen in der Umfrage 2017. Damals standen viele individuelle Probleme zur Wahl; sie zu verstehen und zu vergleichen brauchte allerdings deutlich mehr Zeit und Hintergrundwissen.

Die Arbeit in Themenschwerpunkten sorgt aber nicht nur dafür, dass sich mehr Menschen einfacher beteiligen können, sie macht auch die Arbeit im Projekt effizienter: Jede Verbesserung, die das Team Technische Wünsche angeht, startet mit einer ausführlichen Recherchephase. In der Vergangenheit wurde für jedes Problem neu recherchiert; mit dem Modell der Themenschwerpunkte gibt es jetzt eine Recherchephase und deren Erkenntnisse können für verschiedene Probleme innerhalb des Themenschwerpunkts genutzt werden. So bleibt mehr Zeit für das Umsetzen von Lösungen. Ausführlicher ist der Arbeitsmodus hier beschrieben.

Abstimmungsmethode

wird noch ergänzt

Wer kann abstimmen?

Wenn du ein Nutzerkonto hast, das mindestens 30 Tage vor der Abstimmung erstellt wurde (also am oder vor dem 25.12.2021), kannst du abstimmen. Ein Nutzerkonto ist nötig, um zu vermeiden, dass eine Person mehrere Stimmen für ein Thema abgibt. Es ist aber ausdrücklich nicht nötig, technische Vorkenntnisse oder langjährige Erfahrung in den Wikis zu haben.

Zeitlicher Ablauf

Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
bis 24.11.2021 bis 3.12.2021 bis 2.1.2022 bis 16.1.2022 24.1.-6.2.
Themen und Probleme einreichen Input bündeln / Themenschwerpunkte erstellen Feedback zu Themenschwerpunkten Themenschwerpunkte überarbeiten Umfrage
alle Team Technische Wünsche alle Team Technische Wünsche alle

Themenschwerpunkte

Wie kamen die Themenschwerpunkte zustande?

Die unten vorgeschlagenen Themenschwerpunkte wurden auf Basis dieses Inputs der deutschsprachigen Wiki-Communitys erstellt:

Das Team Technische Wünsche hat all diese Quellen gesichtet und daraus Pakete nach folgenden Kriterien geschnürt:

  • umsetzbar im Rahmen der zwei Jahre, die für die Umsetzung zur Verfügung stehen,
  • auch für technisch weniger Versierte verständlich formuliert,
  • noch etwas enger gefasst als in den letzten beiden Jahren, damit sich die Recherchephase etwas verkürzt und somit hoffentlich noch mehr Zeit in die Umsetzung fließen kann.

Die Probleme wurden so gebündelt, dass sie ähnliche technische Bereiche berühren. Für die meisten Probleme ließ sich ein passender Themenschwerpunkt finden. Leider nicht mit eingeflossen sind aber Probleme, die Community-seitig gelöst werden müssen (beispielsweise Bot-Programmierung und Anpassung einzelner Vorlagen), die vom Projektteam technisch nicht umsetzbar wären (beispielsweise Arbeit an mobilen Apps), und Probleme, die Bereiche betreffen, die andere Teams aktuell grundlegend überarbeiten (beispielsweise das Benachrichtigungssystem oder auch Werkzeuge zur Vandalismusbekämpfung). Zudem gab es eine Handvoll Probleme, die sich keinem Themenbereich zuordnen ließen.

Bitte beachten: Die Wahl der Themenschwerpunkte bestimmt zunächst nur, in welchem übergeordneten Thema es Verbesserungen geben soll. Was genau innerhalb des gewählten Themenschwerpunkts dann letztlich umgesetzt wird, wird sich erst nach der Abstimmung zeigen. Dann startet eine größere Recherche, mit deren Hilfe identifiziert wird, was die tatsächlich dringendsten Probleme sind.

Diese 16 Themenvorschläge stehen dieses Jahr zur Wahl

Suche in Wikimedia-Projekten verbessern

Manchmal ist es schwierig, in den Wikimedia-Projekten genau das zu finden, wonach man sucht. In diesem Themenschwerpunkt würde es darum gehen, leichter und genauer angeben zu können, wonach gesucht wird, sowie die Suchergebnisse nützlicher zu gestalten.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Es ist schwierig, Seiten mit Tippfehlern zu finden.
  • Es ist nicht möglich, nach Worten mit Sonderzeichen aus anderen Sprachen zu suchen.
  • Es werden keine Suchergebnisse aus anderen Sprachversionen angezeigt.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Was will man techinsch machen, um leichter Tippfehler zu finden? Es hat schon einen Grund, warum Aka dazu ein relativ komplexes Vorgehen fährt. Man könnte sich natürlich irgendwo ein umfangreiches Vollformenwörterbuch der deutschen Sprache schnappen und alle Wörter melden, die da nicht drinstehen. Das würde aber ziemlich viele falsch-positive Treffer erzeugen, da eine Enzyklopädie mutmaßlich auch viel mit Wörtern hantiert, die nicht dem Alltagsgebrauch zuzurechnen sind. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 13:46, 3. Jan. 2022 (CET)[Beantworten]

Besser in der mobilen Ansicht arbeiten

In der mobilen Ansicht gibt es einige Probleme, gerade auch im Vergleich mit der Desktop-Ansicht. Dieser Themenschwerpunkt würde sich damit befassen, die Arbeit mit mobilen Geräten zu vereinfachen. Es geht ausdrücklich nicht um die Verbesserung der iOS- und Android-App, weil Teams der Wikimedia Foundation dort aktiv an Verbesserungen arbeiten.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Es ist umständlich, in der mobilen Ansicht zu navigieren. Unter anderem sind die Links zu den Diskussionsseiten unterschiedlich platziert, je nachdem, in welchem Namensraum man sich befindet.
  • Editieren auf mobilen Endgeräten ist umständlich.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Ich hatte bisher noch nie an die Möglichkeit gedacht am Smartphone bsw eine Überarbeitung eines Artikels zu machen, kleine Edits sind bei mir dagegen auf dem Smartphone üblich. Es scheint aber möglich zu sein, nur muss man sich gut mit diversen Apps auskennen, denn erst dann geht das. Sollte das überhaupt anzustreben sein? Wer arbeitet überhaupt so? PS: Der zweite Punkt ist für mich nicht verständlich. Ich verstehe weder das Problem mit der Navigation, noch mit den Diskussionsseiten. Beim ersten Punkt fehlt mir ein Beispiel was da gemeint ist. Wird da vom Visuellen Editor geredet?Goldzahn (Diskussion) 21:21, 8. Dez. 2021 (CET)[Beantworten]
  • Ich schlage vor, die beiden Punkte zu tauschen, d. h. erst Die Navigation ..., dann Editieren auf .... Begründung: Einheitliche Platzierung ist wichtig. Auf mobilen Endgeräten wird hingegen das Arbeiten immer umständlich bleiben. (Ich schalte immer auf die klassische Ansicht um, dann geht prinzipiell alles und alles ist einheitlich platziert, so dass ich es finde. Bei Full HD passt insbesondere alles auf den Schirm.)--Frühlingsmädchen (Diskussion) 13:25, 11. Dez. 2021 (CET)[Beantworten]
  • wäre sehr wichtig dieses Thema vorantzutreiben, da vor allem jüngere Nutzende vorwiegend mit dem smartphone arbeiten. Elena Patrise
  • Selbst beim Lesen gibt es in der mobilen Ansicht Probleme: Bei der Hauptseite des Wiktionarys wird (oft) nur die rechte Spalte angezeigt. Siehe auch wikt:Wiktionary:Fragen_zum_Wiktionary/Archiv/2021#Marsch und den darauffolgenden Abschnitt. -- Peter Gröbner -- 09:00, 13. Dez. 2021 (CET)[Beantworten]
  • Es sollte ohne Probleme möglich sein, ganze Artikel mobil zu bearbeiten und nicht nur einzelne Abschnitte. Ferner sollte es möglich sein, auf die Desktop-Einstellungen auch mobil ohne Probleme zuzugreifen (die derzeit verlinkten Special:MobileOptions sind ein Witz und beinahe vollkommen nutzlos) – KPFC💬 10:52, 18. Dez. 2021 (CET)[Beantworten]
  • Ich weiß jetzt nicht, ob das hier her gehört, oder zum Punkt mit der Beobachtungsliste unten, aber wenn ich das richtig sehe (gerade nochmal am PC in der mobilen Ansicht geprüft), wird in der mobilen Ansicht Fettdruck nicht dazu verwendet, um besuchte Seiten zu markieren (wie es in der Desktop-Ansicht der Fall ist). Da ich insbesondere die Beobachtungsliste auch unterwegs verwende, fände ich es gut, hier die fast vollständige Funktionalität zu haben. Wenn die Hervorhebung mit Fettdruck nicht möglich ist, könnte eventuell der Text auch hinterlegt werde. --Amateur-Wikipedianer (Diskussion) 13:47, 30. Dez. 2021 (CET)[Beantworten]
  • Der über die mobilen Einstellungen aktivierbare erweiterte Mobilmodus (mw:Reading/Web/Advanced mobile contributions) ermöglicht bereits seit Jahren "einen einfachen Zugang zu Diskussionsseiten, Versionsgeschichten, Benutzerwerkzeugen und anderen Bearbeitungs-Werkzeugen". Unter anderem ist dort (wie hier schon jemand erwähnte) das Problem mit der Diskussionsseiten-Platzierung bereits gelöst und es wäre zu überlegen, ob der erweiterte Modus zur Standardansicht gemacht werden sollte, zumindest für eingeloggte Benutzer. Grüße, HaeB (Diskussion) 20:46, 31. Dez. 2021 (CET)[Beantworten]

Merklistenfunktion

Wiederholt kam der Wunsch nach einer Funktion für persönliche Notizen, To-Do-, Wiedervorlage- oder Merklisten auf, auf die von verschiedenen Geräten aus zugegriffen werden kann. Zusätzliche Funktionen, die Unterseiten im Benutzernamensraum nicht bieten können, wären etwa Filter oder Sortierung.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die konkreten Bedürfnisse herauszufinden und die Umsetzung einer solchen Funktion zu konzipieren.


Diskussion

  • Sollte das gemacht werden, würde ich mir wünschen, dass man auch Internetquellen, etc. sammeln und zusammen mit den Infos die für ein ref benötigt werden, in einer persönlichen Merkliste speichern kann. Ergänzt man dann ein ref im Artikel, sollte aus der Merkliste der Datensatz per Klick übernommen werden. Halte ich für sinnvoll wenn man mit dem Smartphone über mehrere Tage hinweg an einem Artikel arbeiten will. Goldzahn (Diskussion) 21:33, 8. Dez. 2021 (CET)[Beantworten]
Hast du nicht hier selbst gesagt, dass du nicht mit einem Smartphone arbeiten würdest? --ElBe 1 | 2 | 3 | JWP 21:40, 8. Dez. 2021 (CET)[Beantworten]
Ich nutze kaum noch den PC, nur noch für Banking und für WP-Artikelüberarbeitungen (einfache Edits mache ich jetzt schon mit dem Smartphone, zB. für diese Umfrage). Ich hatte wegen dieser Umfrage versucht such komplexere Dinge zu machen. Es geht! Die Umstellung scheint mir aber erheblich zu sein und das ganze ist dann komplex, weil man mit zig Apps arbeiten muss. Goldzahn (Diskussion) 21:54, 8. Dez. 2021 (CET)[Beantworten]
Ich habe mir die App Tasks von Google angesehen. Die hat eigentlich die Grundfunktionen, die ich gerne hätte. Die Frage wäre, ob man nicht solche externen Angebote nutzen sollte, statt Mediawiki mit neuen Funktionen auszustatten. Ich selbst werde das für meine nächste Überarbeitung ausprobieren. PS: Es könnte interesannt sein Termine aus der WP heraus automatisiert exportieren zu können, zB aus dem Kurier. Wäre vlt. auch etwas für Wikinews: Also Schreiben in Wikinews und dann auf die Smartphones der Abonnenten versenden. Goldzahn (Diskussion) 22:50, 11. Dez. 2021 (CET)[Beantworten]
  • Wir müssen uns die Fragen stellen, ist die Zeit des Technische Wünsche Teams zum Programmieren der Filter und Sortierungen wirklich dafür notwendig und wäre sie nicht woanders sinnvoller verwendet? Und vor allem müssen wir uns fragen, brauchen wir wirklich Filter und Sortierungen oder reichen uns nicht einfach die Benutzerunterseiten in ihrem jetzigen Zustand? Weil diese Merklistenfunktion wäre ja im Prinzip nur eine Benutzerunterseite die Filter und eine Sortierung hätte oder habe ich das falsch verstanden? --Der König von Franken (Diskussion) 13:13, 11. Dez. 2021 (CET)[Beantworten]
    Denke nicht – wie wir die Millionen von Artikel in der Wikipedia unterhalten können, laufend aktualisieren ist doch eine der grössten Herausforderungen für unsere Arbeit
    Ich fände es super praktisch (hatte ich in den letzten Wochen wiederholt gedacht), wenn ich mir eine Notiz irgendwo machen könnte, dass ich im Februar 2022 noch an dies oder das denken sollte.
    Klar kann man auf externe Lösungen ausweichen – nur wäre es tausend Mal besser, wenn man nicht zwischen Systemen hin- und herspringen müsste und gleich dann den Reminder kriegt, wenn man sowieso in der Wikipedia am Arbeiten ist, und nicht gerade während des Meetings im Geschäft, auf der Radrunde oder beim Einkaufen, wenn man gerade gar keine Zeit hat. Dann ist es garantiert wieder vergessen, bis man vor dem Computer sitzt. --Lars (User:Albinfo) 12:08, 12. Dez. 2021 (CET)[Beantworten]
    Ich verstehe, was du meinst, aber trotzdem glaube ich, steht der Aufwand dafür in keinem Verhältnis zum Nutzen. Das ist im Prinzip ja nur ein Sache der Bequemlichkeit. Ich denke eher das sowas mehr für einen Bot eine Aufgabe wäre, als für unser Technische Wünsche Team, das sich mit wichtigeren Themen beschäftigen muss. --Der König von Franken (Diskussion) 18:13, 13. Dez. 2021 (CET)[Beantworten]
  • Bitte nicht. Es ist aus meiner Sicht besser sich darum zu bemühen wie Listen möglichst gut abgearbeitet werden können durch die Umsetzung eines der anderen Themenschwerpunkte. Auch wenn ich den Wunsch nachvollziehen kann, erscheint es mir in der Priorisierung fragwürdig, die Organisation von Nichtgetanem höher zu bewerten als das Tun an sich. --Fan (Diskussion) 19:25, 11. Dez. 2021 (CET)[Beantworten]
  • Überflüssig, denn um seine Arbeit zu organisieren, legt sich jeder seine eigenen Seiten im Benutzernamensraum an. Bei Kalender- und Benachrichtigungsfunktionen hat jeder andere Neigungen und Vorbehalte, was für individuelle Lösungen spricht. Sinnvoll auf einer Plattform wie Wikipedia wären allein Groupware-Lösungen, die aber nicht benötigt werden: Autoren arbeiten regelmäßig allein, und zur Organisation von Zusammenarbeit in Gruppen werden Wikiseiten im Wikipedia- und im Portalnamensraum routiniert und produktiv genutzt. Viele Grüße, Aschmidt (Diskussion) 00:26, 13. Dez. 2021 (CET)[Beantworten]

Bessere Wikidata-Integration auf Wikipedia

Wikidata wird bereits an verschiedenen Stellen auf Wikimedia-Wikis genutzt, z.B. in Infoboxen oder Listen. In diesem Themenschwerpunkt würde es darum gehen, Probleme rund um die Integration von Wikidata auf Wikipedia anzugehen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Veränderungen an Wikidata-Datenobjekten, die mit Artikeln verknüpft sind, bekommt man nicht unbedingt mit.
  • Wikidata-Daten in Vorlagen zu nutzen, ist teilweise kompliziert und langsam.
  • Wenn man ein Wikidata-Objekt verknüpfen will, ist es schwierig herauszufinden, welches das richtige ist.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Ich würde mir wünschen, dass es möglich ist, Querys die unter Wikidata erzeugt wurden in Wikipedia zu nutzen. Z.B. habe ich unter https://www.wikidata.org/wiki/User:GodeNehler/ACTV ein Query erstellt. Damit werden die Wasserbuslinien in Venedig auf einer Karte dargestellt. Dort kann man dann auch interaktiv reinzoomen. Unter dem Lema https://de.wikipedia.org/wiki/Azienda_del_Consorzio_Trasporti_Veneziano habe ich dann davon eine Screenshot genutzt ... was gelinde gesagt nicht gut aussieht. Hier würde ich mir massive Verbesserungen wünschen. Aber auch einfach Daten von einem Item sollten einfacher zu nutzten sein.--GodeNehler (Diskussion) 21:57, 8. Dez. 2021 (CET)[Beantworten]
  • Ich wünsche mir eine bessere Datenintegration/übernahme von zentralen Daten der Wikidata in die de.wikipedia. Dadurch könnte ein hoher Pflegeaufwand in den Bestandsartikeln in der de.wikipedia erheblich reduziert werden: Es wäre zukünftig unnötig z.B. einen Artikel eines Fußballspielers zu editieren, nur weil dieser jetzt einen Einsatz mehr hat, oder ein Softwareartikel zu editieren, da es ein neues Patchlevel für die Software gibt.
    Das Hauptargument gegen eine solche Einbinden von Wikidata-Informationen lautet, dass diese nicht kontrolliert/gesichtet werden (müssen) und somit die de.wikipedia an Qualität verlöre. Ich könnte mir daher eine Art „Übernahmesichtung“ vorstellen: Wenn auf der Wikidata-Plattform Informationen ergänzt werden, welche durch eine Einbindung auch in einem de.wikipedia-Artikel dargestellt werden, sollten diese Informationen vor Ausweisung im Artikel gesichtet werden. (nicht signierter Beitrag von WikiFreibeuter (Diskussion | Beiträge) 9. Dezember 2021 09:14)
    Die Idee der Übernahmesichtung finde ich interessant. Ich befürchte nur, dass dann jede Wikidata-Änderung auch in der Wikipedia ohne weitere Prüfung gesichtet wird (bereits jetzt erfolgen Sichtungen meist, ohne dass sich der Sichter mit dem Artikelinhalt auseinandersetzt). Und wenn das nicht der Fall ist und tatsächlich jede Wikidata-Änderung vor der Übernahme geprüft werden sollte, haben wir doch wieder fast die gleiche Menge an stupider Arbeit für Wikipedianer wie jetzt. --DerMaxdorfer (Diskussion) 13:47, 14. Dez. 2021 (CET)[Beantworten]
  • Wikidata könnte eine enorme Hilfe sein. Viele Daten sind in zentralen Repositorien außerhalb Wikipedias frei zugänglich. Es müsste möglich sein (d. h. softwareseitig müssten Möglichkeiten geschaffen werden) wie solche Daten direkt in Wikidata importiert werden könnten. ich denke da vor allem z. B. an Bevölkerungsstatistiken aus Volkszählungen, etc. etc. Das würde den Wikipedianern eine Menge letztlich stupider Arbeit ersparen. Die Datenqualität und -integrität in Wikidata muss natürlich besonders scharf überwacht und kontrolliert werden. Dafür müssten besondere Mechanismen geschaffen werden. --Furfur Diskussion 11:34, 10. Dez. 2021 (CET)[Beantworten]
    ... und das Schaffen dieser Mechanismen wird seit Jahren vergeblich versucht. Leider ist das auch nichts, was das Team Technische Wünsche lösen kann, denn es benötigt dafür höchstwahrscheinlich einfach eine Wikidata-Community, und die will sich trotz aller Bemühungen bisher nicht entwickeln. --DerMaxdorfer (Diskussion) 13:47, 14. Dez. 2021 (CET)[Beantworten]
  • Vielleicht wäre ein erster Schritt ein Bot, der ähnlich wie die WP, von einer community betrieben werden kann. Dann könnte man auch in diesem Bereich arbeitsteilig arbeiten. Es gibt die bot-Software schon, aber die installiert man entweder bei sich zu Hause oder im toollab, wo sie auch nur von einer Person betrieben wird. Ich hatte das zweite gemacht und nachdem ich keine Lust mehr hatte, waren alle von mir geschriebenen python bot-skripte nutzlos. Keine Ahnung ob es sie noch gibt, ist schon ein paar Jahre her. Goldzahn (Diskussion) 00:57, 28. Dez. 2021 (CET)[Beantworten]
  • Wie schon oben von GodeNehler wären generierte Listen aus Querys ein guter Anfang. Auch generierte Infoboxen halte ich für gut machbar. Das Problem ist aber, dass ich die Bedienung von Wikidata immer noch für zu umständlich halte. Ich schaffe es nicht mal eine Interwiki-Inkonsistenz zu beheben.--Avron (Diskussion) 08:51, 13. Dez. 2021 (CET)[Beantworten]
  • Die genannten Probleme sind gut verständlich und konkret, sie werden uns aber nicht wirklich weiter helfen. Zu Punkt 1: Ist damit in den Einstellungen / Beobachtungsliste / Erweiterte Optionen / Bearbeitungen auf Wikidata in Beo gemeint? Wenn, dann muss man da nur ein Häkchen setzen --Goldzahn (Diskussion) 21:43, 15. Dez. 2021 (CET)[Beantworten]
    @Goldzahn: Danke für die Rückfrage. Wie @WikiFreibeuter weiter oben auch kommentiert hat, geht es darum, dass Wikidata-Aktualisierungen ungesichtet in Wikipedia eingehen. Ich werde das Problem entsprechend konkretisieren. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 09:46, 5. Jan. 2022 (CET)[Beantworten]
  • Für mich höchstpersönlich ist das Haupthindernis, dass ich auf Wikidata nicht wahrnehme, dass es eine Qualitätskontrolle gibt, die mit Wikipedia, wie wir es leben (wollen), kompatibel ist. Es gäbe dafür zwar auch technische Hebel, aber ohne die Community um zumindest 90° umzupolen, wird da nichts Wesentliches zu ändern sein. … «« Man77 »» Alle Angaben ohne Gewehr. 13:55, 26. Dez. 2021 (CET)[Beantworten]
  • Mehr Wikidata gerne, aber sinnvoll. Dieses Meinungsbild zeigt exemplarisch, was für Probleme es mit Wikidata noch gibt – Qualitätskontrolle, Inkonsistenzbehebung, Inkompatibilitäten mit den Wikipedia-Sprachversionen („Buch“ vs. „Roman“) oder eben die Ansiedlung sprachspezifischer Dinge (Label, Kurzbeschreibung) an zentraler Stelle, wo sie nicht hingehören. Das große Problem ist, wie man erwünschte Daten aus Wikidata übernehmen und zugleich vermeiden kann, dass Vandalismus, Schrott und Idiosynkratisches mitübernommen werden. Ich weiß nicht, ob das hiesige Team Technische Wünsche da irgendwas machen kann. Aber dort müsste man ansetzen. Zweitens müsste der Prozess vereinfacht werden, Daten überhaupt erst nach Wikidata zu bekommen. Momentan machen das vor allem Bots, und hin und wieder greifen sie dabei richtig ins Klo. Wer in der hiesigen Wikipedia eine Einwohnerzahl in einen Artikel einpflegen möchte, sollte wiederum nicht erst nach Wikidata latschen und dort etwas eintragen müssen, das muss doch automatisch gehen, wenn schon eine Einbindung eingerichtet ist. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:01, 3. Jan. 2022 (CET)[Beantworten]

Medienupload auf Wikimedia Commons erweitern

In diesem Themenschwerpunkt würde es darum gehen, wie der Prozess rund um das Hochladen von Bildern auf Commons verbessert werden kann.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Dateien über 4GiB Größe können nicht hochgeladen werden.
  • Es gibt keine integrierten Werkzeuge für Massenuploads.
  • Es ist umständlich, beim Uploaden geeignete Kategorien zu finden.
  • Bildbeschreibungen als Alt-Text (für Blinde) können während des Upload-Prozesses nicht hinterlegt werden.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Wäre wirklich dringend nötig. Erst recht nach dem Java-Chaos, das alle Massenupload-Tools gekillt hat. Die Massendownload-Tools haben ebenfalls den Geist aufgegeben. Commons ist aktuell recht schwer aktiv benutzbar (mal ganz zu schweigen von der kaum brauchbaren Kategorienanzeige, funktionsarmen SDC-Tools, fehlender Duplikationsmöglichkeit von Kategorien usw. usf.). —DerHexer (Disk.Bew.) 00:00, 8. Dez. 2021 (CET)[Beantworten]
  • Ich würde noch ergänzen, dass das Problem Massenupload nicht erst bei mehreren hundert Dateien entsteht, sondern im Grunde schon ab 3-5 Dateien. --GPSLeo (Diskussion) 09:08, 8. Dez. 2021 (CET)[Beantworten]
    @GPSLeo: Danke für den Kommentar. Könntest du kurz erläutern, was auch schon bei 3-5 Uploads problematisch ist? Grundsätzlich gibt es mit dem UploadWizard ja eine integrierte Lösung, die mehrere Uploads gleichzeitig erlaubt. -- Danke und beste Grüße, Johanna Strodt (WMDE) (Diskussion) 12:54, 4. Jan. 2022 (CET)[Beantworten]
    Das Problem beim Wizard ist nicht die Featureliste. Das Problem sind Fehlermeldungen beim Hochladen, komplette Abbrüche an verschiedensten Stellen und ähnliches. Bei einzelnen Fotos ist das Problem geringer, da scheinbar bei jedem Foto neu ausgewürfelt wird, ob der Upload funktioniert. Ich selbst nutze den Wizard nicht mehr, aber beim Forum und der Village pump auf Commons gibt es aber regelmäßig Meldungen zu Fehlern. Und beim Phabricator natürlich auch entsprechend. Vermutlich wäre das beste die Fehler erst einmal genauer zu analysieren und dann zu gucken in wie weit ein Browserbasiertes Tool zumindest für größere Dateimengen überhaupt jemals gut und zuverlässig funktioniert. Ein zuverlässiges Browserbasiertes Tool ist aber natürlich gerade für die Gewinnung von Neuen und die Fotowettbewerbe auch sehr wichtig. --GPSLeo (Diskussion) 13:47, 4. Jan. 2022 (CET)[Beantworten]
  • Ich hab den commonisten auch für Einzeluploads verwendet, denn: Er merkt sich die letzten Einstellungen, die man gemacht hat. Gruss --Nightflyer (Diskussion) 09:37, 8. Dez. 2021 (CET)[Beantworten]
  • +1 --Lars (User:Albinfo) 12:09, 12. Dez. 2021 (CET)[Beantworten]
  • Auch wenn ich alle Vorschläge berechtigt finde, möchte ich mich hier wegen dem Barriereabbau (Alt-Texte) hierfür aussprechen. --Fan (Diskussion) 02:00, 13. Dez. 2021 (CET)[Beantworten]
  • Das Genannte wäre sehr gut. Solche Features sollten in der Tat integriert sein, kein externes Tool. Kategorisierung ist sehr wichtig, unterbleibt aber oft wegen des Aufwandes. Vielleicht ist es hilfreich, wenn man nicht nur einfach eine Kat. sieht, sondern gleich auch einen Teil des Baumes. Ziko (Diskussion) 23:13, 13. Dez. 2021 (CET)[Beantworten]
  • Zustimmung zu allen Vorrednern. Eine sehr wichtige Aufgabe! --DerMaxdorfer (Diskussion) 13:48, 14. Dez. 2021 (CET)[Beantworten]
  • Frage zu den Alt-Texten: Wie sollen sich diese denn von den Captions oder Beschreibungen unterscheiden? Oder geht es darum das Caption/Beschreibung im HTML als Alttext für die Bilder hinterlegt wird? --GPSLeo (Diskussion) 16:22, 15. Dez. 2021 (CET)[Beantworten]
    • Seeeehr gute Frage.
      • Man wälzt zwar schon gigantische Pläne, wie Hunderte von Millionen von Bildern global in ganz vielen Sprachen mit ganz doll vielen Bildbeschreibungen ausgestattet werden sollen, hat aber noch keinerlei blassen Schimmer, was da inhaltlich eigentlich drinstehen soll.
      • Den einzigen Ansatz gibt es hier durch mich, während die technischen Einzelheiten dort pure Heißluft sind.
      • Hinzu kommt, dass die Illustration durch ein Bild vom Kontext der Seite abhängt. Je nachdem, was ein eingebundenes Bild denn illustrieren und verdeutlichen soll, ergibt sich eine völlig anders fokussierte Bildbeschreibung. Damit ist aber die gesamte Idee eines global einheitlichen Beschreibungstextes gaga.
    • „Oder geht es darum das Caption/Beschreibung im HTML als Alttext für die Bilder hinterlegt wird?“
      • Um Himmels Willen.
      • Eine „Caption“ bezeichnet auch für Sehende, was abgebildet wird: „Peter Meyer, 1876“ – „Hauptportal“ – „Tucker 123 mit Aufbau für Löschfahrzeug“
      • Ein „Alt-Text“ beschreibt Menschen, die körperlich (oder ggf. technisch) das Bild nicht sehen können, was darauf zu sehen wäre: „Schwarzweißfotografie mit dem Brustbild eines Mannes. Er trägt einen weißen Vollbart, eine Brille mit runden Brillengläsern und einen Mittelscheitel bei kragenlangen glatten Haaren. Bekleidet ist er mit einem dunklen Anzug, darunter ein weißes Hemd mit Stehkragen und dünner Krawatte.“
      • Das Verfassen eines derartigen „Alt-Text“ ist eine Kunst für sich und bedürfte konkreter Anleitungen und Hilfestellung. In dem Moment, in dem ein Bild hochgeladen wird, ist der falsche Moment für solche Aktionen; das muss schnell und sicher gehen. Nett wäre, wenn wenigstens die description angegeben würde.
      • Auf Commons bedarf es eines anderen Textes description; es genügt nicht „Hauptportal“, sondern der dargestellte Inhalt muss global unterschieden werden: „Germany, Bremen-Altstadt, Mädchen-Unter-Realschule, Hauptportal, 2010“
    • VG --PerfektesChaos 15:36, 19. Dez. 2021 (CET)[Beantworten]
  • Man hatte die Hoffnung, die WMF würde im Zuge von Structured Commons endlich mal ein Augenmerk auf dieses wichtige Teilprojekt legen. Leider hat sie das nicht, nicht einmal ist Structured Commons wirklich gelungen. Dazu das weiterhin bestehende Chaos bei den Lizenzen, was es Abzockern leicht macht. Der Gipfel ist aber - wie an soooo vielen anderen Stellen auch - dass die WMF trotz dauerhafter vollmundiger Bekundungen nicht ansatzweise ein Interesse daran hat, die Beitragenden zu entlasten und zu unterstützen. Deshalb ist es dringend geboten, hier endlich aktiv zu werden. -- Marcus Cyron Come and Get It 18:52, 18. Dez. 2021 (CET)[Beantworten]
  • Übrigens, es gibt eine commons App, die aber nicht von WMF stammt. Goldzahn (Diskussion) 02:48, 19. Dez. 2021 (CET)[Beantworten]
  • Beim Massenupload von Dateien mit dem Hochlade-Assistenten steigt RAM-Verbrauch immmer sehr stark an und dann stürzt die Anwendung immer ab. Ein anderer Punkt wäre man könnte einen Auschnitt aus einem Bild auswählen und damit nach anderen ähnlichen Bildern suchen. Ein dritter Punkt ist die sehr starke Qualitätsverschlechterung von MP4-Videodateien (Originalformat meiner Kamera) ins Format .webm. Manchmal kommt es auch vor das ein Video nach dem Upload plötzlich gedreht dargestellt. Eine Vorschau- und Bearbeitungsfunktion nach dem Upload und vor der Veröffentlichung wäre dazu sehr hilfreich. --Fiver, der Hellseher (Diskussion) 21:48, 30. Dez. 2021 (CET)[Beantworten]
  • Aus Sicht eines Fotografen ist dies ein seit langem wünschenswerter Schwerpunkt. Das Hochladen von Fotos ist es, was Commons überhaupt seine Daseinsberechtigung gibt. Ich setze mich sehr für Verbesserungen in diesem Bereich ein. --Frank Schulenburg (Diskussion) 06:34, 1. Jan. 2022 (CET)[Beantworten]
  • Ich behaupte nicht ganz ohne Erfahrung: Ein Massenupload-Tool/-Skript wäre für einen technisch Kundigen relativ schnell geschrieben. Dass es solche nicht gibt bzw. sie nicht mehr funktionieren, ist eine Schande. Wenn ich hier was von „steigt RAM-Verbrauch immmer sehr stark an und dann stürzt die Anwendung immer ab“ lese, stellen sich mir die Nackenhaare auf – liest da jemand alle hochzuladenden Bilder erst mal in den Hauptspeicher? WTF? (Wobei… stromorientiertes Programmieren scheinen wir noch nicht zu haben.) O ja, da müssen Lösungen her. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:11, 3. Jan. 2022 (CET)[Beantworten]

Leichter mit Vorlagen arbeiten II

Der Themenschwerpunkt „Leichter mit Vorlagen arbeiten“ wurde 2019 zum Gewinner gewählt. Einige Projekte wurden umgesetzt, aber der Bereich Vorlagen ist so groß, dass auch noch vieles zu tun bleibt. In diesem Themenschwerpunkt würde es darum gehen, auf Basis der schon erfolgten Recherche weitere Verbesserungen umzusetzen. Vorstellbar wären beispielsweise:

  • Vorlagen leichter finden können (beispielsweise durch Filtermöglichkeiten oder vorgeschlagene Vorlagen)
  • Es leichter machen, Dateien zu Vorlagen hinzufügen
  • Parameter gruppieren und Abhängigkeiten darstellen
  • Es leichter machen, verschachtelte Vorlagen zu bearbeiten
  • TemplateData leichter bearbeiten und Fehler darin leichter erkennen
  • Im Wikitext-Modus Hilfestellungen aus TemplateData anzeigen können

Diskussion

  • Ich denke, dass die folgende Aussage, die bei den anderen Themen steht, hier auch zutreffen sollte: "Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln." Es gab zwar beim letzten Mal schon eine Recherche-Phase, aber weiß man jetzt wirklich aktuell, was von "Vorstellbar wären beispielsweise" als dringend wahrgenommen wird? --Dirk123456 (Diskussion) 00:25, 3. Jan. 2022 (CET)[Beantworten]
  • Bei der Arbeit mit Vorlagen kann es sicher verschiedene Ansatzpunkte für Hilfestellungen geben:
    • Es gibt eine Vorlage für einen bestimmten Zweck, aber jemand weiß nicht, dass es sie gibt. Keine Ahnung, was man da machen kann.
    • Es gibt eine Vorlage für einen bestimmten Zweck und man weiß auch, dass es sie gibt – nur nicht mehr, wie sie heißt. Das ging mir mal mit Vorlage:Inflation so. Keine Ahnung, was man da machen kann – semantische Suchfunktion?
    • Es gibt eine Vorlage für einen bestimmten Zweck und man kennt sie auch, will sie aber nicht benutzen, weil man sie für unnötig/veraltet/umständlich/kontraproduktiv/… hält. Kann man da technisch überhaupt etwas machen?
    • Es gibt eine Vorlage für einen bestimmten Zweck, aber sie reicht in der konkreten Situation, in der man sie gern einsetzen würde, nicht aus. Beispiel: Vorlage:Literatur oder Vorlage:Internetquelle für Literaturangaben in Sprachen mit nichtlateinischer Schrift, wenn man auch noch Umschrift und vielleicht Übersetzung angeben will (oder auch schon, wenn man das Format dessen, was die Vorlage ausspuckt, nicht leiden kann – siehe vorherigen Punkt). So was zu beheben, ist aber Aufgabe der existierenden Vorlagenprogrammierer bzw. der WP:Vorlagenwerkstatt.
    • Es gibt eine Vorlage für einen bestimmten Zweck und man will sie auch einsetzen, kommt aber mit der Vorlagensyntax oder dem Visual Editor (benutze ich nicht) oder anderem nicht klar. (In diese Kategorie fallen auch schlecht oder gar nicht dokumentierte Vorlagen, derer es in dieser Wikipedia aber zum Glück nicht so viele gibt.) Da könnte man technisch wohl sehr viel machen. Für wahrscheinlicher halte ich aber, dass einer der ersten vier Punkte die Vorlagennutzung vereitelt, denn so schwer ist das nun auch wieder nicht.
Fazit: Gerne, aber mir ist schleierhaft, was man da großartig machen kann. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:26, 3. Jan. 2022 (CET)[Beantworten]

Interaktion mit anderen Projektmitarbeitenden erleichtern

Im Wiki arbeiten viele Menschen zusammen. In diesem Themenschwerpunkt würde es darum gehen, einige der technischen Hürden zu beseitigen, die einer guten Interaktion im Wege stehen.

Bitte beachten: In diesem Themenschwerpunkt würde es nicht um das Thema Bearbeitungskonflikte gehen. Dafür steht ein anderer Themenschwerpunkt zur Wahl.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Man kann anderen nicht dafür danken, dass sie einen Beitrag gesichtet haben.
  • Es ist schwierig, alle Diskussionsbeiträge einer anderen Person zu finden.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

In diesem Fall würde ich den "Danken-Knopf" verwenden. --Hfst (Diskussion) 16:38, 1. Jan. 2022 (CET)[Beantworten]
Das sehen aber die anderen nicht. Es geht ja darum, dass einzelne Kommentare durch eine höhere “Like”-Bewertung hervorstechen und so der Nutzer ein Gefühl bekommt, welche Argumente höhere Bewertungen haben. --Berlinschneid (Diskussion) 00:10, 2. Jan. 2022 (CET)[Beantworten]
  • Wie ich schon weiter unten geschrieben habe, sollte man wirklich aufpassen, die Wikipedia-Benutzeroberfläche nicht mit Buttons zu überfrachten. Insofern halte ich das Problem, dass für Sichtungen nicht gedankt werden kann, wirklich nicht für so dramatisch, als dass da eine umständliche Lösung gebastelt werden müsste. Sollte man wirklich mal den seltenen Fall haben, für eine Sichtung danken zu wollen, kann man auch ganz altmodisch eine persönliche Nachricht schreiben. Die Personen, deren Beiträge gesichtet werden müssen, sind zudem hauptsächlich Neuautoren, und gerade für die sind die vielen Funktionen der Mediawiki-Software jetzt schon zu unübersichtlich. Das zweite oben genannte Problem halte ich zwar auch nicht für besonders dramatisch, aber es wäre schon schön, wenn sich das etwas einfacher gestalten würde. --DerMaxdorfer (Diskussion) 12:23, 15. Dez. 2021 (CET)[Beantworten]
  • Ich möchte zum einem dem Vorredner DerMaxdorfer vollinhalktlich zustimmen. Zum anderen möchte ich darum bitten den Vorschlag von Berlinschneid nicht aufzugreifen. Gerade in den sogenannten "sozialen Netzwwerken" ist ein Problem, dass die Zustimmung oder Ablehnung durch Like- oder Dislike-Buttons viel zu einfach ist. Dadurch werden in erster Linie kurzfristig Gefühle abgefragt, aber häufig keine rationalen Aussagen gemacht. Es ist gut, wenn man erst mal überlegen muss, ob und wie man etwas schreibt, mit dem man Zustimmung oder Ablehnung artikulieren will. Auf einer etwas einfacheren Ebene reicht unsere bisherige Danke-Funktion.--Lutheraner (Diskussion) 22:45, 24. Dez. 2021 (CET)[Beantworten]
  • Was mir fehlt: Ich schaue mir eine Änderung / Diff an. Da hätte ich gerne einen Knopf, mit dem ich eine Nachricht (an den Autor) zu diesem Diff erzeugen kann. Entweder wird ein neuer Abschnitt auf der Diskussionsseite des geänderten Objekts angelegt, inkl. mit einem Link auf das Diff. Oder auf der Diskussionsseite des Autors. Das ist m.E. wichtiger als ein Danken- oder gar ein Undank-knopf.--Hfst (Diskussion) 16:38, 1. Jan. 2022 (CET)[Beantworten]
  • Da gibt es etwas, was mich seit jeher nervt: Es gibt keine Möglichkeit, die Änderungen an einem bestimmten Abschnitt durchzugehen. In der Unterschieds-Ansicht (bspw. Spezial:Diff/218746662) kann man zwar zur vorherigen und zur nächsten Bearbeitung springen, aber auf (Diskussions-)Seiten mit thematisch getrennten Abschnitten, etwa Löschkandidaten oder der Relevanzkriterien-Diskussionsseite, umfasst das auch alle Bearbeitungen an anderen Abschnitten, für die man sich gar nicht interessiert. Wenn ich etwa hier ausgehend von meiner Änderung alle neueren Änderungen an diesem Abschnitt sehen will, bleibt mir nichts anderes übrig, als alle Bearbeitungen der Seite durchzuklicken, auch die an anderen Abschnitten. Insbesondere dann, wenn in einem anderen Abschnitt eine hitzige Debatte geführt wird, frisst das Zeit. Es wäre gut, wenn es einen Knopf gäbe, mit dem man zur nächsten Bearbeitung am selben Abschnitt springen kann. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:33, 3. Jan. 2022 (CET)[Beantworten]

Bearbeitungskonflikte erleichtern

Wenn ich eine Bearbeitung an einer Seite speichere, die in der Zwischenzeit von einer anderen Person aktualisiert wurde, gibt es einen Bearbeitungskonflikt. Das Werkzeug zum Lösen solcher Konflikte wurde in den letzten Jahren vom Team Technische Wünsche schon verbessert, aber es gibt immer noch Situationen, in denen das Werkzeug an seine Grenzen kommt.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Bearbeitungskonflikte erleichtern ist sicher nicht glücklich bezeichnet. Das suggeriert, Konflikte wären wünschenswert und förderwürdig. Vielleicht ist Bearbeitungskonflikte automatisch auflösen treffender?--Frühlingsmädchen (Diskussion) 13:31, 11. Dez. 2021 (CET)[Beantworten]
  • Ich bin eher dagegen. Dieses Thema wurde bereits in der jüngeren Vergangenheit bearbeitet. Die Lösung finde ich zwar nicht optimal, aber die Ressourcen sollten für andere Themen verwendet werden. --GodeNehler (Diskussion) 18:40, 12. Dez. 2021 (CET)[Beantworten]
  • Ich bim mir ziemlich sicher, dass nicht in allen Situationen eine automatische BK-Lösung möglich ist.--Avron (Diskussion) 09:11, 13. Dez. 2021 (CET)[Beantworten]
  • Ich habe manchmal einen BK, und dann zeigt mir die Oberfläche irgendwie das Andere und auch das Meine an. Normalerweise will ich, dass beides in die neue Version kommt. Aber ich verstehe nicht, was ich tun muss, damit das passiert. Selbsterklärend ist es für mich jedenfalls nicht. Ich gebe dann auf und mache es per Hand, indem ich meinen Beitrag kopiere und dann in eine neue Version per Versionsgeschichte einfüge. Ziko (Diskussion) 23:15, 13. Dez. 2021 (CET)[Beantworten]
    Herr Nachbar, ja, so lass ichs auch geschehn. --Viele Grüße, Aschmidt (Diskussion) 00:58, 14. Dez. 2021 (CET)[Beantworten]
  • Wie die Vorredner schon geschrieben haben, ist die Dringlichkeit hier nicht so wahnsinnig hoch, aber immerhin ist das ein Themenschwerpunkt, bei dem ich nicht befürchte, dass die mögliche Lösung an anderer Stelle wieder größere Probleme erzeugt. Insofern wäre es sicherlich kein Schaden, wenn hier mal an einer Weiterentwicklung getüftelt würde. --DerMaxdorfer (Diskussion) 12:25, 15. Dez. 2021 (CET)[Beantworten]
  • Hier ist eine andere Benennung notwendig. Sicherlich will keiner "Bearbeitungskonflikte erleichtern" (das wäre Vandalismus), sondern den Umgang mit Bearbeitungskonflikte erleichtern. Der früher verwendete Name für das Thema, "Bessere Lösung von Bearbeitungskonflikten", war treffender. "Bearbeitungskonflikte leichter auflösen" ginge auch. --Dirk123456 (Diskussion) 00:15, 3. Jan. 2022 (CET)[Beantworten]

Leichter mit Kategorien arbeiten

Kategorien spielen in den Wikis eine wichtige Rolle, aber der Umgang mit ihnen kann sehr umständlich sein. In diesem Themenschwerpunkt würde es darum gehen, technische Verbesserungen umzusetzen, die es leichter machen, mit Kategorien in der Wikipedia zu arbeiten.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  1. Es ist schwer, einen Überblick zu bekommen, was einer Kategorie hinzugefügt wurde und was ausgetragen wurde
  2. Beim Bearbeiten eines Artikels ist es umständlich, die passenden Kategorien zu finden und hinzuzufügen
  3. Auf Kategorieseiten werden Umlaute und Sonderzeichen nicht richtig einsortiert

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Ich finde, dass der dritte Punkt (Umlaute und Sonderzeichen nicht richtig einsortiert) viel allgemeiner ist. Er sollte nicht auf das Kategorienthema eingeschränkt sein. Ziel wäre, dass der Sortierschlüssel auf Seiten mit Umlaut oder Sonderzeichen im Titel nicht manuell und damit fehleranfällig gepflegt wird, sondern dass die Sortierung eine interne Heuristik übernimmt. Ich würde mir fast wünschen, dass die Sortierung das Oberthema ist und Kategorien dort ein Unterpunkt.--Frühlingsmädchen (Diskussion) 13:37, 11. Dez. 2021 (CET)[Beantworten]
  • in den rund 19 Jahren, die ich WP als Nachschlagewerk nutze habe ich jemals Kategorien zum suchen gebraucht. => Ich glaube der Feld-, Wald- und Wiesenleser braucht das nicht und damit sind diesbezügliche Erleichterungen nachrangig. Falls es hier auch um Commons geht schaut meine Bewertung anders aus.—Hfst (Diskussion) 09:13, 3. Jan. 2022 (CET)[Beantworten]
  • Punkt zwei finde ich sehr wichtig, es gilt aber sinngemäß das Gleiche wie bei den Vorlagen weiter oben. Mit anderen Worten, was will man da tun? Punkt eins ist was für RCler und Punkt drei ist ein technischer Schenkelklopfer, weil die Wiki-Software anscheinend keine Möglichkeit kennt, sprachspezifische Sortierlogiken festzulegen (was bessere Programmiersprachen mit diversen Locale-und-so-weiter-Mechanismen in ihren Standardbibliotheken haben). --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:39, 3. Jan. 2022 (CET)[Beantworten]
@Frühlingsmädchen Als eigenes Thema wäre „Sortierung“ für einen Themenschwerpunkt leider zu klein. Aber wenn das Problem für Kategorienseiten gelöst würde, könnte es wahrscheinlich auch auf andere Seiten angewendet werden. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 12:57, 4. Jan. 2022 (CET)[Beantworten]

Beobachtungslisten erweitern

Beobachtungslisten sind für viele Projektmitarbeitende ein zentrales Werkzeug zur Qualitätssicherung. In diesem Themenschwerpunkt würde es darum gehen, sie noch besser nutzbar zu machen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Es ist nicht möglich, konkrete Abschnitte eines Artikels zu beobachten.
  • Massenposts auf Diskussionsseiten führen dazu, dass die Beobachtungsliste unübersichtlich wird.
  • Man kann in den Einstellungen nicht festlegen, wie lange man Artikel grundsätzlich beobachten möchte (also nicht per Artikel).
  • Wenn man eine Seite auf die Beobachtungsliste setzt, werden immer die Seite und die Diskussionsseite zusammen beobachtet.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

Geht das nicht, in dem man den Filter "ungesehene Änderungen" aktiviert? --Berlinschneid (Diskussion) 19:46, 13. Dez. 2021 (CET)[Beantworten]
Nein, weil ich dann erst die in der Liste aufgeführte Seite besuchen müsste. Es wäre schön, wenn es genüge, den Listeneintrag einmal gesehen zu haben. --Frühlingsmädchen (Diskussion) 11:36, 22. Dez. 2021 (CET)[Beantworten]
@Frühlingsmädchen Dein Wunsch steht hier nicht, weil viele Probleme rund um die Beobachtungsliste genannt wurden und wir hier nur einige davon beispielhaft aufführen. Die hier genannten Probleme sind alle nur Beispiele. Das bedeutet ausdrücklich nicht, dass das von dir genannte Problem nicht dennoch angegangen werden könnte. Es ist stattdessen so, dass es im Falle, dass dieser Themenschwerpunkt gewinnt, erst eine Recherchephase geben wird, wo dann erstmal ermittelt wird, welche Probleme es gibt und welche davon am dringendsten sind. -- Johanna Strodt (WMDE) (Diskussion) 11:49, 21. Dez. 2021 (CET)[Beantworten]
(Es war der Wunsch eines anderen, mir ist nur das Fehlen aufgefallen. Danke für die Erläuterung.) --Frühlingsmädchen (Diskussion) 11:33, 22. Dez. 2021 (CET)[Beantworten]
  • Die Diskussions-Werkzeuge bei den Beta-Funktionen in den Einstellungen ermöglichen immerhin bereits (einzelne Abschnitte von) Diskussionsseiten zu verfolgen, ohne den Artikel auf der Beobachtungsliste zu haben. -- Peter Gröbner -- 07:35, 13. Dez. 2021 (CET)[Beantworten]
  • Zu den Massenposts auf Diskussionsseiten: Wenn auf einer einzigen Diskussionsseite massenhaft gepostet wird, äußert sich das nur in einem einzigen Eintrag auf der Beobachtungsliste. Wenn ein Thema über viele verschiedene Seiten gestreut wird und tatsächlich die Beobachtungsliste unübersichtlich macht, sind das meistens WMDE-Mitarbeiter, die auf 'zig Projekt- und Diskussionsseiten für ihre Veranstaltungen und Initiativen werben. Insofern eigentlich kein technisches Problem... --DerMaxdorfer (Diskussion) 12:31, 15. Dez. 2021 (CET)[Beantworten]
  • Eine Anmerkung zum vierten Problem: Sollte daran etwas geändert werden, sollte auf jeden Fall die Standardeinstellung bleiben, dass, wenn man einen Artikel auf die Beobachtungsliste setzt, auch die dazugehörige Diskussionsseite beobachtet wird (genauso natürlich umgekehrt, und mutatis mutandis gilt das auch für Projekt- und Benutzernamensraum). Schließlich gehören die Diskussionsseiten aus gutem Grund zum Artikel/zur Projektseite und beziehen sich direkt darauf, da sollte man nicht gezwungen sein, für beide Seiten einzeln auf "Beobachten" zu klicken. Und oft kommt es ja sogar vor, dass eine Diskussionsseite noch nachträglich angelegt wird und dann nicht auf der Beobachtungsliste derjenigen auftaucht, die den eigentlichen Artikel/die Projektseite beobachten. (Dass man das Beobachten dann im Nachhinein individuell für einzelne Seiten deaktivieren kann, wäre dagegen schon eine Option.) --DerMaxdorfer (Diskussion) 12:31, 15. Dez. 2021 (CET)[Beantworten]

Medieneinbindung in Artikeln verbessern

Auf vielen Wikiseiten sind Medien eingebunden. In diesem Themenschwerpunkt würde es darum gehen, einige Probleme bezüglich deren Darstellung und Platzierung zu lösen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Viele SVG-Grafiken können derzeit nicht richtig als PNG dargestellt werden
  • Es ist schwierig, Bilder an die passende Stelle im Text zu platzieren.
  • Der Abspielknopf von Videos ist so platziert, dass man das Videomotiv nicht gut erkennen kann.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

Häufige Probleme beim Editieren vermeiden

Es gibt einige typische Probleme beim Editieren, die immer wieder viel Korrekturaufwand erzeugen oder für Neulinge schwierig zu verstehen sind. Dieser Themenschwerpunkt würde sich damit beschäftigen, wie einige dieser Probleme bereits beim Editieren abgefangen werden könnten.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Es gibt eine Reihe von typischen Problemen, die speziell beim Anlegen neuer Artikel auftreten, beispielsweise fehlende Kategorien oder Normdaten.
  • Es gibt viele auf Typographie bezogene Vorgaben (z. B. schmale geschützte Leerzeichen, Anführungszeichen, …), aber es ist unklar, dass es diese Vorgaben gibt und wie man diese im Artikel umsetzt.
  • Wenn ich als Neuling einen Fehler mache, kann ich eine Seite manchmal nicht mehr abspeichern, weil ich nicht verstehe, was genau fehlt oder verbessert werden soll.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Die ersten beiden Punkte wollen die Schwelle für Neulinge höher legen (Speichersperre), der letzte will die Sperre besser erklären. Wäre es nicht nötig, zur Mitarbeit zu motivieren? Fehlende Normdaten oder Kategorien machen einen Artikel nicht unlesbar oder wertlos. Ich sofort zu, dass „Bitte wikifizieren“-Boxen nicht zur Lesbarkeit beitragen. Vielleicht lässt sich unter Seiteninformationen links im Werkzeugmenü ergänzen, was auf einer Seite noch so alles getan werden könnte, was die nächsten Schritte beim „Wikifizieren“ wären. Dann können sich neue Mitglieder dort eine Empfehlung abholen. Das Anliegen „Probleme vermeiden“ lässt sich so vielleicht angemessener umsetzen.--Frühlingsmädchen (Diskussion) 13:52, 11. Dez. 2021 (CET)[Beantworten]
  • Ich verstehe nicht, warum Normdaten und Personendaten nicht auf Wikidata ausgelagert werden. Das würde einen Großteil des ersten angesprochenen Problems schon beheben. (Die Kategorien werden von Sprachversion zu Sprachversion dafür zu unterschiedlich gehandhabt, das sehe ich ein.) --DerMaxdorfer (Diskussion) 14:07, 13. Dez. 2021 (CET)[Beantworten]
  • Was die typographischen Vorgaben angeht, sind diese in meinen Augen unterschiedlich zu beurteilen.
    • Einige angebliche dieser Vorgaben existieren in Wirklichkeit gar nicht, so ist mir nicht bekannt, dass irgendwo zum schmalen geschützten Leerzeichen geraten würde (auf Wikipedia:Typografie wird es auch nicht erwähnt). Die typographischen Vorgaben komplizierter zu machen, indem automatisch irgendwelche komplizierten Zeichen eingesetzt werden (wie etwa eben das schmale geschützte Leerzeichen), sollte auf keinen Fall Ziel der technischen Wünsche sein; entsprechend wäre mein Vorschlag, sich vom schmalen geschützten Leerzeichen komplett zu verabschieden. Wikipedia sollte zwar einigermaßen gut aussehen, aber im Unterschied zu den meisten anderen Veröffentlichungen (für die Duden-Redaktion & co. typographische Richtlinien entworfen haben) muss es auch dauerhaft unkompliziert bearbeitbar sein.
    • Anders sieht es mit typographischen Zeichen aus, für die jetzt schon eindeutige Wikipedia-Regeln existieren, an denen nicht gerüttelt werden kann oder sollte, zum Beispiel die typographischen Anführungszeichen. Eigentlich sollte es ja machbar sein, im Quelltext wie im Visual Editor bei Eingabe eines Anführungszeichen automatisch das typographisch richtige daraus zu machen (also „...“ statt "...") – ähnlich, wie das bei Word und co. ja auch der Fall ist. Allerdings weiß ich nicht, ob das typographisch "falsche" Anführungszeichen irgendwo in der Wikipedia tatsächlich richtig und benötigt ist; das müsste abgeklärt werden, bevor man die Software anweist, in Zukunft automatisch „“ zu setzen.
    • Eine dritte Gruppe von typographischen Regeln scheint mir sinnvoll zu sein, dürfte sich aber nicht sinnvoll automatisieren lassen – etwa die Unterscheidung zwischen Halbgeviertstrichen, Bis-Strichen und so weiter. Da sehe ich keine technische Lösung, die fehlerarm und trotzdem für Autoren nicht übermäßig kompliziert ist. Es wird also weiterhin Wikifanten geben müssen, die sich durch die Quelltexte des Artikelbestandes wühlen und sich um solche Kleinigkeiten kümmern. (Und wenn es diese Wikifanten irgendwann nicht mehr gibt und dann der eine oder andere falsche Bindestrich auftaucht, geht die Wikipedia davon auch nicht unter...)
So weit zur Typographie. --DerMaxdorfer (Diskussion) 14:34, 13. Dez. 2021 (CET)[Beantworten]
  • Fehlende Kategorien oder Normdaten sind kein Problem, sondern sollten tatsächlich besser den Benutzern überlassen bleiben, die wissen, was sie tun. Das Spatium ist kein Problem mehr, seit es im Visual Editor und im neuen Wikitext-Editor direkt eingefügt werden kann, auch über die Tastatur. Was fehlt, wäre eine entsprechende Funktion für die typografischen Anführungszeichen: Gänsefüßchen und Guillemets, letztere französisch, deutsch und schweizerisch, einfach und doppelt, solo und geschachtelt, händisch und automagisch. Das ist in der Tat überfällig, denn die Vorlage {{"|Ein Zitat… ist den meisten nicht bekannt und kaum vermittelbar – sie könnte aber als Grundlage für ein VE-Feature dienen. Viele Grüße, Aschmidt (Diskussion) 22:29, 13. Dez. 2021 (CET)[Beantworten]
  • Ja, was Aschmidt vorschlägt bei der Typografie. Und ein - könnte ja auch automatisch in einen Gedankenstrich umgewandelt werden, so, wie es auch bei Word geschieht. - Ein Apparat namens Artikelersteller? Wo einem Fragen gestellt werden? Etwa zu Kategorien: "Ist es eine Person?" "Durch den Beruf definiert?" usw. Ziko (Diskussion) 23:23, 13. Dez. 2021 (CET)[Beantworten]
    Also ein Kategorien-Assistent? Problem: Unsere Kategorien sind ziemlich in Bewegung, und sie sind auch zu einem Zeitpunkt t nur schwer in so ein Schema umzusetzen, das dem Assistenten zugrunde gelegt werden müsste. – Im Übrigen +1 zum Geviert-, Halbgeviert- und Viertelgeviertstrich per --- bzw. -- bzw. -. --Viele Grüße, Aschmidt (Diskussion) 01:02, 14. Dez. 2021 (CET)[Beantworten]
    Ja, wenn die Leute denn wissen, dass ein solcher gesetzt werden sollte. Viele merken den Unterschied nämlich gar nicht. (Der Geviertstrich ist im Deutschen übrigens angeblich ungebräuchlich.) --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:51, 3. Jan. 2022 (CET)[Beantworten]
  • In der mobilen Version habe ich beim Editieren Hilfe beim Formatieren, Wikilinks und Belege. Ich habe keine Hilfe zB bei der Eingabe geschützter Leerzeichen. Vielleicht ist das so aus Platzgründen? Es geht auch ohne, aber es ist recht mühsam. Zum Glück korrigiert ein Bot derartige Dinge, wenn ich keine Lust habe das per copy und paste zu machen. Eine mögliche Lösung wäre wenn man nur einen Ausschnitt der Hilfeleiste auf dem Smartphone anzeigt, diesen aber horizontal scrollen kann, um so auch die anderen Hilfen auf den Bildschirm zu scrollen. PS: Auf dieser Seite wird mobil überhaupt keine Hilfe angezeigt. Goldzahn (Diskussion) 21:47, 16. Dez. 2021 (CET)[Beantworten]
@Frühlingsmädchen Die Probleme sagen erstmal noch nichts darüber aus, wie sie gelöst werden, ob als Speichersperre oder Link in den Werkzeugen wäre hier noch völlig offen. Was da der beste Ansatz wäre, würde sich in der Recherche nach der Umfrage zeigen. -- Nochmals beste Grüße, Johanna Strodt (WMDE) (Diskussion) 13:00, 4. Jan. 2022 (CET)[Beantworten]

Versionsvergleich und Versionsgeschichte verbessern

In den Wikis ist (fast) jede jemals vollzogene Änderung über die Versionsgeschichte weiterhin einsehbar und über den Versionsvergleich nachvollziehbar. In diesem Themenschwerpunkt würde es darum gehen, Verbesserungen in diesen beiden Ansichten durchzuführen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Im Versionsvergleich ist es schwer zu erkennen, wenn Leerzeichen entfernt wurden.
  • Die Versionsgeschichten von Artikeln, die übersetzt oder aufgespalten werden, zu importieren ist technisch sehr aufwändig.
  • Bearbeitungszusammenfassungen können nach dem Speichern nicht mehr korrigiert werden.
  • Links auf Seiten, die zwischenzeitlich archiviert wurden, funktionieren nicht mehr.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • guter Punkt. Meiner Meinung nach wäre der Großteil des Problems gelöst, wenn es im Versionsvergleich stärkere Farben, statt dieses blasse gelb und blau verwendet würden. Wenn es stärkere Farben wären oder die Änderungen rot umrahmt würden im Versionsvergleich, wäre IMHO schon fast alles getan. Eigentlich wäre da aus meiner Sicht „nur“ die Farbcodierung zu ändern, wobei ich keine Ahnung habe wie einfach umzusetzen ist. --Fan (Diskussion) 02:11, 13. Dez. 2021 (CET)[Beantworten]
  • Insbesondere die ersten zwei gemeldeten Probleme halte ich für wichtige Aspekte, in denen hilfreiche Verbesserungen möglich sind. An den Problemen 3 und 4 könnte man von Entwicklerseite natürlich auch mal herumtüfteln, nur sehe ich die Gefahr, dass dann eine "Lösung" entwickelt wird, die das Bearbeiten und Nutzen des Wikipedia-Metabereichs noch umständlicher macht, egal wie responsiv und bestmöglich intuitiv sie gestaltet wird. Zum Beispiel: Natürlich ist es ärgerlich, wenn man in der Bearbeitungszusammenfassung etwas vergessen oder sich vertippt hat. Da wäre es manchmal praktisch, sie für die ersten, sagen wir, fünf Minuten noch bearbeiten zu können. Nur würde das bedeuten, dass in der Versionsgeschichte noch ein weiterer Button auftaucht und alles unüberschaubarer macht, und dass außerdem eine weitere Funktion auftaucht, die sich nicht von sich aus erklärt. Ich sehe schon die ersten Anfragen aufkommen wie „HILFEEEE! Eben konnte ich meine Zusammenfassung noch bearbeiten, jetzt aber nicht mehr!“ oder „Warum kann ich meine Bearbeitungszusammenfassung noch bearbeiten, aber meine Bearbeitung selber nicht mehr verändern?!?“ Gerade auf Neu- und Gelegenheitsautoren wirken die Möglichkeiten der Wiki-Software schon verwirrend genug (aber auch ich selbst würde so eine Funktion zum Korrigieren von Bearbeitungszusammenfassungen wahrscheinlich deaktivieren, sollte das möglich sein.) Insgesamt denke ich also, dass 3 und 4 vielleicht Probleme sind, die die mögliche Lösung nicht wert sind. Zusätzliche technische Funktionen bedeuten immer eine Verkomplizierung, egal wie intuitiv man sie einzubinden versucht. --DerMaxdorfer (Diskussion)
  • Diffs lese ich in erster Linie über Lupins Tooltip. Wenn etwas verbessert werden sollte, dann dies. Seit einiger Zeit erscheint die Rückmeldung nicht mehr, wenn man eine Seite von der Beo oder auf die Beo nimmt – ein schlechtes Zeichen, ich hoffe, das Tool bleibt uns erhalten. Viele Grüße, Aschmidt (Diskussion) 22:33, 13. Dez. 2021 (CET)[Beantworten]
  • Ich habe kürzlich den visuellen Versionsvergleich entdeckt, keine Ahnung wie lange es den schon gibt. Finde es ist damit deutlich einfacher die Diffs zu erkennen. Ich glaube das Entfernen von Leerzeichen wird damit aber auch nicht deutlich, aber die Rot-Einfärbung ohne Text gibt immerhin einen Hinweis und man muss damit nicht rumsuchen wie beim klassischen Diff, wo im Text etwas geändert wurde. Diese Sucherei im Text ist sehr ärgerlich, finde ich. PS: Bei einigen Änderungen wird rechts eine Anmerkung zu der Änderung angezeigt: Finde das sehr gut. Eventuell könnte man hier als Anmerkung "Leerzeichen entfernt", oder so schreiben. --Goldzahn (Diskussion) 22:01, 15. Dez. 2021 (CET)[Beantworten]
  • Siehe oben unter „Interaktion mit anderen Projektmitarbeitenden erleichtern“. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 14:54, 3. Jan. 2022 (CET)[Beantworten]

Wiederverwendung von Einzelnachweisen vereinfachen

Es ist viel Arbeit, Einzelnachweise zu erstellen und weiterzuverwenden. In diesem Themenschwerpunkt würde es darum gehen, diesen Prozess zu vereinfachen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • In einem Artikel auf verschiedene Stellen aus demselben Werk zu verweisen, ist umständlich und fehleranfällig.
  • Wenn man in einen Artikel einen Inhalt aus einer anderen Seiten einbindet, funktionieren die benannten Einzelnachweise <ref name="" /> nicht mehr.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • zum Einbinden von Seiten: Die Fehlermeldungen bei den Einzelnachweisen sind z.T. irreführend, das passiert auch bei Vorlagen (blöde Idee). Der richtige Weg ist die Behandlung von ref komplett zu überdenken, das Minimalziel muss aber sein eine Fehlermeldung zu produzieren, die das Problem korrekt beschreibt und so eine Lösung ermöglicht.
  • Es gibt da drei aktuelle Probleme:
    • Zum einen geht beim VE immer nur dieses merkbefreite "1", "2" etc, keine sprechenden Namen bei den <ref name="Sänger" />
    • Zum andern kann da afaik nicht ein Buch benamsen, und dann in <ref name="" /> einfach die korrekten Seitenzahlen dranhängen, d.h. Bücher müssen sehr oft sehr lang angegeben werden.
    • Zum dritten werden beim Bearbeiten einzelner Abschnitt <ref name="" /> oft als Fehler angezeigt, d.h. es wird nicht im Rest das Artikels nachgesehen, wie die denn nun aussieht.
Ob das hier alles damit gemeint ist weiß ich nicht, das fällt mir jedenfalls dazu ein. Grüße vom Sänger ♫ (Reden) 15:28, 8. Dez. 2021 (CET)[Beantworten]
  • Ich weiß nicht recht. Bei der Eingabe der Refs per visuell Editor gibt es die Option Wiederverwenden. Man klickt da eine vorhandene Quelle an und die wird dann auch hier gesetzt. Wie einfacher soll es denn noch gehen? Gut, da steht dann zB "1" als name, was nicht wirklich prickelnd ist, aber das geht schon. Ob die Funktion irgendwo nicht funktioniert, weiß ich nicht, ist mir noch nicht passiert. Macht man das dann halt per Hand. Das Problem mit den Seitenzahlen löse ich, indem ich in dem ref die Seitenzahlen aller Belegstellen einfüge. Bei einem ref mit a, b, c lauten die Seitenzahlen dann zB S. 17, 66–72 und 73–74. Mit etwas Überlegen kommt man darauf, dass a zu S. 17, b zu S. 66-72 und c zu S. 73-74 gehört. Goldzahn (Diskussion) 00:16, 13. Dez. 2021 (CET)[Beantworten]
    Gute Idee, ist halt Frickelkram. --Hfst (Diskussion) 17:01, 1. Jan. 2022 (CET)[Beantworten]
  • Es gibt seit locker 5 Jahren ein |Konzept aber WMDE bringt es nicht auf die Reihe diesen in die Entwicklung. Statt dessen wir noch eine Umfrage gemacht...--Avron (Diskussion) 09:33, 13. Dez. 2021 (CET)[Beantworten]
    @Avron Ja, es gibt ein Konzept, welches wir auch gern umgesetzt hätten. Aber es gab noch zu viele Stolpersteine, die dem im Weg standen. Uns war es wichtig, die Frage, woran wir arbeiten sollen, an die Community hier zurückzugeben, statt weiter daran zu arbeiten und dadurch die Arbeit an anderen Bereichen aufzuschieben. Erläutert wurde die Entscheidung hier. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 11:58, 21. Dez. 2021 (CET)[Beantworten]
    Lächerlich. Wenn so etwas technisch schwierig sein soll, dann sehe ich schwarz für die technische Plattform. Dann braucht WDME man auch keine Spendengelder für weitere Umfragen zu verschwenden.--Avron (Diskussion) 12:15, 21. Dez. 2021 (CET)[Beantworten]
    Ich verstehe, dass das unerfreulich und ärgerlich ist, aber wir haben nun mal (mit Unterbrechungen) einige Jahre an dem Projekt gearbeitet und können auf Basis dieser Erfahrungen mit Gewissheit sagen, dass es sehr aufwändig ist, es zu Ende zu bringen. Wir haben in diesem Jahr beschlossen, dass wir das Projekt nicht weiter mitnehmen, um die Arbeit an den anderen Projekten nicht weiter zu verlangsamen. Das muss man nicht toll finden und glücklich sind wir darüber auch nicht, aber wir finden es trotzdem richtig, dass alle hier mitentscheiden können, wo unser Fokus liegen soll.
    Ansonsten haben wir zu diesem Thema wirklich schon viel diskutiert und ich würde die Diskussion an dieser Stelle gerne beenden, damit das eigentliche Feedback zu den Themenschwerpunkten nicht untergeht. Wenn du noch weitere Anmerkungen hast, können wir darüber auf der Diskussionsseite des Wunsches weiterdiskutieren. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 09:34, 22. Dez. 2021 (CET)[Beantworten]
  • An sich ist das Wiederverwenden super simpel: Einzelnachweis heraussuchen, diesen kopieren, an passender Stelle einfügen, gegebenenfalls die Seitenzahl anpassen. Die Schwierigkeiten entstehen erst durch die bisherigen Versuche, das ganze "einfacher" zu machen ("ref name" für mehrfachen Verweis auf dieselbe Fußnote, Vorlagen und Untervorlagen, Untermenüs und Sondermenüs im Visual Editor etc.). Aber das ist ja angeblich alles einfacher, als einem Neuautoren beizubringen, dass <ref> für einen Einzelnachweis steht... Kurz gesagt: Ich sehe den Sinn dieser ganzen Weiterprogrammierungen nicht so wirklich. --DerMaxdorfer (Diskussion) 13:51, 13. Dez. 2021 (CET)[Beantworten]
  • Bisher hieß Wiederverwenden von EN: Zusammenfassen. Was es bräuchte, wäre dagegen ein Splitten und Duplizieren von Belegen, damit man sie im VE an verschiedenen Stellen in einem Artikel mehrfach erzeugen und dann nach Bedarf einfügen, befüllen und anpassen kann. Viele Grüße, Aschmidt (Diskussion) 22:36, 13. Dez. 2021 (CET)[Beantworten]
  • Einzelnachweise sind sehr wichtig, aber es macht keinen Spaß sie einzufügen, weil die Bedienung so schlecht ist. Wir sollen seitengenau unsere Aussagen nachweisen aber es gibt keine technische Unterstützung. Da war LaTeX schon vor über 20 Jahren besser. Ich wünsche mir, dass ich einen Einzelnachweis mit zwei kurzen Angaben (Buchkürzel und Seitenzahl) anlegen kann, nachdem ich das Buchkürzel mit den Details (Titel, Autor etc.) verknüpft habe.--Hfst (Diskussion) 16:53, 1. Jan. 2022 (CET)[Beantworten]
    Dafür haben Bibliografiesysteme für LaTeX bis heute Probleme mit Unicode. Na ja, BibLaTeX mit Biber scheint das ganz gut in den Griff zu bekommen, aber dann soll man eine Einreichung für irgendeine Konferenz mit deren Stylefile machen und darf dementsprechend nur das alte BibTeX verwenden, ggf. mit Natbib – aber ich schweife ab, das ist leider (auch) ein Problem der LaTeX-Community und der Konferenz-Communitites, in denen niemand Zeit und Muße hat, die zwanzig Jahre alten Stylefiles mal zu überarbeiten und an moderne Implementationen wie XeTeX etc. anzupassen.
  • Das Problem nervt mich auch hin und wieder. Klar: Man kann kopieren (viel Spaß, wenn man nach der zwölften Kopie merkt, dass man sich beim Titel vertippt hat) oder sich händisch mit HTML-Ankern irgendwas basteln. Das ist aber alles nicht nachhaltig. Den Vorrednern ist zuzustimmen, was die sonstigen Probleme betrifft (Fehler-Anzeige bei außerhalb eines Abschnitts definierten Einzelnachweisen usw.). Hinzufügen möchte ich: Bremser sind ja nicht nur die Techniker, sondern auch Leute, die ganz eigene (zum Teil fachspezifische) Vorstellungen von korrektem Zitieren haben und dann gern mal „a.a.O.“ in ihren Einzelnachweis schreiben, ohne Blick dafür, dass sich die Reihenfolge der Einzelnachweise jederzeit ändern oder ein anderer Einzelnachweis dazwischenschieben kann. Solchen Leuten müsste eine entsprechende technische Lösung entgegenkommen (etwa durch automatisches Generieren des Textes „a.a.O.“, wo er richtig ist), wenn sie nicht ohnehin der Technik viel zu sehr misstrauen, um sie zu nutzen. --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 15:03, 3. Jan. 2022 (CET)[Beantworten]

Textverarbeitung mit dem VisualEditor verbessern

Der VisualEditor soll es leichter machen, in den Wikis mitzuarbeiten. In diesem Themenschwerpunkt würde es darum gehen, einige Probleme anzugehen, die mit der Textverarbeitung im VisualEditor zusammenhängen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • Wenn ich in einem Wikipedia-Artikel auf einen anderen verlinke, erhalte ich keine Vorschau und kann nicht sehen, ob ich einen fehlerhaften Link setze.
  • Der VisualEditor generiert Quelltext, der oft nachgebessert werden muss.
  • Wenn ich an großen Artikeln arbeite, gerät der VisualEditor an seine Grenzen und wird sehr langsam.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

  • Der Visual Editor ist dafür gedacht, das Bearbeiten super easy zu machen, sodass man gewissermaßen auch von unterwegs nebenbei Artikel schreiben kann. Dass dabei dann Ungenauigkeiten und Fehler auftreten, lässt sich nicht vermeiden. In den allermeisten Fällen liegen die Fehler an den Benutzern, die man mit dem Visual Editor anlocken wollte, und an der Arbeitsweise, die der VE nahelegt. Das lässt sich durch Weiterprogrammierung am Visual Editor kaum verändern. --DerMaxdorfer (Diskussion) 13:53, 13. Dez. 2021 (CET)[Beantworten]
Sehe ich anders. Bei anderen Programmen, z.B. Word, Powerpoint, wurden immer nutzerfreundlicher. Warum soll das beim Visual Editor nicht klappen? Wenn wir mehr Autoren wollen, müssen wir den Visual Editor immer weiter verbessern. Gerade ältere Menschen, pensionierte Wissenschaftler etc., würden gerne ihr Wissen an Wikipedia weitergeben, scheitern aber oft an der Technik, wie ich aus der Wikipedia:Telefonberatung weiß. Der Visual Editor ist da die richtige Lösung, die wir aber immer weiter verbessern müssen. --Berlinschneid (Diskussion) 19:56, 13. Dez. 2021 (CET)[Beantworten]
Ob der Visual Editor oder die Quelltextbearbeitung nutzerfreundlicher sind, ist wahrscheinlich Geschmackssache, da müssen wir uns nicht streiten. (Ich persönlich habe das Gefühl, dass der Quelltext vor allem deshalb oft so überfordernd wirkt, weil er mit Programmierkram vollgekleistert wird, deren Mehrwert zweifelhaft ist: Diversen Vorlagen, geschützten Leerzeichen, etc.) Worauf ich hier hinauswill, ist aber, dass Leute, die mit der Quelltextbearbeitung überfordert sind, auch mit dem Visual Editor in der Regel keinen sauberen Quelltext erzeugen: Sie achten nicht auf bestimmte Formalien, sei es, weil sie damit überfordert sind, weil sie es nicht mitkriegen, oder weil sie es nicht interessiert. Daher halte ich es für vergebliche Liebesmüh, durch eine Weiterentwicklung des Visual Editor verhindern zu wollen, dass man den damit erschaffenen Quelltext nachbessern muss. --DerMaxdorfer (Diskussion) 13:39, 14. Dez. 2021 (CET)[Beantworten]
  • Die Vorschau bei Wikilinks auf andere Artikelseiten gibts durchaus schon. Sie liefert aber nur eine Vorschau auf die andere Seite, wenn es auf Wikidata eine Beschreibung und im Artikel selbst ein Bild gibt. Sonst steht dort nur das Lemma. Kann man also nicht im Editor lösen. Der notorisch problematische Wiki-Quelltext des VE ist bekannt und durch dessen normale Funktion bedingt, ist also ein Fehler, der im Design des Tools angelegt ist. Ich weiß nicht, ob ich wirklich möchte, dass VE besser mit sehr großen Artikeln zurechtkommt. Eher wäre das ein Zeichen dafür, dass es Zeit ist, den Artikel aufzuteilen. Viele Grüße, Aschmidt (Diskussion) 22:41, 13. Dez. 2021 (CET)[Beantworten]
  • Mich nervt, das die Visuelle Bearbeitung Verlinkungen so herstellt: [[Verlinkung|Verlinkungen]] und ich dann von anderen Benutzern in Zusammenfassungszeilen belehrt werde, dass [[Verlinkung]]en einfacher gewesen wäre (zum Beispiel hier). Dazu erhielt ich allerdings in m:Community Wishlist Survey 2019/Archive/no nowiki in Visual Editor folgende Anwort: „it is working as designed.“ -- Peter Gröbner -- 10:25, 14. Dez. 2021 (CET)[Beantworten]

Formeln und Sonderschriften unterstützen

In einigen inhaltlichen Themenbereichen ist es nötig, Formeln oder Sonderschriften zu verwenden. In diesem Themenschwerpunkt würde es darum gehen, deren Unterstützung noch weiter auszubauen.

Gemeldete Probleme, die in diesem Bereich angegangen werden könnten:

  • TeX kann nicht überall dargestellt werden, beispielsweise in Bildbeschreibungen im Medienbetrachter.
  • Hieroglyphen können nicht in der korrekten Schreibrichtung dargestellt werden.
  • Es gibt verschiedene Probleme in der Darstellung chemischer Formeln.

Falls dieser Themenschwerpunkt gewählt wird, wird es zunächst eine Recherchephase geben, um die tatsächlich dringendsten Probleme zu ermitteln.


Diskussion

...und zudem sehr sinnvoll. Sehe ich auch so. --DerMaxdorfer (Diskussion) 13:54, 13. Dez. 2021 (CET)[Beantworten]
+1. Verbesserungen bei LaTeX und chemischen Formeln wären sinnvoll. --Viele Grüße, Aschmidt (Diskussion) 22:42, 13. Dez. 2021 (CET)[Beantworten]
+1 besseres LaTeX wäre super, vllt. könnte man sich an der Stelle dann auch überlegen, ob man LaTeX in einer anderen Schriftart rendern kann, die der Standard-Wiki-Schrift näher kommt. Das ist mit teilweise als Argument dafür begegnet, TeX nicht zu verwenden... --Amateur-Wikipedianer (Diskussion) 13:05, 28. Dez. 2021 (CET)[Beantworten]
+1, und mal eine neue TeX-Version einbinden, die Unicode kann. So was sieht beschissen aus: … --2A02:8108:50BF:C694:B195:4B9C:EFB5:4CE8 15:07, 3. Jan. 2022 (CET)[Beantworten]