Wikipedia Diskussion:Umfragen/Technische Wünsche 2020 Themenschwerpunkte

Mich hat das letztes Jahr schon mit der Einschränkung auf Schwesterprojekte geärgert. Aber jetzt wieder eine Einschränkung einzubauen, statt wie früher Ideen zu sammeln und daraus das beste zu wählen, ist in meinen Augen weder zielführend noch hilfreich oder sinnvoll. Warum wird diese ehedem gute Sache in dieser Weise verschlimmbessert? -- Marcus Cyron Tell me lies, Tell me sweet little lies 17:37, 6. Jul. 2020 (CEST)

@Marcus Cyron: Ich bin nicht ganz sicher, ob ich deine Frage richtig verstehe. Darf ich zurückfragen, was du mit "Einschränkung auf Schwesterprojekte" meinst?

Die Gründe für die Arbeit in Themenschwerpunkten sind hier recht ausführlich beschrieben. Trifft das die Punkte, die du verschlimmbessert, siehst? Ich hoffe, die Pro-Argumente sind nachvollziehbar.

--Robin Strohmeyer (WMDE) (Diskussion) 12:11, 7. Jul. 2020 (CEST)

Datum bei hochgeladenen Dateien

Es betrifft zwar vor allem Commons, aber warum wird eigentlich bei hochzuladenden Dateien generell der letzte Änderungszeitpunkt als Datum automatisch übernommen? Bei einem Bild interessiert es nahezu zehn Milliarden potentielle Nutzer einen feuchten Kehrricht, wann Hugo Meier seine Bilder von der Kamera auf den Rechner koipert oder sie im besten Fall nachbearbeitet hat. Wichtig ist der Druck auf den Auslöser und dieser Zeitpunkt ist in den Exif-Daten durchaus enthalten. Ist es wirklich nicht möglich, diesen Wert zur Voreinstellung zu machen? Das Hochladedatum, das manch einer gerne als Entstehungszeit benutzen möchte, obwohl es aus dokumentarischen Gründen unwichtig ist, wird ohnehin an anderer Stelle weiter unten angegeben. Wenn bei einem alten Schwarzweißbild, wo die Leute Zylinderhüte tragen, als Datum irgendwas aus dem 21. Jahrhundert sehe, komme ich mir irgendwie veralbert vor. Bei gescannten Bildern mit chemischem Originalö ist es natürlich nicht möglich, automatisch an den Aufnezeitpunkt zu kommen, aber dafür wäre eine Erklärung am Datumsfeld hilfreich. Die Frage »welches Datum soll in dieses Feld« kommt vergleichsweise oft. –Falk2 (Diskussion) 14:48, 8. Jul. 2020 (CEST)

Der Wunsch passt auf den ersten Blick gut in das Themengebiet Bessere Unterstützung von Grafik, Audio, Video & Co. Das bedürfte aber einer genaueren Prüfung (auch bezüglich der Umsetzbarkeit), die erst nach der Umfrage passieren wird. Dazu tauschen sich dann Teams aus UX-Experten, Programmierern und Wikipedia-Aktiven sowohl onwiki als auch in anderen Formaten aus. Weitere Infos zu dem Arbeitsmodus finden sich hier und hier.--Robin Strohmeyer (WMDE) (Diskussion) 17:40, 9. Jul. 2020 (CEST)

Die kurze Antwort zur Umsetzbarkeit lautet: „Es geht grundsätzlich.” Andererseits kann ich auch nachvollziehen, warum es noch nicht gemacht wird. Das (angebliche) Datum der letzten Änderung wird beim Hochladen mit übertragen und ist neben dem Hochladezeitpunkt das einzige, was problemlos sofort zur Verfügung steht. Du denkst hier offenbar hauptsächlich an JPEG-Bilder aus aktuellen Digitalkameras, es gibt aber sehr viele Dateiformate, nicht alle haben Meta-Daten und Exif ist nur ein Format von vielen. Die Behandlung beispielsweise einfach an der Datei-Endung festzumachen, ist generell keine gute Idee. Nun laufen die Wikimedia-Server unter Linux, das eine gute Dateiformaterkennung eingebaut hat, aber die Aufgabe ist dennoch alles andere als trivial. Man muß in die Datei „hineinschauen“, anstatt sie nur zu speichern. Als erstes muß man das Dateiformat bestimmen, wenn Meta-Daten vorhanden sind, diese auslesen und dem Ergebnis kann man leider genausowenig blind vertrauen, wie dem „Datum der letzten Änderung“. Was, wenn der Mensch wenig fotografiert, der Akku immer mal wieder leer wird und es ihm zu lästig ist, die Uhr nach dem Aufladen zu stellen? Wenn ein Gerät 2004 entwickelt worden ist, hat dessen Uhr womöglich dieses Jahr als „Nullpunkt“. Automatische Plausibilitätsprüfungen kann man nur begrenzt machen, allenfalls sowas wie den 1.1.1970 aussortieren, weil das der „Nullpunkt“ aller Unix-artigen Betriebssysteme und lange vor Erfindung der Digitalfotografie ist. Wenn man es also wirklich substantiell besser machen will, erscheint mir das gar nicht so einfach. So ein „Untersuchungsprogramm“ für die Dateien belastet natürlich bei jedem Hochlade-Vorgang die Server ein wenig mehr, weiterhin wird das System komplexer und daher tendentiell mehr Fehler haben, das hat also neben dem Entwicklungsaufwand auch seinen Preis. Gut, man kann es sich im ersten Anlauf einfach machen, sich auf JPEGs mit Exif beschränken und die an den üblichsten Dateiendungen „erkennen“ und das ausgelesene Datum dann einfach mal glauben. Du wirst dann aber immer noch Schwarz-Weiß-Bilder von Anno Dazumal vorfinden, die dann eben an Stelle des Nachbearbeitungszeitpunktes den des Digitalisierens als „Entstehungszeit“ haben. --CHF (Diskussion) 04:54, 12. Jul. 2020 (CEST)

Prioritäten

Viele Wikipedianer*innen haben Interessenfelder, für die Sie sich besonders begeistern und zu dessen Instandhaltung oder Erweiterung Sie aktiv beitragen wollen

Schön, dass es mit der Geschlechtergerechtigkeit funktioniert- aber Sie wird in dem Fall trotzdem nicht groß geschrieben. --Elektronenhirn (Diskussion) 14:58, 8. Jul. 2020 (CEST)

