Das Projekt Technische Wünsche lebt vom Austausch. Alle Beiträge sind willkommen, solange sie konstruktiv sind. Das Projektteam bittet von persönlichen Angriffen oder beleidigenden Kommentaren abzusehen.
Mein grundsätzliches Problem ist das Erstellen von Artikeln. Ich habe es ein einziges Mal mit Hängen und Würgen geschafft.
Ein zweites Problem sind Editionskriege - bin ein einziges Mal in einen solchen geraten, die Gegenseite hatte eine extrem starke Lobby, so dass ich bald das Handtuch geworfen habe.
Allgemein frustrierend, Wiki Artikel zu verfassen, ich habe im Leben noch andere Dinge zu tun, als Wiki-Technik zu beherrschen. Wissen geht dadurch bei Wiki verloren.
Hallo @EUnderwood, du hast mit manchem, was du schreibst, ziemlich Recht. Wer einfach nur sein Wissen (oder ihr Wissen) in Wikipedia-Artikel schreiben möchte, ohne sich allzu sehr mit Wiki-Technik und anderem „Wiki-Drumherum“ beschäftigen zu wollen, hat es nicht leicht.
Du hat Recht damit, dass einige „Kürzel“ den vollständig ausgeschriebenen Titeln der Themenschwerpunkte entsprechen (bspw. Kürzel:„BENACHRICHTIGUNGEN“—Titel:„Benachrichtigungen“); bei anderen Schwerpunkten ist ein Unterschied erkennbar (bspw. Kürzel:„COMMONS-FINDEN“—Titel:„Medien auf Commons finden und managen“).
Auf den Umfrageseiten findest du die relevanten „Kürzel“, die du kopieren sollst (siehe ...#Themenauswahl, dort: „Abstimmen“—„Welche Themenschwerpunkte sind dir am wichtigsten?“—„1) Kopiere die Kürzel …“) nicht getrennt von den ergänzenden Titeln.
Ich habe mir in einem Textverarbeitungsprogramm kopierbare Zeichenketten gebastelt, die nur die „Kürzel“, nicht aber die ergänzenden Kurzbeschreibungen/Titel enthalten. Das Team Technische Wünsche legt Wert darauf, einzelne Themenschwerpunkte nicht von vornherein zu bevorzugen oder zu diskriminieren, weswegen bei ihrer Angabe auf der Website die Reihenfolge wechselt.
Es folgen zwei meiner selbstgebastelten Kopiervorlagen mit unterschiedlichen zufälligen Reihenfolgen der zehn Themenschwerpunkte, wobei die Trennung der „Kürzel“ zum ersten durch Kommata erfolgt und zum zweiten durch Leerzeichen:
EINZELNACHWEISE BENACHRICHTIGUNGEN KATEGORIEN SPEZIAL VANDALISMUS COMMONS-ERSTELLEN ÄNDERUNGEN MOBIL COMMONS-FINDEN MEDIEN-EINBINDEN
Wenn du möchtest, kannst du dir eine der beiden Vorlage herauskopieren und für dich bearbeiten, um die Zeichenkette im vorgesehenen Feld zu platzieren und mit dem zugehörigen Schaltknopf zu bestätigen:
Ort: ...#Themenauswahl, dort: „Abstimmen“—„Welche Themenschwerpunkte sind dir am wichtigsten?“—„2) … und trage sie in das Textfeld ein.“
Feld für die Eingabe: „PRIO1, PRIO2, PRIO3, PRIO4, PRIO5 (max. 5)“
Schaltknopf: „übernehmen und weiter“
Wenn alles geklappt hat, findest du auch deine Zeichenkette auf der Seite für Stimmabgaben:
Deine Stimmabgabe entspricht dann deiner gesendeten Zeichenkette als Überschrift eines Abschnitts. Da die Überschrift mehrdeutig sein kann, findest du deinen Abschnitt am ehesten dadurch, dass du nach deiner Unterschrift suchst, nämlich indem du deinen Benutzernamen bei der „Suche“-Funktion deines Webbrowsers eingibst.
Du kannst dann deine Überschrift, also deine Stimmabgabe, nachträglich bearbeiten. Du könntest natürlich auch vorher mal bei .../Stimmabgaben vorbeischauen, um dir die die Struktur dort vor Augen zu führen.
Ich hoffe, dass ich die mit meiner „Von einem Benutzer für einen Benutzer“-Information weiterhelfen kann.
Eine gewisse Hürde bei der Auswahl bildet vielleicht doch die zufällige Anordnung der Themenschwerpunkte, die stündlich wechselt, sodass man beim Auswählen eines Namens nicht wirklich nochmal schnell den Bedeutungsinhalt nachschlagen kann, bspw. per Verknüpfung, um zur passenden Beschreibung zu gelangen.
Selbst wenn es egal sei, welche der Namenselemente eines Themenschwerpunktes jemand für die Auswahl verwendenden wollte, muss diejenige oder derjenige, die oder der abstimmen möchte, irgendwie vorher die Beschreibungen gelesen haben, um zu wissen, dass bspw. „ÄNDERUNGEN“ (oder „Änderungen nachvollziehen“) sich auf Bearbeitungsversionen im Kontext Versionsgeschichte / Logbücher / Zusammenfassungszeilen u. ä. bezieht und nicht auf etwas anderes (bspw. auf dynamische Websites, auf Termine usw.).
Die verschiedenen Benennungen eines Themenschwerpunktes, die man bei einer Auswahl verwenden könnte:
nur das „Kürzel“ (Beispiel „ÄNDERUNGEN“)
oder das „Kürzel“ plus Ergänzung in der Kopiervorlage (Beispiel „ÄNDERUNGEN Änderungen nachvollziehen“)
oder nur die Ergänzung zum „Kürzel“ als eine Art „Titel“ (Beispiel „Änderungen nachvollziehen“)
oder eine passende Überschrift auf der Diskussionsseite hier (Beispiel „ÄNDERUNGEN – Änderungen nachvollziehen“),
Ich habe versucht, das mit dem Wort „Kürzel“ zu erklären (12:24, 30. Nov.) und dafür ein anderes Wort gegenübergestellt, nämlich „Titel“.
Wenn das mit dem „Kürzel“ aber weiterhin Schwierigkeiten bereiten würde, warum sollte dann das behelfsmäßig eingeführte Wort „Titel“ einfacher sein? Ist es denn leichter, den unauffälligen Schriftzug „Änderungen nachvollziehen“ zu kopieren als den auffälligeren, nämlich „ÄNDERUNGEN“? Keine Ahnung, vielleicht ist es tatsächlich am einfachsten, „ÄNDERUNGEN Änderungen nachvollziehen“ zu kopieren. Ich weiß es nicht.
Aus meiner Sicht besteht das größere Problem darin, dass man die Beschreibungen und die jeweils passenden Schlüsselwörter nicht „festhalten“ kann, da sie stündlich die Reihenfolge ändern.
Deshalb habe ich mir eine zufällige Reihenfolge der Beschreibungen auf eine eigene Benutzer-Unterseite kopiert und dann „weiterarbeitet“. Ich hatte mir dabei eine Tabelle erstellt, in welcher u. a. die „Kürzel“, die Ergänzungen („Titel“) und die Links zu denjenigen Überschriften vorlagen, unter denen die kopierten Beschreibungen standen. Nach und nach habe ich das „eingedampft“, indem ich aus der ursprünglichen Tabelle kleinere gemacht habe, nämlich durch das Löschen von Zeilen mit denjenigen Themenschwerpunkten, die aus meiner Sicht weniger relevant waren als die stehengeblieben.
Nach mehreren Durchgängen dieser deduktiven Vorgehensweise hatte ich eine Tabelle mit fünf Punkten und der Angabe einer Reihenfolge. Diese Tabelle sortierte ich mit einem Tabellenkalkulationsprogramm, um dann die Spalte mit den Kürzeln zu kopieren. Die Kürzel habe ich dann mit einem Textverarbeitungsprogramm in das gewünschte Format gebracht. Die resultierende Zeichenkette habe ich letztlich „gepostet“ (Wikipedia:Umfragen/Technische Wünsche 2024#Anleitung => „2) … und trage sie in das Textfeld ein.“ => „übernehmen und weiter“).
Letzter Kommentar: vor 11 Tagen16 Kommentare10 Personen sind an der Diskussion beteiligt
Ich habe ja ganz ernsthaft vorgehabt, hier mit abzustimmen, aber meine Beiträge beschränken sich offenbar auf eine Ebene, die gar nicht gemeint ist. Mit anderen Worten: ich habe keine Probleme. Ich verstehe aber in dem Beitrag von Johanna Strodt zu den Kategorien (s.u.) auch kein Wort. Ist doch auch ganz schön, wenn einer mal keine Probleme hat, oder - --Urs.knecht (Diskussion) 12:17, 26. Nov. 2024 (CET)Beantworten
Der von dir genannte Beitrag ist von WikiBayer [1] oder meintest du einen anderen? Freut uns jedenfalls, dass du beim Editieren keine Probleme hast :) Falls dir doch noch einfällt, dass du bei einem der Themen gerne Verbesserungen sehen würdest, kannst du noch bis zum 09.12. abstimmen @Urs.knecht! --Johannes Richter (WMDE) (Diskussion) 18:49, 26. Nov. 2024 (CET)Beantworten
Hallo, die Wikipedianer haben doch ganz eindeutig abgestimmt, dass in der deutschen Wikipedia bis auf weiteres nicht gegendert werden soll. Warum lese da jetzt etwas von „Urheber*in“? Bitte lasst uns doch auch auf Projektseiten an unsere Richtlinien halten. „Urheber“ ist die korrekte generische Form. Vielen Dank! --Geek3 (Diskussion) 20:32, 26. Nov. 2024 (CET)Beantworten
Hallo Geek3, die unter Wikipedia:Generisches Maskulinum genannten Richtlinien gelten in der Form nur für den Artikelnamensraum (und ein paar weitere Namensräume, wie z.B. Kategorien). Zitat: "Außerhalb des Artikelnamensraums, zum Beispiel im Benutzernamensraum, können alle die Sprache verwenden, die sie bevorzugen, auch typografische Lösungen für geschlechtssensible Sprache".
Also ich würde mir ja mal wünschen, daß in der angeblich deutschsprachigenWikipedia eben endlich auch mal bevorzugt Deutsch zum Einsatz kommt, wenn immer das möglich ist. Also so daß Fremdwörter (und zudem allgemeiner entsprechende Fremdbezeichner), wie Diskussion, technisch (siehe dazu, also zur Wortherkunft, ggf. auch im Wikiwörterbuch unter Technik), Kommentar(e, hier also wohl am treffendsten die Anmerkungen) und hier im Folgenden u.a. auch dieser uralte, ja ewiggestrige VANDALISMUS-Unsinn (nebenher bemerkt, soweit mir das bekannt ist, ursprünglich mal eine Benennung der alten Römer (also damals, im römischen Reich), gegenüber einem ihrer feindlichen Nachbarvölker, auf dem Gebiet wo heute/gegenwärtig wohl hauptsächlich Deutschland liegt, siehe auch Vandalen(Dauerverweis) und, vom [Haupt-]Bezeichner her noch immer völlig unübersetzt, Germania magna,(Dauerverweis) daher hier nun also, zudem in die Gegenwartssprache weiter übersetzt „Großdeutschland, zur Zeit der Römer“), eben auch mal vernünftig (hierher) übersetzt werden. Damit (also mit einer entsprechend weitergehenden Übersetzung) könnte sich dann auch diese Veranstaltung hier dann mal erledigt haben (falls das denn überhaupt gewollt ist; immerhin gibt es ja auch immer wieder [Mit?-]Menschen, die meinen, daß alle Menschen gleich seien und wir daher doch besser im [weltweiten] Friede-Freude-Eierkuchen-Land leben sollten). Mit lieben Grüßen. -- 77.188.89.14910:52, 27. Nov. 2024 (CET)Beantworten
Es entbehrt nicht einer gewissen Ironie, dass jemand, der andere ewiggestrig nennt, weiterhin "daß" schreibt, was seit rund 30 Jahren nicht mehr aktuell ist.
Aber um uns mal auf die oberste Ebene von Graham's Hierarchy of Disagreement zu heben: die Worte Vandalismus, Technik und Diskussion mögen ihren Ursprung in anderen Sprachen haben, aber das gilt unter anderem auch für das Wort "Deutsch". Und der Umstand ändert nichts daran, dass sie allesamt in die deutsche Sprache übernommen wurden, mit einer wohldefierten, wenn auch möglicherweise gegenüber ihrer ursprünglichen Verwendung gewandelten Bedeutung. Und mit übernommen meine ich nicht nur von Regelwerken wie Duden, sondern auch von den Menschen, die die Sprache im Alltag nutzen. Es steht dir frei, statt "Diskussion" ein anderes Wort zu bevorzugen, aber es ergibt keinen Sinn, dass ein konsistent verwendeter, allgemein bekannter und korrekt verstandener Begriff gegen ein anderes Wort ausgetauscht wird, um irgendeiner individuellen, idealistischen aber unpraktikablen Weltanschauung zu entsprechen.
Sprache ist ein Werkzeug zur Verständigung und wird dadurch zum Bestandteil der Kultur. Sie ist kein gutes Werkzeug zur aktiven Modellierung von Wunsch-Kulturen. -- Chris (Diskussion) 13:02, 27. Nov. 2024 (CET)Beantworten
Na bloß gut, daß man so eine (fremde) Kultur hier (so wie diese seltsam anmutend vorgelebte Art der „deutschsprachigen“ Wikipedia hier) auch nicht mehr (so wie in früheren Zeiten, als es bspw. noch eine Wehrpflicht gab) mitmachen muß. Übrigens hat das (scharfe) ß durchaus auch weiterhin seine Berechtigung, gleichgültig was unsere lieben (vorgeblichen) Rechtschreibräte (je nach Lust und Laune, oder wo eben gerade die Fahne so hinwehte) daraus gemacht haben (siehe dazu ggf. auch mal unter Lautschrift, was nichts, aber auch gar nichts mit einer ewigen Gestrigkeit zu tun hat, im Gegensatz zu eigentlich völlig überholten Fremdwörtern, so wie eben auch diese Kultur). -- 77.188.89.14913:28, 27. Nov. 2024 (CET)Beantworten
Technisch super unschön, dass man Text copy&pasten soll, selber noch Kommas dazwischensetzen soll, und das alles in ein kleines Textfeld, wenn man eingentlich eine Prioritätenliste anlegen will. Hier wäre ein simples Formular mit Checkboxen für "welche interessieren mich überhaupt" und dann eine Box daneben/drunter, in der man die Auswahl priorisieren kann, indem man die Einträge hoch und runter zieht, sehr wünschenswert, um nicht breite Kreise der Adressaten der Umfrage auszuschließen. Insbesondere diejenigen, die "Editieren ist mir generell zu umständlich" in die Diskussion getragen hätten, würden wahrscheinlich sich nicht die Mühe machen, auf ihrem (potentiell mobilen) Endgerät wiederholt "Paste", (scroll, select,) "Copy", (scroll, Cursor platzier) ",",… durchzuziehen.
Auch finde ich eine Blaue box mit Begriffen drin, die im Fließtext hintereinander weglaufen, sehr unstrukturiert und hätte mir eine Tabelle oder ein zumindest eine Aufzählungsliste gewünscht. MüllerMarcus (Diskussion) 13:31, 27. Nov. 2024 (CET)Beantworten
Hallo @MüllerMarcus, danke für die Rückmeldung! In der Tat wären Checkboxen oder ähnliche Optionen, wie man sie aus externen Umfragetools kennt, schön – aber innerhalb einer Wikiseite nicht gut machbar. Und sobald man anstatt einer onwiki-Abstimmung ein externes Tool nutzt, nimmt die Community-Beteiligung erfahrungsgemäß deutlich ab. Wir haben uns aber dein Feedback notiert und schauen für die nächste Umfrage, was wir technisch vielleicht doch verbessern können. --Johannes Richter (WMDE) (Diskussion) 12:23, 28. Nov. 2024 (CET)Beantworten
Vielen Dank für die Antwort, @Johannes Richter (WMDE)! Ich teile da deine Meinung hundertprozentig – ein externes Abstimmungstool kann da nicht die Lösung sein.
Aber etwas pointiert angemerkt, dies ist die Abstimmung für "wie können wir mittels technischer Maßnahmen die deutschspragie Wikipedia besser machen, dafür sammeln wir technische Wünsche". Wenn der Umfang der technischen Möglichkeiten, die uns dazu zur Verfügung stehen, aber kein Javascript-haltiges Template beinhaltet (und das darf ja gerne nichts anderes tun als ein bisschen GUI auf Browserseite anzeigen für alle mit Javascript aktiviert, und dann die Liste in der aktuellen Form in das Textfeld einfügen), dann darf man sich als externer Beobachter schon fragen, wer denn dann hinterher die im erarbeiteten technischen Wünsche in Lösungen umsetzen kann, bzw. die die Umsetzung durch Freiwillige fachlich koordinieren kann. --MüllerMarcus (Diskussion) 12:40, 28. Nov. 2024 (CET)Beantworten
In die Richtung haben wir auch schon gedacht. Das wurde früher als nicht so gut abgetan, weil es auch Menschen gibt, die Javascript im Browser deaktivieren, aber wäre vermutlich eine Option, die wir uns für kommende Umfragen anschauen. Die internationale Community Wishlist der WMF nutzt inzwischen auch ne ganze Menge Javascript, z.B. beim Formular für Wunscheinreichungen. --Johannes Richter (WMDE) (Diskussion) 13:58, 28. Nov. 2024 (CET)Beantworten
Das Problem war (auch), dass es bis vor Kurzem keine Möglichkeit gab, JavaScript seitenbezogen zu laden (also ähnlich dem von dir genannten javascript-haltigen Template). Inzwischen ist das aber mit einem kleinen Umweg möglich. -- hgzh08:16, 29. Nov. 2024 (CET)Beantworten
Eine Option, die noch niemand erwähnt hat wäre, dass man über unterschiedliche Wege abstimmen kann: Wer ohne Javascript unterwegs ist und Wikisyntax mag, kann gerne wie bisher abstimmen und gleichzeitig gibt es eine anderen Weg mit mehr Usability. Bei vielen politischen Wahlen gibt es auch mehrere Optionen: Man kann vor Ort oder per Brief abstimmen. Ich persönlich bin für alles offen und mache alles mit. --Fan-vom-Wiki (Diskussion) 15:32, 29. Nov. 2024 (CET)Beantworten
Die Kompliziertheit der Umfrage scheint mir ein besonders passendes Beispiel für den grundsätzlichen Wiki-Reform- und Vereinfachungsbedarf bei Regeln, Technik, Hilfsprogrammen etc. --Rundstef (Diskussion) 11:16, 29. Nov. 2024 (CET)Beantworten
Ich frage mich dann, warum man nicht einfach die Liste der Kürzel neben dem Textfeld aufführt, so daß man nicht scrollen muß, um sie zu suchen, sondern sie alle im Blick hat, um sie rauszukopieren. --Kersti (Diskussion) 15:16, 7. Dez. 2024 (CET)Beantworten
Letzter Kommentar: vor 3 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich bin in der Wikipedia-App über einen Beitrag auf meiner Disk auf die Abstimmungsseite gekommen. Meine App ist im dunklen Modus. Bei Schritt 2, wo man die Schwerpunkte eintragen soll, ist das nicht gut zu erkennen.
Erstens ist das Textfeld, in das man eintragen soll, sehr klein in der Höhe.
Zweitens sieht das Textfeld durch den Platzhalter-Text und die Formatierung wie ein nicht bearbeitbares <tt> Element mit Beispiel-Inhalt aus. Dass es sich schon um das Textfeld handelt, ist optisch nicht gut zu erkennen. Ich habe bestimmt 5x über das vermeintliche Beispiel hinweg gescrollt, bis ich gemerkt habe, dass es das besagte Textfeld ist. Ergo: Das Textfeld sollte mehr nach einem Textfeld im gewohnten Stil aussehen bzgl. Randfarbe, Schriftfarbe, Größe, Schriftart, usw.
Und drittens ist die Schriftfarbe des Textfeldes auch im dunklen Modus schwarz, und hat somit keinen Kontrast zur Hintergrundfarbe der Seite. Wenn ich anfange, in das Feld zu tippen und der graue Platzhaltertext verschwindet, ist das Feld optisch leer.
Welche Ironie, dass mein 1. Schwerpunkt MOBIL sein wird, wo mein stärkstes Anliegen der "Support für dunklen Modus in der App" sein wird, der in der de-WP mit ihren unzähligen hartkodierten Farben in Tabellen und Vorlagen nämlich noch sehr ausbaufähig ist. -- Chris (Diskussion) 12:40, 27. Nov. 2024 (CET)Beantworten
Hallo @LWChris, nur um sicherzugehen: Du redest von der Android-App, richtig? Die können wir in unserem MOBIL-Themenschwerpunkt leider nicht behandeln, weil die Wikimedia Foundation aktiv an den Android- und iOS-Apps arbeitet. Stattdessen würde sich unsere Arbeit auf die mobile Browserversion (de.m.wikipedia.org) fokussieren. Wir schauen uns nochmal an, wie wir die Umfrageseite besser an den mobilen Darkmode anpassen können. --Johannes Richter (WMDE) (Diskussion) 12:20, 28. Nov. 2024 (CET)Beantworten
Hi, ja, ich spreche von der App. Naja, trotzdem finde ich dass WP im mobilen Bereich noch zurückhängt. Es kann nicht schaden, irgendwas zu machen, das die Nutzung von WP auf kleinen Bildschirmen verbessert, denn die Probleme, die de.m hat wird die App auch haben. -- Chris (Diskussion) 17:45, 15. Dez. 2024 (CET)Beantworten
Es gibt ein sehr unwahrscheinliches Paradox im Wahlsystem. Problembeschreibung: Umseitig steht: „Im Falle von Gleichstand bei den zwei Kandidaten mit den wenigsten Stimmen wird die Anzahl der Zweitplatzierungen ausgewertet, um zu einer Entscheidung zu kommen.“ Angenommen es besteht ein Gleichstand bei den zwei Themenvorschlägen Thema1 und Thema2. Nehmen wir weiter an, dass der Großteil so abgestimmt hat, dass totaler Gleichstand entstanden ist und zwei Accounts Account1 und Account2 das Zünglein an der Waage seien: Account1 stimmt „Thema1, Thema2“ und Account2 stimmt „Thema2“ (weitere Themen von Account2 sind bereits ausgeschieden oder es wurde nur für dieses ein Thema gestimmt). Nun hätte das Thema2 gewonnen. Das Paradox besteht darin, dass die Entscheidung durch Account1 zustande gekommen ist, obwohl Account1 eigentlich für das andere Thema ist. Das ist widersinnig. Es wird ja auch der Eindruck vermittelt, dass man mit Zweit- bis Fünftstimme der Erststimme nicht schadet. 1. Lösungsvorschlag: „Im Falle von Gleichstand bei den zwei Kandidaten mit den wenigsten Stimmen wird die Anzahl der Zweitplatzierungen der Accounts, die nicht für eine der gleichstehenden Kandidaten stimmen, ausgewertet, um zu einer Entscheidung zu kommen.“ Allerdings zeigt das umseitige Beispielvideo einen Fall, der mit meiner Lösung nicht passt, da alle Accounts an einem Gleichstand zwischen drei Themen zeigt. Am Ende sind das alles Grenzfälle, die sehr sehr unwahrscheinlich sind. Theoretisch ist sogar ein Gleichstand in der letzten Runde möglich – was wird dann gemacht? Aufgrund der komplexen oder nicht lösbaren Fälle, lautet mein 2. Lösungsvorschlag, der den ersten Lösungsvorschlag ersetzt: „Sollte es zu einem Gleichstand von Erststimmen kommen (was äußerst unwahrscheinlich ist), entscheidet das Team Technische Wünsche, wie damit weiter verfahren wird.“ Ich weiß nicht, ob WP-Aktive im Techn.-Wünsche-Team abstimmen oder nicht. Wenn nicht, kann ich persönlich gut damit leben, dass sie dann das Zünglein an der Waage sind. Sollten sie es aber tun und so zum Gleichstand beigetragen haben, vermute ich, dass sie so viel Größe haben bei Gleichstand zu reflektieren, dass sie durch die Arbeit sowieso schon einen größeren Einfluss auf die Techn. Wünsche haben und dann ihren eigenen Wunsch etwas zurückstellen können. Beste Grüße --Fan-vom-Wiki (Diskussion) 23:19, 27. Nov. 2024 (CET)Beantworten
Ich finde das ehrlich gesagt nicht paradox. Im Fall wo Thema 1 gewinnt, würde nur "1,2" den Erstwunsch bekommen, im Fall von Thema 2 bekommt "2" den Erstwunsch und zusätzlich "1,2" den Zweitwunsch. Insofern maximiert die Wahl von Thema 2 die Menge an berücksichtigter Zustimmung laut Wahlergebnissen. Oder habe ich etwas falsch verstanden, was die Prämisse "totaler Gleichstand bei den Übrigen" angeht? --Chris (Diskussion) 08:25, 28. Nov. 2024 (CET)Beantworten
Account 1 hat mit seiner Zweitstimme seiner Erststimme geschadet. Das ist paradox. Genau das soll ja aber verhindert werden. Die ganzen Seiten zur Wahl klingen so, dass man mit Zweit- bis Fünftstimme nicht der eigenen Erststimme schaden würde. --Fan-vom-Wiki (Diskussion) 08:59, 28. Nov. 2024 (CET)Beantworten
Danke für diesen interessanten Grenzfall. Tatsächlich könnte es in diesem Szenario dazu kommen, dass es dann besser gewesen wäre, nur seinen absoluten Favoriten anzugeben. In allen anderen Fällen dürfte es aber besser sein, mehrere Favoriten anzugeben, für den Fall, dass die Hauptpräferenz früh rausfliegt und man somit wenigstens unter den anderen Themen auch noch mitentscheiden kann. Basierend auf den Erfahrungen der letzten Umfragen denke ich aber nicht, dass wir uns darüber groß Gedanken machen müssen.
Zu deinem Lösungsvorschlag: Diejenigen aus unserem Team, die wie ich auch als Ehrenamtliche aktiv sind, stimmen natürlich nicht mit ihrem Ehrenamtsaccount bei unserer eigenen Umfrage ab. Wenn wir in der Auswertung sehen, dass es überraschend zu diesem Grenzfall kam, könnte man im Notfall immer noch über eine Stichwahl nachdenken oder so ;) --Johannes Richter (WMDE) (Diskussion) 12:12, 28. Nov. 2024 (CET)Beantworten
Letzter Kommentar: vor 16 Tagen6 Kommentare2 Personen sind an der Diskussion beteiligt
Ich finde diesen Ansatz aus einigen wenigen Themenschwerpunkten zu wählen nicht besonders optimal. Zumindest finde ich die jeweiligen Beispiele fast ausnahmslos schlecht, d.h. relativ trivial/unwichtig während es etliche viel wichtigere Issues gibt, die teils schon seit einem Jahrzehnt ungelöst sind. Ich verstehe auch nicht wieso man hier einen Prozess hat der scheinbar komplett parallel zur Community Wishlist stattfindet – warum wird die meta:Community Wishlist nicht genannt und verlinkt und z.B. Vorschläge darin genannt/verlinkt?
Ich tue mich schwer z.B. für "Mobil" zu stimmen wenn ich die Beispiele schlecht finde und es stattdessen wichtig finden würde wenn etwa auf Commons endlich die Datei Kategorien angezeigt werden (Wunsch #1 des Commons Tech Surveys) oder man bei breiten Tabellen den Bildschirm rotieren könnte. Heißt denn eine Stimme für einen Themenschwerpunkt, dass man die jeweiligen Beispiele supported? Finde hier das zweite Beispiel nämliche nicht wichtig und das erste wäre mit einem Button um alle Sektionen auszuklappen besser gelöst wofür es ja bereits eine Funktionalität gibt (nur der Button fehlt).
Ich finde dass technische Entwicklung das ist was bei Wikimedia zurzeit am meisten gebraucht wird und die technischen Wünsche, phab Issues, und Community Wishlists sind fast nutzlos wenn es kaum Kapazitäten gibt um diese auch umzusetzen. Konkrete umsetzbare Vorschläge wie man das ändern kann so dass mehr technische Probleme behoben und nützliche Features eingebaut werden habe ich hier vorgestellt.
Die Technische-Wünsche-Umfrage wurde 2013 von der deutschsprachigen Community initiiert und von Wikimedia Deutschland fortgeführt. Die internationale Umfrage der Wikimedia Foundation ist nach unserem Vorbild entstanden und setzt inzwischen (wie wir bereits seit 2019) auch auf Themenschwerpunkte. Hintergrund ist, dass sich dadurch größere Verbesserungen angehen lassen, als wenn man lauter Einzelwünsche zu ganz verschiedenen Themen bearbeitet.
Wie in jedem Jahr bedeutet die Wahl der Themenschwerpunkte aber nicht, dass dann die Beispiele umgesetzt werden – die dienen erstmal nur der Inspiration für unsere vorgeschlagenen Themenschwerpunkte. Nach erfolgreicher Wahl führen wir dann Befragungen und Nutzungstests durch, um die Probleme im gewählten Themenschwerpunkt besser zu verstehen und zu ermitteln, was wir innerhalb des Themenschwerpunkts priorisiert angehen sollten. Dabei wirkt die Community also erneut daran mit, im Zweifel auch ganz andere Probleme innerhalb des Themenschwerpunkts zu bearbeiten, als die beispielhaft genannten.
Mit dem WMF-Team der Community Wishlist stehen wir natürlich in enger Abstimmung, auch um zu vermeiden, dass wir doppelte Arbeit machen. Letztendlich ist dies aber wie gesagt die Umfrage der deutschsprachigen Community, insofern kann es auch sein, dass hier Wünsche thematisiert und dann von uns bearbeitet werden, die vielleicht anderssprachigen Communities weniger wichtig sind.
Viele deiner verlinkten Gedanken teile ich persönlich. Das richtet sich aber primär an die WMF, als WMDE haben wir darauf wenig Einfluss.
2. Ich finde es nicht optimal bzw etwas problematisch wenn es eine parallele Wunscheinreichung der deutschsprachigen Community gibt anstatt das mit der Community Wishlist zu kombinieren denn so fehlen dort Wünsche aus der ersten und v.a. umgedreht fehlen dann hier viele. Man kann die dortigen Wünsche ja transkludieren bzw verlinken und so ein separates Subset oder Bewertung das spezifisch für die deutschsprachigen Community ist erstellen. Ich finde keine Beispiele aus der Wishlist (d.h. sie sind zumindest nicht verlinkt). Zudem finde ich keine Liste der Vorschläge bzw der infragekommenden sondern nur die wenigen Beispiele. Der Wunschparkplatz enthält ja nur einen Vorschlag und der ist für 2026. "Umfrage 2024" verlinkt nur auf die technische Wünsche Seite und die enthält ja keine solche Liste.
3. Das klingt gut. Es wäre gut wenn man bei den Themenschwerpunkt-Votings beachtet dass ein relativ unwichtiger/nicht-dringlicher Themenschwerpunkt mehr Stimmen bekommen kann wenn die Beispiele gut sind und ein wichtiger Themenschwerpunkt weniger Stimmen wenn die Beispiele nicht besonders gut sind. Diese Problem kann man wahrscheinlich irgendwie mildern, etwa indem man stets hochsupportete Vorschläge nennt.
4. Wie beschrieben kann man die Bewertung von der zentralisierten Eintragung (inkl Diskussionsseite) separat durchführen. Jedenfalls sehe ich hier weder Links zu Community Wishlist Vorschlägen noch eine Liste von möglich bearbeitbaren Vorschlägen die auch aus der CW gespeist wird.
5. Das stimmt. Die WMDE könnte diese Vorschläge aber ebenfalls umsetzen, also z.B. einen Banner über eine Kampagne zur (freiwilligen) open source Entwicklung von MediaWiki Issues oberhalb von Artikeln in Kategorie:Software anzeigen.
2. Wir arbeiten mit den Wünschen wie gesagt etwas anders als die WMF Wishlist. Dass wir keine Wünsche explizit verlinken und überhaupt nur wenige Beispiele nennen, liegt daran, dass Wünsche für unsere deutschsprachige Umfrage primär zur Inspiration für Themenschwerpunkte dienen und die eigentliche Recherche, welche Probleme tatsächlich angegangen werden, erst nach der Wahl beginnt. Wie gesagt haben wir dieses Jahr sämtliche offenen Wünsche aller vergangenen Technische-Wünsche-Umfragen ausgewertet, sowie sämtliche offenen Top20 Wünsche aller vergangenen Community-Wishlist-Surveys, außerdem eben aus zahlreichen weiteren Quellen Wünsche zusammengetragen. Der Wunschparkplatz enthielt unzählige Wünsche, die wir Anfang November ins Archiv geschoben haben [2], auch die wurden alle ausgewertet. Zu dieser Auswertung haben wir eine interne Übersicht, die auch für künftige Umfragen laufend erweitert wird. Sämtliche bereits analysierten und noch offenen Wünsche können also auch in künftige Umfragen einfließen, ohne nochmal genannt werden zu müssen. Dabei verzeichnen wir insbesondere auch, wenn Wünsche wiederholt in der deutschsprachigen Community und international auftauchen.
3. Das ist ein guter Punkt. Welche Beispiele besonders attraktiv klingen und welche weniger, lässt sich natürlich nicht immer so leicht sagen, aber auch deshalb haben wir sowohl schriftlich als auch mündlich vorab Feedback von der Community eingeholt und daraufhin sowohl die Formulierungen der Themenschwerpunkte, als auch viele Beispiele nochmal überarbeitet.
4. Wie gesagt haben wir bis auf die paar Beispiele gar keine Liste mit Problemen/Wünschen präsentiert, an der Stelle arbeiten wir anders als die Community Wishlist, auch mit dem Vertrauen der deutschsprachigen Community, dass wir hinterher gutes user research durchführen.
5. Das Thema mehr Menschen zur open source Entwicklung anzuregen, ist tatsächlich auch bei WMDE auf dem Schirm. In die Richtung gehend haben wir z.B. bei der WikiCon einen (noch recht allgemein gehaltenen) Vortrag gehalten [3] und schauen mal, was wir 2025 in die Richtung angehen können. Die Banneridee gefällt mir, auch wenn sie natürlich etwas Vorarbeit bräuchte, wie auch die Diskussion in meta:Talk:Campaigns#Campaign proposal: tech development campaign zeigt, denn die interessierten User bräuchten natürlich entsprechende Handreichungen, Hilfestellungen usw. um dann auch tatsächlich starten zu können.
Ich weiß nicht was "ausgewertet" in der Praxis bedeutet wenn diese Vorschläge nirgendswo aufgelistet oder genannt werden. Aktuell scheint mir als ob man die vielen Phab Issues und EN Wishlist Vorschläge nicht einbezieht aber womöglich passiert das dann ja nachdem die Themenschwerpunkte ausgesucht wurden.
Als Anmerkung dazu: ich denke nicht dass Nutzer die Themenschwerpunkte unbedingt gut oder gemäß ihrer Meinung bewerten können wenn die entsprechenden Vorschläge fehlen, da die Wünsche ja erst kommunizieren was noch fehlt oder nicht funktioniert (wie etwa die Anzeige von interaktiven Charts oder mobil die Anzeige von Kategorien). Ohne diese kann man oder viele sich kaum ein Bild davon machen bei welchen Bereichen noch viel fehlt.
Nur die Top 20 Wünsche der Wishlists auszuwählen finde ich sehr wenig. Zudem hat die aktuelle/neueste Wishlist kein Voting also vermute ich dass die dortigen Wünsche überhaupt nicht berücksichtigt werden/wurden.
Diese Archivseite scheint nirgendwo bzw nicht deutlich verlinkt. Wie soll man sie finden und woher soll man wissen dass sich dort diese Vorschläge befinden...zudem sind diese auch nicht in die Themenschwerpunkte kategorisiert und wie gesagt scheinbar nicht mit der globalen Wishlist kombiniert (z.B. dort inkludiert und der dortige Vorschlag darunter verlinkt).
Es wäre womöglich gut auf dieser Seite (oder zukünftigen) zu Erwähnen dass man auch für andere Beispiele stimmen kann. Auch in diesem Fall nicht unbedingt eine gute Methodik wichtige und/oder gutklingende Beispiele für Themengebiete zu finden um den Themengebiet eine optimale/faire Chance zu geben. Vermutlich noch wichtiger wäre es auf der Themenschwerpunktvoting-Seite klar zu machen dass das nur Beispiele sind und statt den Beispielen auch oder nur anderes umgesetzt werden könnte, dann sind die Beispiele auch nicht ganz so wichtig.
4. Ich denke online könnte man deutlich mehr Menschen erreichen und zum Mitmachen bewegen, v.a. wenn es nicht nur ein Banner ist der auf eine Infoseite verlinkt sondern eine motivierende interessante Seite mit Gamification Elementen wie Leaderboard gelöster Issues, Liste interessanter Vorschläge die man umsetzen könnte (nicht zu schwierig aber für viele nützlich), Mitmach-Badges, Chat, usw. Bezüglich Hilfestellungen könnte es einfach einen IRC Kanal, einen Matrix Chat, und eine Diskussionseite geben wo Nutzer Fragen stellen bzw. bei Problemen Hilfe bekommen können falls es bei oder nach dem schrittweise beschriebenen Setup (am besten mit Video) um zu starten irgendwelche Probleme gibt. Das meiste davon existiert bereits. IRC Kanäle gibt es zB bereits sowie mw:How to become a MediaWiki hacker#Set up your development environment usw.
Wir sammeln sämtliche Wünsche, die uns über verschiedene Kanäle begegnen, in einem internen Tool. Dort vermerken wir u.a. wo sie aufgetaucht sind (z.B. Community Wishlist Survey 2022), wann der Wunsch später erneut aufkam, ob es dazu bereits Phabricatorlinks gibt usw. Anbei ein Screenshot aus der relativ unsortierten Tabellenansicht. In der späteren Analyse zur Identifikation unserer möglichen Themenschwerpunkte schauen wir uns die Wünsche noch anders geordnet an. CW + Jahreszahl im Screenshot steht jeweils für eine Community Wishlist survey.
Die neue Wishlist haben wir in der Tat bewusst nur am Rande angeschaut (bloß darauf untersucht, ob sich dort bereits bekannte Wünsche wiederholen), weil erstmal die WMF mit allen dort frisch eingereichten Wünschen arbeiten sollte und wir sowieso schon eine riesige Zahl an Wünschen hatten.
Das Wunschparkplatz-Archiv ist auf WP:Technische Wünsche/Wunschparkplatz unter "Probleme, die für vorherige Umfragen notiert wurden" verlinkt. Für unsere Zwecke reicht das, weil wie gesagt kein Voting über einzelne Probleme stattfindet und diese sowieso nur der Inspiration dienen. Aus dem gleichen Grund ist eine explizite Verknüpfung des Wunschparkplatzes mit der Community Wishlist auch nicht soo wichtig für uns, sondern wäre eher nice to have.
Letzter Kommentar: vor 16 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt
Der Schutz der Beitragenden und des Projektes steht definitv an erster Stelle, zumal es in Zukunft durch den nachvollziehbaren teilweisen Verlust der IP-Adressen sowieso etwas schwieriger wird.--ᵂᶦᵏᶦᴮᵃʸᵉʳ👤💬Skripte ︱ Rechte ︱ GitLab10:16, 26. Nov. 2024 (CET)Beantworten
Inwiefern machen die temporären Konten das schwieriger? Ganz im Gegenteil, wenn es da Vandalismus gibt, kann man unbesorgter Sperren als bei IP-Adressen. Der Schutz der Beitragenden ist in meinen Augen eher ein soziales als ein technisches Problem, was die technischen Wünsche angeht daher eher nachrangig. -- Perrak (Disk) 20:04, 27. Nov. 2024 (CET)Beantworten
"unbesorgter Sperren als bei IP-Adressen" Du verwechselst hier Schülerspielereien mit richtigen Vandalismus. Klar kann man so gegen Schüler vorgehen ohne größeren Schaden anzurichten, aber bei Trollen usw. muss man immer die IPs abfragen und diese auch sperren. Trolle können die Temporären Konten bewusst nutzen um nicht aufzufallen. OK, geht mit IPs zwar auch, ich hatte letztens z.B. einen Fall, das ein Troll innerhalb 3 Tagen mit über 100 IP-Adressen aktiv war, das ist aber deutlich schwieriger. Außerdem helfen IP-Adressen und Informationen auch zu identfizieren (vor allem in Sprachenversionen deren Sprache man nicht beherrscht.) --ᵂᶦᵏᶦᴮᵃʸᵉʳ👤💬Skripte ︱ Rechte ︱ GitLab22:27, 2. Dez. 2024 (CET)Beantworten
Letzter Kommentar: vor 10 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt
Es wäre sehr nützlich wenn man in Diffs die Änderungen von Bots ausblenden könnte. Ich möchte nicht meterlang scrollen und ein unübersichtliches Diff durchgehen wo an jeder Ecke und zwischen den Inhaltsänderungen irgendwelche Kleinigkeiten geändert wurden weil ein paar Bots irgendwelche Einzelnachweis-Parameter eingefügt haben usw. Das Ausblenden von AWB Edits wäre ebenfalls praktisch. Ohne diese Änderungen in der Watchlist & Diffs könnten mehr Änderungen viel effizienter und angenehmer durchgegangen werden. Siehe "A way to filter edits by Citation bot, InternetArchiveBot and OAbot from diffs". --Prototyperspective (Diskussion) 00:24, 4. Dez. 2024 (CET)Beantworten
Eine Filterfunktion, die erlaubt, die Versionsgeschichte nach geänderten Abschnitten zu filtern, z. B. im Städteartikel nur die Änderungen zum Abschnitt „Bürgermeister“ anzeigen; oder einzelne Autoren aus der Versionsgeschichte des Artikels filtern; oder die Liste der Benutzerbeiträge filtern nach Namensräumen: Artikel, Diskussion, etc. oder nach einem oder mehreren Stichworten, die in der Liste vorkommen. --Brühl (Diskussion) 14:59, 8. Dez. 2024 (CET)Beantworten
Abschnitte könne umbenannt werden und Inhalte darin z.B. aus dem Abschnitt woanders hin verschoben, dann dort geändert, und wieder zurückverschoben werden – das macht es sehr schwierig diesen Vorschlag umzusetzen auch wenn er nützlich wäre .Es gibt das WhoWroteThat Tool das man ggf stattdessen nutzen kann. --Prototyperspective (Diskussion) 19:46, 8. Dez. 2024 (CET)Beantworten
@Lupe weitere Wünsche, dir wir übermittelt bekommen haben, waren z.B. ein neuer Button, um auf die Desktopversion zu gelangen (nicht nur am Seitenende) oder die Verbesserung der Galerieansicht, die im mobilen Browser (wenn das Handy im Hochformat ist) oft nicht gut aussieht. Denkbar wäre auch, Funktionen des erweiterten Modus breiter zugänglich zu machen, sodass mobile Leser*innen z.B. die Versionsgeschichte einfacher sehen können. --Johannes Richter (WMDE) (Diskussion) 18:49, 26. Nov. 2024 (CET)Beantworten
Ich würde mir Geo-Koordinaten in der mobilen Ansicht wünschen. Darstellung von Tabellen ist verbesserbar. Gut wäre da zum Beispiel Zoomen (Schriftgrößenänderung) per Fingergeste. Torsch (Diskussion) 13:39, 27. Nov. 2024 (CET)Beantworten
Wenn man auf einer geschützten Seite mobil auf den Edit-Button oben rechts drück, wird
unten eingeblendet, das die Seite geschützt ist (Schwarzer Balken)
im Balken auf Link "Quelle Anzeigen"
Meldung dass Editor geladen wird (Neue Seite) und es passiert nichts, da ich die Seite ja gar nicht bearbeiten darf.
dort muss man auf Link "Seite neu laden" (und wissen, das dass die Lösung ist.)
dann wird der Quellentext angezeigt (Neue Seite)
und dort dann auf Seiteschutzlogbuch anzeigen drucken
im Seitenschutzlogbuch runter scrollen und dann weiß ich erst, warum die Seite geschützt ist.
Ich wechsele also 3 mal die Seite, nur um zu wissen, warum die Seite geschützt ist. Dabei eine irreführende Fehlermeldung unter 2. Eine Möglichkeit wäre, den schwarzen Balken (1) und den Editor in 2 zu streichen. Dann würde mit Klick auf Editbutton oben rechts direkt der Quelltext angezeigt wenn die Seite gesperrt ist, genauso wie auf Desktop.
Mobil gibt es leider viele so kleine Ärgernisse, die sich zwar umgehen lassen, aber nur wenn man weiß wie es geht. Ich denke, für MOBIL wäre vor allem wichtig, bestehende Funktionen gründlich zu testen, damit so was auffällt und korrigiert werden kann. Die meisten sind nun mal auf Desktop unterwegs, und Leser auf Mobil melden hier sich sicher nicht. Deswegen fällt so was nicht auf. Zumindest meine Vermutung.
Großer Punkt wäre auch, Vector 2022 so anzupassen, dass er unabhängig von der Bildschirmbreite nutzbar ist, also sowohl auf Desktop wie Smartphone. Dann könnte nur noch ein Skin gepflegt und mit Minerva auch dessen Wartung und Fehlerbehebung wegfallen. Das dürfte aber zu viel für die Technischen Wünsche sein.
Ich wünsche mir eine komplette Navigation der mobilen Seite für Blinde. Das heißt eine Suche mit gesprochener Lemmaausgabe und der Option den Artikel vorlesen zu lassen. Alle Eingaben und Navigation per Sprache. Nach dem Bookmark dieser (Einstiegs-)seite sollte man ohne berühren des Displays ans Ziel, den vorgelesenen Artikel, kommen. --Conny09:44, 2. Dez. 2024 (CET).Beantworten
Ich wünsche mir eine Möglichkeit, in welcher Form auch immer, mit der sich alle automatisierten Botmeldungen abschalten lassen. Leider gibt es bisher nur Opt-out-Angebote, aber selbst an diese halten sich nicht alle Botbetreiber. --JasN (Diskussion) 14:45, 30. Nov. 2024 (CET)Beantworten
Wie vieles andere Probleme in der DEWP auch wird das in der ENWP bereits gemacht. Dort wird diese VOrlage auf der Diskussionsseite des Autors hinterlassen: en:Template:Afd notice, könnte man also einfach übernehmen und ist kein oder daher nicht zwangsweise ein technisches Problem. --Prototyperspective (Diskussion) 17:17, 3. Dez. 2024 (CET)Beantworten
Regelmäßig (derzeit im Abstand von 60 s) liest der Bot das Lösch-Logbuch und zwar die frisch gelöschten Beiträge im Artikelnamensraum. […] Danach erhält der Erstautor eine Benachrichtigung über die Löschung. Also erhält der Autor die Benachrichtigung oft oder meist erst nach der Löschung. --Prototyperspective (Diskussion) 18:41, 3. Dez. 2024 (CET)Beantworten
Dieser kommt nicht 60 s nach, sondern mit Stellung des LA 7 Tage vor der routinemäßigen Löschentscheidung.
Adressat ist das Konto mit den meisten Beiträgen, ggf. auch Seitenersteller, ggf. mehrere.
Will sagen: Wir machen das bereits seit fast zwei Jahrzehnten, durch wechselnde Bots, mit wechselnden Auslösern, mit unterschiedlichen Benachrichtigungstexten und Adressatenauswahl.
Danke für die Info. Also ist der genannte Wunsch bereits umgesetzt (@Meister)? Ich verstehe nur nicht wieso der Bot-Post keine Vorlage benutzt (obwohl doch eine standardisierte Textvorlage verwendet wird). Diese könnte dann mit der EN Vorlage verknüpft werden. --Prototyperspective (Diskussion) 19:10, 3. Dez. 2024 (CET)Beantworten
„Ich verstehe nur nicht wieso der Bot-Post keine Vorlage benutzt“
Der Text wird von den Menschen hinter dem Bot signiert und verantwortet, und es muss ohnehin dieser Textbaustein irgendwie im Bot hinterlegt werden. Also gleich komplett.
Signierte Texte dürfen niemals als Vorlageneinbindungen lesbar sein; weil: Diese Aktion ist fast zwei Jahrzehnte alt. Wenn da 2009 mal irgendein Text hingeschrieben wurde, dann darf der nie nie nie seitdem mehr von irgendwem verändert werden, weil sonst würde den Signierenden Inhalt untergeschoben, den sie nie gesehen hatten, oder es wird vorgegaukelt, die Adressaten hätten Infos bekommen, die sie nie gesehen hatten.
In en:User talk:Caleb 1223 steht ein Benachrichtigungstext, der sich aber sofort ändern würde, falls jemand den Text in der Vorlage verändert.
Sowas ist absoluter Pfusch und bei uns hier strikt untersagt.
Zwar schreibt die enWP, man solle diese Einbindungen substituieren (und damit den Zustand bei Abspeicherung einfrieren), aber sie setzt das nicht durch, und erlaubt veränderliche Einbindungen.
Wir haben auch über 200 substituierende Vorlagen, aber wir wehren uns mit Händen und Füßen, dass die als normale Einbindungen benutzt werden, und zeigen dann nur Fehlermeldungen aber keine Inhalte an.
Im Übrigen ist es auch für Newbies verwirrend, wenn sie auf ihrer Diskussionsseite nur eine halbe Zeile kryptische Wikisyntax zu lesen bekommen; wir machen sowas auch deshalb nicht.
Ich wünsche mir Benachrichtigungen über die Nutzung meiner Commons-Uploads² zu erhalten wie im Bild und bereits vor Jahren gewünscht: phab:T77154. (²oder eines Subsets davon via Einstellungen wie z.B. nur erstmalige Nutzungen oder erstmalige nicht selbst-eingebundene Nutzungen oder alle Nutzungen in ENWP & Wikidata) --Prototyperspective (Diskussion) 19:14, 3. Dez. 2024 (CET)Beantworten
Letzter Kommentar: vor 22 Tagen2 Kommentare2 Personen sind an der Diskussion beteiligt
Wie schon angemerkt, fände ich eine Filterung nach Kategorien bei den letzten Änderungen für Portale und allgemein Leute mit thematischen Schwerpunkten (wohl die meisten Benutzer) sinnvoll. Im Moment muss man alle Artikel einzeln auf die eigene Beobachtungsliste setzen. Oder umständlich eine Liste von Artikeln erstellen und regelmäßig aktualisieren, um damit die letzten Änderungen bei in der Liste stehenden Artikeln zu beobachten (Beispiel Portal:Ruanda/Register -> Tab Letzte Änderungen). --Lupe (Diskussion) 09:05, 26. Nov. 2024 (CET)Beantworten
Jedes Logbuch, muss auf einer extra Seite aufgerufen werden, das ist sehr ineffizient. Man sollte sich die meisten Logbücher auf der Spezial:Beiträge anzeigen lassen können und nicht jedes auf einer anderen Seite.--ᵂᶦᵏᶦᴮᵃʸᵉʳ👤💬Skripte ︱ Rechte ︱ GitLab10:14, 26. Nov. 2024 (CET)Beantworten
…
COMMONS-FINDEN – Medien auf Commons finden und managen
Letzter Kommentar: vor 23 Tagen1 Kommentar1 Person ist an der Diskussion beteiligt
@Johanna Strodt (WMDE): Die Kategorien sind meiner meiner Meinung als Themenschwerpunkt nicht zu priorisieren, da es definitv wichtigeres gibt. Was aber definitiv verbessert werden muss ist das API (action: 'query', list: 'allcategories',). Diese schränkt die Möglichkeiten von Verbesserungen mit Skripten ein.
Da ich bei
WBCatHelper allcategories verwende, finde ich Kategorien deutlich besser und habe entsprechend mehr Möglichkeiten als mit HotCat das allpages zweckentfremdet um Kategorien zu suchen. Jedoch benötige ich immer noch "allpages" als Fallback, da das API mit allcategories z.B. bei Eingaben wie "Sprache (Afr" nichts mehr zurückliefert. Ich würde hier würde ich z.B. Befürworten vorerst nur das API zu verbessern, damit Benutzerskripte besser werden können.--ᵂᶦᵏᶦᴮᵃʸᵉʳ👤💬Skripte ︱ Rechte ︱ GitLab10:29, 25. Nov. 2024 (CET)Beantworten
Letzter Kommentar: vor 9 Tagen4 Kommentare4 Personen sind an der Diskussion beteiligt
alle Funktionen zur Tabellenformatierung sollten im VisualEditor verfügbar sein, so z.B. class="wikitable tabelle-kopf-fixiert", d.h. die Kopfzeile der Tabelle bleibt beim scrollen sichtbar --Wikipeter-HH (Diskussion) 17:18, 27. Nov. 2024 (CET)Beantworten
Ja, im VisualEditor sollten grundsätzlich, wenn möglich, alle Funktionen die im Quelltext möglich sind auch abgebildet sein.
Bei "wikitable tabelle-kopf-fixiert", besteht das Problem darin, welche Benutzeroberfläche du in "Einstellungen->Benutzeroberfläche->Aussehen" ausgewählt hast. Im Vector alt (2010) funktioniert es, dass der Tabellenkopf stehen bleibt. Im Vector (2022) funktioniert es nicht. Ich glaube man arbeitet an einer Lösung. Kannst du ausprobieren in Liste der Präsidenten der Vereinigten Staaten. Vector (2010) bleibt der Tabellenkopf stehen. Vector (2022) nicht. In klassischer Browser-Ansicht wie in mobiler Browser-Ansicht. In der Wikipedia App siehst du erstmal nur die Überschriften der Tabellen. Nach aufklappen und scrollen bleibt kein Tabellenkopf stehen.
Dafür, dass gefühlt mit die meisten Vorschläge vom Themenparkplatz mit Tabellen zu tun hatten, bin ich jetzt sehr erstaunt, dass die Tabellen hier nur als Anhängsel zu Medien auftauchen. Ich verstehe auch nicht, was das Einbinden von Medien mit der Bearbeitung und Bedienung von Tabellen zu tun hat. Ich habe jetzt meine Stimme für diese Schwerpunkt abgegeben, aber mit einem recht unguten Gefühl, weil ich eigentlich keine Ahnung habe, für was genau ich jetzt gestimmt habe. Sehr unbefriedigend! --FordPrefect42 (Diskussion) 22:51, 9. Dez. 2024 (CET)Beantworten
Letzter Kommentar: vor 21 Tagen2 Kommentare2 Personen sind an der Diskussion beteiligt
Umseitig wurde „weiße Schrift auf königsblauem Feld“ als schleckiges Design ausgewählt.
Dieses Design ist in allen Wikis reserviert für Aktiv-Buttons, über die neue Abschnitte oder Seiten geöffnet werden können oder neu aufgebaut würden.
Also werden erstmal alle dazu verleitet, dort draufzuklicken, damit irgendwas passiert, und sich über die Erfolglosigkeit wundern.
Umgekehrt führt dieser Missbrauch dazu, dass auf anderen Seiten Verlinkungen nicht mehr als solche erkannt und nicht mehr angeklickt werden, weil ja erlernt wurde, dass das nur irgendein buntes Design ist.
Letzter Kommentar: vor 21 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt
Wo bringe ich meinen eigenen, seit Jahren drängendsten technischen Wunsch unter?
Nämlich dass die Suche unter https://www.wikipedia.de case-sensitiv ist und bei falscher Groß/Kleinschreibung gleich auf "Seite anlegen" linkt, wenn ich nicht aufpasse? Außerdem ist die Auswahlliste, die bei dieser Suche erscheint, nicht tastaturbedienbar (Runter-Taste zum Auswählen, Enter zum Öffnen).
Dieses Verhalten hat die Wikipedia seit bald 20 Jahren unverändert! --Nikolaus16:29, 27. Nov. 2024 (CET)Beantworten
Letzter Kommentar: vor 16 Tagen2 Kommentare2 Personen sind an der Diskussion beteiligt
Die Umfrage lässt leider nicht zu, zu antworten, dass alles einfach so bleiben soll, wie es ist. Für Wikipedia zu schreiben ist nicht schwer, und neue Techniken würden möglicherweise nur anders verwirren, aber auch nichts verbessern. Meiner Meinung nach sollte besser Energie in noch klarer verständliche Tutorials gesteckt werden. Und grundsätzlich ist es auch von Vorteil, wenn ein ganz klein wenig Mühe nötig ist, um für Wikipedia zu schreiben, damit nicht spontaner Unsinn geschrieben wird, wie etwa in Social Media. --Annelenasophie (Diskussion) 12:33, 2. Dez. 2024 (CET)Beantworten
Letzter Kommentar: vor 16 Tagen1 Kommentar1 Person ist an der Diskussion beteiligt
Rückmeldung: In der aktuellen Wikipediaedia-App für Android ging das Abstimmen bei mir nicht, da "übernehmen und weiter" nur als Text und nicht als Button erschien.
Im Browser geöffnet gings dann wieder, ist aber suboptimal.
Letzter Kommentar: vor 16 Tagen1 Kommentar1 Person ist an der Diskussion beteiligt
Manchmal gerät im Quelltexthervorhebungsmodus der Textcursor zwischen zwei Buchstaben, so dass man nicht mehr weiß welchen Buchstaben man editiert. Es tritt auf, wenn man Texte kopiert. Schaltet man die Quelltextformatierung aus und wieder ein, so ist der Cursor wieder richtig positioniert. Ich nutze den Firefox-Browser. Das stört mich deutlich mehr als alles, was das Team hier selbst vorgeschlagen hat. Bitte beheben. =) --Matthias18:50, 2. Dez. 2024 (CET)Beantworten
Diskussion 
.png)
.png)
Diskussion 
16:29, 27. Nov. 2024 (CET)