Wikipedia Diskussion:Umfragen/Technische Wünsche 2020 Themenschwerpunkte

message: 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)
replies: text: 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)

text: 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)
thread_title:  Datum bei hochgeladenen Dateien 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
replies: text:   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)
thread_title:  Prioritäten 

message: 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)
replies: text: Warum? Das ist doch nach kurzer Zeit nur ein Stapel Sickzettel --Bahnmoeller (Diskussion) 02:02, 6. Aug. 2020 (CEST)
thread_title:  WP:Spielwiese 

message: 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)
replies: text: +1 --Met-H(a)us-Al(le)e-M (Diskussion) 23:02, 13. Jul. 2020 (CEST)
thread_title:  Abstimmungspunkt ggf. ergänzen: Wikipedia ist so ausreichend gut wie sie gerade implementiert ist 

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

message: 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)
replies: text: 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)
replies: text: Middlemousebutton"-Klick. Mit dem Rad von der Maus klicken. Cheers, OAlexander (Diskussion) 06:06, 18. Jul. 2020 (CEST)

text: 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)
replies: text: Öffnen im neuen Fenster war bereits vor Jahren in HTML verpönt. --Bahnmoeller (Diskussion) 02:09, 6. Aug. 2020 (CEST)
thread_title:  Layout & Erscheinungsbild 

message: 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)
thread_title:  Auswahl der Themenschwerpunkte (Vorgehensweise von Dirk123456) 

message: 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)
replies: text: 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)
replies: text:  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)

text: 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)
thread_title:  Zum Abstimmungsergebnis eine Diskussion 

message: 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)
thread_title:  offene Fehlermeldungen