Vor allem hält hier jetzt auch dieser zeitraubende Unsinn Einzug: Autorinnen und Autoren, Wikipedianer*innen! Ich fühle mich als Autorin nicht irgendwie zurückgesetzt, wenn hier nur von Autoren die Rede ist... Liebe Grüße--Nadi (Diskussion) 17:43, 8. Jul. 2020 (CEST)

Das Meinungsbild Geschlechtergerechte Sprache war eindeutig. Soll es hier durch die Hintertür konterkariert werden? Gruß, --Anselm Rapp (Diskussion) 17:48, 8. Jul. 2020 (CEST)

Ich habe meinen Abschnittstitel entfernt, weil ich übersehen habe, dass das Thema schon aufgegriffen wurde. Danke, Nadi, für Deine erfrischend selbstbewusste und pragmatische Aussage. (Dich könnten wir bei der Diskussion der Geschlechtergerechten Sprache brauchen!) Gruß, --Anselm Rapp (Diskussion) 19:04, 8. Jul. 2020 (CEST)

Nee, da halte ich mich lieber raus (nun ja, vielleicht schau ich mal kurz rein), zu viel zu tun - ich konnte es mir hier einfach nicht verkneifen, es nervt mich schon bei den täglichen Nachrichten usw. Grüße,--Nadi (Diskussion) 19:25, 8. Jul. 2020 (CEST)

Weise, Dich da rauszuhalten. :-) Aber wenn Du mal guckst, siehst Du, was zu dem Thema hier so abgeht, aber Dir sicher nicht abgeht. Gruß, --Anselm Rapp (Diskussion) 19:36, 8. Jul. 2020 (CEST)

Ja, das ist mir in der Tat zu viel des Guten, da braucht man ja schon Ewigkeiten, um sich da reinzulesen, überlass ich gerne den anderen und nehms halt mit Humor...--Nadi (Diskussion) 20:16, 8. Jul. 2020 (CEST)

Vielen Dank für die Hinweise − kleinere Anpassungen sind da. Weder Rechtschreibung noch Meinungsbilder sollen hier ignoriert werden.--Robin Strohmeyer (WMDE) (Diskussion) 09:30, 9. Jul. 2020 (CEST)

Ja, Meinungsbilder sollten beachtet werden. Bei jenem ging es allerdings NICHT um den Nichtgebrauch von beide Geschlechter ansprechende Formulierungen in Diskussionen usw.! – Ob der selbstverständlich anmutenden Tendenziösität und Verallgemeinerung hier werfe ich ein, dass es Frauen gibt, die entgegen Nadi2018s Empfindung ganz andere Einstellungen haben und sich eben doch in vielen Bereichen ausgeschlossen fühlen. Die auch erleben, wie sie selbstverständlich ausgeschlossen werden. Genauso gibt es Männer, die durchaus realisiert haben, was der Nichtsprachgebrauch des weiblichen Geschlechts bis heute für Auswirkungen hat; historisch manifestiert, v. a. seit der massiven Zurückdrängung von Frauen aus gesellschaftlichen Entscheidungsprozessen seit der Renaissance, enorm verstärkt und bis heute hochgehalten seit dem 19. Jahrhundert. – Nicht alle Frauen erkennen gesellschaftliche Diskriminierung durch Sprache. Nicht alle Männer erkennen gesellschaftliche Diskriminierung durch Sprache, oder wollen es nicht erkennen, oder finden den sich daraus ergebenen Vorteil prima. Nicht alle Männer sind gegen die Doppelansprache bis es endlich eine Gleichstellung, eine selbstverständliche Gleichberechtigung nicht nur per Gesetz gibt. – Von dieser Seite finde ich die Maßregelung des Technikteams ziemlich übergriffig. – Ich finde es auch schade und durchaus bezeichnend, Robin Strohmeyer, dass ihr hier ohne nachzudenken sofort zurückzuckt.--Tozina (Diskussion) 12:09, 12. Jul. 2020 (CEST)

@Tozina: Manchmal - so wie in diesem Fall - gibt es eine Variante, die unterschiedlichen Ansprüchen gerecht wird. Die neue Formulierung „Aktive in der Wikipedia“ ist meines Erachtens grammatisch geschlechterneutral. Übergriffig war die Anpassung sicher nicht gemeint und Ausschluss soll sie weder schaffen noch fortführen. Sollte ich mich hier täuschen, bitte ich um einen entsprechenden Hinweis.--Robin Strohmeyer (WMDE) (Diskussion) 11:56, 13. Jul. 2020 (CEST)

Ansicht auf Mobilgeräten

Auf Mobilgeräten ist die Mobilansicht Standard. Ich nutze aber grundsätzlich die klassische Ansicht, muß also bei jedem Artikel erst zum Fuß gehen, um dort auf Klassik umzustellen. Wenn es schon nicht möglich ist, die klassische Ansicht als Standard einzustellen, dann sollte die Auswahlmöglichkeit dafür am Kopf der Seite und nicht erst unten drunter zu finden sein. --Frau Olga (Diskussion) 09:52, 9. Jul. 2020 (CEST)

Dem kann ich mich nur anschließen. Ich verwende hauptsächlich den Desktop und wenn es einmal ein Mobilgerät ist, dann meistens ein Tablet. Ich fange mit der Mobilansicht nichts an. Gerne würde ich in meinen persönlichen Einstellungen einstellen können, dass ich immer die Desktop-Ansicht sehe, egal auf welchem Gerät. Weiß ev. jemand, ob bzw. wie das mit einem Code-Schnipsel in der common.js oder common.css geht? --Andreas (Diskussion) 22:31, 14. Jul. 2020 (CEST)

Ansicht dieser Abstimmungsseite auf meinem Smartphone Samsung S5 mini 4,5" Android 6 ist mangelhaft:

Bis vor dem "Abschnittstitel" Kurzanleitung o.k.

Das Wort "Kurzanleitung" wird links erst ab dem angeschnittenen "r" angezeigt.

In vielen Folgezeilen wird der erste Buchstabe an- oder abgeschnitten.

Bisher - bei Leden oder Edits - hatte ich keine Anzeigeprobleme am Bildschurm am Smartphone.

Lgh Helium4 (Diskussion) 10:26, 9. Jul. 2020 (CEST)

@Helium4: Das ist natürlich nicht ideal. Als Zwischenlösung: Hilft es, wenn du das Smartphone horizontal hältst? (nicht signierter Beitrag von Robin Strohmeyer (WMDE) (Diskussion | Beiträge) 15:29, 9. Jul. 2020 (CEST))

Das Problem habe ich auch, doch es scheint mit den Browservorgaben zu tun zu haben. Zumindest bei Firefox habe ich die entsprechende Einstellmöglicheit (vermutlich unter about:config) noch nicht gefunden. Die schlaumeiernden Programmierer halten ihre Mobilansicht für der Weisheit letzten Schuss. Wenn es eine Möglichkeit gäbe, der Mobilansicht durch Vorgaben durch persönliche Einstellungen im Wikisystem den Gar auszumachen, wäre das vielleicht nicht besonders sauber, aber doch ausgesprochen nützlich. –Falk2 (Diskussion) 15:09, 10. Jul. 2020 (CEST)

WP:Spielwiese

Für Nutzer der Spielwiese wäre es hilfreich, wenn nicht so häufig gemäht würde.--Mellebga (Diskussion) 19:50, 9. Jul. 2020 (CEST)

Warum? Das ist doch nach kurzer Zeit nur ein Stapel Sickzettel --Bahnmoeller (Diskussion) 02:02, 6. Aug. 2020 (CEST)

Visual Editor BESCHLEUNIGEN

Bei längeren Texten im Visual Editor braucht man schon viel Geduld und die Bedienung wird zäh wie Sirup. Schon mehrfach ist mir passiert, dass der Suchtext der mit Strg+F aufgerufenen Suchfunktion im Artikeltext eingefügt wurde, weil das Fokus-Umsetzen zur Suchfunktion so langsam ist. Grüße, --Schotterebene (Diskussion) 12:14, 10. Jul. 2020 (CEST)

Vielleicht ist hier das eigentliche Problem, daß die „überladenen Funktionen” (Editor, Medienbetrachter) die Voreinstellung und nur mit erheblichen Kenntnissen abzuschalten sind? Auf langsameren Geräten sind diese ganzen modernen „aktiven Elemente” in der Tat eher eine Quälerei. Es wäre also schön, wenn man sie einfacher deaktivieren könnte, wobei der Quelltext-Editor hier auch nicht wirklich fix ist. --CHF (Diskussion) 05:01, 12. Jul. 2020 (CEST)

Hallo --CHF, danke für die Antwort - aber eher nein: ich habe mich bewusst für den Visual Editor entschieden, nachdem ich viele Jahre den Quelltext-Editor verwendet habe. Mein Rechner ist auch kein langsames Gerät. Trotzdem ist das Editieren in einem längeren Text eine Qual.

Vorschlag: Vielleicht könnte ab einer kritischen Textmenge die Nachfrage kommen:

"Für diese größere Textmenge den schnelleren Quelltext-Editor verwenden?

[Ja] [Nein]"

Grüße, --Schotterebene (Diskussion) 08:59, 12. Jul. 2020 (CEST)

Letztere Idee sagt mir als „Schnell-Abhilfe“ zu, ist aber nicht „die“ Lösung, denke ich.

Im täglichen Gebrauch erscheint mir der Rechner, an dem ich das tippe, nicht als „langsam“, das BIOS (als Anhaltspunkt für das Alter) ist von 2009.

Mit dem „neuen“ Editor habe ich durchaus Geschwindigkeitsprobleme, die ich bisher ganz einfach darauf zurückgeführt habe, daß es eben ein vergleichsweise altes Gerät ist.

Nach Deinen Worten ist die Lage aber schlimmer: das Ding schreckt nicht nur Leute ab, die mit langsamen Geräten unterwegs sind, sondern auch die, welche lange Texte bearbeiten wollen.

Dein Vorschlag hilft nun leider auch nur der letzten Kategorie, man sollte jedoch bedenken, daß die Wikipedia ein internationales Projekt und das „langsame“ Gerät vielerorts der Normalfall ist.

Wenn man sich über „Langsamkeit“ beschwert, ist der typische Programmierer-Reflex der Vorschlag, man möge sich doch eine halbwegs aktuelle Maschine zulegen, die bekomme man gebraucht schon für das Äquivalent von (hier eine Anzahl von Tassen Kaffe im teuersten Café am Platze einsetzen).

Also kreuze ich zu dem gesamten Vorschlag mal eine Tendenz zu „Nein“ an und schließe mich Deiner anfänglichen Forderung nach Beschleunigung an.

--CHF (Diskussion) 01:01, 13. Jul. 2020 (CEST)

Vielen Dank für den Wunsch und die rege Diskussion. Das Projekt Technische Wünsche kann erst nach der Umfrage alle Wünsche im Detail auswerten und auf ihre Umsetzbarkeit hin untersuchen. Dazu tauschen sich dann Teams aus UX-Experten, Programmierern und Wikipedia-Aktiven sowohl onwiki als auch in anderen Formaten aus. Die Einladung zu den entsprechenden Formaten wird dann über den Newsletter kommen. Es wäre toll, wenn es dann, wie schon jetzt, weiter so viel Interesse und Unterstützung gäbe. --Robin Strohmeyer (WMDE) (Diskussion) 12:27, 13. Jul. 2020 (CEST)

Bitte ein Wikipediaausschnitts-Offlineprogramm en miniature zum Artikel- oder Abschnittverfassen

Irgendwo hatte ich schon mal vor langer Zeit gelesen, dass sich das jemand über eine Linux-xy selbst gebastelt hatte. Leider fehlt mir die Ahnung dafür. So ein Offlineminiaturprogramm ist aus mehreren Gründen mein Wunsch. Die drei wichtigsten: Momentan schreibe ich neue Artikel im Schreibprogramm offline und gehe zwischendurch auf die Spielwiese zur Prüfung. Doch das ist umständlich und schreibend unübersichtlich, weil man ja für Referenzen nicht mit den üblichen Fußnoten arbeiten kann. Andererseits gefällt es mir aus verschiedenen Gründen überhaupt nicht, jedes Fitzel Arbeit an einem neuen Artikel und jede Minute WP-Schreibe über Unterseiten dokumentiert zu wissen. Bei bestehenden Artikeln, die man ausbauen möchte, ist dies sowieso nicht möglich. Und bei dem Gros, dass hier belegfrei oder mit zusammengepappten (Schein)Sammelbelegen als Literaturangaben unter dem Lemma daherkommt ist es noch einmal erschwert, muss man noch mehr nachdenken, wie man etwas einbaut, ohne das Nichtbelegte zu legitimieren, oder die Zusatzinfo passt nicht in das bestehende Schema. Man muss sich schlicht mehr Zeit nehmen und auch mal aufstehen können ohne online abzuspeichern. Manchmal möchte ich einfach auch vorerst Schluss machen, um die Änderung eine Nacht zu überschlafen. Über allem hängt zudem, dass man netzseitig nicht abgeschnitten werden darf oder dass die Übertragungsrate auf einmal sinkt. Ist mir schon öfter passiert. Vor allem war es ein Riesenproblem, als ich an der laaaangen Baudenkmalliste gearbeitet hatte. Da hilft nur, mangels echter Zwischenspeicherung, immer wieder Copy&Paste in eine Textdatei auf dem eigenen PC. Letztes: Dann könnte man auch im Zug o. ä. bedenkenlos schreiben. Man kann im Haus vorab mit PDF-Inhalten oder Printmaterial dort schreiben, wo es keinen Netzempfang gibt, ohne über das eigene Schreibprogramm zu gehen. Jenseits von Honeypots oder newsgehypten Artikeln sind Bearbeitungskonflikte nach meiner Erfahrung sehr selten. – Vielleicht gibt es noch mehr Interessenten? --Tozina (Diskussion) 13:17, 12. Jul. 2020 (CEST)

Es gibt mehrere Methoden, sich das der Wikipedia unterliegende Programm auf der eigenen Festplatte recht einfach zu erstellen. Ich verwende was mit EasyPHP Das zwar schon alt ist, aber immer noch den vollen Funtionalitätsumfang anbietet. Abgesehen davon schadet es überhaupt nicht, eine "eigene WP" lokal zu haben. Da kann man dann auch alles mögliche Ansammeln, wie Zeitungsberichte, Kochrezepte, Addressen, .... - und natürlich Artikel für die WP aufbauen. Je nachdem wie weit man gehen will, kann das dann auch zur Kollaboration im heimischen WiFi oder auch geschäftlich genutzt werden. Höchst empfehlenswert! Cheers, OAlexander (Diskussion) 05:36, 16. Jul. 2020 (CEST)

Der Hinweis stimmt mich hoffnungsvoll. Dankeschön, OAlexander. Es freut mich auch zu lesen, dass noch andere dieses Bedürfnis des zeitweiligen Offline-Arbeitens haben. "Eigene WP" ;-) ... auch interessant! Allein "Ich verwende was mit EasyPHP" bringt mir leider nichts. Ich hab da keine Ahnung vom grundlegenden Basteln. @Robin Strohmeyer (WMDE): Ist das wirklich so einfach? Wo gibt es eine BastelANLEITUNG? --Tozina (Diskussion) 22:27, 17. Jul. 2020 (CEST)

Hallo Tozina,

Du bist tatsächlich nicht die Einzige, die sich ein Offline-Wikipedia-Artikel-Schreibprogramm wünscht. Sobald Du aber „Linux“ gesagt (oder geschrieben) hast, nimmst Du eine andere Abzweigung. Die Denkweise in den Unix/ Linux-, Perl-, PHP- und anderen, eher Kommando-Zeilen-lastigen Bereichen ist in einigen Punkten ähnlich, wie in der ursprünglichen Wikitext-Welt. „Easy“ kann in diesen Welten unter anderen zwei Sachen heißen:

1. das Tool ist Ressourcen-schonend, d. h., es ist auch für alte Computer leicht umzusetzen – oder/ und –
2. sehr wenig und dafür kryptischer Text hat eine weitgehende Wirkung.

In Unix/ Linux gibt es beispielsweise schon sehr lange den vi (visual interface), wo man alles über kurze Tastaturbefehle steuern kann, aber auch muss (:q beendet z. B. die Textverarbeitung). Die Ausszeichnungssprache Wikitext wahr wohl ursprünglich so gedacht: man soll mit einfachen Sachen einfache Sachen machen – und außerdem online.

Ich helfe mir damit, dass ich einen Kompromiss eingehe. Ich bereite mehr oder weniger alles erst einmal vor. Dazu lege ich eine Seite in meinem Benutzerbereich an, die ich als Baustelle deklariere. Dort nutze ich den VE (Visual Editor; WP:VE, H:VE), der eine grafische Benutzer-Oberfläche ist (GUI). Der VE arbeitet zwar auch nur online, ich kann aber jeden „Mist“ speichern, ohne dass dieser gleich in der „Produktiv-Umgebung“ landet.

Und da haben wir zwei völlig verschiedene Konzepte, was „einfach“ sein soll: mit dem vi aus der Linux-Welt kann man schnell „aus der Hüfte schießen“ und mit dem VE, der für die Wiki-Welt im aktuellen Jahrtausend entwickelt wurde, wird man ein wenig „betreut“.

Artikel-Inhalte lassen sich mit dem VE relativ direkt bearbeiten, bei Diskussionsbeiträgen sieht das anders aus. Auf denn Diskussionsseiten gibt es einige andere Interpretationen des Wikitextes, als z. B. auf Artikel-Seiten. Das betrifft vor allem die Einrückungen und Zeilenumbrüche. Daher ist der VE nicht direkt einsetzbar. Ich nehme in solchen Fällen zusätzlich ein „richtiges“ Textverarbeitungs-Programm und forme den zuvor kopierten Wikitext offline um.

Neulich hatte ich die zündende Idee, dass ich einen „Diskussionsbeitrags-Wikitext“ auch auf einer Diskussionsseite testen kann, statt auf einer Spielwiese, die „Artikel-Wikitext“ interpretiert; nämlich auf derjenigen Diskussionsseite, die meiner Baustelle-Benutzerseite zugeordnet werden kann.

Aber Vorsicht! Wenn Du abgespeicherten Wikitext kopierst, steht dort nicht mehr der Signatur-Code d'rin (vier Tilden: ~), sondern der konkret gespeicherte Signatur-Text. Deshalb schreibe ich meist MfG --~~ unten hin und hoffe, dass ich d'ran denke, zum Schluss noch zwei Tilden zu ergänzen.

Irgendwann möchte man Benutzer-Baustellen vielleicht auch mal löschen. Dazu kann – wie in „Wikipedanien“ üblich – ein kurzes, prägnantes Kommando im Wikitext an entsprechende Stelle untergebracht werden.

Das schreibe ich jetzt hier nicht direkt hin, sondern verweise auf die Vorlage-Seite (die ich gerade lange gesucht habe, weil ich den „Code-Namen“ nicht mehr wusste): Vorlage:Db-u1.

Also eigentlich kann ich auch nur hinschreiben:

• „Ich verwende da was mit Benutzerseiten, VE und einen Schreibprogramm auf meinem Computer“.

Ein Tutorial gibt es dafür nicht. Ich habe versucht, meinen prinzipiellen Arbeitsablauf einmal zu „protokollieren“ (das Beispiel betrifft eine Antwort auf einen Diskussionsbeitrag: Benutzer:Dirk123456/Baustellenbaustelle 001/Baustelle-D/Baustelle-D.10). Ob ich das selbst verstehen würde, wenn ich es nicht selbst geschrieben hätte, weiß ich nicht genau.

Ich bin also sehr interessiert, wenn Du etwas findest, was aus Deiner Sicht „easy“ ist!

MfG --Dirk123456 (Diskussion) 11:59, 18. Jul. 2020 (CEST)

Abstimmungspunkt ggf. ergänzen: Wikipedia ist so ausreichend gut wie sie gerade implementiert ist

Eventuell sollte man einen Abstimmungspunkt ergänzen: "Wikipedia ist so ausreichend gut wie sie gerade implementiert ist; man sollte eher wenig oder nichts von technischer Seite ändern." (o.ä.). So könnte man sich ein Bild machen, ob eventuell ein nennenswerter Anteil der Nutzer ggf. keine oder keine wesentlichen Änderungen mehr möchte. Durchaus sollte man m.E. gelegentlich prüfen, ob die derzeitigen Tools oder eine geplante technische Erweiterungen nicht zu einer ‚over-engineerten‘ Wikipedia führen könnten. D.h. zu viele bzw. zu komplexe Tools, die von der eigentlichen Artikel-Inhalts-Arbeit ablenken könnten. --NeptunT (Diskussion) 14:12, 12. Jul. 2020 (CEST) Ein bedenkenswerter Punkt - danke für den Hinweis --Robin Strohmeyer (WMDE) (Diskussion) 13:11, 13. Jul. 2020 (CEST)

+1 --Met-H(a)us-Al(le)e-M (Diskussion) 23:02, 13. Jul. 2020 (CEST)

Die Infobox in der französichen Wikipedia ist besser aufgebaut

In der dortigen Infobox ist die Verbindung zu Wikidata schön und differenziert vorhanden und lässt sich auch einfach bearbeiten.--Dieter123 (Diskussion) 14:13, 12. Jul. 2020 (CEST)

Das Projekt Technische Wünsche kümmert sich nicht um die Verbesserungen von Vorlagen. Diese werden von der Community geschrieben und gepflegt. Einen guten Überblick bietet dazu die Vorlagenwerkstatt.

Das Projekt Technische Wünsche arbeitet ausschließlich an Verbesserungen von MediaWiki, der Software hinter der Wikipedia und ihren Schwesterprojekten. Ich hoffe, diese Antwort hilft. --Robin Strohmeyer (WMDE) (Diskussion) 12:58, 13. Jul. 2020 (CEST)

Guter Ansatz!

Fast allen hier beschriebenen Problemen bin ich schon irgendwann mal begegnet. Jan Schreiber (Diskussion) 19:53, 12. Jul. 2020 (CEST)

Layout & Erscheinungsbild

Ein Zukunftswunsch: Design- und Layoutarbeit. Für mich als leidenschaftlicher Grafiker ist das Standard-Layout von Wikipedia für den Leser einfach nicht mehr zeitgemäß. Simples Beispiel: Klicks auf Bilder führen zur Medienseite. Ein Nutzer würde sich eine Zoombox mit lediglich wesentlichen Infos wünschen. Textaufbau und -layout wirken wie in den 2000ern stecken geblieben. Kann man da nicht mal was machen? Im Netz gibt es unzählige Designstudien und Konzepte. Gibt es da laufende Projekte und Entwicklungen hinter den Kulissen? Das mobile Erscheinungsbild gefällt mir sehr gut, die weitreichenderen Infos aus dem Desktop-Wikipedia müssten halt entsprechend implementiert werden. Soll Wikipedia zukunftsfähig bleiben und auch neue Nutzer zur Mitarbeit motivieren, ist das ein unausweichlicher Schritt. --lhen (Diskussion) 14:00, 16. Jul. 2020 (CEST)

Ein Klick auf eine Verknüpfung führt grundsätzlich zum Verlassen der Seite. Das empfinde ich als sehr ärgerlich. Es müßte doch möglich sein, daß verknüpfte Seiten sich stets in einem weiteren Tab öffnen.--Frau Olga (Diskussion) 13:43, 17. Jul. 2020 (CEST)

Middlemousebutton"-Klick. Mit dem Rad von der Maus klicken. Cheers, OAlexander (Diskussion) 06:06, 18. Jul. 2020 (CEST)

Am Tablet gibt es keine Maus. Gut, man kann länger auf die Verknüpfung drücken und dann auswählen, aber warum ist der neue Reiter nicht Standard? --Frau Olga (Diskussion) 19:13, 18. Jul. 2020 (CEST)

Öffnen im neuen Fenster war bereits vor Jahren in HTML verpönt. --Bahnmoeller (Diskussion) 02:09, 6. Aug. 2020 (CEST)

Auswahl der Themenschwerpunkte (Vorgehensweise von Dirk123456)

Hallo,

um nachvollziehbar zu machen, wie ich (Dirk123456 / Disk) bei der meiner diesjährigen Planung zur Umfrage/ Abstimmung zu den Themenschwerpunkten vorgegangen bin, habe ich das sozusagen ein wenig „protokolliert“. Ich habe eine Benutzerseite (Baustelle) angelegt und dort einige Links zu den relevanten Projekt- und Diskussionsseiten gespeichert. Danach wollte ich mir die Reihenfolge der Kandidaten vergegenwärtigen, um daraus meine Favoriten-Liste zu „basteln“. Ein Blick in die Versionsgeschichte von "Wikipedia:Umfragen/Technische Wünsche 2020 Themenschwerpunkte" zeigte mir, dass die „Startnummern“ der Kandidaten aller vier Stunden ausgetauscht wurden/ werden.

Das hat Vor- und Nachteile. Der größte Vorteil besteht darin, dass man sicherlich einen objektiveren Blick entwickeln kann, wenn man die Karten unterschiedlich mischt, als wenn immer dasselbe oben steht. Der größte Nachteil ist, dass man einen Themenschwerpunkt schwer wiederfindet, wenn er immer an unterschiedlicher Stelle steht.

Ich habe mir irgendeine Permutation heraus gegriffen, um die neun Kandidaten mit „Startnummern“ zu versehen. Es ging mir vor allem darum, für mich selbst zu wissen, was ich schon ausgewertet habe und was noch nicht. Die herausgegriffene Permutation ist die vom 9. Juli 2020 um 12:02 Uhr (siehe Version: oldid=201720271). Die neun Themenschwerpunkte (Tsp) haben die „IDs“ oder eben die „Startnummern“ Tsp-1 bis Tsp-9 erhalten.

Dann habe ich eine Art „Selbstgespräch“ geführt, wobei ich zu jeden Punkt die Pros und Kontras notiert habe. Zwischenzeitlich habe ich immer mal wieder zwei Themenschwerpunkte hinsichtlich ihrer Relevanz aus meiner Sicht miteinander verglichen. Ziel war es, ungefähr eine Hälfte der Schwerpunkte zu wählen und die andere Hälfte abzuwählen. Während ich meine Auswahl letztes Jahr eher danach getroffen habe, ob ich mir eine Verbesserung wünsche, habe ich sie dieses Jahr eher danach getroffen, ob ich eine Verbesserung für wahrscheinlich halte. Wenn ich zwei Schwerpunkte als ähnlich eingeschätzt habe, habe ich denjenigen favorisiert, der meinen Vorstellungen mehr entsprach.

Finale Auswahl

Am Ende habe ich drei Schwerpunkte ausgewählt:

• Zusammenarbeit on-Wiki leichter machen ←zur Abstimmung
• Tools leichter entwickeln und finden ←zur Abstimmung
• Fehler bei der Arbeit mit Belegen reduzieren ←zur Abstimmung

Es folgen meine Gedanken zu den Themenschwerpunkten in der Reihenfolge ihrer Kandidaten-Startnummern Tsp-1 bis Tsp-9. Die Beschreibungen, die ich kommentiert habe, findet man am besten durch den jeweiligen Link „←zur Abstimmung“.

Tools leichter entwickeln und finden (Startnummer Tsp-1) ←zur Abstimmung

Das ist ein zweischneidiges Schwert. Der Text zu „Was bedeutet das?“ spricht aus meiner Sicht etwas dagegen – vor allem wegen der Passage: „Es sollte einfacher sein, Tools zu entwickeln“. Das klingt ein wenig so, als wenn es noch mehr Tools werden sollen. Der Text zu „Kommentar Team Technische Wünsche“ spricht für den Schwerpunkt – vor allem wegen der Passage: „... geht es nicht darum ... zu reparieren, sondern um strukturelle Verbesserungen“.

Ich bin im Bereich Entwicklung für weniger Wildwuchs. Ich denke, dass Einschränkungen zwar die Motivation beeinträchtigen können, auf der anderen Seite ist die Wikipedia bereits zu komplex für ungezügelte Kreativität.

Bessere Unterstützung von Grafik, Audio, Video & Co (Startnummer Tsp-2) ←zur Abstimmung

Ich sehe dort zwei Aspekte: die eigentliche Enzyklopädie (also den Artikelnamensraum, WP:ANR) auf der einen Seite und die Kommunikation im „Backstage-Bereich“ (also auf Projekt- und Diskussionsseiten) auf der anderen Seite. Der zweite Aspekt, die Einbeziehung von verschiedenen Medien-Typen in die Kommunikation, würde vielleicht ganz gut zum Themenschwerpunkt „Zusammenarbeit on-Wiki leichter machen“ passen.

Für den ersten Aspekt, die Einbeziehung von verschiedenen Medien in Enzyklopädie-Artikel, ist vermutlich eine andere Hürde erforderlich, als für die Diskussion unter Wiki(m|p)edianerinnen und Wiki(m|p)edianern. Das „Aufmotzen“ von Enzyklopädie-Artikeln per Knopfdruck darf nicht zum Ersatz für das Schreiben von richtigem Text werden, weil es so schön bequem ist. Es besteht sonst die Gefahr, dass mehr Material im jeweiligen Artikel landet, als irgendjemand jemals überprüfen können wird.

Einfach einheitliche Typografie in Artikeln erzeugen (Startnummer Tsp-3) ←zur Abstimmung

Da halte ich nicht das allermeiste davon – glaube ich zumindest. Ich habe drei Gründe für meine Zurückhaltung ausgemacht:

• Der erste Grund für meine Zurückhaltung ist der Text „einheitliche Typografie ... erzeugen“, der für mich ein bisschen so klingt, wie „einheitliche Typografie ... erzwingen“ und
• der zweite Grund betrifft mein mangelndes Vertrauen in die Machbarkeit.
• Der dritte Grund betrifft den von mir erwarteten Aufwand. Wenn ich mich mal gedanklich neben die ersten beiden Gründe stellen würde und davon ausginge, dass die Typografie-Unterstützung so ähnlich laufen könnte, wie eine Grammatik- und Rechtschreibungs-Überprüfung in einem Textverarbeitungs-Programm (die man gegebenenfalls ignorieren oder abschalten kann), glaube ich nicht, dass andere Themenschwerpunkte für diesen zurückgestellt werden sollten.

Es ist richtig, dass nicht jeder eine Spezialausbildung auf dem Gebiet allgemeine Typografie hat – ich auch nicht. Nun ist es so, dass die Enzyklopädie Wikipedia kein Fachwörterbuch eines bestimmten, gut abgegrenzten Themenbereichs ist, sondern sozusagen das „Weltwissen“ sammelt und im hier betrachteten Fall in deutscher Sprache verfügbar macht.

Es gibt meines Wissens keine durchgängige, „weltbeschreibende“ Typografie, sondern Regeln, Konventionen und Empfehlungen für allgemeine Themen und einzeln festgelegte Regeln für einzelne Sachgebiete.

Diese einzelnen Regeln können sehr einzeln sein; in der Biologie wird beispielsweise die Kursivschrift ziemlich unterschiedlich eingesetzt – je nachdem, welcher Aspekt den Fokus hat. Der folgende, als Aufzählung gestaltete Textblock kann gegebenenfalls übersprungen werden; er dient lediglich der Demonstration von Vielfalt bei der Anwendung von Kursivschrift in der Biologie.

• Wenn es um Symbole für Gene und die zugeordneten Proteine geht,
  • werden die Gene bei Bakterien meist klein und kursiv geschrieben, die Proteine aber groß (und nicht kursiv),
  • während bei Säugetieren beide Formen groß geschrieben werden, die Gen-Symbole kursiv und die zugeordnete Form für die Proteine nicht kursiv.
    • Wenn es speziell um den Vergleich zwischen Mensch- und Maus-Genen bzw. -Proteinen geht, werden die Symbole beim Menschen oft durchgehend groß geschrieben, bei der Maus nur der Anfangsbuchstabe (z. B. Glycerinaldehyd-3-Phosphat-Dehydrogenase – menschliches Gen: GAPDH, menschliches Protein: GAPDH, Maus-Gen: Gapdh, Maus-Gen: Gapdh).
• Wenn es um taxonomische Einheiten geht,
  • werden die Gattungen und Arten häufig kursiv geschrieben, die übergeordneten Taxa aber nicht;
    • das gilt jedoch nicht immer; gerade, wenn der „vollständig qualifizierte Name“ mit Autorenschaft und dem Jahr der Beschreibung (oder der Anerkennung durch ein entsprechendes Gremium) angegeben wird, ist der eigentliche Name des Taxons meist kursiv hervorgehoben, auch wenn es einen Rang oberhalb der Gattung hat (also Familie, Klasse usw.).

Wenn mehrere Aspekte zusammen kommen, hilft es nicht viel, bei allen Kursivschrift einzusetzen, weil das dann keine Hervorhebung mehr wäre.

Welche Typografie zweckmäßig ist, hängt auch viel von den technischen Voraussetzungen ab. Bei einer Enzyklopädie, die als gedrucktes Werk erscheint, beschäftigt man sich mit dem richtigen Abstand von Seitennummern zu den Seitenrändern, in einer Online-Enzyklopädie eher nicht. Wenn nur der Schreibmaschinensatz zur Verfügung stünde, müsste die Frage, welches die „richtigen“ Anführungszeichen seien, anders beantwortet werden, als bei größerer Auswahl.

„Normalerweise“ werden im Deutschen, wenn mehrere Paare von Anführungszeichen ineinander geschachtelt werden müssen, die doppelten außen („“) und die einfachen innen (‚‘) verwendet. Ein Zitat zum Themenschwerpunkt würde auf diese Weise folgendermaßen lauten: „Und was waren nochmal die ‚richtigen‘ Anführungszeichen?“.

Wenn man diesem Satz deshalb zitieren möchte, weil es thematisch um die Anführungszeichen selbst geht, die um ein einzelnes Wort (richtigen) gesetzt worden sind, wird eine Erörterung dieses Themas schwierig, weil im Original andere Anführungszeichen verwendet wurden, als im Zitat. Nun gibt es sicher auch zu schwierigen Fällen Empfehlungen und Regeln und auch die Wikipedia selbst bietet dazu etwas an:

Enzyklopädie (Artikelnamensraum, WP:ANR; ausgewählte Artikel):

• Typografie
• Typografie für HTML
• Typografische Zeichen in XML und HTML
• Typografie für digitale Texte
• Typografische Anführungszeichen
• Anführungszeichen

Meta-Bereich (Namensräume Wikipedia und Hilfe):

• Wikipedia:Typografie

Ich habe für die Artikel-Suche die Zeichenketten typogr bzw. typograf im Visual Editor eingegeben (Menü-Punkt Link) und für die „Meta-Suche“ die gleichen Zeichenketten mit den davor platzierten Präfixen H: und WP:. Dass man sich gut mit den Namensräumen auskennen muss, um die vielen Seiten zu finden, die Kandidaten für das jeweilige Anliegen sein könnten und viel Zeit aufbringen muss, um die Information auszuwerten und zu filtern, ist ein übergeordnetes Thema und weniger eins, dass allein die Typografie betriftt. Dazu hatte ich schon mal etwas geschrieben, als es um das Schwerpunktthema „Leichter mit Vorlagen arbeiten“ aus 2019 ging (Beitrag #Leichter_finden, August 2019).

Ich denke, dass man bei verbindlichen Regeln zur Typografie in der deutschen Sprache autorisierte Stellen bemühen sollte. Der Duden beispielsweise, ist in seiner Online-Version leider mittlerweile mehr eine Werbewand, als ein Informationsportal (https://www.duden.de/). Insofern sind Seiten in der Wikipedia ein guter Anhaltspunkt, um sich zu informieren.

Allerdings sollten wir es vermeiden, richtige Typografie zu erfinden:

• „Wikipedia ist keine Quelle“ (-; steht so in der Wikipedia, sogar der Namensraum, wo das steht, heißt Wikipedia, siehe WP:WPIKQ! ;-)

Die Besonderheiten zur Typografie in weiterem Sinne, die sich aus der Darstellung dieser Online-Enzyklopädie auf verschiedenen Ebenen selbst ergeben, sind natürlich von dieser Regel, dass die Wikipedia keine Quelle ist, teilweise ausgenommen.

Das betrifft solche Fragen, ob der Visual Editor (WP:VE, H:VE) in Vorlagen (H:Vorlagen) leere Parameter stehen lassen darf, ob man „wikipedianische Sonderzeichen“ in der Normal-Ansicht lieber durch HTML-Entities oder durch nowiki-Tags (H:Tags#nowiki) entschärft und Ähnliches.

Darum scheint es aber bei diesem Themenschwerpunkt nicht zu gehen; wobei die Frage: „Wie (und wo?) fügt man etwa ein geschütztes Leerzeichen ein?“ offen lässt, ob es um die technische Verwirklichung (wie) oder um Regeln geht (wo).

Ich fände es gut, wenn einige Zeichen nicht nur als HTML-Entities im Wikitext eingefügt werden könnten (z. B. das geschützte Leerzeichen:  ), sondern auch im Visual Editor (WP:VE, H:VE). Auch zwei weitere Paare öffnender und schließender Anführungszeichen: »« und ›‹ wären nützlich. Im Visual Editor werden bisher die Paare: „“, ‚‘, “”, „”, «» und ‹› angeboten.

Unter dem Strich finde ich richtige und aussagekräftige Typografie auf verschiedenen Ebenen wichtig, glaube aber, dass bei anderen Themen bessere Aussichten auf eine erfolgreiche Umsetzung bestehen, wenn sie gewählt werden.

Zusammenarbeit on-Wiki leichter machen (Startnummer Tsp-4) ←zur Abstimmung

Das entspricht am besten einem Schwerpunkt, den ich schon bei der letzten Abstimmung (2019-06) favorisiert hätte, wenn damals der Themenschwerpunkt: „Leichter und strukturiert diskutieren“ angeboten worden wäre.

Vandalismus und destruktive Handlungen besser bekämpfen (Startnummer Tsp-5) ←zur Abstimmung

Das ist mit Sicherheit ein wichtiges Thema. Allerdings kenne ich mit der jetzigen Vandalismusbekämpfung wenig aus und kann mir deshalb nicht vorstellen, wie eine bessere aussehen soll.

Fehler bei der Arbeit mit Belegen reduzieren (Startnummer Tsp-6) ←zur Abstimmung

Wenn etwas schon ziemlich gut funktioniert, dann ist dass die „Belegen“-Funktion des Visual Editors. Insofern sehe ich keinen dringenden Handlungsbedarf. Auf der anderen Seite wird im „Kommentar Team Technische Wünsche“ auf die solide Basis hingewiesen.

Von Inhaltsänderungen erfahren, die mich interessieren (Startnummer Tsp-7) ←zur Abstimmung

Es stört mich zwar, dass es so schwer ist, alles mitzubekommen, allerdings nicht so stark, wie andere Sachen, die mit den technischen Gegebenheiten zu tun haben. Das betrifft z. B. die Schwierigkeiten, die im Gewinner-Schwerpunkt „Leichter mit Vorlagen arbeiten“ unter „Häufigst genannte Probleme“ vom Team Technische Wünsche ziemlich gut herausgearbeitet wurden.

Bessere Unterstützung von Geoinformationen (Startnummer Tsp-8) ←zur Abstimmung

Damit habe ich mich noch gar nicht beschäftigt, daher habe ich dazu kaum eine Meinung.

Hilfestellung beim Bearbeiten von Artikeln (Startnummer Tsp-9) ←zur Abstimmung

Das ist zwar ein wichtiges Thema; es wird aber darauf verwiesen, dass es bereits „einige Aktivitäten“ gibt. Mir selbst fehlt da ein wenig die Vorstellung, wie man Neuautorinnen und -autoren am besten hilft. Ich denke, das es am besten über eine gut nachvollziehbare Infrastruktur geht.

MfG --Dirk123456 (Diskussion) 17:28, 17. Jul. 2020 (CEST)

Zum Abstimmungsergebnis eine Diskussion

Hallo, jetzt wurde eine Abstimmungsergebnis mitgeteilt. Kann sein, dass ich es übersehenen habe! Aber ich hätte mir gewünscht, dass man über die statitisch 3 Schwertpunkte mit den meisten Stimmen, eine Absprache und Abstimmung gemacht worden wäre oder vielleicht gibt es zwischengeschoben noch eine Möglichkeit über die 3 ersten Plätze abzustimmen. Jetzt diesen Schwerpunkt rein statitisch festzulegen finde ich persönlich wenig gut. Dass darauf nun 2 Jahre lang schwerpunktmässig gearbeitet wird, da sollte man schon noch mal eine Zwischenstufe haben. Ich persönlich fand ja bei der Abstimmung fast alle Themen wichtig, die haben dann auch alle meine Stimme bekommen. Hätte ich gewusst, dass kein solcher Zwischenschritt erfolgt - einer "Stichwahl" derjenigen Themen, die einen bestimmten Prozentsatz überschritten haben, hätte ich wohl nur maximal 2 Themen meine Stimme gegeben. --BotBln = Botaniker in Berlin (Diskussion) 11:38, 31. Jul. 2020 (CEST)

@BotBln: Es ist natürlich schade, wenn der Abstimmungsprozess unklar ist. Eigentlich dachten wir an allen nötigen Stellen die Wahlmechanismen verlinkt zu haben. Wir werden nochmal überprüfen, ob wir den Prozess noch genauer hätten darstellen können. --Robin Strohmeyer (WMDE) (Diskussion) 00:07, 1. Aug. 2020 (CEST)

Das Abstimmungsergebnis ist hinreichdend klar:

Themenschwerpunkt	Stimmen
Bessere Unterstützung von Geoinformationen	280
Fehler bei der Arbeit mit Belegen reduzieren	228
Einfach einheitliche Typografie in Artikeln erzeugen	226

Mit dem deutlichen Abstand der ersten drei vom übrigen Feld. Signifikant ist auch der Abstand vom ersten Platz zum 2. und 3. Platz. Trotz dieses Abstandes wäre eine Diskussion angebracht, ob für so lange Zeit der Schwerpunkt, dieses Abstimmungsergebnis klar sinnvoll ist. - Aber wie ganz oben schon erwähnt wurde, ist solch Abstimmung halt schon das Problem. Aber auch wer diese Abstimmung halt rechtzeitig gefunden hat. Die Neulinge haben da wohl nicht mit abgestimmt, da wäre diese Abstimmung mit einer anderen Wichtung geendet. Auch deshalb sollte über die ersten drei diskutiert werden und geschaut werden, ob man nicht mehr für die noch nicht alt Eingessenen Wiki-Editoren auch etwas machen kann. Die würden sich vielleicht über den jetzt Platz 2 besser freuen. --BotBln = Botaniker in Berlin (Diskussion) 22:07, 3. Aug. 2020 (CEST)

Bei allem Verständnis - aber bitte nicht schon wieder. Seit fünf Jahren ist abgestimmt und versprochen, dass die Reparatur der defekt dahindarbenden Tools im Bereich Geoinformationen/OSM durchgeführt wird. Seitdem landen sie auf Grund fehlender personeller Ressourcen immer wieder auf der langen Bank und wurde von neueren Themen überholt. Dennoch drohte mit der erneuten Abstimmung 2020 eine weitere Verschiebung. Aber auch diese Hürde wurde genommen. Spätestens mit dieser Abstimmung sollte klar sein, dass das Thema jetzt endlich behandelt werden sollte. Es kann jetzt nicht sein, dass wir solange diskutieren, bis dass das älteste noch auf seine Ausführung harrende Thema aus den Umfragen der Technischen Wünsche wieder von der Agenda fliegt und neuere vorgezogen werden. Sorry, aber es gibt allen Grund dafür, dass letztere bis zur nächsten Abstimmung warten müssen. -- Tirkon (Diskussion) 13:37, 16. Aug. 2020 (CEST)

offene Fehlermeldungen

Bei den technischen Wünschen wurde der auffällige und peinliche Fehler: Punkte auf Karten liegen in der Mobil-App oft an völlig falschen Positionen detailiert beschrieben. Auch eine einfache technische Lösung (Nachschauen in einem anderen Wiki, in dem es funktioniert) ist vorhanden. Gibt es hierzu ein Fehlerticket? z.B. auf https://phabricator.wikimedia.org ? MTheiler (Diskussion) 15:37, 8. Apr. 2021 (CEST)