Wikipedia:Projektdiskussion

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 10 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Gruppendiskussion am Rande der Occupy-Proteste.

Auf dieser Seite können Themen besprochen werden, die das Projekt der deutschsprachigen Wikipedia betreffen. Die Seite soll als zentrale Anlaufstelle für Diskussionen, die die gesamte deutschsprachige Wikipedia betreffen, dienen. Auch Anregungen aus anderen Wikimedia-Projekten können hier besprochen werden.

Ist das die richtige Seite für mich?

• Themen, die einzelne Seiten aus dem Wikipedia-Namensraum betreffen, sollten auf der jeweiligen Diskussionsseite besprochen werden.
• Bevor du ein Meinungsbild anlegst, sollte das Thema entweder hier oder auf einer passenden Diskussionsseite (sofern vorhanden) besprochen worden sein.

Für einige verwandte Anliegen gibt es andere spezielle Seiten:

• Fragen zur Wikipedia für Hilfe zur Bedienung und Wissensfragen zur Wikipedia
• Verbesserungsvorschläge für technische Verbesserungsvorschläge
• Feature-Requests für Ideen zu neuen Funktionen der Wiki-Software
• Redaktionen für fachlich abgegrenzte Themen im Artikel-Namensraum
• Nachrichten aus der Wikipedia-Gemeinschaft
• Anfragen: Übersichtsseite für weitere Anlaufstellen

Eine neue Diskussion beginnen

Archiv

Abschnitte, die seit zehn Tagen mit dem Baustein {{Erledigt|1=~~~~}} gekennzeichnet sind, werden automatisch archiviert. Möglicherweise findest du auch im Archiv die Antwort auf deine Frage. (Gesamtarchiv • dieses Jahr)

Löschantragsteller

umgezogen aus WD:RK: [1]. --Filzstift (Diskussion) 11:50, 8. Mai 2024 (CEST)

Es gibt einige Benutzer, die durch sehr häufige Löschanträge auffallen. Ich möchte eine Sperre beantragen, falls mehrere Anträge gestellt wurden, obwohl die Relevanz eindeutig aus dem betreffenden Artikel zu ersehen ist (laut Relevanzkriterien, also zum Beispiel Chefredakteur einer relevanten Zeitschrift). --AnPa28 (Diskussion) 10:53, 4. Mai 2024 (CEST)

Falls es sich um Störanträge handelt, bei der VM melden, bei länger angemeldeten Nutzern ansprechen. Denke mal, das hat nichts mit Relevanzkriterien hier zu tun. --Bildungskind (Diskussion) 11:02, 4. Mai 2024 (CEST)

Wenn es um die Nutzer geht, an die ich bei der Beschreibung denke, wurden die alle schon mehrfach ohne merklichen Effekt angesprochen. Die Löschregeln bestehen leider fast nur aus sollte-Formulierungen, der Ge- bzw. Missbrauch der LAs als forcierte Qualitätssicherung ist völlig legal. --MaligneRange (Diskussion) 12:02, 4. Mai 2024 (CEST)

Nach kurzem Schauen gehe ich davon aus, dass wir über @Lutheraner reden (ich pinge ihn an, weil ich es für blöd halte, über andere heimlich zu plaudern.)

Er stellt halt viele LAs, ist aber auch ein engagiert in der Eingangskontrolle und in der QS tätig, zieht Löschanträge zurück, wenn die Relevanzdarstellung seiner Meinung nach ausreicht, und in vielen Fällen, wo Relevanz tatsächlich gegeben ist, aber Überarbeitung zu aufwendig für die QS wäre, nimmt er auch Verschiebungen in den BNR vor und bearbeitet auch Artikel im ANR – das Stellen von LAs ist nur ein Teil seiner Tätigkeit, die ich insgesamt sehr schätze und positiv finde. Und wie ich bereits schrieb: Wenn das irgendjemand von euch für sanktionswürdig haltet, dann meldet ihn eben auf der VM, das ist hier nicht der richtige Ort dafür. --Bildungskind (Diskussion) 12:40, 4. Mai 2024 (CEST)

Reine Meta-Konten, die umgehend bei den LK aufschlagen, habe eine kurze Halbwertszeit. Bei den Usual Suspects unter den Etablierten sehe ich subjektiv noch ein, zwei weitere Konten, die vergleichsweise aktiv sind (und teilweise auch recht spartanisch in der Begründung). Für Freude und/oder Freunde sorgt das nicht zwingend, „strafbewehrt“ ist das indes auch nicht... und hier, wie zuvor erwähnt, nicht richtig platziert.

Idealerweise sollte man auch selbst Hand anlegen, bevor man einen LA stellt, aber bei Zeitschriften beispielsweise reicht manchmal schon der Verweis auf die bereits vorhandene ISSN (und den weiterführenden Link zur ZDB) oder das Einfügen selbiger bereits aus, um eine LD frühzeitig zu beenden. Was ich, glaube ich, ausdrücken will: Missbräuchliche Konten werden abgeklemmt, die anderen tragen zur Qualitätssicherung bei — auch wenn das manchmal nur minimaler Aufwand ist. --MfG, Klaus­Heide (^Diskuss_i^on) 12:56, 4. Mai 2024 (CEST)

Ich danke @Bildungskind: für das anpingen und für die sachliche Betrachtung meiner Arbeit in der Wikipedia. Zur Sache möchte ich hier nichts beitragen, Wer meint, etwas, was ich täte sei nicht in Ordnung, möge mich bitte persönlich ansprechen.

An dieser Stelle handelt es sich um einen sachlichen Irrläufer. Ich denke, man kann diese Diskussion hier benden. Freundliche Grüße --Lutheraner (Diskussion) 18:23, 4. Mai 2024 (CEST)

Hier liegt ein Irrtum vor. Ich hatte nicht von einem Benutzer geschrieben, sondern von mehreren. Es wurde auch so von anderen Benutzern verstanden. Lediglich Benutzer:Bildungskind war der Meinung, ich würde nur eine konkrete Person meinen, und hat dieses dann so weitergeleitet.

Das Problem ist mit dieser coolen Äußerung von dem letzten Beiträger nicht erledigt. Aber es ist hier wahrscheinlich nicht der richtige Ort dafür, VM wäre tatsächlich geeigneter, wie ja ganz zu Anfang vorgeschlagen wurde.

Es geht um Regeln, ob es Ausnahmen gibt, und ob die Empfehlungen für Aktivitäten vor Erstellung eines Löschantrages nur Versehen waren, die vergessen wurden, wieder zu entfernen, oder ob sie ernstgemeint sind und gegebenfalls auch einklagbar bzw. sanktionierbar bei dauerhaftem Ignorieren vor dem häifigen Erstellen von Löschanträgen.

Bitte um Hinweis, auf welcher Seite diese Diskussion sachlich und korrekt fortgeführt werden kann.

--AnPa28 (Diskussion) 21:58, 6. Mai 2024 (CEST)

@AnPa28:Wenn du meinst jemand mache etwas, was gegen die Regeln verstößt solltest du ihn direkt ansprechen. Reicht das nicht, ist die VM der richtige Punkt. Allerdings wäre ich damit sehr vorsichtig, denn sowas kann auch nach hinten los gehen, wenn der Eindruck entsteht, du wollest jemand etwas am Zeug flicken. Das Wesentliche findest du unter WP:Vandalismus. Freundliche Grüße --Lutheraner (Diskussion) 22:26, 6. Mai 2024 (CEST)

Ich bin der Meinung, dass es keine Artikel über Personen geben sollte, die in der Wikipedia Löschanträge stellen. --Marcus Cyron Mit Ukraine, Israel, Armenien und Iranern 22:36, 6. Mai 2024 (CEST)

Die Erfüllung der Relevanzkriterien und somit die Darstellung der Relevanz obliegt in erster Linie dem Artikelersteller, sie ist nicht von vornherein "eh klar". Ein LA kann dazu führen, diese Darstellung und die Qualität des Artikels gemeinsam zu verbessern und das bringt allen, vor allem den Leserinnen und Lesern etwas. MfG --Regiomontanus (Fragen und Antworten) 22:44, 6. Mai 2024 (CEST)

(Zu der Anfrage von Benutzer:Lutheraner nach meinen Kritikpunkten )

Ich weiß nicht, ob dieses hier der richtige Ort ist, das zu diskutieren.

Ich hatte beispielsweise in den letzten Tagen mit dir nicht den Eindruck, dass ein sachliches Gespräch möglich ist, und auch nicht bei vorherigen Malen.

Wenn du es möchtest, können wir hier gerne drüber reden, wobei das Wichtigste ja eigentlich schon von mir und den anderen Benutzern – außer Bildungskind – angesprochen wurde.

Du gehörst tatsächlich zu den Benutzern mit den meisten Löschanträgen hier in der deutschen Wikipedia. Wenn ich mal so über den Daumen peile, etwa 2 pro Tag, mal etwas mehr, mal weniger, vielleicht etwas weniger, also so etwa 1,7 mal pro Tag. Das macht bei 365 Tagen etwa 500 Löschanträge im Jahr, in zehn Jahren sind das dann etwa 5000, so grob geschätzt.

Mich hast du noch nie angesprochen vorher, wie es empfohlen wurde, und dass du mit dem Ersteller vorher gemeinsam nach Hinweisen nach Relevanz gesucht hast, ist mir nicht bekannt. Aber wenn dieses doch so sein sollte, kannst du das ja bei Anfrage problemlos nachweisen.

Es stellt sich bei eunigen Löschanträgen, nicht nur von dir, aber auch gelegentlich von dir heraus, dass die Relevanz ganz einfach per Google-Check oder WorldCat-Check oder Blick in die RK festzustellen gewesen wäre, das meinte ich mit der Empfehlung, dieses vorher zu prüfen, wie es ausdrücklich vorgeschlagen wird.

Die sachliche Einschätzung deiner Arbeit hier durch den Benutzer:Bildungskind teile ich überhaupt nicht, aber das können wir tatsächlich an anderer Stelle besprechen, falls du bereit bist, Kritik oder ärgerliche Wahrnehmungen deiner Aktivitäten hier anzusehen ohne gleich mit einem Rachefeldzug zu reagieren.

Eigentlich ging es mir um fairere Regeln für Löschantragstellungen, wie sie ja eigentlich sehr schön formuliert sind viele Benutzer haben die Wikipedia verlassen, usw.

Dann könnten sich alle daran orientieren, eine persönliche Diskussion mit dir war eigentlich nicht die Absicht dieses Abschnittes, da ich mir ehrlich gesagt nicht viel von verspreche, ich lasse mich natürlich auch überzeugen vom Gegenteil.

--AnPa28 (Diskussion) 23:03, 6. Mai 2024 (CEST)

Von Scherzen, Trollen und Irrtümern mal abgesehen (die meisten alten Hasen, die hier LA stellen, kennen die RK und die Mindestanforderungen an Artikeln auswendig): Was ist das Problem bei einem Löschantrag? Das ist ein Antrag, nicht mehr, nicht weniger. Wird angeschaut, diskutiert und dann wird entschieden. Und wenn gelöscht wird, dann hatte der Antrag Hand und Fuss; wenn hingegen behalten wurde, dann nicht selten deswegen, weil der Artikel in Zwischenzeit ausgebaut wurde (oft war die Relevanz nicht dargestellt oder der Artikel entsprach nicht den Mindestanforderungen).

"Gemeinsam nach Hinweisen nach Relevanz gesucht": Bei Autoren, die ernsthaft mitarbeiten wollen, wird das teils gemacht; oft wird aber dennoch direkt ein LA gestellt, zumal die ja genau die LD-Seite diesem Gemeinsam-nach-Hinweisen-Suchen dient (im Sinne: Diskutieren wir das auf der LD-Seite, ist ja die ideale Seite dafür); bei Leuten, die Wikipedia mit Linkedin oder gar Instagram verwechseln, und den eigenen Rotz über sich selbst hier abzukippen (was sehr oft vorkommt), da will man das nicht machen; da spricht man den Benutzer her bestimmt an und stellt direkt einen LA. Jahrelange Erfahrung zeigt, dass da ein Dialog unmöglich ist (der will ja um jeden Preis seinen "Artikel" haben). --Filzstift (Diskussion) 23:22, 6. Mai 2024 (CEST)

"Was ist das Problem bei einem Löschantrag?"

Es ist ein hochgradig frustrierender Vorgang. Sie einfach so als wären sie nichts abzutun ist genauso falsch, wie hier die Sperre von Lutheraner zu fordern. Löschanträge sollten das letzte Instrument sein. Leider sind sie das für ein paar Leute nicht. Und da kann ich schon verstehen, wenn man sich da ärgert, wenn man da frustriert ist. Und ich schätze Lutheraner in ganz vielen Bereichen - aber bei den Löschanträgen bin auch ich der Meinung, dass ihm da die Tastatur oft etwas locker sitzt. Die LK sind eben auch keine QS. Auch keine Hilfs-QS. Nur ist das weder eine Sache die hier zu diskutieren wäre, noch ist er destruktiv und somit zu sperren. --Marcus Cyron Mit Ukraine, Israel, Armenien und Iranern 14:29, 7. Mai 2024 (CEST)

+1 -- Chaddy · D 14:43, 7. Mai 2024 (CEST)

+1 Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:31, 9. Mai 2024 (CEST)

@AnPa28: Nein , es ist nicht der richtige Ort das hier zu diskutieren. Du bist schon wieder völlig off-topic. Jetzt reicht es mir langsam - wenn du mir etwas zu sagen hast, so mache das demnächst auf meiner Diskussionsseite! Deine Erbsenzählerei und dein Rechenexempel sind einfach absurd! Da auch schon andere sinngemäß festgestellt haben, dass diese Diskussion hier ein Irrläufer ist, gehe ich davon aus , dass diese jetzt hier beendet werden kann. --Lutheraner (Diskussion) 23:25, 6. Mai 2024 (CEST)

Mit Verlaub, aber das wird hier doch langsam lächerlich. Die Personen, die „durch sehr häufige Löschanträge auffallen“, könnte man fast an einer einzigen Hand abzählen (ich lese fast alle LAs und weiß daher, wie klein der gemeinte Personenkreis ist). Wenn du @Lutheraner nicht (nur) meinst, wären die anderen möglichen Kandidaten überschaubar – da zu insinuieren, dass meine Lesart abwegig sei, ist nicht glaubwürdig, besonders wenn man eure Konversationen in den LDs und in der QS verfolgt hat. Und dann beginnst du eine Diskussion mit „Ich möchte eine Sperre beantragen“ und wirfst anderen vor, sie könnten keine sachliche Diskussion führen oder du befürchtest einen Rachefeldzug, und schreibst dann auch noch mehrere passiv-agressive Kommentare gegenüber meiner Person.

Diese Diskussion hier begann schon mit dem Antrag einer Sperre ziemlich vergiftet und ich würde echt raten, das nicht weiter auszudiskutieren, sondern in den Archiven verschwinden zu lassen. Hier wären wohl eine Preußische Nacht und Punkt 8 und 9 der Wikiquette hilfreich. --Bildungskind (Diskussion) 02:02, 7. Mai 2024 (CEST)

Also, ich dachte, ich hätte mich verständlich genug ausgedrückt, mir ging es um das Einhalten des im Artikel über Löschanträge vorgesehenen Ablaufes, nämlich möglichst die Antragsteller vorher zu kontaktieren und m i t i h n e n nach konstruktiven Lösungen zu suchen.

Die Fokussierung auf den einen Benutzer wurde von dir allein geschaffen, und eure Reaktionen zeigen deutlich, dass Kritik ein Problem zu sein scheint, was dann als passiv-aggressiv (was ist das?) empfunden wird.

Das mit der Sperre bezog sich eigentlich auf den Löschantragsbereich, das heißt, wer häufig oder sehr häufig die vorgesehenen vorherigen Schritte vor der Erstellung eines Löschantrages vergisst, darf für eine gewisse Zeit keine Löschanträge mehr stellen.

Das würde erwas mehr Frieden und vor allem Sorgfalt in diese unseligen und oft unnötig zermürbenden Diskussionen bringen.

Wo kann ich das beantragen?

--AnPa28 (Diskussion) 13:33, 7. Mai 2024 (CEST)

Du könntest ein WP:Meinungsbild erstellen. Das gab es auch schon (für die Nostalgiker: Punktekonto, das hatte doch was :D ). Dort findest du auch die vorherigen Ansätze, die kann ich gerade leider nicht verlinken, das geht am Handy nicht so richtig. Flossenträger 13:37, 7. Mai 2024 (CEST)

Sachlich zwar richtig, sollte man ihm aber nicht raten - damit kann er sich nur blamieren. --Lutheraner (Diskussion) 13:45, 7. Mai 2024 (CEST)

Oder auch nicht. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:33, 9. Mai 2024 (CEST)

Solltest du nicht eine Sockenpuppe sein kannst du das gar nicht beurteilen, nachdem du erst ein halbes Jahr hier dabei bist. --Lutheraner (Diskussion) 12:35, 9. Mai 2024 (CEST)

Ein Klick auf den Namen hätte gereicht, um den Sockenpuppenstatus zu klären. Nichtmal die winzigste, naheliegendste Recherche zu betreiben ist genau das Verhalten, das hier kritisiert wird. (Abgesehen davon können natürlich auch die Nutzer neuerer Konten Dinge lesen, die vor ihrer Accounterstellung geschrieben wurden.) --MaligneRange (Diskussion) 14:04, 9. Mai 2024 (CEST)

Dadurch dass du deine Meinung hier immer wiederholst ist sie hier immer noch nicht am richtigen Ort . Ich habe dir oben ein paar Hinweise gegeben. Wenn du die nicht lesen oder begreifen willst ist da deine Sache. Allgemeine Fragen, wenn du sonst nicht weißt wo, bitte auf WP:Fragen zur Wikipedia. --Lutheraner (Diskussion) 13:43, 7. Mai 2024 (CEST)

Es geht immer noch um die Athmosphäre der Löschantragsteller und die Empfehlungen vorher.

Die Löschdiskussionen werden von vielen betroffenen Benutzern als frustrierend empfunden, obwohl dem durch ein vorheriges Gespräch meist leicht vorgebeugt werden könnte.

Das müsste meiner Meinung nach eindeutiger formuliert werden.

Das müsste auf einer präzisen Diskussion festgehalten werden – nloß wo?

--AnPa28 (Diskussion) 11:41, 8. Mai 2024 (CEST)

Das wäre unter WD:LR zu diskutieren, denke ich. Allerdings: Was man höchstens machen könnte, ist den Begriff "Löschkandidaten" durch irgend ein anderes Wort auszutauschen (wird dann wohl damit enden, dass man sagt, das sei ein Euphemismus) oder die LD mit der QS zu vereinigen. Doch das geht nicht ohne (vermutlich aussichtsloses) MB. --Filzstift (Diskussion) 11:49, 8. Mai 2024 (CEST)

Jedes Wort, was da geändert werden sollte , müsste durch ein Meinungsbild, denn wir bewegen uns dort auf zentralem Terrain für die grundsätzlichen Fragen der Qualität und Qualitätssicherung der Wikipedia als Ganzes und ich bin sicher, es würde ausgehen wie das Hornberger Schießen --Lutheraner (Diskussion) 11:54, 8. Mai 2024 (CEST)

Ich habe mich aus der Disk etwas ausgeklingt, da ich keine Lust hatte, das weiter zu diskutieren.

Die heutige Tagesseite bei den Löschkandidaten ist aber schon ... hm. Das ist sicherlich nicht schön für einen Nutzer, auf der eigenen Disk eine zweistellige Zahl an Benachrichtigungen zu kriegen.

Also persönlich muss ich sagen, dass das ne unangenehme Atmosphäre erzeugt, auch wenn die LAs möglicherweise berechtigt sind. --Bildungskind (Diskussion) 12:00, 10. Mai 2024 (CEST)

Ist Wikipedia grundsätzlich reformierbar oder sollte man etwas neues versuchen?

Aussage:
Die freie Enzyklopädie die jeder editieren kann

Kritik:
Verglichen mit einem gedruckten Verlagsprodukt fehlen mir hier die Lektoren, meinetwegen auch irgedwie bezahlte, welche für eine bessere Qualitätssicherung sorgen und die Zuverlässigkeit somit deutlich erhöhen würden. Als wissenschaftliches Werk ist sie so aus meiner Sicht kaum zu empfehlen. Auch an der Harmonie zwischen den einzelnen Sprachversionen hapert es, wenn Vorlagen, die in der englischen Wikipedia existieren und sich bewährt haben, hier ohne erkennbare Not nicht existieren. Ich schätze individuelle Freiheit, aber manchmal hätte, glaube ich, hat eine Zentralinstanz auch ihre Vorteile und böte die Möglichkeit Motivation zu stärken und verlorene Editoren zurückzugewinnen. --Klaus Piotrik Qais Felli-Littmann (Diskussion) 19:08, 23. Mai 2024 (CEST)

Grundprinzip der Wikipedia ist das Wikiprinzip. Das ist so also nicht so leicht änderbar. Aber diesbezüglich gibt es schon Alternativen: Der Vorgänger der Wikipedia war die Nupedia, welche aber scheiterte. Daneben gibt es Scholarpedia, oder auch traditionelle Enzyklopädien wie der Brockhaus haben Online-Ausgaben. Dass die nicht denselben Erfolg wie die Wikipedia haben, dürfte schon u.a. am Wikiprinzip liegen. Eine der wenigen Alternativen, die ich persönlich benutze, ist die Stanford Encyclopedia of Philosophy, weil die nach meiner Ansicht viele Teile der akademischen Philosophie besser/ausführlicher darstellt. So weit dazu.

Zu der Sache mit den anderen Sprachversionen: Ja, finde ich persönlich auch doof. Es gibt ja mit Commons und Wikidata einige Harmonisierungen, aber für weitergehende müsste man große Teile der jetzigen Wikipedia ändern und es auch irgendwie ermöglichen, dass man untereinander kommuniziert. Dann in welcher Sprache? Englisch beherrscht nicht jeder im ausreichenden Maße. --Bildungskind (Diskussion) 19:54, 23. Mai 2024 (CEST)

Scholarpedia habe ich mir kurz angesehen, scheint aber nahezu tot zu sein und ist außerdem nur auf Englisch. Brockhaus hatte ich kuzzeitig abonniert, da fehlten jedoch einige für mich interessante Artikel. Was verstehst Du unter Erfolg? Misst Du das nur an der Artikelzahl? Nach dem Prinzip "Less is more" ist die aktuelle Artikelanzahl für mich relativ unerheblich, da würden mir für den Anfang auch die 29.586 Artikel der Wikipedia in Interlingua reichen, ist ja ausbaufähig. Gegen das Wikiprinzip habe ich als jahrelanger Benutzer von Linux auch nichts einzuwenden. Es sollte aber vielleicht ein Zwei-Kammer-System angewendet werden: Eine Kammer wo die Artikel aufgebaut werden und reifen können und eine Kammer wo nur Artikel von professioneller Qualität, dafür durchaus auch bedeutend weniger, enthalten sind. So wie es jetzt ist, ist das Bananaware(reift beim User) und für mich nicht wirklich ernst zu nehmen.

Warum müsste man große Teile der jetzigen Wikipedia ändern? Es würde doch reichen, wenn man die englischen Vorlagen übernimmt, so sie existieren und ihnen Vorrang vor Eigenentwicklungen gibt??? Etwas guten Willen vorausgesetzt ist, glaube ich, Kommunikation schon möglich. Als ich ich meine tunesische Frau kennen lernte und wir uns verlobten, hatte ich nur zwei Jahre Schulfranzösisch und war auch nicht der Beste. Meine Frau dagegen sprach kein Deutsch oder Englisch sondern nur Tunesisch(Arabisch) und Französisch. Ich sehe Interlangua als kommende Sprache. Wir haben in Berlin Neukölln wohl ca. 150 verschiedene Nationen und Interlangua sehe ich da als Möglichkeit, zu versuchen, alle an einen Tisch zu bekommen und miteinander sprechen zu können. Sonst leben viele nur in ihrem eigenem Sprach- / Kulturkreis statt miteinander in Frieden. --Klaus Piotrik Qais Felli-Littmann (Diskussion) 21:31, 23. Mai 2024 (CEST)

Als Ergänzung: es ist auch nicht der Anspruch der Wikipedia, ein wissenschaftliches Werk zu sein. Die Wikipedia:Grundprinzipien nennen das Ziel, eine Enzyklopädie von bestmöglicher Qualität zu schaffen. -- hgzh 20:03, 23. Mai 2024 (CEST)

Wenn nicht wissenschaftliches Werk, dann doch bitte möglichst professionell. So wie es jetzt ist, sehe ich es als Bananaware(siehe oben) an. --Klaus Piotrik Qais Felli-Littmann (Diskussion) 21:37, 23. Mai 2024 (CEST)

"Ist Wikipedia grundsätzlich reformierbar.." Antwort: schwerlich bis schleppend. Gruß--2A02:8108:473F:90A0:C114:E284:2BDF:6F65 20:21, 23. Mai 2024 (CEST)

Es sind auch schlicht andere Menschen, völlig andere Kulturen und Traditionen.

• Die enWP verwendet >500.000 Vorlagen, wir etwas über 125.000 im ANR. Dass es in der enWP Vorlagen gibt, die es bei uns nicht gibt, ist völlig normal und beabsichtigt. >100.000 von den unsrigen kennt die enWP so überhaupt nicht; die kämen obendrauf.
• Der Wirkungsbereich der deWP-Autoren beschränkt sich zu 99 % auf die DACH-Region, mit etwas angrenzendem IT, BE, DK.
• Die enWP reicht von London über Boston und Seattle nach Tokio, Manila, Kalkutta, Kapstadt bis Sydney. Die Muttersprache oder übliche Zweitsprache dort ist Englisch.
• Die Muttersprache in der deWP ist Deutsch. Die meisten verstehen zumindest auf Grundschul-Niveau Englisch, könnten im Lokal dem Hungertod entgehen, sind aber nicht in der Lage, fortgeschrittenes oder technisches und fachspezifisches Englisch zu verstehen, geschweige denn zu schreiben.
• Eine der Grundforderungen der WMF-Wikis ist, dass sie mit möglichst wenigen zusätzlichen Vorkenntnissen außerhalb des Fachwissens bearbeitbar sein müssen. Das schließt Englisch als Basis-Sprache der deWP grundsätzlich aus, und damit auch die geforderte 1:1-Kompatibilität.
• DNB ist für Briten das Dictionary of National Biography, für uns die Deutsche Nationalbibliothek. DDR ist für US-Amerikaner ein Computer-Bauteil, bei uns ein untergegangener Staat. Wir sind aber keine befehlsempfangende Filiale der angloamerikanischen Kultur.
• Das suggerierte Konzept global einheitlicher Vorlagen würde bedeuten, dass die Vorlagen der enWP für alle Wikis auf dem Planeten verbindlich sind. Jede Veränderung würde einen Antrag bei der enWP oder einem globalen Template Government Committee erfordern. Jeder Antrag auf eine Veränderung müsste ein Vetorecht von über 900 anderen Wikis überstehen, und nachweisen dass in keinem anderen Wiki eine Veränderung erforderlich wäre, oder einen Mechanismus bereitstellen, wie in über 900 anderen Wikis die vorhandenen Einbindungen wunschgerecht umzustellen wären.
• Wir können aber jederzeit und meist direkt durch jeden Autor nahezu jede Vorlage ändern; ggf. nach kurzer Ankündigung.
• Geschlechtssensible oder formelle Sprache gibt es in der enWP nicht, oder nur in rudimentäten Ansätzen. You may say you to me. Ein officer ist ein officer und ein surgeon ist ein surgeon, mathematician oder physicist. Wir haben jedoch Vorlagenparameter für Schweizerisches Hochdeutsch oder österreichische Monatsnamen; ein Konzept, das sich in den begehrten weltweit einheitlichen Vorlagen eher nicht durchsetzen wird. Wir schreiben die Hausnummer hinter den Straßennamen; bei den Hausnummern 10 und 1600 ist das unüblich.

VG --PerfektesChaos 21:59, 23. Mai 2024 (CEST)

Auch wenn Du Dich PerfektesChaos nennst und Dich mit den technischen Gegebenheiten sehr gut auszukennen scheinst, habe ich doch meine Zweifel. Ich frage mich immer: Was ist schon perfekt und komme zu dem Ergebnis: Scheinbar nichts. Nebennbei: Ich bin Anhänger der Chaostheorie und liebe Sponti-Sprüche zum Beispiel: Wo wir sind ist Chaos aber wir können nicht überall sein. Vielleicht wäre es ja zu viel erwartet, alle >500.000 Vorlagen der enWP sofort hier zu erwarten, wenn jede WP ihre eigenen Vorlagen verwendet, muss ja vielleicht nicht, wenn hier kein Bedarf besteht. Was mir aber schwer in den Kopf will ist zum Beispiel: Arabische Sprache verwendet in der enWP: "lang-ar" aber in der deWP: "arS" etc. Muss das so sein? Oder anderes Beispiel: Ich wollte verschiedene tunesische Städte aus der französischen WP in unsere WP importieren (lassen): Die verwendeten Infoboxen funktionierten so irgendwie gar nicht. --Klaus Piotrik Qais Felli-Littmann (Diskussion) 07:23, 24. Mai 2024 (CEST)

Die Vielfalt und Eigenständigkeit der Sprachversionen zählt zu einer der Stärken der Wikipedia, es ist keine Schwäche. Es wurden schon so einige Versuche unternommen, eine redaktionell geführte Enzyklopädie aufzubauen: Nupedia, Wikiweise, Knol, sie sind alle gescheitert. Die Kraft, die es benötigt, um so ein Ding zu stemmen generierst du nicht durch mehr Regelungen, weniger Freiheiten, oder Aufdeckung der Klarnamen, auch immer gerne gefordert, noch durch die einfache Übernahme von Texten anderer Sprachversionen inkl der dortigen Vorlagen und Infoboxen. Artikel kann man auch nicht einfach nur übersetzen, Quellen sollten immer gelesen und geprüft werden. Angaben sind zu hinterfragen. Ich habe einige Versuche abgebrochen, einfach nur eine Biografie zu übersetzen, weil ich bei der Prüfung der Quellen gemerkt habe, was da alles so nicht stimmt und direkt neu geschrieben. Gruß --Itti 07:51, 24. Mai 2024 (CEST)

+1

Das meine ich im übrigen mit Erfolg/Misserfolg (weil @Klaus Piotrik Qais Felli-Littmann das oben fragte): Flache Hierarchien und die Tatsache, dass man alle Fehler selbst beheben kann, selbst wenn man eine unangemeldete IP ist, sorgen schon für ein höheres Interesse, bei Projekten wie der Wikipedia etc. mitzumachen. Erfolg messe ich hierbei nicht unbedingt an der Seitenzahl, sondern an der Zahl der aktiven Autoren und der Leser; die Wikipedia gehört heute zu den meistbesuchten Webseites weltweit. Ich wüsste deshalb nicht, wie der obige Vorschlag die Motivation stärken oder verlorene Editoren zurückgewinnen sollte: Ein Kritikpunkt an der Wikipedia ist, dass aufgrund ihrer Größe ein gewisses Maß an Bürokratie notwendig geworden ist. Inwiefern „Zentralisierungen“ Abhilfe schaffen sollten (obwohl das bei anderen Projekten klar nicht funktionierte), wird mir nicht klar. --Bildungskind (Diskussion) 08:24, 24. Mai 2024 (CEST)

@Klaus Piotrik Qais Felli-Littmann – zur angesprochenen „Arabischen Sprache“:

• Das hat einen geschichtlichen Hintergrund:
  • en:Template:lang-ar ist vom 12. Juni 2005.
  • Vorlage:arS ist vom 15. Juli 2005, grad vier Wochen jünger, mutmaßlich nach dortiger Idee nachgeschaffen.
  • Vorlagen mit Parametern gibt es erst seit 2004.
• Das hat einen sprachlichen Grund:
  • ar S steht für „arabische Sprache“ und sollte mit möglichst wenigen Tastendrücken eingetippt werden.
  • lang-ar steht für language arabic und ist für englische Muttersprachler nativ, jedoch für deutschsprachige ziemlich unverständlich und nicht intuitiv. Genau deshalb wurde das nicht in dieser Schreibung übernommen.
• Die Parameterstruktur beider Vorlagen ist anders:
  • Bei uns ist die wissenschaftliche Umschrift nach DMG ein wesentlicher Aspekt, der in der enWP nicht vorkommt.
  • Bei den meisten anderen der bald 500 vergleichbarer unserer Vorlagen können heute bereits mit fr= oder he= weitere Übersetzungen des Textfragments angegeben werden; auch noch weitere Umschriften, außerdem mit IPA= und Audio= schriftlich oder akustisch die Aussprache (dieses Erbstück ist zurzeit noch in einem Migrationsprozess und kann das noch nicht, ist die älteste aus dieser Serie).
  • Wenn wir auf das Schema der enWP beschränkt wären, wären wir deutlich ärmer.
  • Die hiesige Vorlage:lang versteht weit über 1000 Parameternamen, en:Template:lang nur mickrige 7 (in Worten: sieben).

Wir haben eine Vorlage, in der wird unterschieden eine Chefredakteurin alternativ zu Chefredakteur bzw. mit der Schweiz-Option auch Chefredaktor bzw. Chefredaktorin.

• Deine global einheitlichen englischen Wünsche würden dies sicherlich als Parametermodell ablehnen.

Bei uns kann jeder Internetnutzer, sprich jeder Autor sofort eine Vorlage für und gegen alles und jedes anlegen, erstmal egal ob sinnvoll oder nicht, und diese kann auch sofort in irgendwelche Seiten eingebaut werden.

• Das kann letzlich allenfalls durch eine administrative Löschung nach Löschdiskussion unterbunden werden.
• Ansonsten gibt es keine Handhabe, die Entstehung neuer und an unsere Verhältnisse besser angepasster Vorlagen zu verhindern.
• Nach deinen Vorstellungen müsste es verboten werden, eine Vorlage zu einem bestimmten Zweck anders anzulegen als mit genau dem Namen wie in der enWP und mit genau demselben Parametermodell wie in der enWP. Darauf wird sich niemand einlassen.

VG --PerfektesChaos 11:03, 24. Mai 2024 (CEST)

Zur Frage in der Überschrift: Versuch doch was Neues. Vielleicht findest du ja Partner, die das alles so machen wollen wie du. Wäre doch toll. Ich glaube aber, dass du keinen Erfolg haben wirst. Wenn man deine Benutzerseite ansieht, kann man das meiner Meinung nach erkennen. Viele Querköpfe haben die Welt verändert, die meisten sind halt gescheitert. --Hachinger62 (Diskussion) 19:37, 16. Jul. 2024 (CEST)

Digitale Sicherheit - Wie Sie sich auf Wikimedia-Plattformen schützen können

Liebe Wikimedianer,

Das Human Rights und Trust and Safety Team der Wikimedia Foundation hat einige Ressourcen zusammengestellt, die die digitale Sicherheit bei der Nutzung der Wikimedia-Projekte erhöhen sollen.

Was meinen wir mit dem Begriff "Digitale Sicherheit"? Ihre digitale Sicherheit auf den Wikimedia-Plattformen kann sich auf das Risiko beziehen, Opfer von Belästigungen, Doxxing oder Ziel von Angriffen durch externe Organisationen zu werden. Es gibt Möglichkeiten, dieses Risiko bei der Nutzung der Plattformen zu reduzieren. Beispielsweise beschränkt der Schutz Ihrer persönlichen Daten den Zugang zu Ihnen und Ihrem Leben außerhalb Wikimedias für jeden, der Sie anvisiert.

Hier sind einige Ressourcen, die euch bei der digitalen Sicherheit helfen können:

• Ihr könnt viele hilfreiche Ressourcen auf der Meta-Seite des Human Teams finden.
• Es gibt diese Meta-Seite über digitale Sicherheit für Wikimedianer;
• Es gibt diese Meta-Seite von Trust and Safety mit einigen Ressourcen für diejenigen, die mit Mobbing zu tun haben;
• Wir haben auch ein Lernmodul auf learn.wiki über digitale Sicherheit, in dem man selbst eine Bewertung digitaler Sicherheitsrisiken durchführen kann.

Man kann auch die folgenden Diff-Beiträge durchlesen:

• Wie kann ein Accountname dich schützen?
• Doxing: Hast du schon versucht, dich selbst zu doxen?
• Doxing: Warum sollte dich das interessieren?
• Digital safety during election time
• Digital safety best practices when attending conferences
• The Internet Outages Guide

Weitere Ressourcen, die von anderen Organisationen erstellt wurden, sind der Security Planner, mit dem Sie sich proaktiv im Internet schützen können, und das Digital First Aid Kit, das Ihnen bei der Bekämpfung von digitalen Bedrohungen im Falle eines Falles helfen soll.

Wenn Sie digitale Sicherheitsprobleme haben, weil Sie auf Wikimedia-Plattformen aktiv sind und nicht wissen, wie Sie diese lösen können, oder wenn Sie Fragen oder Vorschläge zur digitalen Sicherheit haben, kontaktieren Sie bitte unsere Teams:

• Bei Bedenken bezüglich Belästigung, Missbrauch, Doxing, Desinformation oder anderen Bedenken bezüglich Trust and Safety wenden Sie sich bitte an: ca@wikimedia.org.

• Bei Bedenken bezüglich der Menschenrechten, die Wikimedia betreffen, wenden Sie sich bitte an: talktohumanrights@wikimedia.org.

Mit besten Grüßen,

Human Rights and Trust and Safety at the Wikimedia Foundation --WMFOffice (Diskussion) 14:11, 24. Mai 2024 (CEST)

Persönliche Gefährdung von Autor:innen, die heikle Themen bearbeiten?

Es steht zu befürchten, dass Wikipedianer:innen, die heikle Themen unter Beachtung der Wikipedia-Regeln konstruktiv bearbeiten, in Zukunft möglicherweise verstärkt persönlichen Nachteilen durch staatliche oder nichtstaatliche Akteure ausgesetzt sein könnten. In einigen Fällen werden die Klarnamen der hinter den Accounts stehenden Personen freiwillig offengelegt. In anderen Fällen kann es aber sein, dass die Realidentitäten der Personen, die hinter anonymen Accounts stehen, von Dritten mit entsprechendem Aufwand ermittelt werden können. Wenn beispielsweise Wikipedianer:innen mit Beziehungen zu Staaten mit optimierbarem Rechtsstaatlichkeitsniveau Artikel zu diesen Staaten editieren, kann es sein, dass diese Staaten den betreffenden Wikipedianer:innen die Einreise verweigern oder in den betreffenden Ländern beheimatete Personen oder Institutionen genötigt werden, den Kontakt zu den betreffenden Mitarbeiter:innen der deutschsprachigen Wikipedia abzubrechen. Dies ist die Light-Variante für Wikipedianer:innen mit ausschließlich europäischer Staatsbürgerschaft. Mitarbeiter:innen der deutschsprachigen Wikipedia, die die Staatsbürgerschaft der betreffenden Staaten besitzen oder mal besaßen, könnten von erheblich gravierenderen Sanktionen betroffen sein. Ähnliche, möglicherweise noch unmittelbarere Probleme könnten auftreten, wenn Artikel über organisiertes Verbrechen oder politische Extremisten editiert werden. Es stellt sich auch die Frage, was passiert, wenn in D/A/CH Parteien, die rechtsstaatliche Grundsätze für optional halten, Zugriff auf staatliche Behörden erlangen. Ich kann mir nicht vorstellen, dass dies in der deutschprachigen Wikipedia oder anderssprachigen Wikipedias bislang noch kein Thema war, habe aber bei einer schnellen Recherche leider nichts Einschlägiges gefunden. Gibt es Initiativen, die sich mit dieser Problematik beschäftigen? Wenn nein: sollte man die Initiierung eines Projektes "Schutz gefährdeter und potentiell gefährdeter Wikipedia-Autor:innen" in Erwägung ziehen? Viele Grüße, --Espresso robusta (Diskussion) 14:06, 25. Aug. 2024 (CEST)

Nun hat die Wikipedia und ihre Community nur sehr beschränkten Einfluss auf Regierungen und kriminelle Organisationen. Auch den Erfindungsreichtum von Rechercheuren oder auch Stalker können wir nicht verhindern. Was schwebt dir also vor?--Mit lieben Grüßen Kriddl Bitte schreib mir etwas. 15:39, 25. Aug. 2024 (CEST)

Mir ist natürlich klar, dass eine ehrenamtliche Community und Wikimedia Deutschland e. V. nicht die CIA sind. Allerdings befürchte ich - auch aufgrund aktueller Entwicklungen im Bereich wissenschaftlicher Kooperationen mit sogenannten "schwierigen Partnern", dass die Wikipedia nicht unvorbereitet in derartige Probleme reinrennen sollte. Die Akteure im Wissenschaftbereich (DFG, DAAD, AvH etc.) halten es anscheinend für erforderlich, sich auf die hier skizzierten Probleme vorzubereiten. Im Prinzip würde man da ansetzen, wo der Beitrag zur digitalen Sicherheit oben aufhört. Mögliche präventive Aktivitäten wären etwa die Identifizierung potentieller Gefahrenszenarien, Erhebungen inwieweit diese Probleme tatsächlich bestehen, Identifizierung von potentiellen Schutzmaßnahmen sowie Vernetzung mit anderen betroffenen Akteuren und staatlichen Stellen. Mögliche anlassbezogene Aktivitäten würden die Unterstützung konkret Betroffener oder die Reaktion auf akute Gefahrenszenarien umfassen. Es gäbe hier sicherlich viele Fragen, die man diskutieren kann. Beispiel 1: Soll es für potentiell gefährdete User:innen Schutzsockenpuppen geben, die besonders gute Anonymisierung bieten, da Schutzsockenpuppen nicht mit den Informationen in den regulären Profilen verknüpft sind? Die Aktivitäten, die mit einem Account verknüpft sind, Babelvorlagen oder Informationen in irgendwelchen Uraltversionen irgendwelcher Unterseiten im BNR in Kombination mit Social Engineering oder realen Ermittlungen vor Ort könnten die sicher geglaubte Anonymität von User:innen gefährden. Beispiel 2 wäre, ob bestimmte Bearbeitungen unsichtbar geschaltet werden können, wenn diese zu Gefährdungen führen, oder ob der bearbeitende Account ausgeblendet werden kann. Beispiel 3: Soll eine zentrale Meldemöglichkeit für entsprechende Vorfälle geschaffen werden? Könnte Sinn machen, da Betroffene umständehalber andere Probleme haben dürften, als durch umständliche Recherechen herauszubekommen, wen man für was in der Wikipedia in Marsch setzen muss. Beispiel 4: Ich gehe davon aus, dass es bei Admins, Oversightern oder Wikimedia-Beschäftigten erhebliche Unsicherheiten gibt, wie man sich in derartigen Szenarien verhalten soll. Ähnlich gelagerte (verständliche) Unsicherheiten sind etwa bei Hochschulleitungen zu beobachten. Könnten hier Richtlinien helfen? Oder vielleicht auch schon die Möglichkeit, wie auch immer geartete Unterstützung anfordern zu können? Wenn hier Bedarf gesehen wird, könnte ein Projekt eingerichtet werden, dass diese und/oder andere einschlägige Aspekte bearbeitet. Das Ergebnis kann natürlich sein, dass doch kein Bedarf besteht. Wäre schön... Viele Grüße, --Espresso robusta (Diskussion) 16:22, 25. Aug. 2024 (CEST)

Verlinke doch mal, wie sich "Akteure im Wissenschaftbereich (DFG, DAAD, AvH etc.) auf die hier skizzierten Probleme vorzubereiten". Das würde glaube ich helfen, deine Anfrage zu verstehen. --Jensbest (Diskussion) 17:01, 25. Aug. 2024 (CEST)

Es wird schwierig sein, Informationen aufzufinden, die die oben angeführten Punkte spezifisch behandeln. Der Wissenschaftsbereich hat jedenfalls seine Unschuld aus der Frühphase der Globalisierung verloren. Bezüglich Wissenschaftspionage gibt es beispielsweise ein Informationsportal des Bundesamtes für Verfassungsschutz. Eine Handreichung des BMBF zu Kooperationen mit chinesischen Partnern behandelt auf geboten diplomatische Weise auch Probleme, die hier auftreten könnten. Viele Diskussionen, die die Gefährdung von Wissenschaftlerinnen und Wissenschaftlern beinhalten, werden in einem eher informellen Kontext geführt, und die Informationen, die man dabei erhält, sind häufig vertraulich. Es dürfte eine gute Idee sein, erstmal die oben angeführten Wissenschaftsorganisationen sowie vielleicht den ERC zu kontaktieren und um Informationen zu bitten, die die Diskussion hier weiterbringen. Ich würde dies tun und dann berichten. Viele Grüße, --Espresso robusta (Diskussion) 17:45, 25. Aug. 2024 (CEST)

In der Wikimedia Foundation gibt es z.B. das Team Human Rights, das sich nach meinem Verständnis um solche Themen kümmern sollte. Ich habe aber keinen Überblick, was da in der Vergangenheit gemacht wurde, insbesondere mit Bezug zur de.wp. --Magiers (Diskussion) 18:18, 25. Aug. 2024 (CEST)

Genau Human Rights (und irgend ein anderes Projekt (Name vergessen) ebenso) kümmert sich um solche Probleme. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Wenn du mich anpingen möchtest, pinge bitte mich und nicht meine Diskussionseite an. 10:21, 26. Aug. 2024 (CEST)

Die Anfrage ist etwas rätselhaft.

• Die Problematik ist seit Jahrzehnten bekannt.
• Bei WMF sind es Trust & Safety sowie seit jüngerer Zeit Human Rights, die das gezielt angehen sollen und vorbeugende Ratschläge veröffentlicht haben.

Bei Wikis ist Anonymität der Dreh- und Angelpunkt.

• WP:ANON ist uralt, mit jeweils zeitgenössischer Bedrohungsanalyse.
• Wer unter Realnamen arbeitet, auch noch den Wohnort plakatiert, der kann mit allen Mitteln der realen Welt bis zum Telefonbuch identifiziert werden, und ist vielleicht auch unter Klarnamen in sozielaen Medien unterwegs. Da kann Wiki wenig bewirken.
• Auch wer einen nicht auflösbaren Nick verwendet, kann vielleicht anhand einer sehr spezifischen Thematik, gelegentlichen Angaben zum Beruf, regionalem Bezug von Fachkundigen auf einen minimierten Personenkreis bis zur Einzelperson eingegrenzt werden.
• Mich persönlich wird man nur nach Lebensalter, DE und ungefährem Berufsweg fokussieren können; blieben wahrscheinlich fast eine Million Menschen zur Auswahl.
• Wer andere User de-anonymisiert, wird geeignet administrativ sanktioniert je nach beiläufigem oder vorsätzlichem Handeln, und in Wiki-Seiten werden entsprechende Informationen versteckt.
• Mittel der Anonymität ist die Anmeldung, wodurch die technischen Zugangsdaten geschützt werden. Die „anonyme Mitarbeit“ legt hingegen gerade die IP-Adresse offen.

„Akteure im Wissenschaftbereich“

• Die sind unter Klarnamen unterwegs. Komplett andere Baustelle. Nicht unsers.

Technischer Datenschutz

• Seit immer schon gilt das Prinzip der Datensparsamkeit. Lesende Zugriffe werden nur aus technischen Gründen zur Abwehr von Angriffen für wenige Tage aufgezeichnet und danach rückstandslos beseitigt.
• Bearbeitungen und andere Aktionen werden für 90 Tage aufgezeichnet, und technische Transaktionen sind nur besonders ausgewählten WP:CU zugänglich, deren Aktivität ihrerseits aufgezeichnet und überwacht wird.
• Aus dem letzten Jahrhundert stammt die wenig weitsichtige Idee, bei unangemeldeten Aktivitäten die IP-Adresse in die Wiki-Seiten und Logs hineinzuschreiben, was schon seit anderthalb Jahrzehnten beanstandet wird. Demnächst soll dieses System abgelöst werden durch Pseudo-Namen, die zumindest der breitesten Öffentlichkeit die IP-Adresse verbergen (sie allerdings immer noch größeren Kreisen an Insidern zugänglich machen).

VG --PerfektesChaos 12:00, 26. Aug. 2024 (CEST)

Leider gibt es schon einige Mitwikipedianer, die in Schurkenstaaten eingesperrt wurden, weil sie Wikipedia editierten. en:List of people imprisoned for editing Wikipedia. Der OP fürchtet vielleicht, dass dies bald auch in D passieren kann. Ob die aktuelle Vorbeugung und die geplante IP-Adressmaskierung ausreichen würde gegen solche staatlichen Akteure, sagen wir gegen einen BND unter neuer Leitung und mit erweiterten Aufgaben, würde ich bezweifeln. Es wäre dann sicherer, im Inland nichts mehr zu schreiben und dewiki an die Expatriates zu übergeben. --MBq ^Disk 22:45, 26. Aug. 2024 (CEST)

Community-Wunschliste: Lass uns diskutieren, wie wir die Auffindbarkeit und Wiederverwendbarkeit von Vorlagen verbessern können

Hallo zusammen,

Die neue Community-Wunschliste hat jetzt einen Fokusbereich namens Wiederverwendung und Auffindbarkeit von Vorlagen. Dieser Fokusbereich enthält beliebte Wünsche aus früheren Ausgaben der Wunschliste:

• Wunsch #1: Infoboxen schnell hinzufügen – eine einfachere Möglichkeit für neue Autoren, um verbreitete Vorlagen wie Infoboxen zu finden und einzufügen.
• Wunsch #2: Favoriten und verwandte Vorlagen schnell hinzufügen – eine Möglichkeit, um kürzlich genutzte Vorlagen und Favoriten-Vorlagen für die häufige Nutzung von Vorlagen anzuzeigen.
• Wunsch #3: Vorlagen nach Kategorien auswählen – eine Möglichkeit, um Vorlagen anhand ihres "Typs" zu finden.
• Wunsch #4: Einfacher Zugriff auf Vorlagen – Benutzern dabei helfen, den Vorlagendialog zu konfigurieren, um verbreitete Vorlagen und Favoriten-Vorlagen anzuzeigen.

Wir haben auf der Fokusbereich-Seite geteilt, wie wir dieses Problem sehen und wie wir es angehen wollen. Wir haben auch einige Design-Entwürfe, die wir dir zeigen.

Wir laden dich ein, diesen Fokusbereich zu diskutieren und hoffentlich zu unterstützen (oder uns wissen zu lassen, was wir verbessern müssen). Du kannst deine Rückmeldungen auf der Diskussionsseite des Fokusbereichs hinterlassen.

Im Namen von Community Tech, STei (WMF) (Diskussion) 19:56, 18. Sep. 2024 (CEST)

Wikipedia ist öffentlich!

Hallo, leider kommt es immer wieder vor, dass neue Benutzer von der falschen Annahme ausgehen, es gäbe bei Wikipedia so etwas wie „nicht-öffentliche Hinterzimmer-Seiten“, wo man auch mal persönliche Daten preisgeben kann (die man oft genug dann per OS entfernen muss). Daher wäre vielleicht mal ein entsprechend deutlicher Hinweis auf einer prominenten Hilfeseite angebracht. Ein Vorschlag meinerseits, den auch die anderen Oversighter für eine gute Idee halten, wäre z.B. ein zusätzlicher Punkt Wikipedia ist öffentlich! als dritter Abschnitt unter dem Punkt "Grundsätzliches" auf Hilfe:Allgemeine FAQ:

Alle, wirklich alle, Seiten in der Wikipedia sind öffentlich einsehbar für jederman. Dies gilt für alle Namensräume, also für Artikel und Artikel-Diskussionen ebenso wie für Benutzer- und Benutzer-Diskussionsseiten sowie Funktions- und Hilfeseiten und alle deren Versionsgeschichten. Ausnahmen gibt es nur, wenn Teile von Administratoren oder Oversightern gelöscht wurden.
Das schafft einerseits vollkommene Transparenz in Bezug auf die Funktionsweise der freien Enzyklopädie. Es nimmt aber andererseits jeden, der mitmachen und helfen will, in die Verantwortung, achtsam mit seinen persönlichen Daten (Klarnamen, Telefonnummer, email-Adressen,...) und denen von anderen Mithelfenden sowie von biografierten Persönlichkeiten umzugehen.

Was aber hält die geschätzte Wikipedia-Gemeinde davon? @Doc Taxon, Nolispanmo, Stefan64, Werner von Basil: zur Info. -- Ra'ike _Disk. ^P:MIN 18:25, 7. Okt. 2024 (CEST)

Auf diesen Text sollten auch die Begrüßungsbausteine für neue Benutzer verlinken. Vielleicht noch ergänzen:

... achtsam mit seinen persönlichen Daten und denen von anderen Mithelfenden sowie von biografierten Persönlichkeiten umzugehen. (Klarnamen, Telefonnummer, email-Adressen ...)

--tsor (Diskussion) 19:04, 7. Okt. 2024 (CEST)

falls es was hilft, könnten wir auch probieren, Spezial:Missbrauchsfilter/63 auszubauen. --Johannnes89 (Diskussion) 19:31, 7. Okt. 2024 (CEST)

Halte ich für sinnvoll. Nur zu. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 20:09, 7. Okt. 2024 (CEST)

+1 Zustimmung dazu. --Ichigonokonoha (Diskussion) 20:15, 7. Okt. 2024 (CEST)

Ein ultrakurzer Hinweis bei den Begrüßungsbausteinen wäre noch am ehesten zielführend.

• Hilfe:Allgemeine FAQ liest kein Mensch, und dorthin zu gelangen ist auch nicht übermäßig intuitiv.

Das dargestellte Problem leidet unter dem grundsätzlichen Dilemma:

• Wer aus der Draußenwelt kommt, muss erstmal Tausende von Dingen lernen, was Wochen und Jahre dauert.
• Es ist nicht möglich, alle ach so freundlich gemeinten Hinweise so unterzubringen, dass sie verstanden und ab sofort umgesetzt werden.
• Das führt zum AGB-Syndrom: Der Text mit allen Belehrungen wird so lang und unübersictlich, dass er von vornherein abschreckt, und niemand auch nur anfängt ihn zu lesen.
• Der Umstand, dass irgendwo noch ein Satz steht, oder noch ein Link angeboten wird, oder beides, führt nicht dazu, dass das was da steht verstanden und verinnerlicht und umgesetzt wird.
• Das Gegenteil ist der Fall: Je mehr Hinweise, desto weniger werden beachtet, bis zu Null.
• Das Hauptziel ist das Bearbeiten von Artikeln, und darauf muss der Schwerpunkt liegen, und das ist schon komplex genug: Belegpflicht, Bedienung der Wiki-Technik, WWNI und RK.
• All die vielen anderen Sachen, die es auch noch zu lernen gibt, brauchen Zeit.
• Es ist schlicht nicht realisierbar, eine kleine Textbox hinzuschreiben und anschließend sind die Leute erfahrene Wikipedistas.

Der Button wurde schon vor Jahren von traditionell „Speichern“ heute mit „Veröffentlichen“ beschriftet.

• Hintergrund war die globale Beobachtung, dass Newbies nicht klar war, dass ihre Bearbeitungen sofort öffentlich sind.
• Insbesondere bei den eigenen Benutzerseiten kommt gelegentlich der Glaube auf, das wäre wie bei den asozialen Hetzwerken ein privates Profil, das niemand sonst sehen könnte.

VG --PerfektesChaos 21:14, 7. Okt. 2024 (CEST)

Ich weiß nicht, ob für jedermann oder jemanden neues "Veröffentlichen" insofern klarstellt, dass Daten veröffentlicht werden. Ich meine, der Unterschied zwischen Speichern und Veröffentlichen ist eher nur einer Minderheit wirklich bzw. bewusst präsent. Mehr Hemmungen, auf den Button zu drücken, hätte man vielleicht, wenn da stünde "Veröffentlichen ohne Verstoß gegen die DS-GVO". Oder "Veröffentlichen ohne personenbezogene Daten". Oder: nach Click auf Veröffentlichen kommt noch mal ein Bestätigungsfeld, das auf darauf hinweist, was nicht passieren sollte, wenn der Text veröffentlicht wird. – Doc Taxon • Disk. • 22:09, 7. Okt. 2024 (CEST)

Hilfe:Benutzernamensraum schreibt in der Einleitung seit einiger Zeit: „Sie können aber trotzdem auch außerhalb der Wikipedia von jedem eingesehen …“

• Was in den Nuller Jahren nicht erforderlich war, weil damals die Idee von einem privaten Profil in der Draußenwelt nicht gehegt wurde.
• Aber wer liest schon auch noch diese Hilfeseite als Newbie und nimmt dann dieses Detail wahr?

„Veröffentlichen ohne Verstoß gegen die DS-GVO“

• Das begreift niemand.
• Auch nicht die Konsequenzen.
• Wobei es kein Verstoß gegen die DS-GVO wäre, hier mit eigenem Willen persönliche Kontaktdaten hinzuschreiben, sondern unsere interne Praxis sowas nicht sehen möchte. Offenlegung von Daten anderer Personen wäre wieder was anderes, hat aber in einem Einzelfall wenig mit „DS-GVO“ zu tun.
• Eine Button-Beschriftung muss sehr kurz sein; nachstehend die Leiste und dort auch viele Symbole, mit deren Hintergründen man sich auch erstmal vertraut machen müsste.

Seite veröffentlichen

Absatz

Belegen

Einfügen

• Und nochmal ein Fenster aufpoppen zu lassen, das man nochmal bestätigen soll, wäre nur extrem nervtötend und wird nur ungelesen weggeklickt.
• Die Angelegenheit betrifft vielleicht einen von 100 Newbies, aber mehr oder weniger auf ewig werden alle Bearbeitungen mit so einem Fenster dekoriert, selbst wenn sie überhaupt nichts in der Richtung enthalten und niemand solche Absichten hätte.

Um es zusammenzufassen:

• Das Ansinnen ist nett gemeint.
• Es zielt jedoch auf eine von 100 Regeln ab, die Newbies erst erlernen müssen, was nicht an einem Tag passiert, und was nicht dadurch sofort verinnerlicht würde, dass irgendwo ein Hinweis oder eine Verlinkung stünde.
• Da ist ein individueller Lernprozess erforderlich, und der wird erst dadurch angestoßen, dass einige erstmal etwas falsch machen. Aber diesen einen Fehler macht 1 von 100 und 99 kommen niemals in diese Situation.
• Sehr viele Leute machen sowas mit dem allerersten Edit in der WP, ggf. auf einer Diskussionsseite, haben noch niemals eine Hilfeseite gesehen und streben keinerlei Autorenkarriere an. Da laufen alle Bemühungen ins Leere.

VG --PerfektesChaos 13:50, 8. Okt. 2024 (CEST)

Na ja, Lernprozess hin oder her. Die oben im Kasten genannten Zusammenhänge bezüglich der öffentlichen Zugänglichkeit aller Wikipediaseiten steht meines Wissens aber trotzdem bisher nirgendwo in dieser Deutlichkeit zusammengefasst. Tsors Idee, den Text (gern auch in noch etwas komprimierterer Form) in die Begrüßungsbausteine mit aufzunehmen, ist auf jeden Fall ein Anfang. Den vorgeschlagenen Zusatz habe ich auch mal oben in den Kasten mit aufgenommen.

Dass bei Neulingen trotzdem immer wieder der Fehler vorkommen wird, unabsichtlich persönliche Daten preiszugeben, lässt sich sicher nicht ganz vermeiden. Es muss dann aber zumindest mal möglich sein, auf dieses irgendwo (idealerweise möglichst zentral) festgehaltene "Grundprinzip" der Öffentlichkeit von Wikipedia hinzuweisen und/oder zu verlinken (intern wie extern per Mail).

@Johannnes89: Ich weiß leider nicht, ob und wie sich der Spezial:Missbrauchsfilter/63 ausbauen ließe. Könnte man damit verhindern, dass jemand im Artikeltext und im Änderungskommentar zumindest keine Telefonnummern und EMail-Adressen hinterlassen kann? Viele Grüße -- Ra'ike _Disk. ^P:MIN 18:44, 9. Okt. 2024 (CEST)

WP:ANON ist der eigentliche Punkt, wo dies verbindlich dargestellt sein muss, und die zuständige Seite, wo das auffindbar sein müsste.

Hier geht es ja offenbar um die Situation „Der Benutzer gibt seine Daten selbst preis“

• Deren Nennung wird ausdrücklich erlaubt, sowohl „E-Mail-Adresse, Telefonnummer, Anschrift, Arbeitsstelle oder das Alter“ wie auch deren spätere Verwendung durch andere: „ist es unbedenklich, sie auch zu nennen“.

Ob das heutzutage noch schlau ist, sich im Netz öffentlich und leicht angreifbar zu machen, ist eine andere Frage.

• Verboten ist das jedenfalls nicht, und ein „Verstoß gegen die DS-GVO“ wie oben suggeriert ist es auch nicht, seine eigene E-Mail-Adresse zu nennen.
• Wer mit dem Smartphone geboren wurde, kennt das Konzept „Privatsphäre“ kaum noch, und schreibt sowas bedenkenlos überall hin.

Zuerst müsste WP:ANON aktualisiert werden.

• Eine FAQ darf keine eigenmächtigen privaten Regeln aufstellen, die nicht von den allgemeinen Richtlinien gedeckt sind.

Hier geht es aber letztlich auch nicht um Verstöße gegen ANON, sondern um heutzutage von Menschen mitgebrachten Vorstellungen von privaten Profilseiten, dass irgendwas in der Wikipedia nicht global mitlesbar wäre.

• Das sind auch nur kleine Teile der Menschen, und vermutlich eher aus der Smartphone-Generation.
• Diese glauben irrtümlich, in „ihrem“ BNR wären sie völlig unbeobachtet.
• Weil es in der Auswirkung ANON berührt, wäre ein Hinweis auf öffentliche Sichtbarkeit aller Seiten am besten auffindbar in einem neuen Abschnitt von WP:ANON untergebracht.
• Hilfe:Benutzernamensraum schreibt es in der Einleitung ebenfalls schon.

VG --PerfektesChaos 13:58, 10. Okt. 2024 (CEST)

Es geht nicht nur um eigene Daten sondern auch um Daten Dritter. Wenn sich ein Neuer etwa so vorstellt:Hallo, bin der Karl Meyer aus Fulda. AUfmerksam geworden auf die Wikipedia bin ich durch meinen Freund Detlev Dumpfbacke aus Sickels, der hier als "tsor" aktiv ist. --tsor (Diskussion) 16:28, 10. Okt. 2024 (CEST)

Das wäre dann jedoch ein klarer ANON-Verstoß, weil ein fremder Nick mit einem Realnamen in Verbindung gebracht wird.

• Gleichwohl würden Newbies ggf. nicht wissen, dass dies unerlaubt sei.

Hier geht es jedoch um die Öffentlichkeits-Frage, und ob das in der irrigen Annahme geschehen sei, dies wäre nicht allgemein sichtbar.

• Wenn ich mich aber auf einer „Profilseite“ der Welt vorstelle, wer ich bin und was ich mache, dann geschieht das in der Erwartung, dass Außenstehende meine Selbstvorstellung auch sehen können. Falsche Annahmen über öffentliche Sichtbarkeit können hier kaum relevant sein.

VG --PerfektesChaos 21:08, 10. Okt. 2024 (CEST)

Ra'ike, zum letzten Absatz: ja, das ist möglich. Näheres dazu unter WP:Bearbeitungsfilter/63#Ausweitung. --TenWhile6 10:17, 13. Okt. 2024 (CEST)

Hinweis umgesetzt per Wikipedia:Anonymität #öffentlich. VG --PerfektesChaos 15:33, 22. Okt. 2024 (CEST)

 Info: Alle, die im BNR eine neue Seite anlegen, bekommen MediaWiki:Newarticletext-2 zu sehen.

• Darin steht seit 2012: „Jede Benutzerseite ist nach Erstellung sofort öffentlich einsehbar.“
• Heißt: Die Leutchen, die trotzdem noch glauben, auf dieser „ihrer“ BNR-Seite wäre irgendwas „privates Profil“, sind mit jeglicher Art von Hinweis überfordert, egal wo. Das erfolgt jetzt schon mit Anlage der Seite, ausnahmslos für alle, egal ob neu oder nicht neu.
• Ziel des Projekts ist die Erstellung einer Enzyklopädie anhand belegter relevanter Informationen, und nicht an jeder erdenklichen Ecke erneute Hinweise zu „privaten BNR-Seiten“ zu plakatieren.
• Dass noch mehr Hinweise an unpassenden Stellen irgendeinen Fortschritt bringen würden, ist nicht plausibel; aber je mehr Bequatschung passiert, desto weniger wird irgendwas davon noch wahrgenommen.

VG --PerfektesChaos 14:23, 13. Nov. 2024 (CET)

Update zum neuen Werkzeug für die Vandalismusbekämpfung – Automoderator

Hallo allerseits, ich bin Sam Walton, der Produktmanager des Moderator-Tools-Teams bei der Wikimedia Foundation. Wir entwickeln aktuell ein Werkzeug namens Automoderator, das automatisch schädliche Bearbeitungen auf der Grundlage eines Modells maschinellen Lernens und von der Community festgelegter Regeln zurücksetzen kann. Automoderator wird jetzt von der türkischen, der indonesischen und der ukrainischen Wikipedia-Community genutzt und wir diskutieren die Aktivierung in anderen Projekten. Wir denken, dass eure Community an Automoderator interessiert sein könnte; deshalb wollten wir ein kurzes Update geben, um euch zum Testen einzuladen und euch die Möglichkeit zu geben, uns etwaige Fragen zur Nutzung der Software zu stellen.

Automoderator nutzt aktuell ein sprachunabhängiges Modell, das jede Wikipedia-Sprachversion unterstützt. Wir prüfen derzeit, ob wir ein mehrsprachiges Modell nutzen könnten, da wir glauben, dass ein solches in den 47 unterstützten Wikipedia-Sprachversionen die Leistung stark verbessern kann. Wir brauchen eure Hilfe, um zu verstehen, wie dieses Modell mit den letzten Änderungen in eurem Projekt umgehen kann – bitte lest mehr über unser Testverfahren und beteiligt euch, indem ihr Bearbeitungen aus einem Datensatz bewertet. Das wird uns dabei helfen, die Genauigkeit und Reichweite des Modells zu verstehen, was wir euch dann rückmelden werden, damit ihr eine Entscheidungsgrundlage habt, ob ihr Automoderator in eurem Projekt nutzen wollt oder nicht.

Automoderator kann jetzt für euer Wiki über diese Schritte beantragt werden. Ihr erfahrt mehr über das Werkzeug auf der Projektseite. Wenn ihr Fragen zur Software habt oder an ihrer Nutzung interessiert seid, lasst es mich bitte wissen! --Samwalton9 (WMF) (Diskussion) 17:58, 11. Okt. 2024 (CEST)

Hi Sam, ein solches KI-Tool, welches in den letzten Diskussionen eher keine große Zustimmung gefunden hat, da wir im Bereich RC durch viele fleißige Menschen recht gut aufgestellt sind, kann meiner Einschätzung nach hier nicht ohne Meinungsbild eingeführt werden. Das sehe ich aber eher nicht. Viele Grüße --Itti 18:27, 11. Okt. 2024 (CEST)

Dass es dafür Communitykonsens bräuchte, steht auch für die WMF außer Frage, entsprechend der Hinweis, dass Projekte die Aktivierung beantragen müssen (siehe auch mw:Extension:AutoModerator/Deploying#0. Community consensus). In der Tat zeigen frühere Diskussionen wie Wikipedia:Projektdiskussion/Ein neues Tool zur Vandalismusbekämpfung – Automoderator, dass es in dewiki wohl keinen Konsens für die Nutzung des Tools geben wird bzw. dass man ein erfolgreiches MB bräuchte (und eine Mehrheit per MB sehr unwahrscheinlich wirkt).

Ich persönlich fänd es weiterhin interessant, wenn man das Tool in einer Variante nutzen könnte, wo es verdächtige Edits irgendwo meldet oder markiert, ohne selbst zu revertieren. Aber das hat (zurecht) keine Prio, wenn die meisten anderen Projekte das Tool in der angebotenen Form dankend akzeptieren. Dann nutzen wir es halt nicht, im Gegensatz zu den meisten anderen Projekten haben wir Vandalismus und Spam auch ganz gut im Griff. Wenn man bedenkt, dass Projekte wie die portugiesische oder farsi Wikipedia schon seit längerem IP-Edits unterbinden, weil sie anders nicht mehr mit Vandalismus zurecht kamen, freuen die sich über automatisierte Hilfe...

Übrigens: Mit Blick auf die Statistik in mw:Moderator Tools/Automoderator/Testing#Caution levels wäre das Tool relativ zurückhaltend, je nach "caution"-level käme es im Durchschnitt auf 14-89 Reverts pro Tag in dewiki, also nur ein Bruchteil der durchschnittlich täglich 1.670 Reverts durch dewiki Autor*innen. --Johannnes89 (Diskussion) 22:01, 11. Okt. 2024 (CEST)

Ein Tool, das gerade mal jeden hundertsten notwendigen Revert macht, klingt aber auch nicht gerade rasant nützlich. Insbesondere da das dann nur die Form von Vandalismus sein wird, die ohnehin jedem auffällt und bei uns wegen den gesichteten Versionen nie angezeigt wird. Da finde ich es nachvollziehbar, dass man wegen so einem geringen Nutzen keinen Präzedenzfall für KI-Eingriffe schaffen will. Die KI müsste schon etwas leisten, was über die durchschnittliche menschliche Wahrnehmung hinausgeht. Einfallen würden mir die m.E. unzureichend gegen Vandalismus geschützten Kurzbeschreibungen in Wikidata. Ein Projekt wie Wikidata, in dem sowieso vieles automatisiert abläuft, könnte mit so einem automatischen Schutz vielleicht mehr anfangen. --Magiers (Diskussion) 00:58, 12. Okt. 2024 (CEST)

Dafür spricht der Nutzen - wenn es fertig und erprobt wäre. Gegen einen breiten Einsatz jetzt die genannten Probleme. Kann man sowas nicht in einem supervidierten Modus anbieten? Also zum Finden - den Revert muss ein Mensch bestätigen. Vielleicht findet das besser als die vorhandene Konkurrenz. Dieser Mensch muss aber erfahren sein. Admin? Betreffs Wikidata: Dort sind mehrere Einträge für gleiche Objekte (zusammenführen?) und unbequellte Eigenschaften nach meiner Erfahrung zwei Probleme. Wenn man letzteres löscht, würde das ziemlich ausgedünnt und bei Quellensuche hat KI immer noch Probleme. Wikidata braucht was Soezifisches. Das jetzt als Trainingsgrundlage für KI durch Wikimedia anzubieten, ist schon riskant genug. Wortulo (Disk. * KI-Projekt) 07:55, 12. Okt. 2024 (CEST)

Gudn Tach!

• Aktuell würden wir wohl eine Katze im Sack kaufen ("bezahlen" würden wir mit initialem Zeitaufwand), was das Risiko birgt, dass bei Unausgereiftheit der konservative Teil der Community (a la "brauchen wir nicht, läuft doch alles und wird immer so bleiben") das Tool wieder abgelehnt und deaktiviert (verbrannt) würde und für viele Jahre kein neuer Anlauf mehr möglich wäre.
• Beim edit filter haben wir die Möglichkeit, potentiell verhinderte Edits einfach mitzuloggen. Sowas stelle ich mir auch hier sinnvoll vor, also ein Log der potenziell zu revertierenden Edits (also mit einem Score > 0.97) inkl. Score. Das könnte man ein paar Monate nebenher mitlaufen lassen und währenddessen kontrollieren. Ich wäre sicherlich nicht der Einzige, der sich das mal anschauen würde. Danach könnte man eine Evaluation erstellen, um eine Entscheidungsgrundlage zu haben. Sinnvollerweise sollten dabei auch schon false positives markiert werden können, damit das System sich verbessert.
• Wenn das Tool nicht gut funktioniert, kann man das feedbacken und um Verbesserung bitten. Es ist auch möglich, dass wir nach ein paar korrigierten Anläufen merken, dass es uns tatsächlich aktuell und auch auf absehbare Zeit nix taugt. Aber eine pauschale Ablehnung ohne es auszuprobieren, halte ich für kurzsichtig bis irrational.
• Selbst wenn zu Beginn nur ein Dutzend Edits pro Tag verhindert würden, fände ich es wichtig, ein solches Tool auszuprobieren, 1. weil es weiterentwickelt wird (und wir die Weiterentwicklung beeinflussen können), 2. weil auch Vandalismus sich weiterentwickelt und 3. weil auch eine kleine Entlastung eine Entlastug ist. Wir können nicht davon ausgehen, dass auch in Zukunft (in 10, 20 oder 30 Jahren) die Eingangskontrolle so gut funktioniert wie jetzt, sondern sollten schauen, was langfristig vielleicht für uns nützlich sein könnte.

-- seth (Diskussion) 11:48, 12. Okt. 2024 (CEST)

Auch hier, ohne Meinungsbild ist eine solche tiefgreifende Änderung nicht drin. Es ist ein Paradigmenwechsel, die Menschen in diesem Projekt werden Schritt für Schritt abgeschafft, eine "künstliche Intelligenz" übernimmt. Zunächst wenig, dann immer mehr. Schlussendlich sind Menschen überflüssig. --Itti 11:55, 12. Okt. 2024 (CEST)

Zum ersten Satz: Das hast du oben bereits gesagt und ich sage ja nichts gegen ein MB nach einer Evaluationsphase.

Die beiden anderen Sätze halte ich für unsachlich.

-- seth (Diskussion) 12:45, 12. Okt. 2024 (CEST)

Ich nicht und dir steht es nicht zu über meine Befürchtungen zu urteilen. --Itti 17:23, 12. Okt. 2024 (CEST)

Ich bin grundsätzlich dagegen. Automatisierte Abläufe sind beim Umgang mit Menschen grundsätzlich nicht hilfreich, und darum geht es hier. Ich kann nicht mal erkennen, welchen Sinn ein Test haben sollte. Der Schaden ist grundsätzlicher Natur: Reverts müssen immer von Menschen verantwortet werden. Lässt man sie durch eine technische Instanz vornehmen, zerstört man den Charakter und die Vertrauenswürdigkeit und Ansprechbarkeit der Wikipedia. --Mautpreller (Diskussion) 12:02, 12. Okt. 2024 (CEST)

Wir haben schon seit über 15 Jahren Tools, die das Speichern bestimmter Edits sogar verhindern (z.B. WP:SBL). Dass die Vertrauenswürdigkeit und Ansprechbarkeit der Wikipedia dadurch zerstört worden sei, ist offensichtlich nicht der Fall.

Ein Revert wäre sogar transparenter als die bisherigen Tools, weil nicht nur Admins sehen würden, was ein Algorithmus als schädlich klassifiziert. Die Kontrolle wäre weiterhin bei der Community.

-- seth (Diskussion) 12:42, 12. Okt. 2024 (CEST)

Doch, auch die Filter wirken bereits destruktiv auf die Ansprechbarkeit, wie sich vielfach gezeigt hat. Immerhin funktionieren sie wenigstens regelgeleitet. Das tut ein Tool dieses Typs prinzipiell nicht, es arbeitet eben nicht regelbasiert, sondern nach statistischen Korrelationen. Das lehne ich grundsätzlich ab. --Mautpreller (Diskussion) 13:01, 12. Okt. 2024 (CEST)

Auch die Regeln im Edit-Filter basieren häufig nur auf statistischen Korrelationen, allerdings auf weitaus primitiveren als es bei dem vorgestellten Tool der Fall wäre.

Eine Regel im Edit-Filter ist lediglich in ihrer Funktionalität nachvollziehbarer (zumindest für einige wenige Techies). Im Ergebnis wäre jedoch das neue Tool nachvollziehbarer, weil nicht nur Admins auf die revertierten Edits Zugriff hätten.

-- seth (Diskussion) 13:38, 12. Okt. 2024 (CEST)

Nö, die Filter haben vorgegebene Regeln, worauf auch immer sie basieren. Das neue Tool würde sich seine Regeln selbst basteln und man könnte nicht eingreifen. Das lehne ich grundsätzlich ab. Es ist schlimm genug, dass Menschen allzu häufig verfehlte Reverts vornehmen, die kann man aber wenigstens dafür verantwortlich machen. Die KI kann man nicht mal ansprechen. Macht ein Meinungsbild (bitte mit Zweidrittelmehrheit, da grundsätzliche Veränderung), ich werde es ablehnen. --Mautpreller (Diskussion) 15:05, 12. Okt. 2024 (CEST)

Nur, weil die Regeln im Edit-Filter von Menschen explizit erstellt wurden, heißt das nicht, dass sie immer durchdrungen werden oder weniger Nebenwirkungen haben. Wenn ich z.B. per Filter die Zeichenkette "Schwanz" verbiete, verbiete ich damit auch Wörter wie "Schwanzucht". Das ist natürlich nur ein vereinfachtes Beispiel. Aber letztlich geht es bei sowas immer um die Frage nach den false positives -- selbst bei komplett menschlichen Reverts.

Beim neuen Tool könnten wir übrigens sehr wohl eingreifen und zwar nicht nur durch einen Re-Revert, sondern auch durch Bewertung der automatischen Reverts. False positives können nämlich gemeldet werden und werden dann für die Verbesserung des Tools genutzt.

Meinungsbild: Soweit sind wir noch gar nicht. Man sieht ja hier, dass aktuell die Skepsis/Ablehnung groß genug ist. Erstmal bräuchten wir einen Test, eine Vor-Evaluation. Danach könnte man faktenbasiert diskutieren und überlegen, ob ein MB sinnvoll wäre.

Was ich hier in der Diskussion lese, sind (nicht nur, aber eben) insb. Vorbehalte, die darauf schließen lassen, dass die Technik nicht hinreichend verstanden wurde, was zu teilweise irrationalen Ängsten führt bis hin zu Terminator-ähnlichen Dystopien.

Skepsis ist auf jeden Fall angeraten. Niemand hier ist der Ansicht, dass einem solchen System blind vertraut werden könne/dürfe.

Ein wichtiger Punkt, den du ansprichst, ist die Verantwortung. Das ist ja auch eine große Frage da draußen in der Welt, z.B. wenn ein selbstfahrendes Auto in einen Unfall verwickelt ist. Auch jetzt revertieren Bots manchmal Edits und verhindern Tools andere Edits. Man kann die Verantwortung dafür zu einem Teil bei den jeweiligen Erstellern/Software-Entwicklern sehen, zu einem anderen Teil auch bei der Community, die damit einverstanden ist.

Wichtiger finde ich jedoch, den Fokus aufs Ergebnis zu legen. Angenommen die false positives bei der Software wären unwahrscheinlicher als bei einem durchschnittlichen, viel revertierenden Regular. Dann würden weniger Leute vor den Kopf gestoßen als ohne das Tool. Das wäre ein wichtiges Argument für das Tool -- vorausgesetzt, es würde stimmen (dafür bräuchten wir eine Evaluation). Wenn die Quote dagegen schlechter wäre als beim Regular, dann hätte das Tool für uns aktuell keinen Nutzen, weil wir (anders als manch andere Wikipedias) das Glück haben, bei der Eingangskontrolle gut aufgestellt zu sein.

-- seth (Diskussion) 16:39, 12. Okt. 2024 (CEST)

„Beim neuen Tool könnten wir übrigens sehr wohl eingreifen und zwar nicht nur durch einen Re-Revert, sondern auch durch Bewertung der automatischen Reverts. False positives können nämlich gemeldet werden und werden dann für die Verbesserung des Tools genutzt.“ Genau das ist eben nicht korrekt. Man kann eben nicht kontrollieren, wie das Tool "reagiert". Man gibt die Verantwortung für das "richtige" Ergebnis ab. Es ist wie ein Spamfilter in Office: Der macht nicht mehr viele Fehler, aber man hat keine Kontrolle drüber, sondern muss täglich in seinen Spamordner gucken, ob das Tool wieder mal aus unerfindlichen Gründen einen beruflichen Kontakt als verdächtig gebrandmarkt hat. Vielleicht "lernt" es, aber das heißt nicht, dass es nicht einen ganz ähnlichen Fehler morgen wieder macht. Dafür brauche ich keinen Test. Völlig unabhängig vom Ergebnis: Das wäre eine Entwicklung zum Schlechteren. --Mautpreller (Diskussion) 18:33, 12. Okt. 2024 (CEST)

PS: Auch für einen Test brauchst Du ein Meinungsbild. --Mautpreller (Diskussion) 18:47, 12. Okt. 2024 (CEST) Ich widerspreche ausdrücklich jedem Versuch, eine solche "Evaluation" ohne formelles Meinungsbild zu beantragen. Du kannst nicht für die Community sprechen.--Mautpreller (Diskussion) 19:18, 12. Okt. 2024 (CEST)

PPS: Noch eins: Den Kram mit den irrationalen Ängsten kannst Du Dir bitteschön komplett und dauerhaft schenken. Solches Zeug habe ich schon zu oft gehört und vertrage es wirklich nicht mehr. --Mautpreller (Diskussion) 18:59, 12. Okt. 2024 (CEST)

@seth: Wie läuft es denn eigentlich bei den derzeit aktiven Filtern? Wird da routinemäßig geschaut, welche Beiträge abgefangen wurden, oder nur bei Nachfragen? --Brettchenweber (Diskussion) 19:44, 12. Okt. 2024 (CEST)

Es gibt mehrere Admins, die regelmäßig ins allgemeine Filterlog schauen (primär aber erstmal generell nach Auffälligkeiten gucken, ohne alle Details anzuschauen).

Für die Filter im einzelnen gibt es meist einen primär zuständigen Admin (meist der, der den Filter angelegt oder übernommen hat), der sich die Logs "seiner" Filter genauer anschaut. Die Häufigkeit solcher Kontrollen variiert, frisch erstellte Filter sollte man täglich korrigieren, je länger sie zuverlässig laufen, desto größer können dann die Intervalle bis zur nächsten Kontrolle werden. Ähnlich sollten natürlich Filter, die mit hoher Frequenz Edits verhindern, häufiger kontrolliert werden, als solche, die eher Nischenprobleme abdecken und nur selten anschlagen.

Ich persönlich versuche 1-4x pro Jahr durch sämtliche Filter zu gehen (da schau ich mir dann aber natürlich nicht das Log des ganzen Jahres, sondern der letzten paar Wochen an) und 1-4x pro Monat durch "meine" wichtigsten Filter (häufiger, wenn sie neu sind...).

Dazu kommen natürlich noch Nachfragen auf den Filterdiskussionsseiten, Admin- oder Supportanfragen usw. wo man dann situativ auf false positives reagiert. --Johannnes89 (Diskussion) 20:40, 12. Okt. 2024 (CEST)

Mautprellers Einwand verstehe ich gut und sehe es im Prinzip ähnlich. Auch Ittis Einwand ist nicht von der Hand zu weisen. Trotzdem stehe ich dem Projekt interessiert gegenüber, denn ich bin der Überzeugung, dass Routinemaßnahmen, die gut und sicher (!) von Maschinen übernommen werden können, zur Entlastung von Mitarbeitern tatsächlich herangezogen werden sollten. Einen Start in der de:WP sehe ich derzeit allerdings auch nicht. Ich schaue mir das Projekt erst einmal genauer an und bilde mir dann ein Gesamturteil. Freundlicher Gruß, --CC (Diskussion) 12:17, 12. Okt. 2024 (CEST)

Grundsätzlich finde ich KI-basierte Programme interessant, aber inzwischen mehrere Jahre arbeitstechnischer Erfahrungen machen mich da sehr vorsichtig. Ein KI-Tool, um in Frage kommende Edits leichter zu finden bzw. diese aufzulisten, würde ich testen, mehr aber nicht. Auch ein Testlauf für automatische Rücksetzungen müsste hier zuerst mit einem MB bestätigt werden.--Gruß, Traeumer (Diskussion) Für eine möglichst wertfreie Wikipedia. 12:22, 12. Okt. 2024 (CEST)

In ein selbstständig löschendes Tool hätte ich kein Vertrauen. Ein lernendes KI-Tool, das lediglich Verdachtsfälle markiert, die dann von Menschen (auch ohne Adminrechte) bewertet werden, finde ich allerdings interessant. --Brettchenweber (Diskussion) 12:33, 12. Okt. 2024 (CEST)

Ich wäre auch eher skeptisch gegenüber einem Tool, was automatisch reserviert - Listen von Edits zur Kontrolle wäre zwar okay - aber tendenziell haben wir davon noch so viele, dass noch eine Liste auch nicht unbedingt einen Mehrwert bieten muss. --Ichigonokonoha (Diskussion) 13:25, 12. Okt. 2024 (CEST)

Ich stimme euch beiden zu. Ich bin ebenfalls skeptisch und würde das gerne eine Zeit lang "trocken" (also ohne Eingriff der Software) ausprobieren.

Der erhoffte Mehrwert käme dadurch zustande, weil eine Lücke geschlossen würde, die per WP:SBL und WP:FILT nicht oder nur extrem umständlich bedient werden kann. Aber auch das müsste man ausprobieren

-- seth (Diskussion) 13:32, 12. Okt. 2024 (CEST)

Etwas, was man prinzipiell nicht will, braucht man auch nicht auszuprobieren. --Viele Grüße, Aschmidt (Diskussion) 17:21, 12. Okt. 2024 (CEST)

Jein. Man braucht etwas nicht auszuprobieren, wenn man rationale Argumente hat, die ziemlich klar sagen, dass die Nachteile dabei überwiegen werden (z.B. sich von einem Hund beißen lassen).

Andererseits werden vermutlich auch einige Leute bei der Einführung der Eisenbahn oder von Computern oder der Wikipedia so pauschal argumentiert haben. Ich halte es jedoch für wichtig, neue Dinge ergebnisoffen anzuschauen. Denn sonst gibt's keinen Fortschritt. -- seth (Diskussion) 19:17, 12. Okt. 2024 (CEST)

Wir vertreten dann eben einen unterschiedlichen Fortschrittsbegriff. --Viele Grüße, Aschmidt (Diskussion) 19:24, 12. Okt. 2024 (CEST)

Oder Atomkraftwerke … einfach mal ergebnisoffen ausprobieren … --Mautpreller (Diskussion) 20:43, 12. Okt. 2024 (CEST)

Wie gesagt: Es ist immer eine Frage der Abschätzung, wie groß die Vorteile und die Nachteile sein könnten (Technikfolgen). Bei AKWs ist beides extrem groß, was zu entsprechend kontroversen Diskussionen führt (mit guten und schlechten Argumenten auf allen Seiten). Bei der hier diskutierten Technik geht es um etwas, bei dem sowohl die Vorteile und die Nachteile absehbar klein sind, zumindest kurzfristig. Um die mittel- bis langfristigen Folgen halbwegs gut abschätzen zu können, fehlen aktuell noch Informationen.

-- seth (Diskussion) 23:31, 12. Okt. 2024 (CEST)

Nein, die Nachteile sind gewaltig, und zwar selbst dann, wenn das Tool nur wenige Fehler macht. Es ist eine Kulturveränderung, die auf Dauer dramatische Folgen haben kann. Schon eine Versuchsphase bräuchte ein Meinungsbild als Legitimation. --Mautpreller (Diskussion) 00:20, 13. Okt. 2024 (CEST)

Außerdem fehlen hier keine Informationen. --Viele Grüße, Aschmidt (Diskussion) 00:35, 13. Okt. 2024 (CEST)

Bevor hier das Kind ganz mit dem Bade ausgeschüttet wird: Es geht um die Vandalismusbekämpfung - damit Menschen in der Wikipedia weiter gesichertes kuratiertes Wissen bereitstellen können, was doch die eigentliche Kultur hier ausmacht. Für sone Sachen wie Wikipedia:Huggle und anderes (auch die Filter?) hat es auch kein MB meines Wissens gegeben. Die Admins werden nicht mehr, die Autoren werden offenbar weniger, der Vandalismus kann in Zeiten von KI neue Formen annehmen, die neue Schutzmechanismen erfordern, wenn die das zukünftig schon in der Grundschule lernen sollen. Wenn es dazu wieder mal ein zentrales Projekt mit Ressorucen gibt, sollte man das meiner Meinung nach unterstützen - aber klare Eckwerte vorgeben. Einer wäre: nur supervidiert in der Entwicklungsphase. Also keine langen Listen produzieren, sondern jemand mit Erfahrung (aktive Sichter aufwärts?) startet das, kriegt Verdachtsfälle gemeldet und entscheidet sofort. Denn offenbar muss man das "schärfer" einstellen, wenn es besser als ein Mensch sein soll. Dann steigt aber auch das Risiko von Fehlentscheiden.--Wortulo (Disk. * KI-Projekt) 07:39, 13. Okt. 2024 (CEST)

Wir sind ja zum Glück in der aktuell noch vergleichsweise komfortablen Situation, trotz Autorenschwund noch genügend Menschen zu haben, die sich um Vandalismusbekämpfung, letzte Änderungen und Nachsichtung kümmern. Insofern kann man auch erstmal beobachten, wie gut Automoderator in anderen Sprachversionen funktioniert, wo Communities schon lange auf Hilfe warten (oder sich wie z.B. ruwiki [2] schon selbst ähnliche Tools gebastelt haben). Perspektivisch glaube ich mit fortschreitendem Autorenschwund nicht, dass wir auf solche Werkzeuge verzichten können, dann wird darüber halt in ein paar Jahren nochmal gesprochen, wenn der Leidensdruck höher ist und solide Erfahrungswerte aus anderen Projekten vorliegen. --Johannnes89 (Diskussion) 09:34, 13. Okt. 2024 (CEST)

Ich sehe das ja auch kritisch, wie es jetzt aussieht. Nur kann man warten, bis andere das fertigentwickelt haben und sich quasi zurücklehnen oder den Entwicklungsprozess beeinflussen und irgendwo teilnehmen (wer das will - was offenbar nur geht, wenn das hier freigeschaltet wird). Der Input der deutschsprachigen WP ist dann sicher "nicht ungewichtig" und kann das akzeptabler machen. Blöder Spruch, aber "Waffen entwickelt man besser vor dem Krieg". Wenn wir später mal sowas brauchen (das ist wahrscheinlich, wie ich auch denke), müsste es fertig und fehlerarm sein.--Wortulo (Disk. * KI-Projekt) 11:57, 13. Okt. 2024 (CEST)

Und apropos Sichten: Stand heute warten 18.281 Änderungen, davon die längsten 54 Tage. Nicht sehr motivierend für die Beitragenden. Wenn Sichten wirklich "Vandalismusfreiheit" bedeuten soll (einige machen und erwarten leider mehr), könnte der Stau vielleicht auch etwas abgearbeitet werden. --Wortulo (Disk. * KI-Projekt) 12:12, 13. Okt. 2024 (CEST)

Es tut mir leid, aber wir leben nicht in einer Welt, in der man sich irgendwas auf Halde hinlegt, falls man es nochmal brauchen sollte. Das ist eine Vorstellung aus der Nachkriegszeit des 20. Jahrhunderts. Alles wird ständig weiterentwickelt, und wenn es denn einmal sein sollte, dass es gebraucht werden sollte, wird man weitersehen. Meine These wäre, dass du, die anderen Diskutanten und auch ich dann schon lange nicht mehr teilnehmen werden. Wie ich auch annehme, dass jede Form von Automatisierung viele Benutzer vertreiben wird. --Viele Grüße, Aschmidt (Diskussion) 12:07, 13. Okt. 2024 (CEST)

Eben, alles wird weiterentwickelt - und es geht darum, ob wir an dem Prozess teilnehmen (und unsere Ziele und Werte einbringen) oder abseits zuwarten. Denn das wird noch etwas dauern, ehe das irgendwas von fertig ist, da geb ich Dir recht.--Wortulo (Disk. * KI-Projekt) 12:16, 13. Okt. 2024 (CEST)

„Wir“ brauchen an „dem Prozess“ nicht teilzunehmen. Wenn es soweit sein wird, dass „wir“ „es brauchen“ sollten, wird alles schon wieder so anders sein, dass es mit der heutigen Lage nichts mehr zu tun haben wird. Dann beginnt sowieso alles neu. --Viele Grüße, Aschmidt (Diskussion) 12:20, 13. Okt. 2024 (CEST)

Dazu fällt mir nur noch ein: Amboss oder Hammer sein :-)--Wortulo (Disk. * KI-Projekt) 13:04, 13. Okt. 2024 (CEST)

Weder noch. --Viele Grüße, Aschmidt (Diskussion) 15:11, 13. Okt. 2024 (CEST)

Ich weiß nicht, wie unser Projekt aussehen müsste, damit man einfachem Vandalismus nicht mehr Herr werden könnte. Dann gäbe es längst keinerlei inhaltliche Kontrollen mehr, für die es auf absehbare Zeit immer noch Menschen brauchen wird. Dann müssten wir erst einmal das Sichtungs-System abschalten und vielleicht überhaupt sämtliche Artikel auf Read-Only schalten, zumindest für unangemeldete Benutzer. Ich kann mir auch nicht vorstellen, wie es in anderen Projekten aussehen mag, wenn die sowas wie automatische Rücksetzungen von einfachem Vandalismus dringend brauchen. Ich halte solchen Vandalismus in der de.wp immer für das kleinste Problem, das wir haben, lästig zwar, aber leicht beherrschbar. Jeder umstrittene Artikel, jeder Benutzerkonflikt bindet mehr Kapazitäten als die 14-89 Reverts von einfachen Fällen, die so ein Tool am Tag leisten würde. Von inhaltlich anspruchsvoller Arbeit ganz abgesehen.

Ich bin nicht grundsätzlich gegen KI-Hilfestellungen (z.B. könnte vieles, was hier in Artikeln an Formalien zu leisten ist, von einem Tool als Grundgerüst vorgeschlagen werden, solange die Entscheidung über die Übernahme noch immer ein Mensch trifft), aber beim Automoderator steht für mich der geringe Nutzen in keinem Verhältnis zum erlaubten Eingriff. Wir haben aus guten Gründen enge Regeln für den Einsatz von Bots - und die werden immerhin von Menschen gesteuert anders als eine KI, die sich selbst ihre Regeln schafft. --Magiers (Diskussion) 10:47, 13. Okt. 2024 (CEST)

Community-configured threshold? Wird hier nicht schon fahrlässig die Terminologie aus Tools wie SBL auf den Automoderator übertragen? In einem solchen Modus funktioniert KI doch gar nicht... (?). --Stephan Klage (Diskussion) 12:29, 13. Okt. 2024 (CEST)

Ich denke, dass der "KI-Anteil" die Ermittlung eines "Score" ist. Dh das Tool ermittelt mithilfe statistischer Verfahren eine Zahl, die angeben soll, wie wahrscheinlich eine Zurücksetzung des Edits ist. Ab welcher Wahrscheinlichkeit tatsächlich eine Zurücksetzung stattfindet, kann als "Schwelle" vorgegeben werden. D.h. die Ermittlung des Score ist eine black box, nicht beeinflussbar von der Community, allein darauf gestützt, ob der Edit so ähnlich ist wie solche, die früher revertiert wurden; das "Machine Learning" besteht darin, dass die KI laufend an weiteren Wikipedia-Edits "trainiert" wird und offenbar auch sog. "Feedback" auf einer eigenen Seite erhalten kann. Es ist die typische Simulation von Entscheidungen nach dem Muster früherer Entscheidungen. Das ist es, was wir hier meines Erachtens unter keinen Umständen erlauben sollten. --Mautpreller (Diskussion) 14:35, 13. Okt. 2024 (CEST)

Wie sowas funktioniert und welche Probleme es bringt, kann man an der Zuweisung der VIAF erkennen, die auf ähnliche Weise abläuft. Es ist aussichtslos, hier Korrekturen vorzunehmen, weil man nicht in die Black Box reingucken kann; warum die KI irgendwas als wahrscheinlich einordnet, ist unzugänglich und kann nur geraten werden. Wichtig ist auch der inhärente Konservatismus solcher Verfahren: Was (so ähnlich) zurückgesetzt wurde, ist wahrscheinlich wieder zurückzusetzen. Eine direkte menschliche Beteiligung ist unmöglich, weil diese nur am Output ansetzen kann und die "inner workings" der Maschine jedem Einfluss enthoben bleiben. Damit wird die Verantwortung abgegeben. --Mautpreller (Diskussion) 14:50, 13. Okt. 2024 (CEST)

Man kann solche Programme auch so aufsetzen, dass sie ihre Entscheidungsgänge erklären können. Allerdings weiß ich nicht, ob das hier vorgesehen ist und ob das einen Eingriff in die Entscheidungslogik erlaubt. Vielleicht kann man das ja bei Gelegenheit erläutern? Freundlicher Gruß, --CC (Diskussion) 14:54, 13. Okt. 2024 (CEST)

@Samwalton9 (WMF): Sorry, die Frage war natürlich an Dich gerichtet, da wäre ein Ping sinnvoll gewesen... Gruß, --CC (Diskussion) 14:56, 13. Okt. 2024 (CEST)

Zustimmung - denn das ist ein Projekt der Wikimedia, die ja auf die Bedürfnisse der Communities eingehen sollte. Ich habe an einigen Stellen auch vergeblich versucht, mich da einzulesen. Samwalton spricht laut Babbels nicht Deutsch, vielleicht kann man aber auch auf Englisch mal eine Veranststaltung machen, wo genauer informiert wird und man Fragen stellen kann und dann besser planen. Wortulo (Disk. * KI-Projekt) 16:53, 13. Okt. 2024 (CEST)

Kazuyuki

Guten Tag, Sorry I don't speak German so I will continue in English. It is about the article titled Kazuyoshi Itō. The correct first name of this astronomer is Kazuyuki, not Kazuyoshi. "Kazuyuki" is the name given in the naming citation of asteroid (5737) Itoh, that is named after him. It is also the correct reading of his name written in Japanese (伊藤和幸), that you can find on his X (Twitter) page (和幸 is one possible writing of "Kazuyuki"; "Kazuyoshi" is not written like this). I got confirmation from outside that the correct name is "Kazuyuki", especially from the Akashi Municipal Planetarium, where he is a volunteer. Consequently, could somebody rename and correct the article? Thank you in advance for your help. The mistake seems to originate from the English version of the article, that was created years before the other versions of this article and from which all the other versions seem to have taken the wrong name. SenseiAC (Diskussion) 17:35, 17. Okt. 2024 (CEST)

Hello @SenseiAC, thanks for your comment! It seems plausible to me at first glance, but my Japanese is not fluent enough. I will ask someone to check it for me. --Bildungskind (Diskussion) 18:01, 17. Okt. 2024 (CEST)

@SenseiAC I asked him and there are doubts. He says that both readings are possible in Japanese, even if one is perhaps more common. It is not that easy to judge. Can you give us a public, reliable source where a transcription in Romaji can be found and clearly identifies the person? Unfortunately, I can't move the page just because you know this from private sources/conversations. I hope you understand. For such things, as far as I know, the person concerned can also contact the Wikimedia Foundation and provide evidence that his name is being transcribed wrongly. --Bildungskind (Diskussion) 18:10, 17. Okt. 2024 (CEST)

Hello Bildungskind, One such source is the naming citation of asteroid (5737) Itoh, that is named after him. In the reverse, not any source justifies that the article was ever named Kazuyoshi. SenseiAC (Diskussion) 23:54, 17. Okt. 2024 (CEST)

The article has been moved and corrected by @Renerpho:. SenseiAC (Diskussion) 15:33, 18. Okt. 2024 (CEST)

The burden of proof, I think, lies with anyone who wants to use Kazuyoshi, because no source for this name seems to exist. In constrast, Kazuyuki is well referenced. Renerpho (Diskussion) 22:32, 18. Okt. 2024 (CEST)

Falsche Autorenstatistk in einem durch Auslagerung eines Artikelabschnitts neu entstandenem Artikel

Übertragen aus WP:AA, Diff--Filzstift (Diskussion) 12:29, 19. Nov. 2024 (CET)

Der Benutzer:AxelHH hat den von mir verfassten Abschnitt über die Historischen Grenzsteine im Gellerser Anfang in Form eines neuen Artikels nach Historische Grenzsteine im Gellerser Anfang ausgelagert. Dabei wurde zwar die Versiongeschichte importiert, aber die Autorenstatistik weist hauptsächlich Benutzer:AxelHH als Autor aus. Meine Wenigkeit erscheint gar nicht. Tut mir Leid, aber das ist inakzeptabel. Und somit folge ich dem, was mir der besagte Benutzer geraten hat (und was er für mein Verständnis von Redlichkeit und Transparenz eigentlich hätte selber tun müssen): Ich stelle hier eine Anfrage mit der Bitte, die Autorenstatistik zu korrigieren und an die wahren Begebenheiten anzupassen. Und ich bitte darum, dies ohne meine weitere Beteiligung zu tun. Ich hab's ja schließlich auch nicht verbockt und auch keine Zeit dafür. Gruß--Landmensch 2 (Diskussion) 13:49, 12. Nov. 2024 (CET)

Da scheint mir das Problem aber bei dem Tool zu liegen. Ich nutze beispielsweise ein Skript, das mir oben auf der Seite den Anteil der Autoren an dem Artikel angibt. Da ist das Ergebnis anders: „von de>Landmensch 2 (84 %), de>Redline is courtage (5 %), AxelHH (2 %), 89.53.29.218 (1 %), de>Torsten Bätge (1 %), 103 weiteren Autoren (6 %)“. Meines Erachtens kann dieses Problem also nicht von Admins gelöst werden. --Ameisenigel (Diskussion) 15:12, 12. Nov. 2024 (CET)

Nach dieser Statistik bist Du auch Hauptautor. --Schraubenbürschchen (Diskussion) 15:23, 12. Nov. 2024 (CET)

Hm, mir wird in dieser Statistik unter „Autorschaft“ angezeigt: 1. AxelHH 99,6 %. --Alraunenstern۞ 15:35, 12. Nov. 2024 (CET)

Jetzt bei mir auch, vorher standen da noch viel mehr Autoren drin und mit deutlicher Hauptautorenschaft von Landmensch *kopfkratz* - wer hat die Hamster in den SErverraum gelassen? --Schraubenbürschchen (Diskussion) 15:51, 12. Nov. 2024 (CET)

Hier können Administratoren nicht viel tun, zumal das Tool nicht in der deutschsprachen Wikipedia angesiedelt ist (wir verlinken nur darauf). Es ist nicht mal von der Wikipedia betrieben. Man könnte höchstens bei den Betreibern des Tools beschweren. Wahrscheinlich wäre das unter https://www.mediawiki.org/wiki/Talk:XTools zu machen. Würde da aber nicht viel hoffen wollen (die deWP-Autorenstatistik haben sie kaum auf ihrer Priorität). --Filzstift (Diskussion) 15:32, 12. Nov. 2024 (CET)

PS: Hier wird beschrieben, wie das Ganze funktioniert: https://www.mediawiki.org/wiki/XTools/Authorship --Filzstift (Diskussion) 15:35, 12. Nov. 2024 (CET)

Wenn es jemanden gäbe, der des Englischen mächtiger ist als ich und der diese Anfrage erledigen könnte, wäre ich sehr dankbar! Und wenn es Bereiche in der Wikipedia gibt, die nicht zu kontrollieren oder irgendwie anzusprechen sind, dann wäre es ja mal an der Zeit, dies zu ändern ;). --Landmensch 2 (Diskussion) 18:22, 12. Nov. 2024 (CET)

Das Tool macht nicht wirklich etwas falsch, es zählt die Bearbeitungen, die mit Benutzerkonten in der deutschsprachigen Wikipedia verbunden sind. Das sind die importierten Versionen nicht, erkennbar an dem de> vor dem Benutzernamen. Sie tauchen auch nicht in der Beitragsliste der Benutzer auf. Das ist letztlich nur eine Art Weiterleitung auf den Benutzer.

Beim Import kann man einstellen, dass die Versionen mit dem ursprünglichen Benutzerkonto verknüpft werden und früher war das Standard. Ich habe nie verstanden, wieso man davon abgekommen ist., insbesondere seit alle Konten global sind und es nicht mehr zu falschen Zuordnungen bei Importen aus anderssprachigen Wikimedia-Wikis kommen kann. -- hgzh 19:37, 12. Nov. 2024 (CET)

Das führt aber zu verfälschten Statistiken. Problematisch wird dies dann insbesondere bei der Vergabe von Benutzerrechten. Es lässt sich dann nur sehr mühselig nachvollziehen, ob es sich um „echte“ oder importierte Bearbeitungen handelt. --Ameisenigel (Diskussion) 19:45, 12. Nov. 2024 (CET)

Ich bin mir gerade nicht sicher, ob Importe die Autopromote-Zähler beeinflussen. Einen Fall, in dem importierte Bearbeitungen für Sichterrechte relevant geworden wären, kenne ich nicht. Müssen wir hier aber auch nicht vertiefen. Gruß, -- hgzh 20:32, 12. Nov. 2024 (CET)

Die maßgebliche Bearbeitung des Quellartikels [3] taucht im Import gar nicht auf, weil der Import vorher abbricht. Das wurde einfach direkt reinkopiert, ist also eigentlich URV. Da kann also kein Tool was dafür, wenn das nicht passt. MBxd1 (Diskussion) 18:52, 12. Nov. 2024 (CET)

Das war ein Revert, der Inhalt war vorher bereits im Artikel enthalten. -- hgzh 19:32, 12. Nov. 2024 (CET)

Stimmt, ich hatte nicht gesehen, dass die inhaltlichen Bearbeitungen viel älter sind. MBxd1 (Diskussion) 19:39, 12. Nov. 2024 (CET)

Die Thematik wurde schon hinlänglich auf Diskussion:Westergellersen diskutiert und das ganze hat ein Vorspiel siehe Wikipedia:Löschkandidaten/31._Juli_2024#Historische_Grenzsteine_im_Gellerser_Anfang_(LAE). --AxelHH-- (Diskussion) 19:44, 12. Nov. 2024 (CET)

Du hättest natürlich vorher den Artikel duplizieren sollen. Erst einfach auslagern ist nicht der richtige Weg. Der Versionsimport fand erst nach dem LA statt. Vorschlag: Aufgrund des Bagatellcharakters der nachgelagerten Änderungen wird der Artikel gelöscht und kann dann von Landmensch 2 selbst neu angelegt werden, ohne Versionsimport. Dann ist er wahrheitsgemäß zu 100% Autor. MBxd1 (Diskussion) 19:59, 12. Nov. 2024 (CET)

Der Versionsimport mag erst nach dem LA stattgefunden haben, beantragt habe ich ihn vor dem Löschantrag. Für mich war die Auslagerung der richtige Weg, einen anderen kenne ich nicht. Ich weiß nicht, was mit duplizieren gemeint ist. Ihr könnt gerne den jetzigen Artikel löschen und mit gleichem Inhalt neu anlegen, damit die Autorenschaft erkennbar ist. Habe bisher nicht erlebt, das jemand solchen Wert darauf legt trotz Versionsimport. --AxelHH-- (Diskussion) 21:14, 12. Nov. 2024 (CET)

Soweit nachzulesen, ist das schon ziemlich rustikal abgelaufen. Du hast eine einziges Mal auf der Diskussionsseite gefragt und nach mehr als einem halben Jahr ohne jegliche Ankündigung umgesetzt. Das gehört sich so nicht und hat sicher zur Verärgerung beigetragen - auch wenn es aufgrund des Nachimports dann einigermaßen repariert wurde. Es geht hier auch um sowas wie Respekt vor den Erstellern. Und bei dem, was du gemacht hast, war da keiner. MBxd1 (Diskussion) 22:31, 12. Nov. 2024 (CET)

Klingt für mich nach Arbeitbeschaffungsmaßnahme. Die Versionsgeschichte ist vorhanden und das ist das, was aus urheberrechtlicher Sicht relevant ist. Nachimporte gehören auf WP:IMP zum Tagesgeschäft und sind somit durchaus üblich. --Ameisenigel (Diskussion) 21:43, 12. Nov. 2024 (CET)

Ich würde nicht annehmen, dass die eine Löschung so umwerfend viel Arbeit macht. Den Rest müsste Landmensch 2 eh selbst machen. Und sicher sind Nachimporte Standardgeschäft, aber der Weg sollte eigentlich über vorherige Artikelduplizierung laufen. Ich werde mich jetzt aber hier raushalten. MBxd1 (Diskussion) 22:31, 12. Nov. 2024 (CET)

Die Anfrage halte ich für legitim. Hier geht es meines Erachtens nicht nur ums Urheberrecht, dafür reicht der Versionsimport, sondern auch um den Respekt vor einem Autor. Wir (fast) alle arbeiten hier ohne Bezahlung, die "Ehre", in der Autorenstatistik weit oben zu stehen ist für viele Autoren eine wichtige Motivation mitzumachen. Wenn es keine grundsätzlichen einwände gibt, lösche ich den Artikel temporär, dann kann Landmensch 2 den ausgelagerten Teil selbst neu einstellen, anschließend stelle ich die Versionen der nachfolgenden Änderungn wieder her. -- Perrak (Disk) 22:41, 12. Nov. 2024 (CET)

Dann passt doch aber die Chronologie des ganzen nicht mehr. Dann wären die Änderungen an dem Artikel älter als die Auslagerung selbst. --Ameisenigel (Diskussion) 10:58, 13. Nov. 2024 (CET)

Stimmt, dann funktioniert es so nicht, stimmt. -- Perrak (Disk) 20:19, 15. Nov. 2024 (CET)

Hinweis: WikiHistory berücksichtigt (seit der neuen Implementierung in diesem Sommer) auch die in der Datenbank als rev_parent_id hinterlegte Version, diese ist im Allgemeinen identisch mit der Version in der Zeitlinie davor, es sei denn jemand hat eine ältere Version als Basis des Edits gewählt, also eine "stille" Art der Rücksetzung. Das wird ähnlich wie echte Rücksetzungen gewertet bzw. diese Edits werden übersprungen. Bei Nachimporten hat das bei den mir bekannten Problemfällen zu einer deutlichen Verbesserung geführt. Eine Rücksetzung einer Änderung, indem einfach per Edit zuvor von einem anderen User eingefügte Teile entfernt werden, wird nur als Rücksetzung erkannt wenn die neue Version identisch mit einer davor ist, ist irgendwas zusätzlich geändert dann wird das nicht erkannt. Ganz fehlerfrei wird das aber nie, egal welches Tool. --Wurgl (Diskussion) 22:48, 12. Nov. 2024 (CET)

Das ist klar. Aber in diesem verhältnismäßig einfachen Fall lässt sich das Reparieren, und ich sehe keinen Grund, das nicht zu machen. Die Arbeit wäre es mir wert. -- Perrak (Disk) 23:35, 12. Nov. 2024 (CET)

Das wäre alles nicht nötig, wenn der Autor meine Frage nach Auslagern nicht ein halbes Jahr ausgesessen hätte. Seine Nichtreaktion hat mir gezeigt, dass es ihm egal ist. Warum sollte ich da nochmal nachfragen? Hatte ich übrigens auf seiner Disk und da hatte er im Oktober gesagt keine Zeit. Im nächsten Juli habe ich ausgelagert.--AxelHH-- (Diskussion) 00:29, 13. Nov. 2024 (CET)

So, jetzt möchte dir, Benutzer:AxelHH, der Autor mal was sagen: Ich hatte damals keine Zeit, mich in Vorgehensweisen einzuarbeiten, die mir nicht geläufig waren - und ich habe heute auch keine! Du hast sicherlich zurecht bemängelt, dass der Artikelteil über die Grenzsteine zu lang ist - aber mal ganz ehrlich: Geht davon diese Enzyklopädie gleich unter, angesichts der hier zu Hauf aufzufindenden Artikel, die auch noch schlecht recherchiert und voller Fehler sind? Ich habe recht viele Stunden an der ganzen Kiste gesessen, ICH (und nicht du) besitze die Literatur kenne alle diese Grenzsteine (und mittlerweile auch noch deutlich mehr in diesem Wald - sollte ich dazu jemals was veröffentlichen kann ich mich dann ja selbst zitieren). Und ich habe mich einfach darüber geärgert und tue es immer noch, dass da jemand OHNE jegliche Expertise im Thema sich meine Arbeit unter den Nagel reißt! Wenn du es wenigstens 'richtig' gemacht hättest und somit auch die Urheberrechtsgeschichten innerhalb der Wikipedia angemessen berücksichtigt hättest. Wie gesagt: Meine Maxime ist hier: Tue nur das, was du kannst, schreibe nur über das, wovon du auch was verstehst! Du hast das verbockt und mir immerhin geraten, hier eine Anfrage zu stellen - warum hast du es nicht selber getan? Es war dein Fehler. Vermutlich war es dir nicht so wichtig. Benutzer:Perrak spricht vom oben "Respekt vor dem Autor" - und genau den habe ich in deinem Agieren immer vermisst: Außer Abwiegeln kam da nix. Ich hatte - nach ähnlich sinnfreien Diskussionen an anderen Stellen - tatsächlich überlegt, mich hier abzumelden. Es gibt hier zu viele selbsternannte Saubermänner, die immer was zu nörgeln haben (weiteres Beispiel: die Fotogröße im Artikel - mir kam es auf die Lesbarkeit der Inschrift an), aber bei denen ich eines vermisse: verhältnismäßiges und kompetentes Agieren. Dieses vermisse ich auch - und das hat mit den Grenzsteinen im Gellerser Anfang nicht direkt zu tun - in solchen Wer-bearbeitet-am-meisten-Wettbewerben wie dem Denkmalcoup. Da wird der niedersächsische Denkmalviewer (der voller Fehler steckt - bei den historischen Grenzsteinen kann ich das wirklich beurteilen) hier in umfangreichen Listen dupliziert (nach zum Teil selber ausgedachten Ordnungskriterien ohne sachlogischen Verstand), ohne das diejenigen, die das tun, in der Lage wären, die Qualität des Denkmalviewers überhaupt beurteilen zu können. Deswegen arbeite ich mittlerweile mit den Denkmalschutzbehörden zusammen - und verzichte drauf, mich diesem Listenwahnsinn hier anzuschließen.

Wie oben bereits erwähnt, hatte ich hatte damals einen Löschantrag gestellt - der leider abgelehnt wurde. So genau, wie hier, hat sich damals vermutlich niemand damit beschäftigt. Dank an alle, die das jetzt hier getan haben! --Landmensch 2 (Diskussion) 15:42, 13. Nov. 2024 (CET)

a) Es war nicht annähernd AxelHHs Fehler
b) das mit dem Urheberrecht funktioniert ja (die Versionsgeschichte ist ja korrekt). Nur die Erkennung des Hauptautors läuft bei manchen einem Tools falsch. Das kann aber auch intendet behaviour (AxelHH ist dann in der Sicht der Hauptautor, weil er die meisten Teile ausgelagert hat) sein. Das können uns nur die devs der Tools bzw. dessen Dokumentationen verraten. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 12:44, 19. Nov. 2024 (CET)

Leider ist immer noch nichts passiert, die Autorenstatistik ist unverändert. Bitte nach Perraks Vorschlag vorgehen. Meiner Meinung nach wäre es sogar möglich, den Artikel Historische Grenzsteine im Gellerser Anfang ganz zu löschen und den Abschnitt im Artikel Westergellersen wiederherzustellen. Dann kann man über eine fachgerechte Auslagerung reden, die hier nicht geschehen ist. Leider ist Benutzer:AxelHH für das ganze Schlammassel verantwortlich und sollte sich daher für eine Korrektur engagieren.--Mautpreller (Diskussion) 11:07, 15. Nov. 2024 (CET)

Das ist unwahr. Durch den Versionsimport ist die Auslagerung korrekt erfolgt. --Magnus (Diskussion) 11:15, 15. Nov. 2024 (CET)

Warum sollten wir über die Auslagerung nochmals reden? Es ist doch ganz klar, dass dieser riesige Teil der Grenzsteine mit 16.000 kb den Artikel mit 22.000 kb überlagert hat und es förmlich nach Auslagerung schrie. Ich mache da gar nichts mehr. Im übrigen hat sich der Autor beschwert, das meine Auslagerung ein schlechter Artikel sei, hat aber nichts daran geändert. Viel Geschrei um nichts.--AxelHH-- (Diskussion) 11:25, 15. Nov. 2024 (CET)

Sorry, Du hast Mist gebaut. Ja doch, die Grenzsteine verdienen einen eigenen Artikel. Aber Du bis verantwortlich dafür, dass der Urheber des Textes nicht gewürdigt wird. Deswegen solltest Du sehr wohl noch was machen. --Mautpreller (Diskussion) 11:33, 15. Nov. 2024 (CET)

@Benutzer:AxelHH: Ich finde einige Formulierungen von dir tatsächlich sprachlich leicht daneben gegriffen. Aber: Warum soll ich etwas verbessern, was in meiner Version besser war? Damit ich dann in der jetzigen Statistik mit 0,x% auftauche? Nein. Bevor die Statistik nicht stimmt, mache ich nichts mehr an dem Artikel. --Landmensch 2 (Diskussion) 13:16, 15. Nov. 2024 (CET)

Offenkundig ist sie nicht korrekt erfolgt. Der Artikel hätte zuerst dupliziert werden müssen, bevor ausgelagert wird. Da das nicht geschehen ist, ergibt das Tool für die Autorenanteile falsche Ergebnisse. Das ist ein ernsthaftes Problem. --Mautpreller (Diskussion) 11:31, 15. Nov. 2024 (CET)

Die einfachste Lösung wäre in der Tat, nach Perraks Vorschlag vorzugehen.--Mautpreller (Diskussion) 11:45, 15. Nov. 2024 (CET)

Leider weiß ich nach 20 Jahren hier nicht was mit duplizieren gemeint ist. Ich meine, die Auslagerung wurde von mir korrekt vorgenommen. Vielleicht bekomme ich das fürs nächste Mal hier erklärt. --AxelHH-- (Diskussion) 11:58, 15. Nov. 2024 (CET)

Hilfe:Artikelinhalte auslagern#Lizenzkonforme Auslagerung durch Duplikation. --Mautpreller (Diskussion) 12:03, 15. Nov. 2024 (CET)

Landmensch 2 hatte oben geschrieben, dass er wenig Zeit hat. Da die Neuanlage von ihm durchgeführt werden müsste, damit der erwünschte Effekt erzielt wird, warte ich darauf, dass er die nötige Zeit hat, mein Angebot steht weiter (heute hätte ich allerdings erst abends Zeit). Da außer uns beiden niemand daran beteiligt sein muss, können wir hier von mir aus auch schließen. -- Perrak (Disk) 12:17, 15. Nov. 2024 (CET)

@Perrak: Meine Anmerkung hattest du gesehen? --Ameisenigel (Diskussion) 12:51, 15. Nov. 2024 (CET)

Nein, hatte ich tatsächlich übersehen. -- Perrak (Disk) 20:19, 15. Nov. 2024 (CET)

Alternativ wäre vielleicht Folgendes möglich: Duplizierung des Artikels Westergellersen in einen Benutzernamensraum (wie in Hilfe:Artikelinhalte auslagern vorgesehen). Dort zunächst Revert auf die Fassung vom 29. Juli. Dann Streichung aller zur aktuellen Fassung von Westergellersen redundanten Texte. Löschung des Grenzsteine-Artikels, Verschiebung des BNR-Artikels auf dieses Lemma. Spätere Änderungen am Grenzsteine-Artikel müssten manuell nachgetragen (also wiederholt) werden.--Mautpreller (Diskussion) 12:34, 15. Nov. 2024 (CET)

Diese späteren Änderungen waren übrigens minimal und betrafen hauptsächlich das durch die Auslagerung erforderliche neue Intro. Sie dürften kaum Schöpfungshöhe haben.--Mautpreller (Diskussion) 12:52, 15. Nov. 2024 (CET)

Wenn der von Benutzer:Mautpreller vorgeschlagene Weg gangbar ist: Ich bin dabei, aber ich kann nicht sagen, wann ich im Moment dazu kommen könnte, den Artikel dann wieder neuanzulegen. Könnte man den eigenständigen Artikel nicht zunächst einfach löschen und dann zu gegebener Zeit neu anlegen? Der Inhalt schlummert ja noch in der Versionsgeschichte von Westergellersen. --Landmensch 2 (Diskussion) 13:28, 15. Nov. 2024 (CET)

Ich bin kein Spezialist für sowas, vielleicht kann Benutzer:M.ottenbruch da fachlichen Rat geben. Für die Duplizierung stell ich gern meinen Benutzernamensraum zur Verfügung. Man muss nur gucken, ob Benutzer:AxelHH Wert auf die Autorschaft an seinen geringfügigen nachträglichen Änderungen legt. Eine dieser Änderungen ist natürlich zwingend notwendig, nämlich ein neuer Einleitungssatz, da der Kontext ja durch die Auslagerung entfernt ist. --Mautpreller (Diskussion) 13:39, 15. Nov. 2024 (CET)

PS: Wenn es funktioniert, was ich mir vorstelle, müsstest Du zunächst mal nichts machen. Der duplizierte Artikel müsste die korrekte Autorschaft ausweisen, der Copy & Paste-Edit fiele weg, es müsste eigentlich erstmal nur gestrichen werden, nichts hinzugefügt. Das käme erst danach (eventuell). --Mautpreller (Diskussion) 14:01, 15. Nov. 2024 (CET)

Dupliziert wurde die Versionsgeschichte ja schon, die Bearbeitungen ordnet das Auswertungstool nicht richtig zu. Was einerseits korrekt ist, da die Bearbeitungen an anderer Stelle bereits gezählt werden, andererseits das hier angesprochene Problem verursacht. Ich befürchte, der Umweg über den BNR würde daran bichts ändern. -- Perrak (Disk) 20:20, 15. Nov. 2024 (CET)

Bei meinem Artikel Lied der Mutter Courage funktionierte dieses Verfahren astrein. ist das nicht mehr so? Da müsste dann überhaupt kein C&P mehr stattfinden, sondern nur gestrichen werden. Das gäbe mit Sicherheit nicht dasselbe Ergebnis. Wie wärs, es mal auszuprobieren? --Mautpreller (Diskussion) 20:23, 15. Nov. 2024 (CET)

In Anbetracht der vorgerückten Nachtzeit habe ich das Problem noch nicht vollständig nachvollzogen und daher sicherlich auch noch nicht völlig durchschaut, möchte aber aus Sicht eines Importeurs schon mal ein paar Gedanken beitragen, die man dann vielleicht zu einer zivileren Tageszeit weiter diskutieren könnte:

1. Ich teile Perraks oben geäußerte Ansicht: „Hier geht es meines Erachtens nicht nur ums Urheberrecht, dafür reicht der Versionsimport, sondern auch um den Respekt vor einem Autor.“
2. Natürlich ist es möglich, den Artikel zu duplizieren, sei es mit oder ohne „Verkürzung“ der Versionsgeschichte.
3. Worum es hier aber geht, ist etwas Anderes: Es gibt beim Import zwei Möglichkeiten, die Versionsgeschichte zu „formatieren“: Autoren können in der Form: „Projektname>Benutzername“ oder in der einfachen Form „Benutzername“ auftauchen, also bsplsw. bei einem Import aus der de-WP als: „de><Benutzername>“, oder als: „<Benutzername>“.
   1. Wählt man die erste Form, so wird der Autor des Edits in der Versionsgeschichte zwar genannt, aber der so gekennzeichnete Edit zählt nicht in seiner Beitragsstatistik. In der Artikelstatistik des Duplikates wird der Autor allerdings – in der Form mit Präfix – mit dem korrekten Anteil an Beiträgen genannt. Hat er vor und nach dem Import zum Artikel beigetragen, taucht er zweimal in der Artikelstatistik auf: einmal mit und einmal ohne Präfix.
   2. Wählt man die zweite Form, so zählt der durch den Import erzeugte Eintrag in der Versionsgeschichte des duplizierten Artikels auch für die Beitragsstatistik des Autoren, d.h die Beitragsstatistik wird des Autors wird durch den Import um die Anzahl seiner Edits im Ursprungsbeitrag erhöht, also diese zählen praktisch doppelt. Daher wird diese Form nur gewählt, wenn der Ursprungsartikel nach dem Import bsplsw. gelöscht werden soll (wordurch die Edits ja als „Live-Edits“ aus der Statistik des Autors entfernt würden), damit die Edits des Autors weiterhin wenigstens einmal in seiner Beitragsstatistik auftauchen.
   3. Zu Anfang meiner Tätigkeit als Importeur habe ich bei Importen aus der de-wp immer die zweite Form gewählt, weil mir das bis hierhin Geschilderte nicht klar war. Man hat es mir dann erklärt, und seitdem handhabe ich es – bis auf die genannten Ausnahmen – mit der ersten Form, wie auch bei Importen aus Schwesterprojekten. Das hat nichts mit dem SUL zu tun, sondern mit der Korrektheit der Autorenstatistik.

HTH, zum Rest bei Tageslicht … -- M.ottenbruch ^{¿⇔! RM} 02:56, 16. Nov. 2024 (CET)

Ah, danke, das war mir so nicht klar. Dann ließe sich das Problem lösen, indem man den Versionsimport einfach in der Form wiederholt, bei der die "de" wegfallen, anschließend alle Bearbeitungen des alten Artikels bis auf eine löscht. Damit würde die Autorenstatistik zwar um eine Bearbeitung verfälscht, das erscheint mir bei einem Autor, der schpn lage Sichter ist, aber verschmerzbar. -- Perrak (Disk) 12:09, 16. Nov. 2024 (CET)

Hallo M.ottenbruch, ganz verstehe ichs noch nicht. Das Problem ist eigentlich nicht, ob die Edits oder deren Größe doppelt oder einmal gezählt werden, das scheint mir relativ belanglos. Das Problem ist einzig und allein, ob der Anteil am gegenwärtigen Artikel korrekt wiedergegeben wird. Jede Lösung, die das schafft, ist in Ordnung. Das heißt aber auch, dass die Edits vor dem Import ihrem Urheber zugewiesen werden müssen. Ich weiß nicht, ob das bei der Präfix-Lösung der Fall ist.

Wenn ich mir die Autorenstatistik von Historische Grenzsteine im Gellerser Anfang angucke, stell ich feat: Unter "Top-Bearbeiter" wird die Statistik korrekt wiedergegeben, sowohl "nach Bearbeiter" als auch "nach eingefügtem Text", wenn auch mit dem Präfix. Es kommt aber auf die "Autorschaft"-Statistik an. Hier werden die Edits mit Präfix offenbar schlicht ignoriert, die ausgeklügelte Mechanik des Tools, die bloße Reverts etc. ausschalten soll, funktioniert also nicht. Der Benutzer:Landmensch 2, der praktisch den gesamten Artikel verfasst hat, kommt also gerade dort, wo es darauf ankommt, überhaupt nicht mehr vor. Das kann meines Erachtens nicht angehen. Wenn ich es recht verstehe, muss wohl die zweite Form (ohne Präfix) gewählt werden. Ich vermute, dass das auch beim Lied der Mutter Courage der Fall war, wo alles einwandfrei funktionierte.

Das Ärgerliche ist insbesondere, dass der Copy&Paste-Edit [4], der bei korrektem Vorgehen gemäß Hilfe:Artikelinhalte auslagern#Lizenzkomnforme Auslagerung durch Duplikation gar nicht nötig gewesen wäre, nicht als solcher erkannt wird. Es erscheint dann so, als ob dieser Edit ein originärer Beitrag von Benutzer:AxelHH wäre. Das ist aber natürlich nicht der Fall. --Mautpreller (Diskussion) 12:24, 16. Nov. 2024 (CET)

Bei der Angabe der Ursache Import-Präfix habe ich mich geirrt, es gibt andere Artikel, bei denen diese mit einbezogen werden, wenn auch nicht mit dem eigentlichen Benutzer zusammengeführt werden.

Das Problem ist m.E. ein anderes: in der Datenbank ist je Version ein Verweis auf die Vorversion angegeben. Das Tool hangelt sich vermutlich auf diese Weise die Versionsgeschichte nach hinten, bis dieser Verweis mal 0 ist (0 steht für die erste Version bei Seitenanlage), und bricht dann ab. Im fraglichen Artikel ist die erste Version mit Verweis 0 die Anlageversion von AxelHH, weil sie vor dem Import die erste Seitenversion war. Ein Nachimport ändert daran nichts, die importierten Versionen liegen also vor der „ersten“ Seitenversion und werden von dieser für das Tool „versteckt“.

Will man das Problem lösen, bleibt m.E. nur, alle nicht nachimportierten Versionen (also ab der Seitenanlage durch AxelHH) zu löschen und die Auslagerung inkl. Anpassungen dann auf Basis der letzten Importversion neu durchzuführen. -- hgzh 12:40, 16. Nov. 2024 (CET)

Genau so ist es. --Ameisenigel (Diskussion) 13:04, 16. Nov. 2024 (CET)

Ich kann auch nach längerer Beschäftigung mit dem „Problem“ nur den Eindruck bestätigen, daß das Tool „Autorenschaft“ (https://xtools.wmcloud.org/authorship/de.wikipedia.org/Historische_Grenzsteine_im_Gellerser_Anfang) wohl – mindestens im Bezug auf diese konkrete Fragstellung – fehlerhaft arbeitet. Die Tools „Analyse – Xtools“ (https://xtools.wmcloud.org/articleinfo/de.wikipedia.org/Historische_Grenzsteine_im_Gellerser_Anfang#top-editors), „Analyse – WikiHistory“ (https://wikihistory.toolforge.org/wh.php?page_title=Historische_Grenzsteine_im_Gellerser_Anfang&wiki=dewiki) und „Analyse – Σ“ (https://sigma.toolforge.org/articleinfo.py?page=Historische_Grenzsteine_im_Gellerser_Anfang&server=dewiki) stellen den Sachverhalt korrekt dar, ebenso das von mir ebenfalls genutzte Helferlein, das die Analyse im Seitenkopf des Artikels darstellt. Ob eine Wiederholung des Importvorgangs mit anderen Parametern dazu führt, daß alle fünf Tools eine korrekte Analyse liefern, kann ich nicht beurteilen, bezweifele es aber aus zwanzigjähriger Erfahrung mit den Tools und ihrer Interaktion untereinander. Erschwerend kommt hinzu, daß die Wahl der oben von mir so genannten „zweiten Form“ ja bewußt dazu führen würde, daß die Beitragsstatistik der Autoren verfälscht wird. Ich halte das nicht für eine gute Idee, werde mich aber auch nicht sperren, wenn jemand Anderes das trotzdem machen möchte.

Ich schließe auch nicht aus, daß eine Löschung des ausgelagerten Artikels nebst erneuter Duplizierung incl. Import vor Weiterbearbeitung des duplizierten Artikels zum gewünschten Ergebnis führt; und wenn Ameisenigel davon ausgeht, daß das funktioniert, hat er erfahrungsgemäß wahrscheinlich recht. Da ich selbst dafür allerdings nicht garantieren könnte, halte ich mich auch da heraus. Schönes Restwochenende! -- M.ottenbruch ^{¿⇔! RM} 21:54, 16. Nov. 2024 (CET)

Hallo M.ottenbruch, das Tool „Analyse – Xtools“ arbeitet natürlich deshalb fehlerlos, weil es nicht den Anteil der Autoren am gegenwärtig bestehenden Text misst, sondern lediglich die Edits und ihren Umfang zählt und aufaddiert. Für die Bestimmung der Autorschaft ist das aber irrelevant. Dasselbe gilt für das Tool „Analyse – Σ“. Einzig WikiHistory funktioniert tatsächlich korrekt. Insbesondere ist das das einzige aller Tools, das den C&P-Edit von AxelHH korrekt als solchen erkennt und daher nicht als Beitrag zum Artikel aufführt. --Mautpreller (Diskussion) 11:26, 17. Nov. 2024 (CET)

Ich seh hier durchaus ein Problem, weil mit dem standardmäßig zur Verfügung gestellten Tool zur Autorschaft eine glatt falsche Zuschreibung produziert wird. Zudem wäre das vermeidbar gewesen, wenn der Auslagerer die Vorgaben der einschlägigen Hilfe-Seite beachtet hätte. Ein C&P-Edit ist grundsätzlich das falsche Mittel zur Auslagerung. --Mautpreller (Diskussion) 11:33, 17. Nov. 2024 (CET)

Möglicherweise habe ich mich mißverständlich ausgedrückt: Ich leugne keineswegs die Existenz des Problems, nämlich einer Fehl- oder mindestens mißverständlichen Funktion des Authorship-Tools in einer konkreten Situation wie dieser. Ich weiß nur nicht, ob eine Wiederholung der Auslagerung – gegebenenfalls mit anderen Parametern beim Import – dieses Problem löst, ohne andere aufzuwerfen. Damit meine ich nur, daß ich es nicht weiß oder auch aus aus frühereren Erfahrungen mit anderen Tools bezweifele, nicht aber, daß ich sicher wäre, das es nicht funktioniert. (Und keineswegs betreite ich, daß das Problem wohl nicht aufgetreten wäre, wenn man die Auslagerung vor vornherein korrekt durchgeführt hätte.) Um das zu beurteilen, fehlt mir schon das technische Wissen. Ich kann mit den Tools rund um den Import umgehen, aber wie sie genau funktionieren, geht über meinen Horizont. Da sind bsplsw. Ameisenigel als global sysop und Doc Taxon als interface administrator wesentlich kompetenter als ich, weswegen ich diesbezügliche Entscheidungen und Aktionen ihnen überlassen würde und mich selbst da heraushalten.

Was das Tool „Analyse – Xtools“ angeht, war ich bisher der Meinung, daß es beides tut: Edits und Textanteile zu ermitteln („Top 10 by edits“ und auch „Top 10 by added text (approximate)“). Ich hatte das aus der Erläuterung geschlossen: „Added text is any positive addition that wasn't reverted“. Aber wie gesagt: Mein technisches Verständnis ist da etwas limitiert. -- M.ottenbruch ^{¿⇔! RM} 18:15, 17. Nov. 2024 (CET)

Das Tool Analyse – Xtools erkennt unmittelbar folgende totale Reverts, mehr nicht. Es ist ja auch offensichtlich, dass es die weitgehend identischen Versionen von Landmensch 2 und AxelHH doppelt erfasst. Für die Bestimmung der Autorschaft ist eine weitaus raffiniertere Mechanik nötig. Aber okay. Wer auch immer das macht: Könntet Ihr den Artikel Westergellersen in meinem Benutzernamensraum duplizieren? Am besten die Versionen bis hier: https://de.wikipedia.org/w/index.php?title=Westergellersen&oldid=247193564 ? Ich möchte gern mal sehen, wie das Autorschaft-Tool damit umgeht. Damit wäre keine Entscheidung getroffen, ich möchte nur mal gern wissen, ob es dann hinhaut. --Mautpreller (Diskussion) 10:22, 18. Nov. 2024 (CET)

Bitteschön: Benutzer:Mautpreller/Westergellersen --Ameisenigel (Diskussion) 11:10, 18. Nov. 2024 (CET)

Danke! Schade nur, dass das Autorschaft-Tool im BNR offenbar nicht funktioniert. --Mautpreller (Diskussion) 11:17, 18. Nov. 2024 (CET)

Hallo Benutzer:Landmensch 2 und Benutzer:AxelHH, in meinem Benutzernamensraum liegt nun der Artikel, so wie er unmittelbar vor der Auslagerung bestand. Ich habe gemäß Hilfe:Artikelinhalte auslagern#Lizenzkonforme Auslagerung durch Duplikation alle Bestandteile entfernt, die nicht mit den Grenzsteinen zu tun haben. Prinzipiell könnte man nun den Grenzsteine-Artikel löschen lassen und diesen Artikel Benutzer:Mautpreller/Westergellersen auf das Grenzsteine-Lemma verschieben. Noch zu tun wäre vorher allerdings: die Einleitung hinzufügen und evtl. weitere kleinere Redaktionstätigkeiten. Das hattest Du, Benutzer:AxelHH, ja schon einmal gemacht. Magst Du das nochmal tun oder, falls Du auf die Autorschaft keinen Wert legst, mir das gestatten? Meines Erachtens könnten wir so die Kuh vom Eis bringen.--Mautpreller (Diskussion) 12:59, 19. Nov. 2024 (CET)

Dann stimmen aber nicht die Beitragsdaten (also Datum und Uhrzeit) Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 13:04, 19. Nov. 2024 (CET)

Das wäre meines Erachtens zu verschmerzen - sofern Axel-HH keinen Wert darauf legt. Es handelt sich ja bloß um die paar Edits nach der Auslagerung. --Mautpreller (Diskussion) 13:09, 19. Nov. 2024 (CET)

Moin Benutzer:Mautpreller! Erstmal vielen Dank an dich - und natürlich auch an die anderen, die sich hier einen Kopf gemacht haben! Ich habe nun auf Benutzer:Mautpreller/Westergellersen mal das überbarbeitet und ergänzt, was mir nötwendig erschien. Wäre ja klasse, wenn dieses Kapitel dann mal abgeschlossen werden kann. Gruß --Landmensch 2 (Diskussion) 17:57, 19. Nov. 2024 (CET)

Ich hab noch ein bisschen an der Einleitung gemacht, die sollte sofort die wichtigsten Infos bringen, nämlich was ist das und wo ist das. Wenn das alle Beteligten so gut finden, könnten wir beantragen, den derz. Grenzsteine-Artikel zu löschen, um diesen darauf zu verschieben. --Mautpreller (Diskussion) 18:18, 19. Nov. 2024 (CET)

Alles gut! War mir durchgerutscht! Gruß --Landmensch 2 (Diskussion) 18:25, 19. Nov. 2024 (CET)

Und wenn man einfach mit Spezial:Exportieren die beiden XML-Dateien exportiert, händisch die Fehler in eine neue xml korrigiert (ja wäre sehr viel Handarbeit) und den ausgelagerten Artikel zuerst löscht und dann mithilfe von Spezial:Importieren die neue xml als ausgelagerten Artikel einfügt? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 13:04, 19. Nov. 2024 (CET)

Das überfordert mein technisches Verständnis. --Mautpreller (Diskussion) 13:10, 19. Nov. 2024 (CET)

Macht mit dem Artikel was ihr wollt, Hauptsache er ist ausgelagert aus dem Ortsartikel. --AxelHH-- (Diskussion) 13:39, 19. Nov. 2024 (CET)

Zwei Projektankündigungen für 2025

Hallo allerseits,

im Kommenden Jahr werden zwei bereits bekannte von WMAT bzw. von WMDE+WMAT organisierte Projekte weitergeführt, teils mit Änderungen. Das eine ist die virtuelle Vortragsreihe GLAM digital (für den gesamten DACH-Raum), das andere der österreichweite Foto-(auch Audio- und Video-)Wettbewerb WikiDaheim, zu dem Teilnehmer auch aus allen anderen Ländern eingeladen sind. Bei Letzterem gibt es die grundlegende Änderung, dass schon ab 1. Januar Beiträge hochgeladen werden können, nicht erst später im Jahr wie bisher. Wir werden das alles auch in Newslettern, ggf. auch an dafür Angemeldete als Disk.Seiten-Massennachricht, bekannt machen - und als Central Notices, mit angepasster Ausspielungsrate, um Banner-Müdigkeit vorzubeugen, die im Januar geschaltet werden sollen; die beiden Anträge dafür sind auf Meta gestellt. Falls ihr Anmerkungen dazu habt, bitte gerne auf Request/WikiDaheim 2025 oder Request/GLAM digital spring 2025. Herzliche Grüße, Manfred Werner (WMAT) (Diskussion) 13:44, 9. Dez. 2024 (CET)

Dieser Abschnitt kann archiviert werden. –IWL04 • 12:24, 2. Apr. 2025 (CEST)

Bitte um Feedback zu Subreferenzierung

Hi zusammen, wir haben unter WD:Technische Wünsche/Topwünsche/Subreferenzierung#Bitte um Feedback zu Subreferenzierung eine größere Ankündigung zum geplanten Subreferenzierungs-Feature gepostet. Wir müssen die Wikitext-Syntax anpassen, um technischen Limitationen zu begegnen und freuen uns über eure Gedanken dazu! Dankeschön und viele Grüße --Johannes Richter (WMDE) (Diskussion) 14:13, 17. Dez. 2024 (CET)

Restrict new users from cross-wiki uploading files to Commons

Long story short: The Commons community fully supported restricting users of local wikis from cross-wiki uploading files into Commons. So have the en.wiki (discussion) and ar.wiki communities. I created a Phabricator ticket based upon the consensus made by those communities. To this date, not much major development has been made yet. Even my Community Wish attempt was rejected as policy-related. --George Ho (Diskussion) 23:36, 25. Dez. 2024 (CET)

Hochwertige PDFs aus Wikipedia Artikeln

Hallo,

unter

https://mediawiki2latex.wmcloud.org/

kann man kostenlos innerhalb weniger Sekunden hochwertige PDFs von Wikipedia Artikeln bekommen. EPUB, ODT und LaTeX geht auch.

Mehr über das zugrunde liegende freie Softwareprojekt gibt es im Vortragsvideo File:MediaWiki2LaTeXTalkRevision4.webm oder auf der Projektseite b:Benutzer:Dirk Hünniger/wb2pdf

Frohe Weihnachten nachträglich und einen guten Rutsch

Euer --Dirk Hünniger (Diskussion) 12:47, 31. Dez. 2024 (CET)

Was bedeuten die neuen KI-basierten Bildbearbeitungsmöglichkeiten für die Bebilderung in der Wikipedia?

Bild mit störenden Kabeln

Bild ohne störenden Kabeln

Kabel/Oberleitungen automatisiert entfernt, Version mit Kabeln in der Dateihistorie

Hier habe ich sehr starke auf KI-basierte Maskierungsmöglichkeiten zurückgegriffen und alles um das Objekt herum abgedunkelt

Starker Rückgriff auf KI-basierte Maskierungsmöglichkeiten zum Aufhellen des Gebäudes. Wenn man es sehr eng sieht könnte man sagen, dass ich die Lichtsituation stark verändert habe (s. Versionshistorie)

Hallo zusammen! Ich bin in der Regel eher auf Commons unterwegs und steuere Fotos bei, s. User:Tuxyso. In den letzten Jahren haben die Möglichkeiten an KI-basierten Bearbeitungsmöglichkeiten in Bildbearbeitungsprogrammen (insbesondere Adobe Lightroom und Photoshop, das die meisten ambitionierten Hobby-Fotografen nutzen dürften) drastisch zugenommen. Spätestens mit den KI-basierten Entfernungsmöglichkeiten ist mEn eine Schwelle überschritten, die zum nachdenken anregt (mich zumindest). Aus der Praxis mal ein paar typische Bildbearbeitungen, die ich gelegentlich nutze:

• Selektive Aufhellung bestimmter Bildelemente (z.B. Gebäude wenn diese im Schatten sind)
• KI-basierte Entrauschung bei Aufnahmen mit hoher Sensorempfindlichkeit (ISO)
• einzelne störende Äste in einem Bild entfernen
• KI-basiertes Entfernen einzelner störender und nicht zum Hauptmotiv gehörender Bildelemente (möglich, bisher von mir wenig praktiziert)
• KI-basiertes vergrößern der Bildfläche um z.B. einen engen Zuschnitt zu vermeiden - dabei wird in der Regel automatisiert etwas Himmel generiert und an den bisher im Bild vorhandenen Himmel angepasst

Ich habe zu den genannten Punkten mal ein paar Beispiele rausgesucht (s. Vorschaubilder). Das Beispiel vom Bahnhof Antwerpen ist natürlich extrem und würde ich so auch nicht machen. Vom Entfernen von Kabeln kann mEn ein Gebäudebild zur Illustration von Artikel deutlich profitieren. Die Integration von KI-Funktionen in Bildbearbeitungstools wird mEn weiter zunehmen. Bei KI-Funktionen, bei denen potenziell auch neue Inhalte generiert werden, versteht es sich von selbst eine entsprechende Retouched-Vorlage zu verwenden, wie ich das Beispielsweise hier gemacht habe: Commons:File:Stadtquartier-2021-01-retouched.jpg.

Bei einem Foto habe ich es (für die Frage hier) mal auf die Spitze getrieben:

• 
  Ursprungsversion
• 
  Umfassend bearbeitete Version die störende Bildelemente weitgehend entfernt, aber auch neue Inhalte generiert. (die Bearbeitung ist nicht besonders gut, es geht mir aber um eine plakative Illustration)

Kurzum an den versammelten Sachverstand hier: Gibt es auf de:WP Leitlinien dafür wie weit Bildbearbeitungen bei Bildern, die der Illustration von Artikeln dienen, gehen dürfen? Oder müssten solche vielleicht noch entwickelt werden, um bei der Bebilderung von Artikeln eine entsprechende Transparenz herzustellen. Ich persönlich meine, dass man nicht gänzlich auf die segenreichen KI-basierten Bearbeitungsmöglichkeiten verzichten sollte. Bearbeitungen rund um Licht finde ich unkritisch. Beim Entfernen von größeren Elementen wie Oberleitungen ist in jedem Fall eine Kennzeichnung erforderlich. Wenn allerdings ein Artikel zu einem Gebäude bebildert werden muss, kann mEn ein Entfernen hilfreich sein und die Aufmerksamkeit stärker auf das Gebäude richten. Bei einem zu extensiven Entfernen ist vielleicht irgendwann auch die Schwelle überschritten, dass so ein Bild nicht mehr einen Artikel bebildern kann. Das Beispiel vom Bahnhof Antwerpen wäre für mich so eins. Dort habe ich die komplette Baustelle entfern sowie direkt am Gebäude Fahrzeuge die zu einer umfassenden Generierung neuer Gebäudeteile geführt haben.

Ich freue mich über Eure Einschätzungen / Meinungen. --Tuxyso (Diskussion) 17:00, 11. Jan. 2025 (CET)

Das Leipziger Rathaus ohne die dort vorhandenen Straßenbahnoberleitungen fühlt sich so falsch an, es ist einfach ein Blick, der so nicht dort möglich ist und die Wirklichkeit verfälscht. --ɱ17:03, 11. Jan. 2025 (CET)

Wie man das findet ist das eine. Dass derlei Fotos zunehmen werden das andere, weil es eben extrem einfach geht. Noch vor wenigen Jahren hätte eine solche Bearbeitung wie die beim Leipziger Rathaus vermutlich eine Stunde oder mehr gedauert, damit es halbwegs vernünftig aussieht. Inzwischen sind dies zwei Klicks. Ein Element musste ich noch manuell maskieren und dann entfernen. Gesamtbearbeitungszeit: knapp eine Minute. --Tuxyso (Diskussion) 17:13, 11. Jan. 2025 (CET)

Ja, schauen wir den Illusionen und Fakes ins Gesicht, mit der Wahrheit kommen ja immer weniger Menschen zurecht. Nur weiter so. --Stephan Klage (Diskussion) 17:23, 11. Jan. 2025 (CET)

Das erinnert mich daran, dass das erste Bild im Artikel Wolfgang Schäuble bearbeitet ist; im eigentlischen Foto befand sich ein Glas Wasser, was aber wohl etwas störte. Bis auf das, was in Wikipedia:Artikel illustrieren steht (bzw. eher nicht steht), wäre mir keine Richtlinie bekannt.

An sich bin ich skeptisch, aber andererseits sind so ziemlich alle Gemälde und Kunstwerke (die ja zur Bebilderung verwendet werden) nicht wirklich realitätsgetreu und schon seit Anbeginn der Fotografie ist es Usus, dass man Bilder nachbearbeitet; also ich bin mir nicht so richtig sicher, was der beste Weg wäre. Wahrscheinlich lässt sich das so oder so nicht vermeiden, weil in seltenen Fällen jemand die Fotos nachprüfen kann. --Bildungskind (Diskussion) 00:12, 12. Jan. 2025 (CET)

Frage Dich was Du mit Deinem Bild vermitteln wolltest? Stellt das bearbeitete Bild noch das dar, was Du uns zeigen wolltest. Ich denke leichte Retouche von störenden Elementen sind gerechtfertigt. Vor allem am Bildrand. Wenn Du Dich danach selbst unwohl fühlst, weil die KI in das Original hineindichten musste, dann solltest Du es lassen. Einen ganzen Fuhrpark entfernen, geht nicht. Mit einem Glas hätte ich kein Problem. Eine ganze Person würde ich durch Freistellung (Crop) entfernen.Eine Haarsträhne einer solchen Person, oder ein Ellenbogen etc. würde ich wegretouchieren. Aber natürlich nicht eine Person aus einem Gruppenbild, oder aus der dokumentarischen Aufnahme eines Ereignisses. Aufhellungen, wie beim Haus halte ich für okay. Gerade bei Gegenlicht belichte ich bei der Aufnahme bewusst sehr stark unter, so dass die Hintergrundstrukturen sichtbar bleiben, sehr wohl wissend, dass ich die Strukturen des Hauses, die dann zu dunkel werden, beim Entwickeln aufhellen kann. Dazu gibt es ja die Zebrafunktion und das Histogram in der Kamera um die Grenzen zwischen Blackout, wo ich keine Strukturen mehr herauskitzeln kann und Whiteout, wo gar keine Strukturen mehr auf meinem Sensor dargestellt wurden schon bei der Aufnahme einkalkulieren kann, mit dem Wissen im Hinterkopf, was ich dann beim Entwickeln aus der Aufnahme herausholen kann. Den Unterschied zwischen einer guten Abbildung und einer Bildfälschung sollte jeder Fotograf (Lichtbildner) selbst im Gefühl haben. Deine Objektfotografie finde ich sehr gelungen. Der Nutzer dieses Fotos interessiert sich für das Objekt, nicht für die Glasvitrine, oder sich hinter dem Objekt befindliche andere Kunstwerke oder Museumsbesucher. --Wuselig (Diskussion) 21:24, 12. Jan. 2025 (CET)

Vielen Dank, Wuselig für deine ausführliche Antwort und deinen Appell an den GMV (Gesunden Menschenverstand). Deine Punkte bzgl. moderater Unterbelichtung / Highlight-Betrachtung handhabe ich genau so. Tatsächlich gehe ich sehr reflektiert an meine Fotos - sonst hätte ich den obigen Beitrag gar nicht gestartet. Mein Grundgedanke, der mich bewogen hat, den Beitrag zu starten: Wenn die Entfernung von einzelnen Objekten / Personen oder Retuschen beispielsweise am Himmel oder gar das Einfügen ganz neuer Objekte mit ein paar Klicks oder Wischs erledigt ist, dürften sich derlei "KI-Retuschen" häufen - das bemerke ich für kleinere Retuschen auch an meiner Bildbearbeitung. In meiner Anfangszeit auf Commons:QIC empfand ich es als sehr hilfreich ein paar klare Orientierungen zu bekommen, was ein "Qualitätsbild" ausmacht oder auch (manchmal etwas anstrengende) Diskussionen auf Kandidaten für exzellente Bilder hinsichtlich des enzyklopädischen Mehrwerts von sehr guten Fotos und ihrem Wert für die Wikipedia. Diese Art der Orientierung fehlt aus meiner Sicht sowohl auf Commons wie auch in der (deutschsprachigen) Wikipedia.

Auch deine Hinweise, Bildungskind sind sehr nahe an meinen Gedanken dazu. Ein Foto ist immer irgendeine Art von Realitätsabbildung. Ich erkenne auch für die Bebilderung von Artikeln nichts Verwerfliches darin, wenn man ein Foto (fallbezogen) auch mal etwas stärker bearbeitet und um den Blick auf das Wesentliche zu schärfen - wir sollten uns meiner Ansicht nach bei der Bebilderung von Artikeln auch von Fotojournalismus abgrenzen, der natürlich andere Maßstäbe anlegt.

Bleibt für mich die Frage, ob bei KI-Bearbeitung zukünftig ein einfacher Hinweis auf Bildbearbeitungen / Retuschen ausreicht, oder ob derlei Inhalte noch spezifisch gekennzeichnet werden sollten. --Tuxyso (Diskussion) 21:20, 17. Jan. 2025 (CET)

Gleich zu Beginn: Die Realität wird auf keinem Foto/Bild/Ausdruck abgebildet, philosophisch gesehen immer nur ein Zustand eines Objektes/der Welt zu einem (kurzen oder längeren) Zeitpunkt. ;-) Schon die Auswahl des Abbildungszeitpunktes, Standort, Objektiv=Bildwinkel, Belichtungszeit etc beeinflusst das Foto/Abbild.

Wie überall im Leben, stellt sich die Frage des Warum und Wozu? Will jemand das Bild „verbessern“ (im Sinne von störenden Dingen entfernen), das wurde bisher auch schon gemacht. An Anfang der Photographie manuell auf dem Abzug, später beim Belichten etc. Digital ging da bisher OHNE KI auch schon sehr viel. MIT KI ist natürlich deutlich mehr möglich (mit relativ wenig Aufwand). Oder will man den Inhalt des Bildes verändern (das wird idR hier eher unerwünscht sein). Sinnvoll kann es zB sein, Dinge zu zeigen, die das menschliche Auge niemals so sieht (viele Abbildungen aus dem Kosmos sind sowas - oft rein virtuell; oder wissenschaftliche Bilder von Elektronenmikroskopen).

ab wann SOLL/MUSS sowas gekennzeichnet sein? Schwierige Frage: verändert werden alle digitalen Bilder (in gewisser Hinsicht). Wenn Original und verändertes Bild in WESENTLICHEN Bildteilen unterschiedlich sind (oben die Autos im Vordergrund weg), dann MUSS das mMn gekennzeichnet werden (oder das Original im Vergleich dazu gezeigt werden). Bei unwesentlichen (nebensächlichen) Teilen SOLLTE es vermerkt werden. Dann bleibt die Frage: was ist unwesentlich (die Oberleitungen im Bild oben sind schon ein Grenzfall?)

das Thema des Motives des Bildes (und Sehgewohnheiten) spielt auch noch eine Rolle. Menschen dürfen mMn nicht zu ihren Nachteil verändert werden (absichtlich hässlich oder gealtert), das galt aber vorher auch schon. Wie weit man Menschen schöner machen darf, ist natürlich auch ein Thema (speziell bei Werbung oder Personen der Öffentlichkeit), betrifft uns aber eher selten.

Objekte und Bauten dürfen mMn idealisiert (= besser als die Realität) dargestellt werden, wenn es dem Zweck des Fotos dient. In der Architekturfotografie war das bisher auch schon geübte Praxis, Dinge des Alltags oder Menschen aus dem Bild „raus zu bekommen“ (analog wurden zB Mistkübel kurzfristig zur Seite gestellt; ein besseres Beispiel fällt mir jetzt nicht ein). Aber da gibt es auch wieder Grenzen und Ausnahmen: wenn eine Straßen- oder Platzszene fotografiert wird, werden idR Menschen oder Fahrzeuge dort unterwegs sein. Klinisch reine Platzfotos OHNE Menschen wirken unnatürlich. Muss jetzt aufhören, es gäbe noch viel dazu zu schreiben. --Hannes 24 (Diskussion) 12:52, 18. Jan. 2025 (CET)

Viele der hier diskutierten Bearbeitungen wurden auch schon früher gemacht, d.h. ohne „KI“, ja sogar schon in den Zeiten der analogen Fotografie. Durch die EBV und nun durch die „KI“-Werkzeuge wird das Entfernen von als störend empfundenen Elementen usw. zwar einfacher (und daher auch viel häufiger vorgenommen), das ändert aber nichts an ihrer grundsätzlichen Einschätzung. Die Frage, was üblich, was erlaubt ist, was noch OK und was unter „geht gar nicht“ fällt, hat sich schon immer gestellt und hängt nicht von den eingesetzten Werkzeugen ab. Sie hängt dagegen vom fotografischen Genre, vom Motiv und insbesondere vom Verwendungsbereich ab. In der Porträt-, Mode- und Werbefotografie sehen Kunden:innen schon lange starke Überarbeitungen als selbstverständlich an; retuschieren ist hier keine Option, sondern oft Pflicht. Am anderen Ende stehen „wir Wikipedianer:innen“ mit unserem starken Dokumentations- und Fakenethos … Da gibt es keine generelle und ideale Antwort, vielmehr müssen die Fotografierenden und ebenso die Nutzer der Bilder – in unserem Fall hier: die Wikipedianer:innen – selbst entscheiden, wo sie die Grenzen ziehen.

Um es ganz praktisch anzugehen: Auf den Commons-Bildbeschreibungsseiten weisen wir üblicherweise mit der Vorlage Retouched darauf hin, dass ein Bild umfassender bearbeitet wurde. Diese Vorlage kann und sollte natürlich auch bei „KI“-gestützen Bearbeitung eingesetzt werden. Dann können alle Nachnutzer:innen, also auch alle, die an Wikipedia-Artikeln mitarbeiten, entscheiden, ob das Bild für den jeweiligen Verwendungszweck passend ist oder nicht. Daher sollte unsere erste Bitte immer die an die Fotograf:innen sein, diese Vorlage fleißig und korrekt einzufügen. Unseren Fotograf:innen zu verbieten, z.B. Oberleitungen herauszuretuschieren, halte ich für prolematisch; dadurch bedienen wir nur unser altes Negativimage als obergescheite Besserwisser und vergraulen am Ende noch unsere Kollegen:innen. Sinnvoller scheint es mir, die Fotograf:innen um eine klare Kennzeichnung zu bitten – sowie ggf. bei weitgehenden Bearbeitungen wie der Oberleitungsentfernung darum, dass sie einfach beide Fassungen hochladen, einmal mit, einmal ohne die Oberleitungen, sodass Nachnutzer:innen die für sie jeweils passende Version wählen können. Und bei importierten Bildern (z.B. von Flickr), die wir ja ebenfalls in großen Mengen auf Commons haben, sollten wir einfach alle mithelfen, Bearbeitungen durch Ergänzung der Vorlage Retouched zu kennzeichnen. – Aristeas (Diskussion) 10:37, 26. Jan. 2025 (CET)

Sehe diesen Thread erst jetzt (für Leute, die weniger in der de-Wikipedia unterwegs sind, ist vielleicht der Hinweis wichtig, dass "Projektdiskussion" bei uns keine sehr stark frequentierte Seite ist und die Diskussionen eher verteilt auf andere Projektseiten stattfinden) und habe in letzter Zeit an so vielen Diskussionen zum Thema KI hier und auf Commons teilgenommen, dass ich etwas ermattet bin und keinen grossen Beitrag leisten mag. Auf Wikipedia Diskussion:WikiProjekt KI und Wikipedia möchte ich aber doch schon mal hinweisen, falls du es nicht kennst, Tuxyso. Das "Extrembeispiel" des Bahnhofs Antwerpen ist m.E. ganz klar unbrauchbar. Hinter den wegretuschierten Fahrzeugen sieht der Eingangsbereich rechts beim Starbucks nun so aus, als sei dort ein Brandanschlag auf den Bahnhof verübt worden, mit starker Beschädigung und Schutt davor, was ja alles Hinzudichtungen sind, da auf dem anderen Bild nichts davon zu sehen ist. Das ist durchaus eine gefährliche Realitätsverfälschung und keine akzeptable Retusche mehr, daher möchte ich dir vorschlagen, das Bild auf Commons wieder löschen zu lassen, wenn es seinen Zweck für die Diskussion hier erfüllt hat. Gestumblindi 21:55, 28. Jan. 2025 (CET)

Vielen Dank, lieber Gestumblindi, für deine zahlreichen Meta-Informationen. Ich empfand den Einführungstext auf der hiesigen Seite für meine Gedanken / Frage einschlägig. Weise doch gerne auf den von dir genannten Seiten auf die Diskussion hier hin, das würde mich jedenfalls freuen. Sieh mir bitte nach, dass ich nicht gleich die von dir genannten einschlägigen Seiten gefunden habe, da ich meist auf Commons aktiv bin und in den über 13 aktiven Jahren schon sehr viele hochwertige und exzellente Fotos beigesteuert habe. Ich habe es mir für das nächste Mal notiert :) Deinen berechtigten Hinweis zu meinem illustrativen Beispiel Bahnhof-Antwerpen-Rueckseite-2012-retouched.jpg nehme ich gerne auf. Ich habe in der Retouched-Vorlage von Anfang an explizit geschrieben, dass ich dieses zu Demonstrationszwecken erstellt habe: " Extensive AI-based removal of disturbing objects for demonstraction purposes" (den Rechtschreibfehler sehe ich erst jetzt...). Kurzum: Ja, es ist eine schlechte Bildbearbeitung und ja, die hinzugefügten Elemente - auch die untere Fassade des Bahnhofsgebäudes - sehen richtig schlecht aus. Ich werde die Tage direkt im Bild einen zusätzlichen roten Warnhinweis ergänzen, damit keine Verwendung in Wikipedia-Artikeln erfolgt. Löschen möchte ich das Bild nicht, da es sich auch in anderen Diskussionen mal als Negativbeispiel verwendet werden kann.

Hast du denn auch noch einen inhaltlichen Beitrag zur Diskussion? Da du dich offenbar schon viel mit derlei Fragen auseinandergesetzt hast, habe ich da wirklich Interesse dran, sonst hätte ich die Frage hier nicht gestellt. --Tuxyso (Diskussion) 06:40, 29. Jan. 2025 (CET)

Das „Editing team“ hat eine neue Funktion, die Neulingen hilft: Edit check

Hallo zusammen

Entschuldigt bitte diese lange Nachricht. Ich habe sie mit DeepL übersetzt und kann die englische Version zur Verfügung stellen, wenn ihr das bevorzugt.

Die Zusammenfassung der Nachricht lautet: Das Editing team hat eine neue Funktion, die Neulingen hilft, Belege hinzuzufügen, wenn sie einen neuen Absatz auf Wikipedia hinzufügen, und wir planen, sie bald in eurem Wiki einzusetzen. Wir haben festgestellt, dass diese Funktion wirklich wirkungsvoll ist. Weitere Informationen findet ihr unten.

Das Ziel von „Edit Check“ ist es, den Benutzern beim Bearbeiten mehr Anleitung zu geben und so die Anzahl der Bearbeitungen von geringerer Qualität zu reduzieren. Das bedeutet, dass erfahrene Benutzer weniger Kleinstbearbeitungen durchführen müssen. „Checks“ sind kontextbezogene Ratschläge, die angezeigt werden, wenn eine bestimmte Aktion ausgeführt wird. Sie sind nur für Neulinge sichtbar.

Ein gutes Beispiel ist das Hinzufügen von Belegen und Quellen. Bei Wikipedia wird darum gebeten, einen Beleg anzugeben, wenn man einen neuen Fakt hinzufügt, aber Neulinge verstehen diese Anforderung oft nicht. Sie wird nicht wirklich erklärt, nachdem man auf „Bearbeiten“ geklickt hat, sodass Neulinge sie vergessen könnten.

Screenshot der References Check ab Januar 2025

Unserer erster Schritt ist „References Check“ („Belegprüfung“). In seiner ersten Iteration wird „References Check“ angezeigt, wenn ein neuer Absatz ohne Quellenangabe zu einem Artikel beim visuellen Bearbeiten hinzugefügt wird. Ihr könnt es in eurem Wiki testen, indem ihr einen beliebigen Artikel bearbeitet und &ecenable=1 zur Bearbeitungs-URL hinzufügt. Beispiel:

1. Klickt auf https://de.wikipedia.org/w/index.php?title=Astronomie&veaction=edit&ecenable=1. Dadurch wird der Artikel im Modus „Visuelles Bearbeiten“ geöffnet.
2. Fügt dann einen neuen Absatz ohne Quellenangabe zum Artikel hinzu.
3. Klickt dann auf „Veröffentlichen“: Die Bearbeitung wird nicht veröffentlicht. Stattdessen wird die Quellenprüfung aktiviert, wie auf dem Screenshot zu sehen ist.
4. Probiert die verschiedenen Optionen aus. (Veröffentlicht also nicht wirklich, bis ihr wisst, was ihr tut.)

Jede hiermit vorgenommene Bearbeitung wird markiert und geloggt. Auf diese Weise können Bearbeitungen identifiziert werden, bei denen die Referenzprüfung aktiviert wurde die Einladung zum Hinzufügen einer Quellenangabe abgelehnt wurde. Dies sind nützliche Informationen, wenn ihr eine revertierte Bearbeitung erklären müsst.

Wir haben die Referenzprüfung in 11 Wikis getestet und die Ergebnisse sind ermutigend. Die Referenzprüfung hat zu einer Qualitätssteigerung bei den von Neulingen veröffentlichten Bearbeitungen geführt und keine nennenswerten Störungen verursacht. Personen, denen die Referenzprüfung angezeigt wurde, veröffentlichen mit größerer Wahrscheinlichkeit eine neue Inhaltsbearbeitung, die eine Referenz enthält und konstruktiv ist (und nicht innerhalb von 48 Stunden rückgängig gemacht wird): 2,2-mal wahrscheinlicher auf dem Desktop und 4,2-mal wahrscheinlicher auf Mobilgeräten.

Wenn diese Funktion aktiviert ist, wirkt sie sich nur auf ausgeloggte Benutzer und eingeloggte Benutzer mit weniger als 100 Bearbeitungen aus (diese Zahl ist konfigurierbar).

Wir haben die Gruppe der Wikipedianer informiert, die sich um neue Freiwillige in eurem Wiki kümmert. Da sich die Funktion hauptsächlich an diese Gruppe neuer Autoren richtet und die Mehrheit der Community von dieser Funktion nicht betroffen ist, sieht sich die Gruppe nicht in der Lage, eine Entscheidung zu treffen (außerhalb der Governance-Regeln von deWP), hält die Aktivierung durch die WMF jedoch vorerst für unproblematisch. Die Aktivierung kann auch jederzeit rückgängig gemacht werden, falls Probleme auftreten sollten.

Wir planen, „References Check“ in zwei Wochen (Woche vom 3. Februar) in eurem Wiki bereitzustellen. Wenn ihr in der Zwischenzeit Fragen zu dieser Funktion haben, lasst es mich bitte wissen.

Trizek (WMF) (Diskussion) 18:58, 22. Jan. 2025 (CET)

Ich freue mich drauf, was ich in den anderen Projekten gesehen hab, kann das sehr helfen, dass Neulinge tatsächlich Einzelnachweise für ihre Ergänzungen angeben! --Johannnes89 (Diskussion) 19:08, 22. Jan. 2025 (CET)

Ich bin eher nicht überzeugt. Viele lehnen das ab und wie viele dann komplett abbrechen ist unbekannt. Wikipedia:Fragen_zur_Wikipedia#Markierungen:_Bearbeitungsprüfung_(Belege)_aktiviert,_Bearbeitungsprüfung_(Belege)_abgelehnt --Bahnmoeller (Diskussion) 15:56, 20. Feb. 2025 (CET)

Die Quote liegt überschlägig etwa bei 50:50, also wurden bei 1500 Bearbeitungen auch gut 800 Belege angegeben. -- hgzh 16:40, 20. Feb. 2025 (CET)

Umfrage zur Verbesserung der „Letzte Änderungen“ Feed

Hallo! Das Moderator-Tools-Team möchte gern mehr darüber erfahren, wie Communitymitglieder die Liste „Spezial: Letzte Änderungen“ verwenden und welche Daten am nützlichsten sind, sowie Feedback zu frühen Designkonzepten sammeln.
Aktuell benötigt das Team Teilnehmer für eine kurze Umfrage (10–15 Minuten). Wenn Sie Interesse daran haben, besuchen bitte die Umfrage unter:
https://wikimedia.qualtrics.com/jfe/form/SV_3zaigQl9TIYh5yK
Auf der Projektseite erhalten Sie mehr Informationen über die Arbeit an der Funktion „Letzte Änderungen“.

Bei weiteren Fragen schreiben Sie bitte an:
otichonovawikimedia.org
Vielen Dank! OTichonova (WMF) (Diskussion) 21:02, 12. Feb. 2025 (CET)

Dieser Abschnitt kann archiviert werden. –IWL04 • 12:25, 2. Apr. 2025 (CEST)

Verein für Dialekt

Servus. Nur ums klarzustellen: Ich habe absolut keine Verbindung zu diesem Verein. Ich habe vor kurzem über diesen Verein gelernt, und dachte, es könnte einige hier interessieren. Es war mir ein Vergnügen.

P.S. : Diese Nachricht hinterlasse ich mal der Vorsicht halber auch auf der Allemanischen und hier auf der deutschen Wikipedia, anscheinend gibt's dort und hier mehr trafic. Hier wegen Foederverein (Diskussion) 22:17, 22. Feb. 2025 (CET)

Dieser Abschnitt kann archiviert werden. –IWL04 • 12:26, 2. Apr. 2025 (CEST)

Zensur auf Wikipedia bzw. willkürliches Rückgängig machen von Ergänzungen: Z. B. Verbreitung von Falschinformationen nicht korrigierbar

Man kann bei wikipedia kaum noch Informationen zu Artikeln ergänzen. Entweder werden sie seit Monaten nicht freigegeben oder willkürlich rückgängig gemacht, selbst wenn man nur Wahlergebnisse hinzufügt (offensichtlich ist der Moderator in folgenden Fall CSU-Fan und möchte keine schlechten Ergebnisse sehen). Alles wird pauschal als "Änderung nicht sinnvoll" abgelehnt. Seit wann ist das Hinzufügen von Wahlergebnissen für den Bundestag einer Politikerin (Erststimme) nicht sinnvoll?

Beispiel von seit Monaten nicht geprüften Änderungen: "Mike Litt".

Beispiel für Zensur: "Dorothee Bär": Der Moderator hat ihre persönlichen Erststimmenergebnisse als "nicht sinnvoll" zurückgewiesen. Das ist Zensur und Manipulation denn natürlich sind Erststimmenergebnisse einer Politikerin des Bundestages notwendig. Aber der "Zensurstelle" passte wohl nicht, dass Frau Bär zuletzt knapp 20 % geringeren Stimmenanteil hatte als bei Wahlen zuvor und somit mit unter 40 % nur noch eine Minderheit der Bürger in ihrem Wahlkreis vertritt.

Auch die Korrektur von mutmaßlich falschen Angaben (da nicht belegt und im Widerspruch zu sämtlichen offiziellen Erhebungen) inklusive vielen Belegen wurde zurückgewiesen. So steht im Artikel zu ihr ihre Aussage, dass es 250.000 Prostituierte in Deutschland geben würde. Dieses ohne jeglichen Nachweis/Quelle. Die Ergänzung, dass diese Behauptung unbelegt und anhand sämtlicher seriöser Erhebungen auch staatlicher Stellen falsch sein muss, wurde als "Nicht sinnvoll" abgelehnt. Aber unbelegte und damit mutmaßlich Falschbehauptungen von Politikern werden hier verbreitet. Die Wahrheit wird hingegen als "nicht sinnvoll" blockiert. Es gibt zu ihre Behauptung nur zwei angegebene Quellen, die jedoch auf Artikel verweisen, wo sie selbst zitiert wurde. Aber dort steht weder, dass die Zahl richtig ist, noch ein Beleg dafür. Wenn jemand selbst zitiert wird, belegt das nicht, dass eine zitierte Aussage desjenigen richtig ist.

Wikipedia betreibt somit die Verbreitung von Falschinformationen, wenn Korrekturen mit Quellen zu richtigen Daten nicht zugelassen werden. Wenn dem Moderator die Korrekturen nicht passen, hat er zumindest Kenntnis von der Falschinformation erlangt und müsste zumindest die Falschinformation entfernen. Wikipedia verkommt anscheined immer mehr zu einer "Fake-News"-Seite, die alles wegzensiert, was dem jeweiligen Moderator persönlich nicht passt. --80.187.112.216 01:49, 23. Feb. 2025 (CET)

Bei Dorothee Bär geht es offenbar um die folgende Änderung[5]. Nun, der erste Teil ist unbelegt, es ist nicht klar ob diese von dir eingefügte Einordnung der Erststimmenergebnisse medial reflektiert wurde. Ohne Beleg also nicht haltbar. Beim zweiten Teil gehst auch du stark in die Wertung. Es ist der Abschnitt um Positionen, in dem du direkt die Kritik einwebst. Das ist allgemein inkorrekte Arbeitsweise, wenn überhaupt gehört sowas in einen gesonderten Abschnitt Kritik. Auch ist das was du dort einfügen wolltest OR: Du darfst hier nicht deine eigene "Forschung" einbauen, sondern nur die von anderen etablierten Quellen reflektieren. Und das Litt nicht gesichtet wurde mag auch daran liegen, dass dort eine Instagramquelle eingefügt wurde, und damit heikles Gebiet betrten wird, da Instagram nicht unbedingt Quellentauglich ist. Es geht hier nicht um die Verbreitung von Falschinformationen, sondern deine mit dem Regelwerk der Wikipedia nicht vereinbarten Änderungen. Ich würde also Vorschlagen du beschäftigst dich mit unseren Regeln etwas genauer (und ja, zugegeben, die sind nicht einfach), und dann schauen wir weiter. Falls du Unetrstützung brauchst wird man dir sicherlich helfen können.--Maphry (Diskussion) 06:46, 23. Feb. 2025 (CET)

Hilfreich ist es auch, wenn man bei sich selbst ansetzt und nicht immer bloß bei den anderen. Wenn man in politischen Artikeln mit politischer Motivation editiert, braucht man sich nicht darüber beschweren, dass andere dasselbe tun (mal davon abgesehen, dass das beim konkreten Revert gar nicht der Fall war, wie von Maphry schon erklärt). Und warum lässt man andere seine Bearbeitungen sichten und beschwert sich noch darüber, dass das nicht zeitnah passiert, anstatt sich ein Benutzerkonto zuzulegen und selbst zum Sichter zu werden? Wenn man den Weg wählt, seine Beiträge nicht zu einem Konto zuordnen zu lassen, dann bezahlt man die größere Anonymität eben durch den Verzicht auf die Vorteile eines Kontos: Wiedererkennung und Etablierung in der Community, leichtere Ansprechbarkeit und persönlichere Diskussionen, Vertrauensvorschuss durch Sichterrechte. Das hat man aber auch selbst so gewählt. --Magiers (Diskussion) 10:01, 23. Feb. 2025 (CET)

Wenn du an einer konstruktiven Mitarbeit in der Wikipedia interessiert bist, solltest du Abstand davon nehmen, Begriffe wie "Zensur" zu verwenden und anderen Mitarbeitern politische Motivation zu unterstellen. Außerdem würde ich empfehlen, bei Meinungsverschiedenheiten die Diskussionsseite des Artikels aufzusuchen. Auf der anderen Seite möchte ich @Perrak ermutigen, Reverts etwas ausführlicher zu begründen als mit "Änderung nicht sinnvoll". --Discostu (Disk) 10:34, 28. Feb. 2025 (CET)

Ich begründe Reverts ausführlich, wenn sie es verdienen. Wenn jemand seine eigene Meinung in einen Artikel schreibt, dann ist "Änderung nicht sinnvoll" die höfliche Version dessen, was ich mir eigentlich denke. Für eine ausführliche Begründung ist mir in dem Falle meine Zeit zu schade. -- Perrak (Disk) 18:14, 28. Feb. 2025 (CET)

Schultüte or Zuckertüte?

Hi, I've noticed that the user @Tecumseh*1301 has been moving the page from "Schultüte" to "Zuckertüte" across various wikis. I'm unclear whether this is an appropriate action or if there's a specific reason for the change. If "Zuckertüte" is indeed the correct term, why hasn't the article on German Wikipedia been updated accordingly? Could someone help clarify this situation? For more details, you can see the explanation for the move on da:Diskussion:Schultüte. This is not to call out the user or anything, I would like to know what the German community think about this. Thanks. --SimmeD (Diskussion) 10:10, 24. Feb. 2025 (CET)

In my view "Schultüte" is the usual name for this and the proper name to choose for the Lemma. I've never heard "Zuckertüte" before (though that's not meant to be anargument). The Digitales Wörterbuch der deutschen Sprache seems to confirm that: for Schultüte no restrictions in usage are mentioned, while Zuckertüte is called a synonym mostly used in East-Germany. BTW, according to the DWDS, both words have similar usage frequency. --Qcomp (Diskussion) 10:45, 24. Feb. 2025 (CET)

There are regional differences. It originates in the center-east part of Germany, is traditionally called Zuckertüte and has a hexagonal form. Later the tradition spread to other parts, where a round form and the term Schultüte are more common (see [6]).

Regarding prevalence:

• Duden: Zuckertüte more common than Schultüte
• DWDS: Zuckertüte equally common to Schultüte
• Wortschatz-Portal der Universität Leipzig: Zuckertüte less common than Schultüte

Zuckertüte is the original name but it seems like nowadays it is considered more of a regional variant. However, if the article focuses more on the history, Zuckertüte could still be a correct name. -- hgzh 11:07, 24. Feb. 2025 (CET)

Google Ngram Viewer: Zuckertüte came up around 1880, Schultüte around 1950 (though it had a short time of usage before). Zuckertüte remained the more popular term to around 1980, followed by 10 years of somewhat equal usage. From 1990 on, Schultüte exploded, while Zuckertüte roughly remained on the same level. --YMS (Diskussion) 19:27, 28. Feb. 2025 (CET)

This user is a man on a mission to spread his personal preferences about language across several wikis, as he is promoting a very strict linguistic purism, e.g. on dewiki he tries to replace every anglicism by very unusual, more "german" sounding, old and unusual words. He got blocked on skwiki for edit warring on the topic about Schultüte/Zuckertüte for three months, he is indeffed on eswiki for being a single-purpose-account. In dewiki, his autoreview right was revoked because of this. Furthermore, as already pointed out by other users, Zuckertüte is not the usual german word for this, it should be Schultüte. This should be reverted across all wikis (and imo this user should be globally banned, but this won't happen, I guess). --Icodense 21:19, 28. Feb. 2025 (CET)

Hab die crosswiki Verschiebungen rückgängig gemacht [7]. Nicht angerührt hab ich seine Maschinenübersetzungen [8][9][10] [11], dort gibt es keine Vorversion, auf die ich revertieren könnte. --Johannnes89 (Diskussion) 18:56, 1. Mär. 2025 (CET)

Hi, friends. I don't know, what has been happening, oh my gosh..

I am on a mission, of course, we all are kinda. But what is my mission, can anyone look into my head? I can tell you what it is: t correct the wrong!

I was kinda shocked, when reading about Schultüte / Zuckertüte. Who actually says „Schultüte“? Very strange..

But not new. Weird article names have a long history, especially on German Wikipedia.

So, let's put out the facts:

The „Duden“ is the most important reference for anything about German words, right? Every school, every class refers to the Duden, and only the Duden.

The „Häufigkeit“, which means how often a word is used, is categorized into 4 strokes. Which means, that this is not into the detail, the Häufigkeit might have a difference of thousands of entries, still a word would have the same stroke.

It would be a '''HUGE''' difference, if a word would have 1 less stroke than the compared word has.

And this actually is true for „Schultüte“ compared to „Zuckertüte“ - „Schultüte“ has only '''Häufigkeit 1''' while „Zuckertüte“ has Häufigkeit 2,that's a huge gap.

https://www.duden.de/rechtschreibung/Zuckertuete

https://www.duden.de/rechtschreibung/Schultuete

https://www.duden.de/rechtschreibung/Zuckertuetenfest

This is the evidence from the Duden.

Plus that the word ''Zuckertütenfest'' exists only, but no word named ''Schultütenfest''.

Each time I changed this article's name, I wrote in the discussion, sometimes waiting days, before I changed the name. Some Wikipedia members wrote concerns and there a discussion evolved, where we still need to find a consensus, so I didn't change.

I am absolutely happy to discuss: always.. and be proven wrong.. but here I am not wrong and the Duden proves this.

What Johannes89 did was pure vandalism, without writing '''anything''' in any discussion he just moved dozens of articles crosswiki.

Thats losing that level of respect for the habits of Wikipedia, Johannes89 should still be able to discuss beforehand. --Tecumseh*1301 (Diskussion) 23:35, 1. Mär. 2025 (CET)

The Duden is by no means the only or most important reference, especially not for word frequencies. But even the Duden-entries show that you shouldn't make the changes you're doing: "Zuckertüte" is of regional use only (landschaftlich), and the Duden actually uses "Schultüte" to explain the meaning of "Zuckertüte". Second, your emphasis on word frequencies is misplaced: First, as you see here, it varies with the corpus used and the time frame considered and the ngram linked above by YMS is especially clear. Second, what's stated in the Duden provides no basis for your claim of a "HUGE" in frequency: As explained there, "two strokes" means the word appears more than once per million words in their corpus; and less then 10 times since that would be the next group; "Das Wort ist durchschnittlich mehr als ein Mal in einer Million Wortformen des Dudenkorpus belegt") and "one stroke" means less than once per million ("Das Wort ist durchschnittlich weniger als ein Mal in einer Million Wortformen des Dudenkorpus belegt."). Without knowing where in their respective groups these words are, there's no basis to draw your extreme conclusion, the difference could be just 5 %.

Third, I think Johannes89 did the right thing and thankfully repaired some of the misinformation you created when exporting your personal view of the matter to other WPs. --Qcomp (Diskussion) 00:46, 2. Mär. 2025 (CET)

Noting that Tecumseh*1301 forced their POV to multiple language versions of this article with the only discussion being posting to each talk page, claiming that "Zuckertüte" is the common term, even though that's not the case. Given that it's useful to have one central discussion instead of discussing the same issue on multiple article talk pages, I've used this discussion as consensus for reverting the page moves, which I indicated in my edit summary (e.g. [12]). Moving those pages to "Zuckertüte" a second time without consensus is edit-warring [13] --Johannnes89 (Diskussion) 06:23, 2. Mär. 2025 (CET)

Hi, Johannes,

as everyone is able to see, you did your '''very first''' comment on the discussion yesterday, AFTER you moved the article's name wrongfully!

So not taking part in a discussion, neither on talk pages nor on this project discussion - but taking action instantly - that's pure vandalism.

And yet we are waiting for your response to my argument with the indication the Duden makes, that „Zuckertüte“ is indeed more common than Schultüte.

Either you didn't care or you didn't respect the arguments that were written here in the project discussion, but that's not the way.. As I said, I am happy to discuss anything, but I am still waiting for you to finally engage in it except for simply making statements and moving article's names. --Tecumseh*1301 (Diskussion) 08:46, 2. Mär. 2025 (CET)

Multiple users left their comments agreeing that Schultüte is the common term. I implemented their consensus five days after the discussion started. You didn't react – despite being pinged – only to appear in this discussion after I reverted your page moves. And to be clear: Your initial page moves happened without consensus, you are the one needing to find consensus before implementing your POV. --Johannnes89 (Diskussion) 09:22, 2. Mär. 2025 (CET)

Warum wird hier eigentlich unter lauter deutsch Muttersprachlern auf englisch diskutiert? --Ailura (Diskussion) 10:29, 2. Mär. 2025 (CET)

Because the thread opener is Dansk, with only de-1. And it's an interwiki problem, the POV-stuff by Tecumseh*1301. --Grüße vom Sänger ♫ ^(Reden) 10:58, 2. Mär. 2025 (CET)

It's okay, friends, I'm fine talking in English, so everybody is aboard and understands it quite quickly.

I didn't see the ping, where was it?

Anyways, so up to now, I've provided at least evidence, and you, Johannes89, are just arguing, that some Wikipedia members have said so. We are still waiting for some evidence from you. --Tecumseh*1301 (Diskussion) 20:03, 2. Mär. 2025 (CET)

@Tecumseh*1301:, you should start to engage with the arguments made here in this thread. You have only provided weak evidence that does not support your conclusion and your actions and you have chosen to not even respond to the additional data provided above that. Even the Duden you quote makes clear that Schultüte is (nowadays) the primary term, as do additional statistics provided above. Likewise, current usage examples show that: NDR and WDR at most mention that "Schultüte" is regionally also called "Zuckertüte" as does this book eingeschränkte Vorschau in der Google-Buchsuche and even MDR uses both terms. I think the current status in de.WP ("Schultüte" as lemma and "Zuckertüte" as a redirect there) is correct and reasonable and there is no reason that it should be different outside in other wikipedias (though that's up to their editors to decide). --Qcomp (Diskussion) 14:41, 3. Mär. 2025 (CET)

I guess, we should ask the Atlas der Alltagssprache to include this in the next questionnaire. It helped with those people, who wnated the only regional name for Pfannkuchen as the lemma, Eierkuchen. It's of course a WL, but the lemma name should be made according to normal german understanding. --Grüße vom Sänger ♫ ^(Reden) 20:48, 2. Mär. 2025 (CET)

The Zuckertütenfest doesn't exist in most parts of Germany, this does't prove anything. --Ailura (Diskussion) 20:41, 2. Mär. 2025 (CET)

Well, it's wrong, that „it doesn't prove '''anything''' “ - it proves, that, in these parts, where Zuckertütenfest exists, the term Zuckertüte is used more often!

Plus, this opens up a whole other debate, in which parts it exists and where not. Let's rather not open this Pandoras box, friends.

Good evening. --Tecumseh*1301 (Diskussion) 21:49, 2. Mär. 2025 (CET)

So you suggest us to have two Articles about Zuckertüten and Schultüten? If the neue Bundesländer with 16 Million inhabitants including Berlin have Zuckertüten and Zuckertütenfeste this will not make a majority in Germany. I didn't open this argument, you did. --Ailura (Diskussion) 14:00, 3. Mär. 2025 (CET)

We've seen above that Google Ngram Viewer indicates "Schultüte" as far more frequent that "Zuckertüte" for at least the past 25 years. The Wortschatz-Portal der Universität Leipzig (text corpus: news 2022) corroborates that, with HK 15 for Schultüte compared to a meagre HK 18 for Zuckertüte (HK 18 means roughly 8× less frequent than HK 15). Cheers, --Yen Zotto (Diskussion) 15:05, 3. Mär. 2025 (CET)

So that's clear by now, nothing else to discuss. 3HK difference is beyond discussion. --Grüße vom Sänger ♫ ^(Reden) 15:37, 3. Mär. 2025 (CET)

Only one thing is clear.. that you want to end the discussion as soon as possible, Sänger. That's always not a good sign.

The Duden still has Zuckertüte more frequent than Schultüte and is by far a more important source than Google Ngram or a University of Leipzig portal..

The Duden is the most important source for anything about words in Germany. --Tecumseh*1301 (Diskussion) 23:14, 9. Mär. 2025 (CET)

Frustrierende Löschdiskussion

In Kassel gibt es zwei Eishockey-Clubs: Den DEL2-Club udn den Verein Eishockeyjugend Kassel, letzterer benutzt teilweise ebenfalls den Namen Huskies, hat jedoch eigene Strukturen und ist ein volwertiger und unabhängiger Verein. Als ich den Artikel Eishockey Jugend Kassel anlegte, hieß es er erfülle die Relevanzkriterien nicht, als ich diese belegte, hieß es der Verein sei ja lediglich eine "Jugendabteilung" des DEL2-Clubs (was nicht stimmt, die EJK hat sogar Erwachsenenmannschaften). Es ist frustrierend wenn sachliche Argumente übergangen werden. Habt ihr auch solche Phänomene beobachtet? (nicht signierter Beitrag von ChristosV (Diskussion | Beiträge) 00:00, 28. Feb. 2025 (CET))

Das ist doch so in etwa wie bei Eintracht Braunschweig und der Eintracht Braunschweig GmbH & Co.KGaA, der gleiche Laden, aus rein formalen Gründen verschieden benamt und aufgestellt. --Grüße vom Sänger ♫ ^(Reden) 17:46, 28. Feb. 2025 (CET)

Wer sollte IP-Adressen sehen können, wenn wir temporäre Konten aktivieren?

Mit temporären Konten ersetzen wir die IP-Adressen nicht angemeldeter Benutzer:innen durch neue, eindeutige Identifikatoren. Nach dieser Änderung werden die IP-Adressen nicht angemeldeter Benutzer:innen nicht mehr öffentlich einsehbar sein. Wir nehmen diese Änderung vor, um Sicherheit und Privatsphäre zu stärken, sodass sich unsere Beitragenden weiterhin sicher fühlen.

Allerdings müssen in einigen Situationen Benutzer:innen, die die Wikis schützen (vor Spam, Vandalismus, Belästigungen usw.), die IP-Adressen nicht registrierter Benutzer:innen einsehen, um sinnvoll arbeiten zu können. Um diese Bedürfnisse auszugleichen, sehen unsere Richtlinien vor, einigen Benutzer:innen den Zugang zu IP-Adressen temporärer Konten gemäß den nachstehend beschriebenen Verfahren zu ermöglichen.

Bevor wir im Verlauf dieses Jahres temporäre Konten in der deutschsprachigen Wikipedia aktivieren, müssen wir klären, wer die IP-Adressen temporärer Konten sehen kann. Wir möchten euch um eure Meinung dazu bitten.

Das Problem

Aktuell erhalten Benutzer:innen das Recht automatisch, wenn sie

1. erweiterte Rechte haben (z. B. Admins, Checkuser, globale Admins, Stewards – siehe die Richtlinie für weitere Beispiele)
2. keine erweiterten Rechte haben, aber seit mindestens sechs Monaten angemeldet sind und mindestens 300 Bearbeitungen im lokalen Projekt getätigt haben.

Das Problem betrifft nur den zweiten Fall. Wir haben diese Schwellenwerte gewählt, bevor wir temporäre Konten in Wikis aktiviert haben. Uns ist mittlerweile klar geworden, dass die Schwellen relativ niedrig sind und es für böswillige Akteure immer noch zu einfach ist, auf IP-Adressen temporärer Konten zuzugreifen. Mehrere Communitys haben ihre Bedenken hierzu geäußert, auch jene aus der ersten Pilotgruppe. Wir wollen, dass temporäre Konten die Privatsphäre der Beitragenden erheblich verbessern, daher müssen wir restriktiver sein, bevor wir diese Funktion auf Wikis mit großen Communitys bereitstellen.

Nach Beratung über andere Optionen mit Stewards, Communitymitgliedern aus einigen der Pilot-Wikis und englischsprachigen Communitymitgliedern, die auf Discord aktiv sind, fragen wir nun euch um Rückmeldungen, bevor wir die endgültigen Anpassungen vornehmen.

Der neue Ansatz

Wir schlagen vor, dass Benutzer:innen ohne erweiterte Rechte das Recht auf Ansicht von IP-Adressen temporärer Konten beantragen können, woraufhin Admins oder Stewards entscheiden, ob sie es erteilen. Unser Ziel ist es, den Zugang zu IP-Adressen konsequent auf jene zu begrenzen, die ihn benötigen. Das bedeutet, dass mehr manuelle Arbeit gefragt ist, doch die Belastung sollte geringer sein, als wenn die Rechte weiter automatisch vergeben würden.

Wenn wir temporäre Konten auf weiteren Wikis bereitstellen, können wir die Auswirkungen prüfen und unseren Ansatz nach Bedarf anpassen.

Wie es funktioniert

• Wenn Benutzer:innen ohne erweiterte Rechte IP-Adressen temporärer Konten anzeigen möchten, müssen sie eine Anfrage stellen, um in die Gruppe „IP-Betrachter temporärer Konten“ aufgenommen zu werden. Sie werden die Anfrage an Admins (die lokalen Communitys können über das Verfahren entscheiden) oder Stewards (für Wikis ohne lokale Admins) richten.
• Die Software verlangt, dass Benutzer:innen mindestens 300 Bearbeitungen getätigt haben und seit mindestens 6 Monaten angemeldet sein müssen. Admins und Stewards können den Zugriff auf IPs temporärer Konten nicht an Benutzer:innen gewähren, die diese Kriterien nicht erfüllen. Diese Vorgabe ist lediglich ein Minimum, und wir empfehlen den Communitys – insbesondere den größeren –, höhere Schwellenwerte vorzugeben. Auf der Grundlage der Rückmeldungen aus Communitys, die temporäre Konten bereits testen, empfehlen wir mindestens 600 Bearbeitungen als Schwellenwert.
• Wer die Anfrage bearbeitet, prüft, ob die anfragenden Benutzer:innen die Anforderungen erfüllen und ob sie eine gültige Begründung angegeben haben. Das Recht wird über Spezial:Benutzerrechte gewährt.
• Die Benutzer:innen, die das Recht gewähren, sind auch für die Entfernung des Rechts zuständig.

Die Anforderungen für den Zugang zur Funktion IP Info sind identisch mit jenen für den Zugriff auf IP-Adressen temporärer Konten.

Andere Optionen, die wir in Betracht gezogen haben

---

Wir haben eine Reihe von Optionen in Betracht gezogen:

• Ausschließliche Vergabe des Rechts an Benutzer:innen mit erweiterten Rechten.
  • Vorteil: Dies ist aus Sicht der Benutzersicherheit ideal, da nur Benutzer:innen, denen von den Communitys das Vertrauen ausgesprochen wurde, Zugriff erhalten können.
  • Nachteil: Das ist zu restriktiv. Viele Kontrollaktivitäten werden von Benutzer:innen durchgeführt, die keine erweiterten Rechte haben. Wenn wir dies tun, werden wir die Belastung der Benutzer:innen mit erweiterten Rechten im Kontrollbereich erhöhen.
• Erhöhung der Schwellenwerte für Bearbeitungszahl und/oder Alter des Kontos bei Beibehaltung der automatischen Vergabe.
  • Vorteil: Das ist eine einfache technische Anpassung.
  • Nachteil: Das Risiko, dass böswillige Akteure Zugriff auf IPs temporärer Konten erhalten, ist immer noch hoch. Mit Hilfe eines automatisierten Werkzeugs oder Skripts können böswillige Akteure jede Schwelle erreichen, egal wie hoch sie gesetzt wird. Gleichzeitig würde es für gutwillige Benutzer:innen in kleineren Projekten schwieriger, diesen Zugriff durch regelmäßige Bearbeitungen zu erhalten.

Unsere Fragen an euch

• Berücksichtigt der neue Vorschlag die datenschutzrechtlichen Bedenken ausreichend?
• Gibt es Konsequenzen für eure Community, von denen wir wissen sollten, während wir an dieser Richtlinie arbeiten? Wir möchten die Richtlinie innerhalb von 2–3 Wochen aktualisieren.

In den kommenden Wochen werden wir weitere Neuigkeiten und Materialien über temporäre Konten und damit verbundene Funktionen bereitstellen.

Noch einmal vielen Dank an alle, die uns geholfen haben, verschiedene Optionen auszuloten. Wenn ihr mehr über das Projekt erfahren möchtet, lest den Diff-Beitrag, besucht unsere Projektseite und seht die FAQ durch. Abonniert den Newsletter, um am Laufenden zu bleiben. Danke! NKohli (WMF) und SGrabarczuk (WMF) (Diskussion) 00:20, 5. Mär. 2025 (CET)

Bei manueller Vergabe bräuchten wir eine Seite analog zu WP:GV/R, auf der man das Recht beantragen kann. Wenn wir von manueller Vergabe sprechen, sollte das Recht aus meiner Sicht nur an erfahrene Wikipedianer vergeben werden, die die Berechtigung wirklich benötigen, z.B. zur Vandalismus-, Spam- oder Trollbekämpfung. Das dürfte - grob geschätzt - eine niedrige dreistellige Anzahl an Personen sein. Das setzt aber natürlich voraus, dass das von Szymon skizzierte Vergabeverfahren auf Zustimmung stößt. --TenWhile6 00:31, 5. Mär. 2025 (CET)

Ich bin ein bisschen irritiert? Es hieß doch, dass alle aktiven Sichter*innen dieses Recht automatisch bekommen sollen? Ich sehe nicht wirklich den Sinn darin, das jetzt unnötig zu verkomplizieren. Die aktive Sichter*innenstufe ist als Hürde hoch genug angesetzt (Wikipedia:Gesichtete Versionen#Automatische Vergabe des Status „(Aktiver) Sichter“). Wenn wir jetzt doch irgendwelche spezielle Kriterien ausarbeiten wollen braucht es dafür ein MB und das wird dann definitv nicht in 2 bis 3 Wochen zu einem Ergebnis kommen.

Hier im Hinterzimmer (ja, diese Seite blieb leider in der Realität ein solches, auch wenn die Idee mal war, dass es eine zentrale Diskussionsseite zum Projekt werden soll) ist die Diskussion übrigens nicht so gut aufgehoben. -- Chaddy · D 00:48, 5. Mär. 2025 (CET)

Ich halte für unser Projekt auch die automatische aktive Sichtervergabe für angemessen. Andere Projekte (die nicht auf Sichter setzen) mögen das gerne per Einzelfallentscheidung machen, aber bei uns ist das aktive Sichterrecht schon ziemlich schwer zu erreichen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:18, 5. Mär. 2025 (CET)

Wenn ein geübter Vandale sechsmal pro Tag sein temporäres Konto ändern kann, ist für normale Benutzer also nicht mehr zu erkennen, dass es sich um dieselbe Person handelt? Das erschwert die Arbeit im RC-Bereich natürlich. Wie ist es bei den „IP-Betrachtern temporärer Konten“? Werden ihnen die IP-Adressen standardmäßig angezeigt oder müssen diese erst eingesehen werden? Im zweiten Fall wäre das Erkennen von Vandalen mit höherem Zeitaufwand verbunden. --Brettchenweber (Diskussion) 00:44, 5. Mär. 2025 (CET)

IP-Adressen müssen immer manuell aufgedeckt werden. --TenWhile6 00:49, 5. Mär. 2025 (CET)

Gibt es schon Vorschläge, wie die Arbeitsgeschwindigkeit im RC-Bereich trotzdem erhalten bleiben kann? Wir können natürlich schon den ersten unsinnigen Edit melden, aber das erhöht das Arbeitsaufkommen auf VM ungemein. --Brettchenweber (Diskussion) 00:58, 5. Mär. 2025 (CET)

Das halte ich nicht für sinnvoll.

1) ich gehe davon aus, dass die typischen Schülervandalen sehr gut per Tempkonto verfolgbar sind, sogar ohne Aufdeckrechte. (Damit ein neues Konto generiert wird, müssen die Cookies gelöscht werden, das wird wohl kaum jemand tun.) -> das wiederum bedeutet, dass man sehr gut sieht, wann der Zweitedit kommt.

2) Um Sperrumgeher (die sicherlich intelligent genug sind, Cookies zu löschen) oder langfristigen Abuse (den man nur per Sperrlog der IP identifizieren kann) zu bemerken, muss man aber trotzdem die IP-Adresse aufdecken und sich einmal ansehen, was die IP so getrieben hat. Das ist an der Stelle tatsächlich ein Klick mehr. --TenWhile6 01:04, 5. Mär. 2025 (CET)

Werden von den Admins dann IPs oder temporäre Konten gesperrt? --Brettchenweber (Diskussion) 01:16, 5. Mär. 2025 (CET)

Mindestens die temporären Konten – genau die können auch einfach auf VM gemeldet werden. Auf nowiki sperren sie die IP nicht zusätzlich – wie wir das hier machen wollen, dürfte auf WP:AN noch rechtzeitig Thema werden. --TenWhile6 01:37, 5. Mär. 2025 (CET)

Typisch, für dewiki erscheint ihnen die Schwelle zu niedrig, auf allen anderen Wikis ist es ok. Also doch ein Trollschutzprogramm der WMF. Hier soll es also denen, die sich in dem Bereich tummeln, so schwer wie möglich gemacht werden. --Itti 06:25, 5. Mär. 2025 (CET)

Hast du den Text gelesen? Da steht nicht von "auf allen anderen Wikis ist es ok", sondern davon, dass sie erstmal mit der automatischen Vergabe an alle mit 300+ Edits gestartet waren, aber sich nun nach einigen Monaten Testphase fragen, ob das dem Datenschutzziel genügt. Wenn es künftig stattdessen eine manuelle Vergabe gibt, gilt dass nicht nur für dewiki, sondern auch für alle anderen Projekte (inkl. denen, die bereits temporäre Konten haben).

Der Hauptunterschied dieser Änderung wäre, dass nicht alle 22.000 aktiven Sichter automatisch das Recht zur IP-Einsicht erhalten, sondern nur die, die das Recht beantragen, weil sie mindestens sporadisch auch mal mit Vandalismus umgehen (ich würd auf maximal 500 User tippen, vermutlich deutlich weniger). Wenn ich einfach nur Artikelarbeit mache, muss ich keine IPs einsehen können.

@Brettchenweber: Bei Sperrung temporärer Konten wird ein Autoblock für die IP gesetzt. Im Normalfall wird es also keine extra Sperre der IP brauchen.

Dass man pro Tag 6 temporäre Konten erstellen kann, ist übrigens nicht anders dazu, dass man pro Tag 6 normale Konten erstellen kann, die du auch nicht einander zuordnen kannst ohne CU (im Gegenteil sehen wir bei temporären Konten also deutlich mehr, weil du da die IP sehen kannst und auf der von hgzh genannten Spezialseite anschauen kannst, welche temporären Konten von der gleichen IP/Range arbeiten).

@Chaddy wir müssen kein MB machen und keine eigenen Richtlinien definieren, die WMF fragt uns nach Feedback zur Anpassung der globalen WMF-Richtlinien. Wir können dann freiwillig auch striktere lokalere Richtlinien beschließen, aber das muss nicht jetzt sein, das muss auch gar nicht sein, darüber können wir als Projekt diskutieren, wann immer wir wollen (oder auch gar nicht). --Johannnes89 (Diskussion) 08:11, 5. Mär. 2025 (CET)

Naja, das ganze ist ja offensichtlich sehr kontrovers, wie diese Diskussion hier zeigt. Und es kursieren hier in dieser Diskussion auch schon mehrere konkurrierende Vorschläge. Also doch, das läuft wohl schon auf ein MB hinaus. -- Chaddy · D 17:54, 5. Mär. 2025 (CET)

Nö, letztendlich ist es an der WMF (die ja nicht nur von dewiki Feedback einholt, sondern Input aus vielen Projekten sowie auch speziell von Funktionsträgern wie Checkusern oder Stewards einholt) zu überlegen, wie die finalen globalen Richtlinien aussehen sollen.

Darüber können wir am Ende eh nicht entscheiden, sondern nur unseren Input geben, wie alle anderen Projekte auch (die Verantwortlichen bei der WMF können ja auch eh nicht einfach frei danach handeln, was Volunteers wollen, sondern müssen auch beachten, was WMF Legal für konform mit Standards wie der DSGVO hält). Was immer im Zuge der aktuellen Feedbackrunden rauskommt (entweder die bereits bestehende Richtlinie oder irgendein Update) gilt dann für uns als Mindeststandard, den wir dann noch per MB verschärfen könnten - aber nicht müssen. Wenn wir uns nicht einigen würden, bleibe es halt bei dem Mindeststandard, den die WMF definiert, zu dessen möglicher Anhebung wir gerade Feedback geben. --Johannnes89 (Diskussion) 18:25, 5. Mär. 2025 (CET)

Es wird eine neue Spezialseite Special:IPContributions geben, die zu einer IP-Adresse oder Range die zugehörigen Bearbeitungen temporärer Konten anzeigt, die von der/den IP-Adresse(n) aus getätigt worden sind (phab:T363357). -- hgzh 07:56, 5. Mär. 2025 (CET)

Bitte an die aktiven Sichterrechte koppeln. In Zeiten sinkender Mitarbeiter- und Adminzahlen sehe ich keinen Bedarf für zusätzliche Bürokratie und formale Prozesse. Die Kriterien dort sind aufgrund ihrer höheren Spezifität mE mit der 600-Edit-Empfehlung vergleichbar, obwohl die absoluten Zahlen natürlich geringer sind. Zudem ist mir nicht klar, inwiefern die „Belastung [...] geringer sein [sollte], als wenn die Rechte weiter automatisch vergeben würden“. Man kann es ohnehin nicht verhindern, dass Personen, die unbedingt an die IP-Adressen kommen wollen, dies auch erreichen.

Ich wäre indes sehr dafür, mit einer Sperre des temporären Kontos im Sinne eines Autoblocks auch die zugehörige IP zu sperren. Alles andere würde es doch sehr leicht machen, die Kontensperre zu umgehen. In jedem Browser kann man heutzutage mit drei Klicks Websitedaten gezielt löschen. -- hgzh 07:48, 5. Mär. 2025 (CET)

Autoblock gibt es auch, die Sperrung temporärer Konten funktioniert genauso wie die Sperre normaler Konten. Falls du es dir mal anschauen willst: test2wiki:Special:Block/~2025-29033.

In meinen Augen ist es nicht nötig, allen 22.000 aktiven Sichtern automatisch das Recht zur IP-Einsicht zu geben. Mit 300 Edits hab ich typischerweise nichts mit Vandalismusbekämpfung zu tun. Und wenn wir mal WP-Sprachversionen in nicht-demokratischen Regionen denken, ist es vermutlich ganz gut, wenn man nicht nach 300 Pseudoedits wie bisher auf IPs zugreifen kann, sondern die manuelle Vergabe noch eine extra Hürde ist (wo jemand mit Pseudoedits auffallen würde, so wie es auch bei WP:GVR manchmal auffällt, wenn jemand Edits offensichtlich nur macht, um schneller Rechte beantragen zu können). --Johannnes89 (Diskussion) 08:19, 5. Mär. 2025 (CET)

Wäre es sinnvoll, die Zahl der Zurücksetzungen miteinzubeziehen, weil diese natürlich bei RClern höher ist, oder könnte das einen falschen Anreiz setzen? --Brettchenweber (Diskussion) 08:25, 5. Mär. 2025 (CET)

Ich würde sagen, das setzt eher einen falschen Ansatz.

Meines Erachtens sollten wir auch versuchen, die Arbeit hierzuwiki nicht komplizierter und bürokratischer zu machen als sie ohnehin schon ist. Das manuelle Beantragen setzt natürlich für die Vandalenbekämpfer höhere Hürden. Wie hgzh sagte, wer es am Ende wirklich haben will um damit zu schaden, kriegt das auch hin. Daher sehe ich den Nutzen höherer Hürden auch eher weniger (auch wenn man natürlich darüber nachdenken könnte die Hürden für aktiver Sichter zu erhöhen, da die meines Erachtens sehr niedrig sind) --Ichigonokonoha (Diskussion) 08:47, 5. Mär. 2025 (CET)

Mir wären die Reverts auch eher egal. Aber schon exakt die aktuell gültigen Mindestkriterien + manuelle Vergabe anstatt automatisch wäre ja schon eine kleine Hürde für mehr Datenschutz, die ich nicht schlecht fände --Johannnes89 (Diskussion) 08:49, 5. Mär. 2025 (CET)

Das finde ich nicht gut. Aber offensichtlich sollen die RCler in dewiki klar benachteiligt werden, vermutlich weil das Sichtungssystem bei der WMF eh in einem schlechten Licht steht. --Itti 09:21, 5. Mär. 2025 (CET)

Wo genau siehst du eine Benachteiligung für dewiki? Wenn es zur manuellen Vergabe kommt, dann für alle Wikis, nicht nur für uns. Mit den Sichtungssystem hat das auch null zu tun. Und es gäbe doch keinen einzigen aktiven RCler, der die Rechte bei uns nicht bekommen könnte? --Johannnes89 (Diskussion) 09:24, 5. Mär. 2025 (CET)

In den anderen Wikis haben die die Rechte bereits. Dass denen die entsogen werden, davon habe ich nichts gelesen. Ob hier jemand die bekommen soll, wird dann, dafür kenne ich das hier zu gut episch ausdiskutiert werden. Schlussendlich wird so mancher es gar nicht "beantragen" und andere haben keinen Bock mehr darauf. --Itti 09:36, 5. Mär. 2025 (CET)

Das Problem sehe ich auch - gerade bei der Vergabe zusätzlicher Rechte wird häufig von der Seite hereingeredet. Eher fände ich es sinnvoll höhere automatische Vergabe zu machen - bspw. 1000 oder 2000 Beiträge. Ich brauche dieses Recht nicht, da es mir zurzeit reicht mich um die ganzen Seiten auf meiner Beo zu kümmern, aber ich fände es sinnvoll, wenn es RClern direkt zur Verfügung steht und es im Zweifel nicht zu höheren Hürden kommt - vor allem dann, wenn es über AAF beantragt werden muss. --Ichigonokonoha (Diskussion) 09:58, 5. Mär. 2025 (CET)

Meiner Meinung nach sollten datenschutzrelevante Rechte nicht automatisch vergeben werden, schon aus Gründen der Datenzugangssparsamkeit. (Ich bin Sichter, wäre aber gar nicht auf den Gedanken gekommen, dass ich das Recht haben sollte, IP-Adressen einzusehen, die aus Datenschutzgründen verborgen werden.) Mit AGF sollte ein simples opt-in mit ggf der Unterzeichnung der notwendigen Erklärung, dass man alle Regeln zum Datenschutz beachtet, ausreichen, eine individuelle Prüfung durch Admins halte ich erstmal für unnötig. Es wäre mE auch sinnvoll, dass das Recht nach zu langer Inaktivität auch automatisch wieder verloren geht (aber danach auch problemlos wieder erlangt werden kann). --Qcomp (Diskussion) 10:10, 5. Mär. 2025 (CET)

Genau. Wir waren eigentlich davon ausgegangen, dass es so läuft wie bei dem IP-Informationstool. Da haben bei uns auch nur aktive Sichter drauf Zugriff, wenn sie in den Einstellungen den Haken setzen, dass sie sich mit Richtlinien für das Werkzeug IP-Information auseinandergesetzt haben und ihnen zustimmen.

Nun kommt die WMF aber an, dass bei uns eine manuelle Prüfung durch Admins oder sogar Bürokraten erfolgen soll, weil die anderen Sprachversionen/Projekte zu doof sind den Sinn in Sichtern zu sehen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:33, 5. Mär. 2025 (CET)

Für eine solche Prüfung habe ich hier bislang keine überzeugenden Argumente gelesen und schliesse mich dann denen an, die den Vorteil des WMF-Vorschlags nicht sehen: eine inhaltliche Prüfung jedes Antrags auf Erteilung dieser Rechte durch Admins halte ich für unpraktisch (auf der Basis welcher Kriterien und Daten sollen die Admins das entscheiden? haben sie nicht schon so genug zu tun? welche "Bedrohung" wird denn dadurch weniger wahrscheinlich gemacht?). Ich möchte auch nochmal auf das Grundprinzip AGF verweisen, das mE zunächst eine weniger restriktive Vergabe nahelegt. Wenn sich zeigt, dass mit einem automatisch nach opt-in erteilten Rechten schlecht umgegangen wird, kann man sich immer noch zu einer restriktiveren Vergabe entschliessen. --Qcomp (Diskussion) 13:30, 5. Mär. 2025 (CET)

Ggf. auch einfach entziehen, wie es auch mit dem Sichterrecht gemacht wird, wenn damit nicht ordentlich umgegangen wird. Viele Grüße --Itti 13:33, 5. Mär. 2025 (CET)

Ggf. auch automatisch bei Sichterrechtentzug. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:48, 5. Mär. 2025 (CET)

Itti andere Wikis (wir reden über 12 der 800 WMf-Projekte [14]) testen halt gerade als Pilotwikis die temporären Konten, während zahlreiche Adminwerkzeuge dafür gerade erst noch in Entwicklung sind. Dewiki könnte sich bei der WMF künftig gerne auch als Pilotwiki melden, aber normalerweise meckert unsere Community immer, wenn wir nicht fertig entwickelte Dinge testen sollen. You can’t have it both ways.

Nach meinem Verständnis bedeutet eine Umstellung auf manuelle Vergabe auch, dass es bei den Pilotwikis die entsprechende Umstellung gibt. Wenn nicht, haben diejenigen, die bisher dort das Recht automatisch bekommen haben (in nowiki keine 400 User [15]), halt Glück gehabt. Wie gesagt: Wir könnten uns künftig gerne auch mal häufiger als Pilotwiki melden und dann vielleicht auch davon profitieren, dass in einer Frühphase irgendwas anders läuft, als im regulären Rollout. Bisher will unsere Community regelmäßig, dass andere Projekte unausgereifte Technik testen und bei uns bloß nichts unfertiges ankommt. --Johannnes89 (Diskussion) 10:27, 5. Mär. 2025 (CET)

Meine Autoblock-Anmerkung bezog sich auf die obige Anmerkung von TenWhile6 zu nowiki. Ich habe es mir auf dem Testwiki angesehen, danke, so sollte es auch hier voreingestellt sein.

Bei Sprachversionen in nicht-demokratischen Regionen stimme ich dir zu, und diese können den Zugriff natürlich auch selbst restriktiver handhaben. Ich bleibe aber bei meiner Ansicht: wer unbedingt an die IPs kommen will, den schrecken auch 300 zusätzliche Edits nicht ab und der kann sich genauso durch ein manuelles Vergabeverfahren mogeln wie sich zum Admin wählen lassen. Gegen diese „kriminelle Energie“ wird man mE nicht ankommen. Natürlich soll das nicht heißen, dass man auf jegliche Schwelle verzichten kann, aber der „Grenznutzen“ einer höheren Schwelle wird irgendwann sehr gering.

Zudem muss man ja in den Einstellungen noch manuell sein „Ehrenwort“ geben, also würden auch nicht sofort alle 22.000 Sichter mit den Rechten ausgestattet sein; ein signifikanter Prozentsatz vsl. von dieser Möglichkeit gar nichts mitbekommen. Gruß, -- hgzh 08:40, 5. Mär. 2025 (CET)

Nowiki zeigt dann ja, dass für deren Zwecke der Autoblock ausreichend ist, sonst würden die Admins noch manuelle IP-/Rangesperren setzen.

Ich stimme dir zu, dass man am Ende um jede Hürde rumkommt, aber halte trotzdem eine manuelle Vergabe für Datenschutzfreundlicher, weil wenigstens eine Chance besteht, Missbrauch zu entdecken. --Johannnes89 (Diskussion) 08:52, 5. Mär. 2025 (CET)

Ich stimme da zu. Ich würde die Hürde "Sichterrechte" auch für zu niedrig ansehen, und das Recht auf die beschränken, die es wirklich benötigen, und das sind fast ausschließlich gewähte Funktionsträger, RCler, Neulingsbetreuer/Mentoren, Urheberrechtsverletzungs-Bekämpfungs-Spezialisten. Benutzer, die nur in Ruhe Artikel ihres Interesses ausbauen, brauchen das Recht zur IP-Einsicht zumindest meiner Meinung nach nicht, warum sollte man es ihnen automatisch geben? Tobias, auf Arbeit als --Auf Maloche (Diskussion) 10:00, 5. Mär. 2025 (CET)

> Neulingsbetreuer
Jeder kann durch einen einfachen Haken (auch weit vor dem Sichterrecht) Lotse werden. Warum ich als Lotse (ja ich war mit meinem alten Account Lotse (aber auch als Mentor)) Zugriff auf IPs gebraucht hätte, ist mir vollkommen schleierhaft. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:38, 5. Mär. 2025 (CET)

Der erste Teil deiner Aussage stimmt nicht, dein Konto muss mindestens 90 Tage alt sein und 500 Edits haben, um Lotse zu werden, siehe Spezial:CommunityConfiguration/Mentorship. Ich persönlich frage mich manchmal, ob das nicht sogar noch zu niedrig ist, aber jedenfalls kommen Sichterrechte früher. Wäre aber jetzt off-topic… --Johannnes89 (Diskussion) 13:44, 5. Mär. 2025 (CET)

Ganz grundsätzlich: Ja, man kann jede Regel aushebeln, wenn man es aus schlechten Absichten wirklich will. Aber man sollte zumindest den Aufwand, den jemand mit schlechten Absichten treiben muss, hoch halten, damit nicht einfache, botbetriebene Konten an dieses Recht kommen. Auch kriminelle Energie ist endlich ;) --Kritzolina (Diskussion) 11:13, 6. Mär. 2025 (CET)

Ich halte aus Datenschutzgründen eine automatische Vergabe des Rechts an zigtausende Nutzer auch für problematisch. Ich glaube auch nicht, dass es langfristig ein riesiger bürokratischer Aufwand ist, wenn alle, die in der Vandalismusbekämpfung aktiv sind, einmalig dieses Recht beantragen müssen. --Discostu (Disk) 10:02, 5. Mär. 2025 (CET)

ich klicke auch auf die Bearbeitungsliste von IPs die mir durch einen Edit auffallen. Aber ob das eine ähnliche IP wie in der Vorwoche ist, das schaue bzw erkenne ich nicht. Somit bleibt doch für mich alles beim alten. Die Beiträge die jemand zukünftig am selben Tag macht sehe ich üblicherweise. Teilweise sogar über Monate. Also alles gut. --0815 User 4711 (Diskussion) 10:15, 5. Mär. 2025 (CET)

Das Problem ist, die IP-Verschleierung ist effektiv Trollschutz. RClern wird es noch schwerer gemacht, nachdem bereits ein CU völlig ineffektiv gemacht wurde. Wenn die WMF meint, Datenschutz verträgt sich nicht mit offen sichtbaren IPs, dann sollen sie IPs die Nutzung verbieten. Nur noch angemeldet editieren und fertig. So ist das eine einseitige Bevorzugung aller, die sich zum Trollen abmelden und eine Benachteiligung derer, die sich bislang darum gekümmert haben. Vor allem die ohne Adminrechte, aber sorry, wer mit Adminrechten kümmert sich denn schon darum? Gut grundsätzliche Diskussionen sind denen eh egal, zumal es viel zu spät ist. --Itti 13:06, 5. Mär. 2025 (CET)

Btw. ich kann noch nicht mal mehr meine Bearbeitungsliste, oder neue Artikelliste ansehen. Ist das auch eine Verbesserung? --Itti 13:08, 5. Mär. 2025 (CET)

Durch ständige Wiederholung wird es nicht wahrer, das Gegenteil ist der Fall:

• Wenn ich effektiv trollen möchte, kann ich mir jeden Tag 6 Sockenpuppen erstellen. Damit kann ich viel ungestörter Unfug machen als mit temporären Konten, weil da nur fünf dewiki Checkuser meine IP sehen können und die auch nur nach Richtlinien, die deutlich schwerer sind, als in allen anderen Projekten.
• CU „wurde nicht ineffektiv gemacht“, die dewiki Community hat sich ineffektive Regeln gegeben. Könnten wir ändern und CU so wie alle anderen Projekte handhaben. Das ist unsere Schuld, nicht die der WMF.
• Wenn ich mit temporären Konten trolle, können nach bisheriger Planung 22.000 aktive Sichter meine IP sehen, nach dem jetzigen Vorschlag jedenfalls alle Sichter (einige hundert?) die sich mindestens sporadisch mit RC/Vandalismus beschäftigen. Damit sind die alle so ne Art Mini-CU und können deutlich leichter Zusammenhänge erkennen, als bei angemeldeter Trollerei.
• In keinem der 12 Pilotprojekte gab es übrigens bisher neue Probleme mit Vandalismus/Trollen, im wesentlichen läuft es dort genau wie früher mit IPs.

--Johannnes89 (Diskussion) 13:51, 5. Mär. 2025 (CET)

Funktionslogisch entspricht das Recht „IP-Betrachter temporärer Konten“ einem Rollbacker-Recht auf Commons, das auf dem dortigen c:Commons:Requests for rights einfach beantragt werden kann und genauso einfach vergeben wird. Auf dewiki gibt es eine solche zentrale Seite nicht (vielleicht ja mal ein Anstoß, dies zu verändern …). Für das Sichtungsrecht haben wir Wikipedia:Gesichtete Versionen/Rechtevergabe, für „Benutzerkontenersteller“/noratelimit wird die Wikipedia Diskussion:Bürokraten verwendet und für alles Sonstige Wikipedia:Administratoren/Anfragen – alles Rechte, die in einer ähnlichen Logik stehen und ebenfalls mit einer recht einfachen Prüfung und ohne die befürchten langen Diskussionen vergeben werden. Wer es benötigt, bekommt es einfach. Wer es nicht benötigt, bekommt es nicht automatisch mit einem anderen Recht und damit mehr Informationen, als die Person vielleicht haben wollte (das Thema Datensparsamkeit, das uns auf dewiki ja üblicherweise sehr wichtig ist, wäre damit gut behandelt). Und wer es unpassend verwendet hat, bekommt es auch leicht wieder entzogen, ohne dass andere vielleicht nicht unpassend verwendete Rechte (wie eben das aktive Sichten) automatisch mitzuentziehen. Oder gar eine automatische Vergabe, wenn die Checkbox in den Einstellungen angekreuzt ist und ein Schwellenwert überschritten wurde. Unterm Strich sehe ich fast nur Vorteile, einen etwas höheren Aufwand (insbesondere am Anfang) bei der Rechtevergabe, dafür mehr Transparenz, wer denn tatsächlich im Themenfeld der Vandalismusbekämpfung aktiv ist. Über einen automatischen Entzug nach einer bestimmten inaktiven Zeit sollte ebenfalls aus Kontoschutzgründen nachgedacht werden. Grüße, —DerHexer (Disk., Bew.) 14:47, 5. Mär. 2025 (CET)

Und welchen Unterschied siehst Du zur nach opt-in automatischen Vergabe? Dabei bekommt auch keiner das Recht, der es nicht meint zu brauchen, man erhält ebenso einen Überblick darüber, wer es hat, aber man spart sich den "Prüfungsschritt" und die damit verbundene Notwendigkeit, Zulassungskriterien zu definieren (sowie mögliche Verzögerungen). Wenn die "Zulassungskriterien" so sind, dass alle hinreichend aktiven und erfahrenen Editoren, die das Recht wollen, es auch bekommen, dann genügt ein opt-in. Wenn eine inhaltliche Prüfung als notwendig angesehen wird ("Hat Editor X überzeugende Gründe dafür, dieses Recht zu benötigen'"), dann sehe ich zwei wichtige Fragen als bisher nicht beantwortet an: (i) "Was sind hinreichend überzeugende Gründe?" und (ii) "Warum ist anzunehmen, dass Editoren ohne solche Gründe das Recht beantragen und missbrauchen würden?" Ohne diese Antworten kommt mir die vorgeschlagene Regelung wie ein pauschales Misstrauensvotum vor. --Qcomp (Diskussion) 15:16, 5. Mär. 2025 (CET)

+1 Dem ist nichts hinzuzufügen. Vielen Dank. --Itti 15:23, 5. Mär. 2025 (CET)

(BK) So wie ich das aktuelle System verstehe, wäre bei Checkbox + automatischer Vergabe unklar, wer dann überhaupt das Recht hat. Das wäre mit einer Kopplung an eine schon vorhandene Gruppe ein bisschen transparenter (nur ist dann halt zu fragen, ob es eine passende Gruppe gibt – Es gab ja einige Argumente, die Sichter für zu viele in der Anzahl finden). Aber selbst dann wüsste man ja nicht, welcher der Sichter in den Einstellungen das Häkchen gesetzt hat und wer nicht. Den hinreichend überzeugenden Grund würde ich minimal ansetzen (Bedarf in der Vandalismusbekämpfung – das könnte fast jede Person, die hier ihre Beo pflegt, schreiben). Es geht, wie geschrieben, weniger um Missbrauch und mehr um Datensparsamkeit. Alle, die es benötigen und denen wir vertrauen, aber nicht alle, denen wir vertrauen, es aber nicht benötigen. Grüße, —DerHexer (Disk., Bew.) 15:28, 5. Mär. 2025 (CET)

Warum kann man es nicht so lösen, dass man, sobald man auf das Häkchen klickt, das Recht als extra Nutzergruppe erhält. Und bei Deaktivieren des Hakens oder dem Entzug der Sichterrechte automatisch auch diese extra Nutzergruppe wieder entfernt? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 16:25, 5. Mär. 2025 (CET)

Danke für die Antwort. Mir war nicht klar, dass das "Setzen des Häkchens" nicht öffentlich einsehbar ist. Geht das nicht zu machen? Etwa so, dass zusammen damit der Status eines IP-Sichters vergeben wird, der ebenso einsichtbar ist wie der des Sichters? Aber wenn die Erteilung so quasi-automatisch erfolgt wie z.B. die Bitte um einen Artikelimport zwecks Übersetzung, dann hab ich da letztlich auch auch kein Problem mit, da ich auch bei den Admins von AGF ausgehe. So ein Durchwinken kommt mir nur wie eine schlechte Nutzung ihrer Arbeitskraft/Zeit vor. --Qcomp (Diskussion) 16:27, 5. Mär. 2025 (CET)

Sorry, aber wozu braucht irgendein normaler Nutzer ohne weitere Rechte Zugriff auf IP-Adressen? Wenn es Konflikte gibt, sollen das Leute mit Rechten klären, ansonsten sollten wir Edits anschauen, nicht Benutzer. --Ailura (Diskussion) 14:55, 5. Mär. 2025 (CET)

Es gibt viele CVU, die nur aktive Sichter sind. Die benötigen die IP-Adresse, um zu erkennen, ob die Person ein Wiedergänger ist. Nur Wiedergänger werden üblicherweise auf WP:VM gemeldet. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 15:02, 5. Mär. 2025 (CET)

::Ich rede hier von Usern ohne erweiterte Rechte, CU haben erweiterte Rechte, wenn das die falschen sind, muss man darüber auch reden. --Ailura (Diskussion) 15:07, 5. Mär. 2025 (CET) Korrektur von MM

Wozu? Weil "normale User", die sich mit dem RC beschäftigen, sich IP-Ranges merken, um gezielt bestimmte Trolle zu identifizieren. Wir haben da eine nette Bandbreite, wie den Pommestroll, den Vodafone-Troll, usw. Manche können nur durch gezielte Rangesperren gestoppt werden, was durch die PVv6-Ranges nicht einfacher geworden ist und 90% der Admins sind nicht mal in der Lage eine Range zu berechnen, geschweige denn... Aber klar, genau das ist es, was ich befürchtete. Der Trollschutz wird über alles gestellt, nur noch etwa 5 User werden zukünftig "auserwählt" sein und alles wird gut. Zumindest wenn man ein Troll ist. CUler dürfen gar nicht die Trolle sperren, die sie identifizieren, nur mal nebenbei erwähnt. Ob sie "die falschen" sind, oder nicht. --Itti 15:08, 5. Mär. 2025 (CET)

(BK) Dieser unsachliche Defätismus ist nicht hilfreich. Für RCler wird das Leben mit dem genannten CU-light einfacher, eben weil nun IP-Adressen und Browser über die temporären Konten verknüpft werden. Ja, man müsste das Recht wohl einmal betragen. Ich glaube, das bekommen die, die es benötigen, hin (meine Beispiele zu ähnlichen Rechten und wie es da funktioniert siehe zuvor). – CUler dürfen über all Trolle sperren. Nur bekommt es, wie Johannnes89 geschrieben hat, dewiki seit Jahre nicht hin, eine dem entgegenstehende lokale Regel endlich zu aktualisieren. Das hat mit der hiesigen Angelegenheit nun wirklich gar nichts mehr zu tun. —DerHexer (Disk., Bew.) 15:13, 5. Mär. 2025 (CET)

Hallo, ich bin Szymon von der Wikimedia Foundation, von den Movement Communications- und Trust and Safety Product-Teams. Grüße aus Warschau.

I'm reading the discussion and will give more replies, but I think I should confirm - about "nur noch etwa 5 User werden zukünftig "auserwählt" sein" - all administrators will continue to have the right, also all CheckUsers, and a couple of smaller groups. I'd like to emphasize: will continue to have, because the setting is already made, it works on the pilot wikis. This right is designed for people who either are in advanced groups, or actually track trolls and vandals. --SGrabarczuk (WMF) (Diskussion) 14:42, 7. Mär. 2025 (CET)

Ich meinte natürlich nicht CU, sondern CVU Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 15:10, 5. Mär. 2025 (CET)

Müssen sie dann halt einmal einfach beantragen. Wo ist das Problem? —DerHexer (Disk., Bew.) 15:14, 5. Mär. 2025 (CET)

Es muss eine sinnvolle Grenze irgendwo zwischen 5 und 20.000 geben. Im CVU-Projekt sind 50 Personen ohne Rechte angemeldet. --Ailura (Diskussion) 15:17, 5. Mär. 2025 (CET)

Als Kompromiss aus automatischer Vergabe und Sparsamkeit, natürlich nur sofern technisch Umsetzbar:

• Automatische Vergabe für aktive Sichter mit allgemeinem Stimmrecht.
• Bei Auslauf des allgemeinen Stimmrechts oder bei manuellem Entzug des Sichterrechts auch automatischer Entzug.
• Zusätzlich manueller Rechteentzug durch Administratoren bei Missbrauch (wie auch bisher beim Sichterrecht).

Rein subjektiv betrachtet, ohne wirklich Zahlen hierzu zu kennen, gehe ich nämlich davon aus, das nur ein geringer Anteil Nutzer mit aktivem Sichterrecht (relativ zur gesamten Anzahl gesehen) überhaupt noch aktiv genug ist, um auch noch das allgemeine Stimmrecht zu besitzen. -- Martin _(Mpns/BD) 17:43, 5. Mär. 2025 (CET)

Was wäre denn Missbrauch in diesem Fall und wie kann man den feststellen? -- Chaddy · D 17:51, 5. Mär. 2025 (CET)

"(wie auch bisher beim Sichterrecht)" durch Admin-Entscheid, oft/meist im Mehraugen-Prinzip. Natürlich Basis der von der WMF vorgegebenen Richtlinien zur Rechtenutzung. -- Martin _(Mpns/BD) 18:53, 5. Mär. 2025 (CET)

Das bedeutet meine Fragen leider nicht wirklich. Wie sähe konkret Missbrauch bei dieser Funktion aus? Die IP-Adressen zu veröffentlichen dürfte klar Missbrauch sein? Aber sonst? Gibt es sonst auch andere Formen des Missbrauchs dieser Funktion? Diese Form des Missbrauchs lässt sich natürlich dann auch leicht entdecken. Aber bei anderen Formen des Missbrauchs? -- Chaddy · D 19:39, 5. Mär. 2025 (CET)

Hey @Chaddy, you can find some description of the intended use (and e contrario misuse) of this right in the policy, secion Verwendung und Offenlegung der IP-Adressen temporärer Konten. --SGrabarczuk (WMF) (Diskussion) 15:05, 7. Mär. 2025 (CET)

Thank you -- Chaddy · D 04:24, 8. Mär. 2025 (CET)

Gibt es irgendwo eine Zusammenfassung des Stands der Test-Wikis? Ich bin in einem davon sehr aktiv (Konto mit 20.000 Bearbeitungen) und habe anders als weiter oben erwähnt keine Berechtigungen, die IP-Adressen einzusehen. Ich hatte daran aber auch kein Interesse; Admins und ein Pool von Vandalenbekämpfern haben die Berechtigung (die haben ganz andere Problem als hier, alleine schon weil es das System mit den gesichteten Seiten nicht gibt). --2001:16B8:BA72:4A00:BCD5:D721:698C:8349 17:47, 5. Mär. 2025 (CET)

Wenn du in einem der 12 Pilotwikis mit nem Konto aktiv bist, was den aktuell für die Pilotwikis geltenden Kriterien aus wmf:Policy:Wikimedia Access to Temporary Account IP Addresses Policy entspricht und dort in letzter Zeit editiert hast, solltest du in der entsprechenden Nutzergruppe für IP-Einsicht sein und musst dann dort in den Einstellungen noch das nötige Häkchen setzen und solltest dann bei temporären Konten die Möglichkeit nutzen können, deren IP einzusehen. --Johannnes89 (A/S) (Diskussion) 18:37, 5. Mär. 2025 (CET)

What Johannnes89 says. In addition, according to our data, really few people who are not local admins or AbuseFilter editors or CheckUsers etc., use the right on the pilot wikis. To some degree, this was predictable - we wanted to pick wikis where the rollout would be fairly smooth, quiet and safe, where there are not too many troublesome users. But it also may confirm that the majority of active users do not need this right to continue doing what they typically do. --SGrabarczuk (WMF) (Diskussion) 15:14, 7. Mär. 2025 (CET)

---

Bisher haben wir offenbar folgende Vorschläge, wie das Recht „IP-Betrachter temporärer Konten“ erlangt wird:

• automatische Vergabe des Rechts an alle Benutzer, die seit mindestens sechs Monaten angemeldet sind und mindestens 300 Bearbeitungen haben
• automatische Vergabe des Rechts an alle Benutzer, die seit mindestens sechs Monaten angemeldet sind und mindestens 600 Bearbeitungen haben
• automatische Vergabe des Rechts an alle aktiven Sichter
• automatische Vergabe für aktive Sichter mit allgemeinem Stimmrecht, bei Auslauf des allgemeinen Stimmrechts oder Entzug des Sichterstatus auch automatischer Entzug.
• Erteilung durch Administratoren auf Anfrage; Begründung der Notwendigkeit nötig, z. B. für die Vandalismus-, Spam- oder Trollbekämpfung
• Erteilung durch Administratoren an aktive Sichter auf Anfrage; Begründung der Notwendigkeit nötig

--Brettchenweber (Diskussion) 18:56, 5. Mär. 2025 (CET)

TL; DR:

• Individuelle Vergabe auf Anfrage.
• Anfangs mal weniger als 100 abzuarbeiten, danach tröpfelnd.
• Vereinfachtes Schnellverfahren in der Startphase (einige Monate); Signatur in Liste ist hinreichend.
• Später formlos, Nick wird häufig schon geläufig sein, Beiträge sollten inhaltliche Arbeit regulär im ANR sein und keine automatisierbare Abarbeitung von Tippfehlerlisten; Begründung ist trivial und letztlich nicht ausschlaggebend, ich brauch das halt weil mir seltsame temp-Konten auffielen.
• Diese Diskussion zeigt, dass wohl ein MB erforderlich sein wird, sobald die Umsetzung hierzuwiki näher rückt. Also so oder so im Lauf des Jahres, falls die WMF nicht für alle Wikis das Maximalniveau „individuelle Vergabe“ definiert.
• Ein „Datenschutz“, der sich per automatisiertem Massenedit auf Vorrat von allen Internetbenutzern des Planeten sofort wieder unterlaufen lässt, lohnt den ganzen Aufriss nicht.

„Bei Sprachversionen in nicht-demokratischen Regionen“

• Menschen, die in DACH-Wikis aktiv sind, können auch für Auftraggeber außerhalb von DACH interessant sein; insbesondere wenn die IP in der Türkei oder nordöstlich davon lokalisierbar ist. Und der Artikel oder Diskussionsbeitrag sich um Uiguren, Kurden, Nawalny oder Gaza dreht.
• Vokaki bekam ja neulich einen unerfüllten Auftrag.
• Einschüchterungsversuche und Rache an NGO; wenn sich jemand als Mitglied einer NGO kritisch zum künftigen Bundeskanzler äußert, bekommt diese NGO zukünftig kein Geld vom Staat mehr. FES HBS RLS stehen drauf, KAS HSS TDS werden nicht angefragt. Exakt so wurde die ungarische Richtlinienkompetenz auch begonnen.
• DACH ist keine Insel der Seligen, die für immer vor „nicht-demokratisch“ gefeit ist.

„kann sich genauso durch ein manuelles Vergabeverfahren mogeln wie sich zum Admin wählen lassen“

• Dass jemand durch Jahre ausschließlich zur Überwindung hoher Schwellen inhaltliche Arbeit machen wird ist sehr unwahrscheinlich.
• Jemand, der ohnehin schon da ist, ein Jahrzehnt lang brav im ANR in Sachen lampukistanicher Liebeslyrik editiert hatte, kann privat-persönlich irgendwie drauf sein oder sich in Richtungen ändern. Das ist der wahrscheinlichere Fall, und kaum zu unterbinden. Es gab ja auch mal ein SG-Mitglied, das sich dann als AfD-Funktionär herausstellte.
• Es geht auch nicht nur um direkte Regierungsaufträge und Geheimdienste, sondern auch um alle Privatpersonen mit Mission.
• Nahost oder Remigrationsfragen, wer äußert sich wie? Doxing.
• Schlauer wäre es ja seit immer, sich anzumelden; aber das verlangen wir zwecks niederschwelligem Sofort-Mitmachen ab dem ersten Klick nicht.

„Das ist an der Stelle tatsächlich ein Klick mehr“

• Es ist eine Frage der Zeit, bis jemand ein JS geschrieben hat, das irgendwelche Mausklicks simuliert oder die API abfragt, und dann zu jedem Temp-Account die IP-Werkzeugliste einfügt.

Wenn schon Kopplung an Sichter:

• Dann müsste es wenigstens die Möglichkeit geben, unabhängig von den Sichterrechten bei sozial problematisch auffälligen Accounts das IP-Einsichtsrecht wieder zu entziehen. Ebenso bei mehrjähriger Inaktivität, häufigen temporären Sperren, Stalking-Hounding usw.
• Eine Automatik, die global unwiderruflich an Editcounts gekoppelt ist, so wie anscheinend ursprünglich von der WMF vorgesehen, ist strikt abzulehnen.
• Menschen können sich die Edits nach inhaltlicher Tiefe und tageszeitlicher Verteilung ansehen und WzeM einschätzen.
• Automatiken akzeptieren 300 oder 700 Edits binnen drei Stunden, die irgendeine Tippfehlerliste abarbeiten.

VG --PerfektesChaos 20:44, 5. Mär. 2025 (CET)

Ich befürworte ebenfalls eine individuelle Vergabe auf Anfrage und halte eine Koppelung an die aktiven Sichtungsrechte für falsch. Wir haben mehr als 20.000 aktive Sichter. Ein Großteil dieser Accounts beschäftigt sich überhaupt nicht mit der Vandalismusbekämpfung und benötigt daher auch nicht die Berechtigungen zur Einsicht von IP-Adressen. Die Rechte per "Gießkannenprinzip" automatisch zu vergeben, wird dem Ziel des Datenschutzes aus meiner Sicht nicht gerecht.

Gleichzeitig befürworte ich eine möglichst unkomplizierte Vergabe an alle Benutzer, die das Recht wirklich benötigen. Das sind VM bzw. RC-aktive Nutzer. --TenWhile6 21:05, 5. Mär. 2025 (CET)

Genau so gestern Abend im Metawiki passiert: Konto seit 2020 global angemeldet ohne jegliche Bearbeitungen. Innerhalb von 2,5 Stunden knapp über 300 maschinell erstellte Übersetzungen reingespamt, inklusive falscher Sprache. Letztere Bearbeitung führte in meiner Beo dazu, dass ich mir das Konto angeschaut habe und mir nur deshalb die automatische Vergabe aufgefallen ist. Das Recht habe ich separat entzogen und die WMF auf den Fall hingewiesen. Die weitere Überprüfung des Kontos und dessen Bearbeitungen ist noch anstehend. Grüße, —DerHexer (Disk., Bew.) 18:26, 11. Mär. 2025 (CET)

> automatische Vergabe für aktive Sichter mit allgemeinem Stimmrecht
Für diese Lösung wäre ich. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 21:22, 5. Mär. 2025 (CET)

Eine automatische Vergabe an mehrere tausend Leute halte ich nicht für sinnvoll. Dann könnte man das ganze auch lassen. Lieber Vergabe durch Admins an jeden Sichter, der ein Interesse daran bekundet. Eventuell könnte man am Anfang eine Positivliste von RClern ohne Adminrechte erstellen und diesen ohne Anfrage das Recht geben. Der Aufwand für die Vergabe würde sich in Grenzen halten, denke ich. -- Perrak (Disk) 23:21, 5. Mär. 2025 (CET)

Super, eine "Positivliste", bitte nicht so etwas. Das wäre nichts anderes als eine Art Prangerliste. Vermutlich ist das Recht zukünftig eh nicht nützlich. Darf man überhaupt noch IP-Adressen sammeln? Sie sortieren und in einen Zusammenhang setzen? Darf man diese nennen? --Itti 23:29, 5. Mär. 2025 (CET)

Inwiefern könnte eine Positivliste ein "Pranger" sein? Ganz davon abgesehen müsste die Liste nicht notwenigerweise öffentlich sein.

Ob das Recht nützlich sein würde ist natürlich eine andere Frage. Ist es das nicht, könnten wir uns die Diskussion natürlich sparen. Aber selbst, wenn die nennung von IP-Adressen unerwünscht wäre, könnte man sicher öffentlich schreiben, dass bestimmte temporäre Konten zusammengehören. Das ist bei CU für normale Konten ja ebenfalls erlaubt. -- Perrak (Disk) 01:26, 6. Mär. 2025 (CET)

Wer darauf steht gehört zu den "guten" wer nicht, gehört zu den nicht so guten. Sorry, natürlich ist das ein Pranger, was meinst denn du? Deine restlichen Ausführungen, du hast mich nicht verstanden. Wie soll denn jemand, der als RCler eine Range ermittelt hat, diese einem Admin nennen, wenn man sie nicht mehr schreiben darf. Soll ich dann privat irgendwo eine Liste damit führen? Wie soll ein Austausch stattfinden? GAR NICHT! Das ist, was ich als aktiver Trollschuzt durch die WMF bezeichne. Dann rennt man demnächst per Mail hinter einem Admin her, damit dieser eine Range sperrt? Sorry, dann macht halt eure Arbeit alleine, oder lasst sie von der WMF erledigen. --Itti 06:12, 6. Mär. 2025 (CET)

Verstehe ich nicht. Du kannst doch melden, dass zwei anonyme Konten zur selben IP-Range gehören. Welche das ist, sieht der Admin ja. --Discostu (Disk) 07:38, 6. Mär. 2025 (CET)

Ja, das sieht "der" Admin? Meine Erfahrung ist da eine andere. --Itti 07:41, 6. Mär. 2025 (CET)

Zur anderen Frage: Nein, du darfst ohne Einwilligung keine personenbezogenen Daten sammeln. --Discostu (Disk) 07:43, 6. Mär. 2025 (CET)

Ach, soll ich dann jeden Troll fragen, ob ich seine IP sammeln darf? Wie stellt die WMF sicher, dass solche Informationen sachgerecht genutzt werden? --Itti 07:47, 6. Mär. 2025 (CET)

Wenn man sich selbst in eine Liste einträgt, ist das wohl kaum ein „Pranger“.

Ranges sollte man nach wie vor auf VM melden können, mglw. auf einer eingebundenen Unterseite, die alle X Tage gelöscht wird. Ein Admin schaut sich das an, sieht die zugehörigen Bearbeitungen, sperrt die Range. -- hgzh 07:48, 6. Mär. 2025 (CET)

„Darf man überhaupt noch IP-Adressen sammeln? Sie sortieren und in einen Zusammenhang setzen? Darf man diese nennen?“

1. Für die Situation bis jetzt; vorhandene Auflistungen:
   • Entstammen öffentlich sichtbaren Edits (wenn nicht via CU).
   • Altbestand kann deshalb belassen werden.
2. Nach Einführung temporärer Konten:
   • „Darf man überhaupt noch IP-Adressen sammeln?“ – im Prinzip ja.
   • „Darf man diese nennen?“ – über IP-Berechtigung erlangte Informationen dürfen dann nicht mehr öffentlich sichtbar sein.
     • Ähnlich wie bei CU müssten die auf lokalen Speichermedien verwaltet werden; können nichtöffentlich per Mail mit anderen geteilt werden.

VG --PerfektesChaos 01:24, 6. Mär. 2025 (CET)

Das ist doch alles nicht praktikabel und im Gegensatz zu denen, die ein WMF oder WMDE hinter ihrem Namen tragen sind die, die sich bislang damit beschäftigt haben nicht auf der Lohnliste. Warum soll ich extern irgendwelche Listen führen, mich mühsam mit dritten austauschen? Woher soll ich wissen, das jemand anderes dazu eine Liste extern führt und wie soll ich einem geneigtem Admin dann die IP übermitteln? per Mail und der geneigte Admin ignoriert das dann? Wie es auch so schon passiert? --Itti 06:18, 6. Mär. 2025 (CET)

Unter der Maßgabe, dass wir ohne zusätzliche Antragsseite und zugehörigen Krimskrams auskommen, die dann wieder jemand beackern muss, und dass eine initiale Vergabe en bloc passieren kann, würde ich meinen Widerstand gegen eine Entkopplung vom Sichterrecht aufgeben.

Mglw. ließen sich ja Wikipedia:Gesichtete Versionen/Rechtevergabe, Wikipedia:Benutzeroberflächenadministratoren/Anträge, das was auf der Wikipedia Diskussion:Bürokraten abläuft, und was bislang auf Wikipedia:Administratoren/Anfragen an Rechteanfragen aufläuft zusammenfassen (danke an den Hexer für die Idee oben), das wäre mir dann fürs erste genug Bürokratieabbau. -- hgzh 08:13, 6. Mär. 2025 (CET)

Um mal ein wenig Grundlegender zu werden: Wo wird die IP-Adresse spezifisch benötigt. Abseits von Strafverfolgung, die man über OS klären kann, eben dann, wenn durch die temporären Konten nicht mehr eine zusammenhängende Identifizierung gesichert ist. Heisst, für 90 Tage (sollte der Nutzer seine Cookies nicht löschen) am Stück ist eine in Zusammenhangbringung für jeden Nutzer ohne IP-Ansicht-Recht möglich. Löscht jemand seine Cookies ist dies zumeist wohl der folgende Fall: Computer-Nerd, Angsthase, Institutionsabhängiger (also Schulen, wo die IT das Standardmässig eingestellt hat) und Bösewicht (ja ich weiss, sehr vereinfacht). Das Problem besteht also nur beim letzteren (beim vorletzten gibts nochd as gang-Problem, aber nunja), also jemand der systematisch die Kontrollen versucht zu unterlaufen, bei dem die VM-Jäger ihren Job machen (was durch IPv6 erschwert wurde und nun womöglich verunmöglicht wird wenn man nur temporäre Konten hat (je nach Tools wird es auch nicht mehr wirklich möglich sein systematisch vorzugehen)). Die Frage also wie kann man diejenigen die das ganze quasi semiprofessionell machen (das wäre die Recht auf Zuruf Variante, das scheint ja unbestritten) unterstützen in dem eine automatische Vergabe für einen gewissen Benutzerkreis gewährleistet wird. Wenn man es nicht an tausende vergeben will (guter Grund), dann eventuell an tausend. Damit wären wir wohl wenn man der beitragsliste glaubt bei etwa 10000 Beiträge + Stimmberechtigung. Bei denen könnte man annehmen das sie eine hinreichend grosse Beobachtungsliste, häufig in Spezialbereichen haben (sonst kommt man schwerlich abseits von Kats und Rechtschreibkorrektur auf so viele Beiträge). Alles drunter wäre wohl schwierig zu rechtfertigen, in der Höhe könnte man eben rechtfertigen, dass ansonsten keine effektiver Trollschutz möglich ist (also abseits dem wohl nicht durchsetzbaren Registrierungszwangs). Das System muss einfach und klar sein, denn wiki ist nun einmal under attack. Wenn man GDPR nicht in Einklang mit VM-Bekämpfung bekommt, dann hat man eben ein Problem (eben so wie die Temporären Accounts derzeit ausgelegt sind, man könnte natürlich diese durch eine Range Information ergänzen, dann wäre der Fall Schülergangproblem auch schneller begegnet, denn GDPR verlang wohl nur, dass man die Person nicht im RL identifizieren kann, nicht das man die Leute nicht auf Grund einer Eigenschaft poolen kann). Wie man es auch macht, landet man bei Kompromissen. Bleibt VM-jagen nur den semi-profis überlassen, oder bekommen die sehr aktiven hier zumindest die Möglichkeit mobbing und systematische Angriffe selbst zu identifizieren um diese dann an VM weiterzuliefern?--Maphry (Diskussion) 08:40, 6. Mär. 2025 (CET)

Warum jetzt gerade 10.000 und nicht 5.000? Oder 15.000? Mit meinem alten Account 7.500 und mit meinem neuen 4.100. Insgesamt also 11.600. Wäre es nicht sinnvoller, die Beiträge im ANR zu zählen und ungefähr 5000 ANR-Edits zu verlangen? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 11:00, 6. Mär. 2025 (CET)

Ich wäre dafür, dass "normale" Mitarbeiter keine IP-Adressen sehen können. -- Hans Koberger 10:51, 6. Mär. 2025 (CET)

Nun, wo sich die Schlagzahl in dieser Diskussion etwas beruhigt hat, noch eine Rückfrage an den technisch versierten Kollegenkreis hier in dieser Runde:
Kann man irgendwie herausfinden, wie hoch die Anzahl jener Nutzer ist, welche das aktive Sichterrecht und allgemeines Stimmrecht haben?
Es geht mir um meine oben geäußerte Idee, welche von Brettchenweber so prägnant mit "automatische Vergabe für aktive Sichter mit allgemeinem Stimmrecht, bei Auslauf des allgemeinen Stimmrechts oder Entzug des Sichterstatus auch automatischer Entzug." zusammengefasst wurde. Hier wäre zur Beurteilung eine Sicht auf die reellen Zahlen in meinen Augen hilfreich. Über 20.000 aktiven Sichtern würde ich persönlich das Recht nämlich auch nicht automatisiert geben wollen. Selbst 5.000 wären in meinen Augen noch zu viel. Bei 1.000-2.000 Mitwirkenden, auf welche beide Kriterien gleichzeitig zutreffen, sähe das in meinen Augen dann schon wieder anders aus. Für eine Automatik spricht hier auch, dass niemand um das Recht betteln muss (Sichtweise kommt nicht von mir sondern war nach meinem Verständnis hier zum Thema manuelle Vergabe zu lesen) oder durch Nicht-Listung auf entsprechenden Seiten am "Pranger" stehen würde (auch nicht von mir sondern hier zu lesen).
Alles in allem können wir, und das hatte mMn Johannes auch ganz klar deutlich gemacht, hier auch nur einen Meinungs-Querschnitt (nicht zu verwechseln mit Meinungsbild) erfassen. Grundsätzliche Entscheidungen zu diesem Thema wird die WMF treffen und erst danach können wir uns hier, zur Not auch über ein MB, wirklich noch darüber hinaus gehende Regeln geben. -- Martin _(Mpns/BD) 08:29, 7. Mär. 2025 (CET)

Laut Benutzer:MisterSynergy/Stimmberechtigung gibt es aktuell 4766 User mit Stimmberechtigung. Die meisten davon dürften auch aktive Sichterrechte haben, denn die verliert man (anders als Stimmberechtigung) ja nicht wieder.

Kopplung an Stimmberechtigung hätte aber den Nachteil, dass man alle paar Tage aus der Gruppe der IP-Einseher rausfliegen und wieder reinkommen könnte, wenn man nur knapp über den nötigen 50 ANR Edits in den letzen 12 Monaten ist.

Wirksamer Datenschutz wäre eine Beschränkung auf die paar hundert Sichter, die als Nicht-Admins mindestens sporadisch (oder erst recht, wenn sie als RCler häufig) mit Vandalismus zu tun haben - nicht mehrere tausend User, die diese Möglichkeit nie brauchen. --Johannnes89 (Diskussion) 16:39, 7. Mär. 2025 (CET)

Ich schrieb ja schon, dass auch mir die von mir hypothetisch angenommene Anzahl "5.000" auch zu hoch vorkommt. Und das Ergebnis liegt ja nicht viel daneben. So pragmatisch ich meine Idee im Ansatz fand - das ist dann wirklich (vor allem auch im Sinne der Datensparsamkeit) zu viel, das sehe ich auch so. Eine Lösung, welche nicht jedem das Recht zuweist, der es eigentlich nicht benötigt aber auch eine gewisse Automatisierung mitbringt wäre in meinen Augen erstrebenswert. Vor allem sollte man aber auch versuchen, den "Nasenfaktor" herauszuhalten, also im Sinne eines Neutralitätsgebotes das Recht mit harten Fakten verknüpfen und nicht "auf Zuruf" vergeben. Eine reine Verknüpfung mit einem (A) halte ich aber dann wieder für zu Eng gestrickt, da viele engagierte Trolljäger ja ohne (A) unterwegs sind. -- Martin _(Mpns/BD) 17:16, 7. Mär. 2025 (CET)

Gibt es denn einen Kennwert, denn Trolljäger haben, den andere normale Nutzer - wie ich - nicht erfüllen? --Ichigonokonoha (Diskussion) 17:20, 7. Mär. 2025 (CET)

Der allgemeine Tenor hier ist, dass vertrauenswürdige, langjährige Benutzer*innen das Recht unbürokratisch erhalten sollten. Also wirst du es auch bekommen, denn niemand kann nachweisen, dass du nicht wenigstens ab und zu mal in der Vandalismus-/Troll-Bekämpfung tätig bist. Ein solcher Nachweis würde eine umfassende qualitative Analyse deiner Edits erfordern und die wäre auch nicht so datenschutzkonform und würde auch gegen den Verhaltenskodex verstoßen. -- Chaddy · D 17:29, 7. Mär. 2025 (CET)

Ich brauche das Recht aber nicht - zwar melde ich ab und zu Vandalismus und kümmere mich um Artikelbestand - aber dazu brauche ich nicht irgendwelche IPs sehen und daher nicht dieses Recht. Daher wäre wirklich meine Frage, ob es irgendeine harte Kennzahl gibt, die man hat, wenn man Trolle bekämpft, die ich bspw. nicht habe, damit man dort vielleicht auch eine automatische Vergabe hinkriegt, ohne das Recht mit der Gießkanne zu vergeben? --Ichigonokonoha (Diskussion) 17:40, 7. Mär. 2025 (CET)

Wie bereits erwähnt würde ein irgendwie gearteter, sinnvoller Automatismus auch gleichzeitig den "Nasenfaktor" verhindern. Wenn dann Klaus das Recht bekommt, kann es dann nicht sein, dass er dies auf Grund eines gute Verhältnisses zu Peter (A/B) erhält. Und wenn Uwe das Recht nicht erhält, kann dies dann ebenso wenig daran liegen, dass Walter (A) ihn nicht mag. -- Martin _(Mpns/BD) 17:53, 7. Mär. 2025 (CET)

Die Sorge verstehe ich ehrlich gesagt nicht ganz. Andere Arten der Rechtevergabe wie WP:GVR funktionieren ebenfalls problemlos, obwohl die Richtlinien nicht in Stein gemeißelt sind, sondern Admins da nen gewissen Ermessensspielraum haben.

Wenn ein User die WMF-Mindeskriterien erfüllt und das Recht zur IP-Einsicht beantragt, haben Admins das im Normalfall zu gewähren, sofern nicht besondere Gründe vorliegen, warum das keine gute Idee ist (z.B. weil ein 6 Monate altes Konto mit Blick auf dessen Edits ersichtlich nur erstellt wurde, um IP-Einsicht zu erhalten). Jeder Regular, der hier diskutiert, bekommt das Recht also ohne Diskussion, ganz egal, ob Admin Walter den User mag. --Johannnes89 (Diskussion) 21:28, 7. Mär. 2025 (CET)

Was den imaginären Admin Walter betrifft, sind wir beide wohl einer Meinung. Auch wenn vielleicht in seltenen Fällen Ausnahmen die Regel bestätigen könnten, blieben dies dann immer noch Ausnahmen. Diese sollten daher aber auch keinen grundsätzlich entscheidenden Einfluss haben. Aber wenn ich dann hier in dieser Diskussion Mitwirkende sehe, für die es scheinbar sogar einen Pranger darstellen kann nicht auf einer Positiv-Liste zu erscheinen, könnte ein wie auch immer gearteter Automatismus die gewählte Adminschaft vor derartigen Nachreden, gleichgültig in welcher Richtung, schützen. -- Martin _(Mpns/BD) 22:27, 7. Mär. 2025 (CET)

Also, meine Vorstellungen von der Vergabe wären wie folgt:

• Begründungslose Eintragung in einer Wunschliste.
• Admins und Bürokraten sehen das und haben folgende Möglichkeiten:
  1. Jemand kennt den Nick langjährig, schätzt als vertrauenswürdig ein, irgendwelche Mininmalstandards (Monate, Editcount) sind automatisch erfüllt: Berechtigung erteilen, Haken dran.
  2. Das Konto ist aus irgendwelchen Gründen problematisch, was sich meist auch im Sperrlog mit mehrfachen heftigen Einträgen niederschlägt. Etwa Anti-Wiki-Aktivitäten außerhalb der WMF; politisch extrem Richtung Nordzypern, Kosovaren, Kurden oder Putin oder dergleichen Kontext, der Bedrängung von IP befürchten ließe. Dann gesonderten Abschnitt eröffnen, Routineverfahren abbrechen, Meinung von 2. und 3. Entscheidungsträgern beiziehen, ggf. mit Begründung ablehnen. Oder wenn das Konto eigentlich nur in Diskussionen rumsenft und weder ANR- noch RC-Arbeit gemacht hat, sondern sich nur irgendwie einen Editcount raufgeschafft hat: dann sofort verweigern.
  3. Bisher hat sich noch niemand geäußert; dann irgendwie unbekannt: Sperrlog, Editcount, Diskussionsseite, Tätigkeitsprofil. Entscheidung.

Wer die Berechtigung benötigt, weil RC, Vandalenjagd, undeklarietes PE, SEO oder was, soll sie mit geringstmöglichem Aufwand bekommen.

Umgekehrt sind IP-Adressen schon seit vielen Jahren ein geschütztes Rechtsgut und es wird dieses Jahr eine extrem fragwürdige und eigentlich unzulässige Praxis beendet. Dazu gehört, dass der Personenkreis auf diejenigen beschränkt werden muss, die im Einzelfall ein höherwertiges Interesse haben, die geschützten personenbezogenen Daten einzusehen. Das darf nicht ohne Notwendigkeit über Tausenden ausgekippt werden, weil es damit wertlos wird. Was ich so an Nicht-Admins bei RC und PE mitbekomme, liegt in der Größenordnung von 50–100 zu erwartenden Konten, die IP-Adressen benötigen. Eine Obergrenze gibt es nicht; wer meint das zu brauchen, und sofern nichts dagegenspricht, erhält die Berechtigung.

VG --PerfektesChaos 01:01, 8. Mär. 2025 (CET)

Meinungsbild

Der erste Werktag nach der Anfrage hat bereits gezeigt, dass so oder so ein Meinungsbild erforderlich werden wird:

1. Die WMF setzt ihre momentane Zielrichtung auf individuelle Vergabe doch nicht für alle Wiks verpflichtend um.
   • In diesem Fall müssten wir klären, ob wir individuelle Admin-Vergabe oder Übernehme von WMF-Editcounts wünschen.
2. Es gibt nur noch individuelle Vergabe durch Befugte.
   • In diesem Fall, und genauso als „Vorschlag 2“ in einem MB gemäß 1. brauchen wir eine Vorgabe für die Admins.
   • Meine Vorstellung wäre:
     • In der Einführungsphase, bis zum Ende des zweiten Kalendermonats nach Start / bis zum 31. Dezember 2025, genügt eine einfache Signatur auf einer Antragsseite, so wie Voting in einem MB.
     • Begründung ist bei Antragstellung nie erforderlich, weil eh immer das gleiche Gestotter.
     • Entscheidung über Vergabe erfolgt gemäß reiner Willkür der Admins; geleitet durch:
       1. Nick ist geläufig,
       2. Inhaltliche ANR-Arbeit, Anciennität, Sperrlog, massenhafte Edits typisch für RC (etwa kommentierte oder unkommentierte Reverts).
       3. Zusätzlich Zahlenwerte für Mindestjahre und Editcount. 1 Jahr, 1000 Edits oder was.
     • Wenn die Beitragsliste Zweifel eröffnet, also eigentlich nur Diskussionsseiten-Gesenfe, dann Rückfrage betreffend Begründung und Absichten und Notwendigkeit.
     • Nach Ende des verkürzten Startverfahrens je ein ===-Abschnitt pro Antrag, Archivierung.
     • Aberkennungs-Rubrik auf Antragsseite
       • Projektstörung, mehrfache Sperren, schlechte Sozialprognose, verdächtiges Editierverhalten oder was auch immer.
       • Mehrjährige Inaktivität wird bekannt, dann aus Sicherheitsgründen erstmal Entzug; Wiedererlangung formlos.
       • Infiniten (und Verstorbenen) sollte das Recht bei Gelegenheit entzogen werden, um die Liste der Berechtigten langjährig überschaubar und aussagekräftig zu halten.
       • Falls keine individuelle Vergabe, dann keine Antragsseite, dann über A/A abzuwickeln.

Damit wären die nächsten Schritte:

• Projektseite für diese „IP-Berechtigten“, Erklärung der technischen Funktionalität und Auswirkung der Berechtigung. Datenschutzerklärung für Berechtigte. Vorstellung eines Regelwerks wie vorstehend skizziert. Antragsseite als Unterseite davon (individuelle Vergabe vorausgesetzt).
• Ausarbeitung eines MB-Entwurfs. Fertigstellung erst nach definitiver Entscheidung der WMF über künftige Methodik (individuell „Der neue Ansatz“ oder automatisch).
• Berechtigte sollten zu gegebener Zeit per Massenmail einen Text auf die BD gespült bekommen, mit Vergatterung; später nach individueller Zuweisung dann per Substitution einer Vorlage, ggf. auch mittels Bot?

VG --PerfektesChaos 01:16, 6. Mär. 2025 (CET)

Geht es auch noch komplizierter? Niemand benötigt für diesen Murks ein Meinungsbild und es benötigt auch nicht tausend neue Seiten, Abläufe und Botläufe. Niemand benötigt dieses Recht, mit dem man gar nichts anfangen kann. Die WMF möchte Trollschutz, die WMF sehtz Troll-Schutz um. --Itti 06:15, 6. Mär. 2025 (CET)

Gehe von guten Absichten aus, auch bei der WMF Diese destruktive Argumentation hilft niemandem weiter. --Discostu (Disk) 07:40, 6. Mär. 2025 (CET)

Dann möge die WMF doch mal praktikabel aufzeigen, wie wir dieses Problem lösen können. Bislang scheinen sie es nicht mal zu verstehen. --Itti 07:48, 6. Mär. 2025 (CET)

Welches Problem? -- hgzh 08:20, 6. Mär. 2025 (CET)

Die Kommunikation untereinander wird abgewürgt. Ich kann nicht mal schnell in die Listen von Gustav, Seewolf, RoBri schauen, um jemanden zu identifizieren. Das ist das Problem, gut, wenn man eh der Meinung ist, es gibt ja gar kein Getrolle, dann gibt es auch kein Problem. --Itti 08:24, 6. Mär. 2025 (CET)

Wieso solltest du dort nicht mehr nachschauen können? Die Listen müssen ja nicht entfernt werden. -- hgzh 08:32, 6. Mär. 2025 (CET)

Die veralten jedoch leider und du darfst ja nichts neues mehr machen. Somit darf dann jeder nur noch wo auch immer das sammeln und sorry, aber selbst meine Freizeit habe ich nicht gestohlen. --Itti 08:35, 6. Mär. 2025 (CET)

Dass die Seiten nicht aktuell gehalten werden dürfen, steht auf wmf:Policy:Wikimedia Access to Temporary Account IP Addresses Policy#Disclosure aber nicht, ebensowenig in den FAQ. -- hgzh 08:48, 6. Mär. 2025 (CET)

Hm, da steht, du darfst eine IP dann nur noch per Mail an jemanden schicken, der die gleichen Rechte hat und du bist verpflichtet vorab zu prüfen, ob dem so ist, ... Na Danke. Das ist doch genau, was ich kritisiere. Gut, wenn man sich damit nicht beschäftigt, hat man damit natürlich auch kein Problem. Ich dann zukünftig auch nicht mehr, sie trollen dann hal ungebremmst weiter. --Itti 08:54, 6. Mär. 2025 (CET)

Im zweiten Anstrich des von mir verlinkten Absatzes steht: When it is reasonably believed to be necessary, users with access to temporary account IP addresses may also disclose the IP addresses in appropriate venues that enable them to enforce or investigate potential violations of our Terms of Use, the Privacy Policy, or any Wikimedia Foundation or user community-based policies. Appropriate venues for such disclosures include pages dedicated to Long-term abuse. (eigene Hervorherbung durch Unterstreichung) Long-term abuse verlinkt übrigens auf Wikidata, das wiederum auf Wikipedia:WikiProjekt Vandalismusbekämpfung/Troll-Dokumentationsseiten verlinkt und genau die Seiten enthält, von denen du behauptest, sie könnten nicht weiter betrieben werden.

Die FAQ schreibt: Some communities currently have public pages for documenting the activities of some bad actors, including their IP addresses (e.g., Long-term abuse). Will this documentation still be permitted?. Die (kurze) Antwort ist: Yes.

Wie man daraus dann deine Schlüsse ziehen kann, leuchtet mir nicht ein. -- hgzh 09:35, 6. Mär. 2025 (CET)

Da erinnere ich mal an die Entknopfung einer CUlerin, die sich an die üblichen Gepflogenheiten gehalten hatte, IP-Adressen nicht aktiv zu nennen, jedoch offenbarte Zusammenhänge zu bestätigen. Wer legt denn aus, was nötig ist? Wann es hilfreich war, dass öffentlich zu machen und was nicht? --Itti 09:40, 6. Mär. 2025 (CET)

An die Details des CU-Falls erinnere ich mich nicht mehr besonders gut, von daher kann ich dazu nichts sagen.

Letztendlich wird sich der Umgang mit den neuen Umständen sicherlich etwas einschwingen müssen, das ist aus meiner Sicht aber kein Grund, in Fundamentalopposition zu gehen. Die Behauptung, dass Ranges/IP-Adressen unter keinen Umständen und nirgendwo mehr öffentlich genannt werden dürfen, ist im Lichte der obigen Auszüge aus der Richtline jedenfalls nicht haltbar. Der Anwendungsfall Dokumentation langandauernder Störungen ist sogar recht klar genannt. -- hgzh 09:55, 6. Mär. 2025 (CET)

Wenn man schlechte Erfahrungen gemacht hat, ist man halt nicht uneingeschränkt optimistisch. Ich habe meine Zweifel, was die zukünftige Dokumentationsmöglichkeit angeht und auch, wie man das zukünftig melden kann. Auch möchte ich nicht in die Situation kommen, belangt zu werden, weil ich versucht habe Trollerei zu unterbinden, von Trollen, die keine Probleme haben, z.B. Personen mit Beleidigungen und Nennung des Klarnamens zu überziehen. Die haben nämlich nichts zu befürchten. --Itti 10:13, 6. Mär. 2025 (CET)

Deine Aussage zum CU-Fall von 2021 stimmt nicht. Im CU-Ergebnis wurde nicht nur eine Verbindung zwischen Konten und bereits in der CU-Anfrage genannten IPs bestätigt (was übrigens auch schon immer verboten war, wie die Ombudskommission bereits 2019 den Checkusern per Mail und öffentlicher Ankündigung einschärfte), sondern auch drei IP-Adressen veröffentlicht, die noch gar nicht in der CUA genannt waren. Die dewiki Community hatte jahrelang ein falsches Verständnis der CU-Policy, obwohl mindestens den Checkusern die Klarstellung der Ombudskommission hätte bekannt sein müssen.

Wer legt bei temporären Konten aus, was ok ist und was nicht? WMF & Ombudskommission. Und wie im CU-Fall werden die zunächst eine Klarstellung veröffentlichen, an die man sich dann zu halten hat. Im CU-Fall wurde aber die Klarstellung einfach ignoriert, weshalb es dann zwei Jahre später Konsequenzen gab.

Übrigens sollte es bei temporären Konten ganz leicht sein, die Nennung deren IPs zu vermeiden, z.B. in dem man das temporäre Konto auf VM meldet und dazu sowas schreibt wie „bitte auch einen Blick auf die IP werfen und deren Range anschauen, da scheint noch mehr Vandalismus zu sein“. Und dann notiert man einfach das temporäre Konto, nicht deren IP auf den Troll-Dokuseiten. --Johannnes89 (Diskussion) 14:40, 6. Mär. 2025 (CET)

Offensichtlich war die "Klarstellung" aber "so" klar nicht und aus so nicht bekannt, denn das "Problem" hatten die anderen CUler auch "so" nicht auf dem Schirm, wie sie seinerzeit auch schrieben. Aber Danke für deine Antwort, denn du bestätigst ja damit meine Bedenken umfänglich und auch meine Einschätzung, dass zukünftig die Rechte der Trolle durch die WMF maximalem Schutz erfahren werden. Warum sollte man sich die Mühe denn überhaupt machen, auf eine imaginäre Range hinzuweisen? Die WMF sollte sich ehrlich machen. Pflicht zur Anmeldung und fertig. Dann haben wir gleiches Recht für alle und nicht Vorzugsbehandlung für Trolle. --Itti 15:38, 6. Mär. 2025 (CET)

Bitte ließ, was ich oben bereits schrieb. Nochmal in Kürze: Es gibt keine Vorzugsbehandlung für Trolle, im Gegenteil ist es deutlich einfacher, angemeldet zu trollen, weil da nur 5 Personen (Checkuser) die IP sehen können (und gerade in dewiki nur mit sehr restriktiver Richtlinie). Entsprechend sehen wir in allen Pilotwikis bisher keine größeren Probleme mit Trollen und Vandalen, die plötzlich temporäre Konten stärker missbrauchen würden, als man das zuvor per IP-Edits konnte. Temporäre Konten sind eine Umgewöhnung für uns, aber bieten Trollen keinen nennenswerten Vorteil. --Johannnes89 (Diskussion) 17:28, 6. Mär. 2025 (CET)

Das MB können wir uns mE sparen, es hat bei BOA, IP-Sperre-Ausnahme, Limit-Ausnahme etc. auch ohne funktioniert. Viel festzulegen gibt es ohnehin nicht, wenn die WMF auf einer individuellen Vergabe besteht; dann liegt es im Adminermessen unter Berücksichtigung der WMF-Mindestanforderungen. -- hgzh 08:18, 6. Mär. 2025 (CET)

Projektseite

Wir sind hier auf PRD im Geburtskanal, und müssten nun die weiteren Geschehnisse des Jahres 2025 strukturiert vorbereiten.

1. Wie soll das Kind denn genderneutral heißen?
   • Wir kennen ja bereits WP:Benutzeroberflächenadministratoren.
   • Das lässt sich doch sicher toppen: Internetprotokolladresseneinsichtsberechtigung.
   • Oder etwas kürzer?
   • Nachdem Konsens über einen Namen hergestellt wurde, kann eine entsprechende Projektseite eingerichtet werden.
   • WP:IPB wäre als Shortcut noch frei.
2. Welche Inhalte muss die neue Projektseite erhalten?
   • == Technischer und rechtlicher Hintergrund ==
   • == Wie werde ich IPB? ==
     • to be completed
   • == Rechtsfragen ==
     • Da IPB eine Art CU light sind, können die CU hier sicherlich organisatorische Details aus der täglichen Arbeit beisteuern.

     Was darf ich?

     Ein temporäres Konto an Admins melden. Diese sehen dann die genutzten IP.

     Auf nichtöffentlichem Weg (E-Mail) IP oder vergleichbar an andere Berechtigte übermitteln.

     Was darf ich nicht?

     Eine aktuelle vollständige IP öffentlich machen.

     Engräumige geografische Informationen oder Firmenzugehörigkeit öffentlich machen.

     • Nicht: Arbeitet oft aus dem WLAN der Klingelstädter Straßenbahn.
     • Okay: Arbeitet oft aus dem WLAN von Einrichtungen der Schweizerischen Bundesbahnen.
     • Okay bei Themenbezug: Bearbeitet Artikel zur deutschen Politik aus dem Netz des Deutschen Bundestages.
       • (welche Volldeppen arbeiten denn vom Dienst-PC statt vom privaten Smartphone, wo irgendein Mobilfunkanbieter aufträte???)

     Ein Verstoß gegen diese Regeln ist einem Verstoß gegen WP:ANON gleichgestellt.

     Wie kann ich Erkenntnisse veröffentlichen?

     Eine hinreichend große Range, die nicht bis zum letzten Endkunden auflösbar ist, kann offengelegt werden.

     Bei IPv4 wären das die ersten beiden Oktetts, also: 128.555.*.*

     Bei IPv6 entspechend.

     Ein großer Telekommunikationsanbieter ohne regionale Einschränkung kann benannt werden.

     • Okay: Arbeitet aus dem Netz von Telekom Austria.

     Was ist mit IP-Adressen bis 2025?

     • Sie waren öffentlich sichtbar und sind in Signaturen hinterlegt.
     • Sie können deshalb in Altbeständen sichtbar bleiben.
     • IP-Adressen veralten meist innerhalb einiger Jahre. Provider haben Pakete von Ranges, die sie bedarfsweise rund um den Globus zuordnen und austauschen. Manche Netze, etwa Universitäten, haben schon seit Einführung des www dieselben IP-Ranges und interne Aufteilung; Anbieter für Klienten werden teils binnen Monaten andere Kontingente in einem Gebiet nutzen.

   • == Vorgeschichte ==
     • IP-Adressen lassen eine Identifizierung von Bearbeitenden mehr oder weniger genau zu und sind deshalb eine Verletzung der Privatsphäre.
     • Das war eigentlich schon im letzten Jahrhundert bekannt gewesen.
     • Die US-amerikanischen Nerds, die Anfang der 2000er die Wikis programmiert hatten, scherten sich wenig um Datenschutz. In Europa war man hier schon deutlich aufmerksamer gewesen und hätte sich nicht darauf eingelassen, im Klartext IP-Adressen in Versionsgeschichten und Signaturen zu schreiben, sondern hätte die IP-Adresse durch eine Verschlüsselung gejagt und den resultierenden Hashcode gleicher Länge als Pseudo-Nick verwendet. Gleiche IP-Adressen hätten gleichen Hashcode, wären aber nicht zurückzurechnen. Die jetzt eingeführte Methodik läuft auf das Gleiche hinaus, zieht aber auch die Cookies zur Identifizierung beim Wechsel der IP heran und ermöglicht dadurch sogar konstanteres Tracking, falls nicht die Cookies usw. mit Ende jeder Browser-Sitzung gelöscht werden (allgemein übliche Praxis) oder diese absichtlich zum Identitätswechsel entfernt wurden.
     • Dieser Geburtsfehler stand bereits seit 2010 unter Technische Schulden auf der Agenda, und seit 2020 gab es Konzepte zur Heilung.
     • Gefährdung für Wiki-Nutzer durch autokratische Regierungen rund um den Planeten, und über Social Media steuerbare Privatpersonen in großer Anzahl, die Wiki-Beteiligte aufspüren und bedrängen können, waren letztlich Anlass zur Umsetzung.
     • Konzeptionell war schon immer an die vorherige Registrierung als bester Schutz der Privatsphäre gedacht gewesen. Damit war die IP-Adresse (und die Browser-Konfiguration) nur den CU zugänglich. Weil aber gleichzeitig die Mitarbeit niedrigschwellig, also durch sofortiges Editieren ohne Anmeldung und Merken eines Passworts möglich sein soll, verfiel man unglücklicherweise auf die Idee, als Ersatz-Nick die IP-Adresse im Klartext zu verwenden.

Mal so am Rande bemerkt: Die Zahl der IPB sollte in der Größenordnung 50–100 beschränkt bleiben; also diejenigen, die sich aktiv darum beworben haben und wissen was sie tun, was sie dürfen und was nicht.

• Weil, Unwissenheit schützt vor Strafe nicht, und wer zufällig auf irgendwelche Links klickt und irgendwas ausplaudert, hängt böse mit drin.
• Die Berechtigung mit dem großen Bottich ohne irgendeine Einweisung und Erklärung über Tausenden von Konten auszukippen wäre deshalb nicht so wirklich schlau. Das ist vermutlich mittlerweile auch der WMF gedämmert, weshalb sich bei etwas Nachdenken der Kurswechsel von Editcount zur individuellen Vergabe herauszustellen scheint.

VG --PerfektesChaos 12:53, 6. Mär. 2025 (CET)

50–100? Ne, ein so eng begrenzter Kreis wird sicher nicht konsensfähig sein. -- Chaddy · D 01:09, 7. Mär. 2025 (CET)

Gute zwei Jahrzehnte konnte jeder jede IP-Adresse sehen. Ob das nun problematisch war lassen wir an dieser Stelle mal weg, es hat auf jeden Fall kaum jemand gestört. Nun den kompletten U-Turn zu machen und quasi niemanden mehr die IPs sehen zu lassen ist daher in meinen Augen Quatsch. Das Recht sollte meiner Meinung jeder Benutzer automatisch bekommen, der eine Weile dabei ist. Denn nicht nur wir brauchen die Information welche IP wo werkelt, auch die Nicht-Wikipedia-Welt benötigt diese Informationen. So erinnere ich mich z.B. an Reportagen, welche wo IP-Adressen mit problematischen (Eigen-)-Edits in Verbindung gebracht wurden. Und ehrlich gesagt möchte ich auch nicht bei einem Admin darum betteln müsssen, ein Recht wiederzubekommen, dass ich Jahrzehnte hatte. --DaB. (Diskussion) 00:19, 7. Mär. 2025 (CET)

"Und ehrlich gesagt möchte ich auch nicht bei einem Admin darum betteln müsssen, ein Recht wiederzubekommen, dass ich Jahrzehnte hatte." - Seh ich genauso. -- Chaddy · D 01:11, 7. Mär. 2025 (CET)

Das wird nicht zu machen sein, damit würde der Zweck der temporären Konten ab absurdum geführt. Es geht ja gerade darum, dass die meisten Leute die IP-Adressen nicht mehr sehen sollen. Das Prinzip der Datensparsamkeit verlangt, dass die Information nur für diejenigen sichtbar sein sollte, die sie benötigen.

Ein Recht behalten zu wollen, dass man Jahrzehnte hatte, nur um des Behaltens willen, obwohl man es nicht benötigt, ist zwar nachvollziehbar, aber kein schützenswerter Wunsch. Außerdem, was soll "bei einem Admin darum betteln müsssen" heißen? Wir waren uns doch einig, dass jeder, der das benötigt, das Recht unbürokratisch erhalten soll. Was ist daran "betteln"? -- Perrak (Disk) 02:04, 7. Mär. 2025 (CET)

Genau so empfinde ich es auch. Du willst eine "positiv"-Liste, auf der die "guten" eingetragen werden, usw. auch wenn du dir das nicht vorstellen kannst, für die, die sich da eintragen "müssen", ist es Bettelei. Wenn es einen Automatismus gibt, der gerne auch höher sein kann, ok, aber rumbetteln, nein. --Itti 06:04, 7. Mär. 2025 (CET)

Ich will gar nichts, das sollte ein Vorschlag zur Vereinfachung sein. Wenn das so negativ aufgenommen wird braucht es das auch nicht.

Ich selbst bräuchte das Recht nur sehr selten, bekomme es aber wohl automatisch. Insofern bin ich natürlich nicht betroffen. -- Perrak (Disk) 20:55, 7. Mär. 2025 (CET)

Es geht nicht um Recht erhalten eine IP zu sehen, sondern um Recht auf Schutz der eigenen Person. Wenn die temporären Konten nicht die Informationen liefern um sich selbst zu schützen (weil eben Information über Zusammenhängen zwischen Konten fehlen (und nein, GDPR fordert nicht das dieses neutralisiert wird)), dann muss man eben grundlegend Fragen ob die Mitarbeit von "IPs" noch rechtfertigbar ist (vielleicht mal ein MB wert). Alternativ kann man natürlich auch konsequent jede Beleidigung nicht bei der VM abliefern, sondern direkt zur Anzeige bringen, dann bekommt man die IPs wohl auch so.--Maphry (Diskussion) 08:33, 7. Mär. 2025 (CET)

Bei normalen Konten kannst du die IP (und Zusammenhänge zu anderen Konten) auch nicht sehen und trotzdem können wir auf Beleidigungen etc. reagieren. Im Übrigen werden ja eben sehr wohl viele hundert Nicht-Admins die IPs von temporären Konten einsehen können und insofern deutlich leichter Zusammenhänge herstellen können, als das bei normalen Konten geht. Dafür braucht es auch nicht 22.000 Menschen mit Einsichtmöglichkeit, sondern nur die paar hundert, die mindestens sporadisch mal mit VM zu tun haben. Wir werden mit temporären Konten weiterhin alle nötigen Informationen haben. --Johannnes89 (Diskussion) 09:32, 7. Mär. 2025 (CET)

Ich glaube da sind wir nicht so weit auseinander. Ich hab ja oben 10.000 ANR Beiträge genannt als Schwelle plus Stimmberechtigung. Damit kommen wir auf in etwa 1.000 Leute (inklusive der Admins). Die haben mit hoher Wahrscheinlichkeit lange Beo-Liste und können unterstützen. Die Sache mit dem registrierte Nutzer können wir auch nicht nachverfolgen. Korrekt, aber es wird unter Umständen einen Effekt der gefühlten Anonymität geben. Und das lässt allen Erfahrungen nach so manchem Spezialisten dieses ausnutzen und an die Spitze treiben. Denn IP fühlt sich nicht anonym an und registrierter Account auch nicht, temporärer Account den nur wenige Nachvollziehen können ohne Strafanzeige ist da etwas anderes, und genau um diesen Effekt abzuschwächen geht es.--Maphry (Diskussion) 08:42, 8. Mär. 2025 (CET)

"Das haben wir schon immer so gemacht" ist kein valides Argument. Und die rechtliche Situation hat sich durch Gerichtsurteile und DSGVO geändert. --Discostu (Disk) 07:52, 7. Mär. 2025 (CET)

IP-Adresse #Speicherung von IP-Adressen (Stand 2010)

• Und da ist die DSGVO noch gar nicht mit bei: Grundsätze.

Angesichts der Ausspähung von Beiträgen und anschließender Hetzjagd (wer schreibt etwas Kritisches über Friedrich Merz, wer zu Kurden oder Gaza?) gehören auch in DACH IP-Adressen in den Bereich von uns zu schützender personenbezogener Daten.

• Die Zahl der Personen, die Zugang zu personenbezogenen Daten haben, ist auf das absolute Minimum zu beschränken und erfordert ein berechtigtes Interesse im Einzelfall.
• Es war schon 2001 eine riesige Eselei gewesen, jemals IP-Adressen im Klartext sichtbar zu machen, und hätte niemals passieren dürfen.

VG --PerfektesChaos 15:18, 7. Mär. 2025 (CET)

Vector 2022 wird die Standardoberfläche

Ein zweiminütiges Video über Vector 2022

Hallo! Wir sind das Webteam der Wikimedia Foundation. Wir wollen an dieser Stelle ankündigen, dass Vector 2022 am 31. März die Standard-Benutzeroberfläche (Skin) für die Desktopversion der deutschsprachigen Wikipedia wird. Wir antworten gerne auf eure Fragen, Sorgen oder andere Hinweise! Wir helfen euch auch, Dinge anzupassen, mit denen Vector 2022 möglicherweise nicht kompatibel ist. Schaut euch unsere FAQ an – ihr findet dort viele nützliche Antworten.

Wenn du die Vector-Legacy-Skin verwendest, kannst du fortan Vector 2022 erhalten. Um die Umstellung zu vermeiden, wähle Vector Legacy als globale Einstellung aus. Angemeldete Benutzer:innen können jederzeit auf andere verfügbare Skins wechseln oder Vector 2022 beibehalten und zwischen dem hellen und dunklen Modus wechseln. Benutzer:innen anderer Skins werden keine Veränderungen sehen.

Last-minute edit: according to our tool, there are practically no problems with dark mode on German-language Wikipedia. It is then very likely that at the same time, we will make dark mode available for all Vector 2022 users, including the logged-out. Many thanks to everyone involved in adjusting templates and articles to dark mode!

• Artikelanfang
• 
  Vector Legacy (aktueller Standard)
• 
  Vector 2022

• Ein Artikelabschnitt
• 
  Vector Legacy (aktueller Standard)
• 
  Vector 2022

Warum wir die Skin jetzt ändern

Aus technischen Gründen (unten aufgeführt) müssen wir die Skin bald – in etwas weniger als drei Wochen – umstellen. Danach werden wir weiterhin Fragen zur Skin diskutieren und gerne mit euch an verschiedenen Problemen wie der Kompatibilität von Helferlein arbeiten. Wir können die Aktivierung für kurze Zeit hinauszögern, wenn deutliche Fehler vorliegen, die das Lesen oder Bearbeiten unmöglich oder sehr schwierig machen, wie Infoboxen, die den Inhalt einer Seite nach unten verschieben. Wir werden uns darauf konzentrieren, solche Fehler zu beheben, bevor wir die Skin ändern. Diese Änderungen werden auf vielen Wikis gleichzeitig vorgenommen.

Mehr Details

---

• Aufgrund der Bereitstellung neuer Funktionen, die nur in Vector 2022 verfügbar sind, können wir aus technischer Sicht nicht mehr beide Skins als Standard unterstützen. Mehr als eine Skin in verschiedenen Wikis auf unbestimmte Zeit beizubehalten, ist unmöglich. Dabei geht es um die Architektur unserer Oberfläche. Als Wikimedia Foundation oder auch als Wikimedia-Bewegung im Allgemeinen haben wir nicht die Kapazität, Software zu entwickeln und zu pflegen, die standardmäßig mit verschiedenen Skins arbeitet. Je länger wir deshalb mehrere Skins als Standard beibehalten, desto höher ist die Wahrscheinlichkeit von Fehlern, Regressionen und anderen Problemen, für deren Behebung wir nicht über die nötigen Ressourcen verfügen.
• Vector 2022 ist seit über einem Jahr der Standard in fast allen Wikis. In dieser Zeit hat sich gezeigt, dass die Skin beim Lesen Verbesserungen bietet und sich auch weiterentwickelt. Nachdem wir Vector 2022 in den meisten Wikis bereitgestellt hatten, haben wir neue Funktionen hinzugefügt, etwa das Menü „Erscheinungsbild“ mit der Funktionalität „Dunkelmodus“. Wir werden weiter an der Skin arbeiten, und die Umstellung bedeutet nicht, dass bestehende Probleme nicht behoben werden. So haben wir zum Beispiel im Rahmen unserer Arbeit am Projekt „Barrierefreies Lesen“ den Dunkelmodus entwickelt, die Breite der Hauptseite wieder auf volle Breite geändert (T357706) und Probleme mit breiten Tabellen gelöst, die die Menüs in der rechten Spalte überlappt haben (T330527).
• Der Code von Vector Legacy ist nicht vollständig mit bestehender, kommender oder zukünftiger Software kompatibel. Wenn diese Skin als Standard beibehalten würde, würden die meisten Benutzer:innen von diesen Verbesserungen ausgeschlossen werden. Wichtige Beispiele für Funktionen, die nicht durch Vector Legacy unterstützt werden, sind: das erweiterte Inhaltsverzeichnis auf Diskussionsseiten, der Dunkelmodus und auch die Erfahrung für Benutzer:innen mit temporären Konten (#Wer sollte IP-Adressen sehen können, wenn wir temporäre Konten aktivieren?), die wir aus rechtlichen Gründen einführen müssen. Die einzige Skin, die Funktionen für temporäre Konten unterstützt (wie Banner, die darauf hinweisen, dass jemand ein temporäres Konto nutzt), ist Vector 2022.

Über Vector 2022

Globale Einstellungen

Wir empfehlen dir, die neue Skin auszuprobieren, indem du in deinen Einstellungen unter dem Reiter Aussehen Vector 2022 aus der Liste der Benutzeroberflächen auswählst. Es kann ein paar Tage dauern, sich daran zu gewöhnen – das ist die Standarderfahrung bei Änderungen der Benutzeroberfläche.

Details zum Skin

---

Vector 2022 ist die modernisierte Version der derzeitigen Standardskin Vector Legacy. Sie ist bereits in fast allen Wikimedia-Wikis (mehr als 1000 von 1030+ Wikis) Standard. Das entspricht ca. 13 Milliarden menschlicher Seitenaufrufe pro Monat (insgesamt haben alle Wikis ca. 15 Milliarden Aufrufe pro Monat). Die meisten aktiven Beitragenden nutzen sie und wechseln trotz einfachen Zugangs zum Opt-Out-Link nicht in statistisch bemerkbarem Umfang zurück. (Quelle)

[Unsere Antwort von 2022, warum eine Änderung notwendig ist] Als die aktuelle Standard-Skin entwickelt wurde, spiegelte sie die Bedürfnisse der Lesenden und Beitragenden im Jahr 2010 wider. Seitdem haben neue Benutzer:innen das Internet und die Wikimedia-Projekte auf unterschiedliche Weise verwendet. Obwohl sich die Funktionen der Skin geändert haben, blieben die Struktur, die Navigation, das visuelle Layout und die allgemeine Lesbarkeit der Skin weitgehend gleich. Die alte Vector-Oberfläche erfüllt nicht mehr die Bedürfnisse der aktuellen Nutzenden.

[Ziel] Das Ziel für die Vector-2022-Skin ist es, die Oberfläche für Lesende einladender und angenehmer und für erfahrene Benutzer:innen nützlicher zu machen. Sie enthält eine Reihe von Änderungen, die darauf abzielen, Probleme, die neue und bestehende Lesende und Beitragende mit der alten Skin hatten, zu beheben. Sie ist inspiriert von früheren Anfragen von Benutzer:innen, den Umfragen zur Community-Wunschliste und Helferlein und Skripten. Die Arbeit half dabei, unseren Code zu standardisieren und alle anderen Skins zu verbessern. Wir haben den PHP-Code in den anderen verfügbaren Skins um 75 % reduziert. Das Projekt war auch darauf ausgerichtet, die Unterstützung von Helferlein und die Nutzung von APIs zu erleichtern.

[Überblick über die Änderungen] Vector 2022 führt Änderungen an der Navigation und am Layout der Website ein. Die Skin fügt dauerhaft sichtbare Elemente wie einen fixierten Header und ein Inhaltsverzeichnis hinzu, um häufig genutzte Links leichter zugänglich zu machen. Sie ändert auch die Gesamtgestaltung der Seite. Die Analyse der gesammelten Daten ergab, dass diese Änderungen die Lesbarkeit und Benutzungsfreundlichkeit verbessern und die Zeit, die derzeit für das Scrollen, die Suche und das Navigieren benötigt wird, reduzieren – daraus kann gefolgert werden, dass die Leseerfahrung erleichtert wird. Die neue Skin entfernt keine Funktionen, die derzeit in Vector Legacy verfügbar sind. Für Wikis mit Vector 2022 als Standard haben sich keine negativen Auswirkungen auf Seitenaufrufe, Neuanmeldungen oder Bearbeitungszahlen ergeben. Auf unseren Projektseiten findest du die Ergebnisse und Erkenntnisse kurz zusammengefasst.

Zusammenfassung der Ergebnisse und Erkenntnisse

• Im Durchschnitt verwenden 87 % der angemeldeten Benutzer:innen unserer Pilot-Wikis (einschließlich der französischen Wikipedia) die neue Skin nach dem ersten Versuch weiter.
• Der fixierte Header erleichtert es, Werkzeuge zu finden, die Beitragende oft verwenden. Er verringert das Scrollen zum Seitenanfang um 16 %.
• Das neue Inhaltsverzeichnis erleichtert die Navigation zwischen verschiedenen Abschnitten. Lesende und Beitragende sind um 50 % mehr zu verschiedenen Abschnitten der Seite gesprungen als noch über das alte Inhaltsverzeichnis.
• Die neue Suchleiste ist leichter zu finden und erleichtert ihrerseits das Finden der richtigen Suchergebnisse in der Liste. Dies erhöhte die Anzahl der getätigten Suchanfragen in den von uns getesteten Wikis um 30 %.
• Die Skin hat keinen negativen Einfluss auf die Seitenaufrufe, die Bearbeitungszahlen oder die Neuanmeldungen. Vielmehr gibt es in Partnercommunitys Anzeichen für eine Zunahme der Seitenaufrufe und Neuanmeldungen.

Wie können Beitragende diese Skin ändern und anpassen?

Unsere Anpassungen können konfiguriert und personalisiert werden. Wir freuen uns, mit technisch versierten Freiwilligen zusammenzuarbeiten, die neue Helferlein und User-Skripte entwickeln möchten. Bisher wurden schon viele Helferlein und User-Skripte in der Community entwickelt. Dazu gehören die Graufärbung des Hintergrunds, das Deaktivieren fixierter Elemente, die Wiederherstellung des alten Inhaltsverzeichnisses und vieles mehr. Wir empfehlen, in unserem Repositorium die Liste der aktuell verfügbaren Anpassungen und Änderungen durchzusehen oder eigene dort hinzuzufügen.

Wie wir bei der Änderung vorgehen werden

1. Wiki-Seite: Die Seite Hilfe:Skin/Vector 2022 beschreibt, wie man die Skin ändern oder anpassen kann, erklärt die Geschichte und bietet nützliche Links, wie sie auch in dieser Ankündigung vorkommen.
2. CentralNotice-Banner für angemeldete Benutzer:innen: Vor der Umstellung und noch kurze Zeit danach werden wir ein Banner einblenden, das die Änderung ankündigt. Dieses wird auf die genannte Wiki-Seite verlinken. Dadurch sollen Verwirrung und die Anzahl der Fragen von Neulingen zur Änderung verringert werden.
3. Kontakt mit Wikimedia Deutschland: Wir haben uns bereits an WMDE gewandt und nützliche Links sowie den Zeitplan weitergegeben.

Danke! OVasileva (WMF) und SGrabarczuk (WMF) (Diskussion) 02:39, 12. Mär. 2025 (CET)

Wird die Umstellung auch für angemeldete Benutzer, die bisher den alten Vector nutzen, durchgeführt? Das wird aus dem Text nicht ganz klar. -- hgzh 08:07, 12. Mär. 2025 (CET)

@Hgzh, hi! I will confirm with other team members, but I believe that regardless of what you were using previously, if you are now using Monobook or Timeless - anything that's not the default now - you will not see the change. --SGrabarczuk (WMF) (Diskussion) 09:21, 12. Mär. 2025 (CET)

Thanks, to clarify my question: will users that use Vector legacy skin now get their skin changed to Vector-2022 or is the change only affecting unregistered users? -- hgzh 09:43, 12. Mär. 2025 (CET)

Das kommt darauf an, ob jetzt tatsächlich „Vector-2010“ oder „standard“ ausgewählt ist. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:45, 12. Mär. 2025 (CET)

Diese Unterscheidung gibt es doch gar nicht, oder übersehe ich etwas? -- hgzh 10:11, 12. Mär. 2025 (CET)

Stimmt diese Unterscheidung gibt es nicht 🤷. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:15, 12. Mär. 2025 (CET)

Deshalb die Empfehlung in der Nachricht oben, den alten Vector via Spezial:Globale Einstellungen auszuwählen, wenn man ihn behalten möchte. Das verhindert, dass bei Umstellung des dewiki Standards von Vector auf Vector 2022 beim eigenen Konto die lokale Auswahl wechselt. Wenn man eh Monobook oder Timeless (oder Minerva) nutzt, ist das natürlich egal, weil man dann gar nicht auf dem Standard ist. --Johannnes89 (Diskussion) 11:28, 12. Mär. 2025 (CET)

Also werden tatsächlich alle Vector-2010-Nutzer, die keine wirksame und überschreibende globale Einstellung für den Skin haben, von Vector-2010 auf Vector-2022 umgestellt?

Will every user of legacy Vector that not have a global preference set get their default skin changed to Vector-2022? Can you confirm, @SGrabarczuk (WMF)?

Ich reite deshalb so darauf herum, weil ich eine kurze Kuriernotiz verfassen möchte, und das ist die wahrscheinlich zweitwichtigste Information dafür. -- hgzh 18:40, 12. Mär. 2025 (CET)

Yes, exactly, this is how it works. I'm glad that you are going to write something for der Kurier! If I can be of any help, let me know. --SGrabarczuk (WMF) (Diskussion) 01:54, 13. Mär. 2025 (CET)

→ Wikipedia:Kurier#Vector 2022 wird Standardskin. -- hgzh 08:09, 13. Mär. 2025 (CET)

Oben steht: „Aus technischen Gründen (unten aufgeführt) müssen wir die Skin bald […] umstellen.“ Wo „unten“ sind diese technischen Gründe aufgeführt? Ich habe sie bisher nicht gefunden. Gruß, --Yen Zotto (Diskussion) 09:29, 12. Mär. 2025 (CET)

Unter „Mehr Details“ (muss rechts ausgeklappt werden) steht dazu etwas. Hauptgrund dürfte die Einführung der temporären Konten sein, die Vector-2022 voraussetzen. -- hgzh 09:40, 12. Mär. 2025 (CET)

(Quetsch) Das war's . Danke! --Yen Zotto (Diskussion) 09:47, 12. Mär. 2025 (CET)

> edit: according to our tool, there are practically no problems with dark mode on German-language Wikipedia.
Wir haben noch jede Menge praktische Probleme mit dem Dunkelmodus (ich verweise auf das MediaWiki-Tool Spezial:LintErrors/night-mode-unaware-background-color, das noch randvoll mit Fehlern ist und unsere Projektseite auf der mindestens einmal in der Woche ein Fehler besprochen wird).
> Wir können die Aktivierung für kurze Zeit hinauszögern, wenn deutliche Fehler vorliegen, die das Lesen oder Bearbeiten unmöglich oder sehr schwierig machen
Ein Fehler müsste euch seit langer Zeit bekannt sein, dessen Behebung, weil wir uns um den Darkmode kümmern mussten, sich sehr verzögert: Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten & phab:T91481 #2451920. Da wir aber auch nicht in absehbarer Zeit eine vollständige Lösung gefunden haben, werden wir wohl damit leben müssen, dass diese Probleme noch nicht behoben sind. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:46, 12. Mär. 2025 (CET)

Der Lint-Fehler ist Unsinn und kein Fehler, da muss in der Regel gar nichts korrigiert werden.

Dass die Koordinaten noch nicht soweit sind, ist schade, aber es ist auch ein Mammutprojekt. Das bisherige System funktioniert trotzdem halbwegs, wenn auch nicht überall. -- hgzh 10:15, 12. Mär. 2025 (CET)

Mir ist klar, dass da in den meisten Fällen nichts korrigiert werden muss, dennoch tauchen ja mindestens einmal in der Woche neue Fehler auf WD:DM/P auf und das Chemiker-SVG-Problem ist auch noch nicht fertig besprochen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:18, 12. Mär. 2025 (CET)

Ganz ohne Probleme wird man nie sein, weil ja mit jeder Vorlagenänderung usw. neue entstehen können. Relevant ist, dass das Tool insgesamt wenige Probleme anzeigt, d.h. unsere Lesenden werden einen gut funktionierenden Darkmode nutzen können, nur auf wenigen Seiten werden Darstellungen vielleicht mal nicht so gut sein, dort muss man dann halt ganz im Notfall mal kurz auf den hellen Modus wechseln. --Johannnes89 (Diskussion) 11:34, 12. Mär. 2025 (CET)

wann wird https://phabricator.wikimedia.org/T293395 endlich behoben. Der fehlende Wiki-Ball oben ist das größte Problem, das ich habe. --0815 User 4711 (Diskussion) 10:06, 12. Mär. 2025 (CET)

Ich verstehe das Problem nicht? Oben links ist doch der Ball und rechts daneben der Text „Wikipedia [Umbruch] Die freie Enzyklopädie“.

EDIT: Ah, es geht darum, dass der Globus nicht persistent ist. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:09, 12. Mär. 2025 (CET)

sroll ein Stück nach unten. Der Ball verschwindet. Es ist heute üblich, dass oben in einem Eck ein "Home" oder Hauptmenü Button ist. --0815 User 4711 (Diskussion) 10:10, 12. Mär. 2025 (CET)

@0815 User 4711, thanks for the question. It seems the situation is not really binary - it doesn't need to be just "are we adding the logo or not". In the discussion to the ticket, you can find two comments by our designer, Justin, starting with this one. You are most welcome to join that discussion! --SGrabarczuk (WMF) (Diskussion) 13:21, 12. Mär. 2025 (CET)

@SGrabarczuk (WMF): You should eliminate incompatibilities before you change Vector2022 to standard skin, shouldn't you? --Doc Taxon (Diskussion) 18:28, 12. Mär. 2025 (CET)

And what is the reason, that temporary account functions cannot to be integrated to Vector Legacy, too. The functions will be the same, Doc Taxon (Diskussion) 18:41, 12. Mär. 2025 (CET)

@Doc Taxon, about temporary accounts - I think the answer is in the original message above - Vector legacy does not support the temp account's experience, in other words, what a person using a temp account can see. That skin's architecture is, well, legacy - it was frozen in 2019, it's not developed, and only Vector 2022 supports things like the banner at the top of the screen temporary users see. Similarly, Vector legacy doesn't support dark mode, for example.

About incompatibilities - which ones do you mean? --SGrabarczuk (WMF) (Diskussion) 02:01, 13. Mär. 2025 (CET)

> About incompatibilities - which ones do you mean?
I think he means: „Ein Fehler müsste euch seit langer Zeit bekannt sein, dessen Behebung, weil wir uns um den Darkmode kümmern mussten, sich sehr verzögert: Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten & phab:T91481 #2451920. Da wir aber auch nicht in absehbarer Zeit eine vollständige Lösung gefunden haben, werden wir wohl damit leben müssen, dass diese Probleme noch nicht behoben sind.“ Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:10, 13. Mär. 2025 (CET)

Ich halte das überhaupt nicht für vordringlich. Auch im jetzigen Skin sieht man kein Logo, wenn man etwas herunterscrollt. -- hgzh 18:34, 12. Mär. 2025 (CET)

That the backslash after all the discussions we had about it in the last years will be major is probably no surprise (the last poll was massively against its introduction). So simple question: When V22 was introduced in the other wikis the Team in an Q&A session described, that there should be an evaluation of the effects of the new Vector. They were not happy to make a scientific one, but a general evaluation was promised anyway. So as the most serious fear about V22 is the (from the developers wanted) shift from a balanced viewing/editing experience towards a mainly viewing experience, how have editing numbers behaved after the introduction of the new skin as standard? As we had added little identifiers in the Summary line if the new Vector was used for the edit, is there an evaluation for example in the deWP on how much of the edits are currently done within the older skins, and will it be done in the future? Because if it is especially those who add a lot to the Information here are those using/sticking towards the old skins, then they will still need support for a long long time so that we can keep the high quality up. Anyway, we should quickly inform the users and also add the V10 option into the global settings, because it should not be the case that one has to wait for V22, has then to navigate in an unknown environment to the settings and so on to get back to the old experience. It is basically about damage control here, because this is a topic which could seriously explode and put the role of WMF, their commitments and prior statements on this topic seriously under the microscope again.--Maphry (Diskussion) 08:30, 13. Mär. 2025 (CET)

Tja, dass man sich mehrere Tage daran gewöhnen muss, ist das eine, aber was ich schwierig finde, die bisherigen monobook-Skripte laufen da nicht. Unter Vektor funktionieren sie schon. Klar, man kann sagen, braucht ja niemand, aber doch ich benötige sie, da sie nützlich sind und einige Extras bieten. Vermutlich wird das aber, wie immer, niemand anfassen, so dass eine Umstellung bedeutet, Skripte adé. --Itti 08:46, 13. Mär. 2025 (CET)

Frag mich nicht wie aber ich habe die 0.99u unter Vector 2022 laufen. Einiges läuft nicht, vieles doch (z.B. die Linkziele) . Wenn @PDD: oder jemand anderes das sich nochmal vornehmen würde, wäre ihm sicher Dank vieler sicher. --Wortulo (Disk. * KI-Projekt) 09:05, 13. Mär. 2025 (CET)

Hey @Itti, in general, user scripts may be adjusted to Vector 2022. I'm not sure which ones don't work for you and why - perhaps you could ask some specific questions on Technik/Werkstatt - but if community members aren't sure what to do exactly to update a script, our team can help out. --SGrabarczuk (WMF) (Diskussion) 14:43, 13. Mär. 2025 (CET)

Man kann Vector 2010 schon jetzt als globale Einstellung festlegen.

Im Allgemeinen sehe ich auch eher keine Verschiebung vom Bearbeiten hin zum Lesen. Man kann im neuen Vector mE genausogut bearbeiten und sogar etwas besser administrieren als im alten. Ein bisschen Eingewöhnung braucht man eben. -- hgzh 09:16, 13. Mär. 2025 (CET)

+1, unter Spezial:Globale Einstellungen#mw-prefsection-rendering einfach Vector 2010 auswählen, wenn man sicher gehen möchte, dass man von der Umstellung des Standards auf dewiki nichts mitbekommt.

Ich müsste die Zahlen nochmal raussuchen, aber soweit ich weiß, ist Vector 2022 aktuell in dewiki der zweithäufigste genutzte Skin (nach Vector 2010, weil die meisten einfach immer den aktuellen Standard nutzen), dann kommt Monobook, zuletzt Timeless. Wenn man lieber in den anderen Skins editiert, kann man das weiterhin tun, es geht ja primär darum, dass unsere Lesenden (und künftig Nutzende von temporären Konten) die Desktopverbesserungen nutzen können.

Zur gewünschten Evaluation: Als Vector 2022 vor 2,5 Jahren in der englischsprachigen Wikipedia (und den meisten anderen Sprachversionen) als Standard eingeführt wurde, wurden einige Researchergebnisse veröffentlicht: en:WP:Requests for comment/Deployment of Vector (2022)/More about Vector (2022). Dort heißt es „Wikis with the Vector 2022 skin as default did not experience any decreases in edit rates attributed to the Vector 2022 skin“. Gibt bestimmt auch aktuellere Zahlen, die das weiterhin bestätigen sollten, die französischsprachige Wikipedia nutzt den neuen Skin nun schon seit fünf Jahren als Pilotwiki, ohne dass ich was von Problemen mitbekommen hätte. --Johannnes89 (Diskussion) 09:23, 13. Mär. 2025 (CET)

Die zuletzt erhobenen Daten zur Skinnutzung (ca. ein Jahr alt) finden sich hier: phab:T361638#9723961. Monobook und V22 halten sich da ungefähr die Waage. Erkennbar ist auch, dass Monobook hier überdurchschnittlich häufig genutzt wird. -- hgzh 09:49, 13. Mär. 2025 (CET)

Ich gehöre bspw. zu denen, die bisher ausschließlich mit dem alten Vector gearbeitet haben. Das alte Design macht es meines Erachtens viel einfacher zu editieren als das neue. Klar kann man sich nach einiger Zeit mit allem arrangieren, aber es ist doch schon eine Frage des Komforts beim Editieren - immerhin ist das die eigene Freizeit. Diesen Druck den neuen Vector zu benutzen - nur noch dafür Features und Unterstützung - finde ich sehr schade. Klar kann ich verstehen, dass man technisch zwei verschiedene Systeme nicht immer gleich unterstützen kann. Aber trotzdem ist das meines Erachtens für die Frage der Begeisterung zum Editieren die falsche Entscheidung. --Ichigonokonoha (Diskussion) 09:20, 13. Mär. 2025 (CET)

Es geht nicht darum, dass man damit nichts bearbeiten kann, sondern. Durch die eingebundenen Skripte kann ich z.B. einen SLA mit einem Klick und voreingestelltem Grund anlegen, den ggf. manuel bearbeiten und mit einem zweiten Klick speichern. Ähnlich mit LAs. Hinzu kommen viele Seiten, die ich mit einem Klick ansteuern kann, die mir in einer Liste ausgegeben werden. Mir geht es um diese Funktionen. Ich kann das nicht programieren. --Itti 09:26, 13. Mär. 2025 (CET)

Da ich keinerlei Skripte nutze, kann ich dazu nichts sagen - mir geht es schon um das Editieren. Das halte ich im alten Skin für deutlich angenehmer - wobei es halt schon den Druck zum neuen Vector gibt, um Sachen wie den Dunkelmodus nutzen zu können. --Ichigonokonoha (Diskussion) 09:28, 13. Mär. 2025 (CET)

@Ichigonokonoha inwiefern Druck? Die Umstellung von Monobook auf Vector erfolgte vor 15 Jahren und bis heute kann man weiterhin problemlos im Monobook-Skin editieren. So wird es auch mit Vector 2010 laufen, lediglich neue Features wie der für Vector 2022 entwickelte Darkmode oder eben die reibungslose Nutzung von temporären Konten werden halt nur im für alle WMF-Projekte gültigen Standardskin angeboten werden können.

@Itti wenn ich es richtig sehe, nutzt du PDD's Monobook-Skriptsammlung? In meinen Augen wäre es deutlich leichter, Skripte zu warten, wenn man sie in seinen Einzelteilen lädt. So kann man veraltete Skripte besser gegen Neuentwicklungen austauschen, z.B. sollte Benutzer:TenWhile6/XReport ebenfalls SLA können und müsste im neuen Vector funktionieren? Vielleicht kann Ten ja auch eine Ergänzung für LA schreiben? --Johannnes89 (Diskussion) 09:32, 13. Mär. 2025 (CET)

Der Druck entsteht halt eben durch entsprechende Features. So ist ein Darkmode halt schon viel besser für die Augen, vor allem wenn man ohnehin viel am PC arbeitet. Das ist schon der passive Druck, wenn man halt sich nicht von solchen - sehr hilfreichen Features - abschneiden möchte, diesen Vector zu nehmen. --Ichigonokonoha (Diskussion) 09:40, 13. Mär. 2025 (CET)

Der eingebaute Darkmode wurde Vector nicht "genommen," er wurde erst durch den neu gebauten Vector 2022 möglich und ließe sich so in den alten Skins gar nicht implementieren. Erst die Neuerungen des Vector 2022 haben die Grundlagen geschaffen, endlich einen verlässlichen Darkmode zu entwickeln. Mehr Infos dazu [16][17]. Wikipedia:Dark Mode#CSS nennt ein paar Möglichkeiten, wie du auch im Vector 2010 Darkmode-Alternativen nutzen kannst, die aber weniger gut funktionieren. --Johannnes89 (Diskussion) 09:51, 13. Mär. 2025 (CET)

Bei den Skripten von Ten sind die Funktionen in Menüs verborgen. Zunächst mal muss man den richtigen Reiter finden und dann sich weiter durchklicken. Bei dem bisherigen habe ich es links als eigenschändige Toolbox, wobei mir links, rechts, oben unten egal ist, aber eben nicht in einem Menü versteckt, sehe es direkt und kann es ohne rumgesuche anklicken. Das ist deutlich funktionaler. Viele Grüße --Itti 10:31, 13. Mär. 2025 (CET)

Bei der Toolbox ist die richtige Positionierung das Problem, die Box selbst funktioniert ja nach wie vor, wenn mein kurzer Test ausreichend war. Das ist sicher hinzubekommen. Die Ten-Skripte dürften übrigens in V22 in der Werkzeugleiste liegen, die man rechts ausklappen und in die Seitenleiste verschieben kann. Dann sind sie auch immer direkt verfügbar. -- hgzh 10:58, 13. Mär. 2025 (CET)

@Hgzh: Wenn das mit der Positionierung der Box funktioniert, kann ich gern schauen, dass die von Itti erwähnten Admin-Skripte usw., die ich vor ~15 Jahren geschrieben habe, dann auch weiter funktionieren. An die Box traue ich mich nicht wirklich ran – dafür sind meine Programmierkenntnisse dann doch zu schlecht. – Ich selbst habe vor einiger Zeit auf V22 umgestellt, vermisse die Box jetzt aber auch nicht unbedingt (gut, bin ja hier auch bald fünf Jahre kein Admin mehr). Grüße, —DerHexer (Disk., Bew.) 16:34, 17. Mär. 2025 (CET)

Ich habe im Beta-Wiki schon mal ein bisschen herumprobiert; man kann die Box relativ schön in die rechte Werkzeugleiste verfrachten, aber damit ist's nicht getan; die Skriptsammlung braucht ohnehin eine Neukonzeption. -- hgzh 22:29, 17. Mär. 2025 (CET)

@Itti wir können gerne ein wenig experimentieren und bessere Orte für die Funktionen finden. Ich kann das Erscheinungsbild jeweils an den aktivierten Skin anpassen. LG, --TenWhile6 22:31, 24. Mär. 2025 (CET)

Genau das (LA/SLA) funktioniert nicht - die Seiten kann ich aber ansteuern. Das scheint ein "einfaches" Problem, dass die Scripts nicht schreiben können? genauso, wie die "Erle" bei Diskussionen nur manchmal funktioniert. --Wortulo (Disk. * KI-Projekt) 09:33, 13. Mär. 2025 (CET)

stimmt, das funktioniert auch nur noch rudimentär, wie so eines andere auch. Schön fand ich auch meinen eigenen Begrüßungsbaustein, den ich einfach per Klick einsetzen konnte... --Itti 09:56, 13. Mär. 2025 (CET)

@Itti an der Stelle sei mir ein Hinweis auf User:TenWhile6/messageHelper erlaubt, mit dem du auch deinen eigenen Begrüßungsbaustein einsetzen kannst, dürfte mit allen Skins funktionieren. LG, --TenWhile6 22:34, 24. Mär. 2025 (CET)

> Because if it is especially those who add a lot to the Information here are those using/sticking towards the old skins, then they will still need support for a long long time so that we can keep the high quality up
Wenn ich das richtig verstanden habe, geht es bei den Nichtfunktionen von Vector 2010, Timeless, und Monobook nicht um die temporären Konten Features für Nutzer mit Account, sondern nur um die temporären Konten Features von unangemeldeten Nutzern. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:08, 13. Mär. 2025 (CET)

Für diejenigen die sich für die bisherigen Diskussionen interessieren, die ja quasi seit Mai 2021 bestehen, hier ein kleiner Überblick: Mai 2021: Erste Aufregung; Oktober 2021: erste Ankündigung; Januar 2022: Update (ohne Diskussion); Juni 2022: Update (heftige Diskussion); Juli 2022: Erneutes Gesprächsangebot; Januar 2023: Meckern über Breite; Juni 2023: Umfrage mit deutlicher Ablehnung von V22 (37:12:76).--Maphry (Diskussion) 16:35, 14. Mär. 2025 (CET)

Andere Frage, als jemand, der hier RC macht, wenn ich mir eine Änderung ansehe, habe ich seitlich links nicht mehr die Schaltflächen mit Werkzeugen, sondern eine Inhaltsangabe des Artikels. Wo finde ich da konkret "Letzte Änderungen" um im RC weiterzumachen? (nicht signierter Beitrag von Itti (Diskussion | Beiträge) 10:55, 13. Mär. 2025 (CET))

Das Hauptmenü müsste eingeklappt ganz oben links hinter dem Hamburger-Menü-Icon erreichbar sein. Man kann es auch dauerhaft links in der Seitenleiste fixieren, dann verschwindet es nicht mehr von allein. -- hgzh 11:13, 13. Mär. 2025 (CET)

Je mehr ich ausprobiere, desto schlechter finde ich es. Wie findet denn jemand seine Diskussionsseite? Warum sind da nur so völlig willkürliche Symbole, die zumindest mir nichts sagen. Gut, vermutlich ist es in heutigen Zeiten nicht mehr üblich etwas zu beschriften, sondern irgendwelche Symbole zu nutzen. Insgesamt scheint es ja so zu sein, die neue Oberfläche ist geschaffen, um es Menschen mit Handys, die als Lesende hier unterwegs sind einfach zu machen. Ggf. noch Trollen, die rumspielen möchten. Für den RC nicht praktisch, Inhaltsverzeichnis seitlich ist unpraktisch, zumindest sehr gewöhnungsbedürftig, die Beschriftungen fehlen mir, die Anordnungen sind unpraktisch, die Funktionalität durch Skripte ist nicht mehr gegeben, usw. Wer kümmert sich um solche "Mängel" oder ist das einfach persönliches Pech? --Itti 12:04, 13. Mär. 2025 (CET)

Vieles davon ist reine Gewöhnung. Auf Handys wird diese Oberfläche gar nicht genutzt. Symbole sind schneller zu erfassen als Schrift. Was das mit Trollen zu tun haben soll, erschließt sich mir nicht. Das Inhaltsverzeichnis in der linken Seitenleiste kannst du verbergen, wenn du es nicht brauchst. Beim Navigieren durch lange Seiten kann es ganz praktisch sein. Wenn Skripte nicht mehr funktionieren, bedeutet das, dass ihre Autoren sie offenbar nicht mehr pflegen (oder die Anpassung noch vornehmen müssen). Ich benutze Vector 2022 seit Jahren und für mich gibt es kein zurück. --Discostu (Disk) 12:42, 13. Mär. 2025 (CET)

Ich möchte aber ein Inhaltsverzeichnis haben, für meine Artikelarbeit. Ich möchte jedoch das Inhaltsverzeichnis nicht statt einer Werkzeugleiste haben, die ich für andere Dinge, wie den RC benötige. Je schlechter hier Benutzer den RC bedienen können, desto mehr profitieren Trolle. Hier wird einem mal wieder ein "Fortschritt" verkauft, der eigentlich nur ein Rückschritt ist. Nochmal, wie findet denn jemand die eigene Benutzerdiskussionsseite? Das ist doch wichtig. --Itti 12:47, 13. Mär. 2025 (CET)

Wieso denn "statt einer Werkzeugleiste"? Die Werkzeugleiste ist nun (bis auf das Hauptmenü) rechts und lässt sich wie alles andere dauerhaft ausklappen. Zu seiner Benutzerdisk kommt man übers User-Icon oben rechts, worüber man auch auf Einstellungen und Beitragsliste kommt. Aber wenn man sich nicht dran gewöhnen mag, kann man ja einfach wie bisher ältere Skins nutzen. --Johannnes89 (Diskussion) 13:02, 13. Mär. 2025 (CET)

Weißt du, "wenn man sich nicht daran gewöhnen mag" ist daneben. Ich habe mir die Mühe gemacht, aufzuzeigen, was ich vermisse, was unpraktisch ist und wo ich auch bei anderen, z.B. neuen Benutzern Probleme sehe. Das kann man wegwischen, nach dem Motto, da nörgelt sie schon wieder nur rum. Aber warum spreche ich es denn überhaupt an? Eben weil es seit Jahren ein Problem ist. Es wird immer etwas neues entwickelt, dabei geht jedoch immer auch etwas sehr praktisches verloren. Ansprechen darf man solches offenbar nicht. Ich habe schon Workshops auf einer WikiCon gemacht, um zu sammeln, was alles an Funktionalität weg ist. Es interessiert nur niemanden. Die Entwickler nicht und diejenigen, die sich selbst mal schnell in Skipt basteln können auch nicht. Die Dummen sind die, es das eben nicht können. So, da ich kein Bock habe immer nur angemacht zu werden: Es ist toll, eure neue Benutzeroberfläche ist einfach klasse und sie ist super intuitiv, nach spätestens einer Woche hat man sich auch sicher daran gewöhnt und ich bin jetzt schon restlos begeistert. Ist es so recht? --Itti 13:56, 13. Mär. 2025 (CET)

Ich sehe jetzt nicht den großen praktischen Unterschied, ob die Werzeugleiste links oder rechts ist. Wenn man das Inhaltsverzeichnis und das Hauptmenü verbirgt, verhält sich der neue Vector-2022 genauso wie der alte; nur dass die Werkzeugleiste auf der anderen Seite ist. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:06, 13. Mär. 2025 (CET)

Ich muss da Itti mal sowas von recht geben. Doc Taxon (Diskussion) 15:33, 13. Mär. 2025 (CET)

Jeder hat unterschiedliche Vorlieben und Arbeitsweisen, deshalb kann man ja glücklicherweise die Oberfläche anpassen. Diese Lösungen müssen sich aber erst entwickeln, weil der Bedarf ja noch gar nicht feststeht. Wenn du in der Benutzerleiste oben lieber Text lesen willst, gibt es auch dafür eine Möglichkeit. Ich habe Benutzer:Hgzh/css/vectorUserMenuLabels.css angelegt, kannst du in die vector-2022.css importieren:

@import url(https://de.wikipedia.org/wiki/Benutzer:Hgzh/css/vectorUserMenuLabels.css?action=raw&ctype=text/css);

Übrigens sind doch Arbeitshilfen wiedergekommen, bspw. das Doppelstimmen-Tool. Anderes ist inzwischen fester Teil von MediaWiki, bspw. die globale Beobachtungsliste und bald auch globale Beiträge. Der Fall des PDD-Skripts ist ein besonderer, weil davon a) zig verschiedene Versionen mit abweichenden Konfigurationen herumschwirren und es eine komplexe Kiste ist, die unzählige eigentlich eigenständige Skripte kombiniert und verwustet. -- hgzh 15:37, 13. Mär. 2025 (CET)

Danke für deine Antwort. Dein Skript werde ich ausprobieren und ja, das Doppelstimmentool ist zurück, nach Jahren, in denen ich danach gefragt habe. Ich bin da auch wirklich froh drum. Genau das ist ja auch mein Problem. Das PDD-Skript ist sehr komplex, das ist mir klar, aber es ist wirklich eine super Sache gewesen und eigentlich noch immer. Ich mag die Sammlung der kleinen "Klicks". Link auf unterschiedliche Metaseiten, extrene Datenbankseiten und auch QS, LA und SLA. Klar, man kann das auch alles tippen, aber wozu, wenn es auch mit einem Klick getan ist? Solches wünsche ich mir. Eine Modernisierung dieser äußerst nützlichen Sammlung. Und ja, sorry, ich kann das wirklich nicht. Aber eines, dass es keinen direkten Link auf die eigenen Diskussionsseite gibt, das halte ich wirklich für einen groben Fehler. Viele Grüße --Itti 15:55, 13. Mär. 2025 (CET)

Links auf unterschiedliche Metaseiten kann man mit Benutzer:Schnark/js/dropdown erzeugen. Finde ich auch sehr praktisch. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 16:05, 13. Mär. 2025 (CET)

Um das althergebrachte Inhaltsverzeichnis wiederherzustellen, gibt es en:User:Phlsph7/ClassicalTOC(Vector2022) -- hgzh 15:48, 13. Mär. 2025 (CET)

Allgemein lohnt ein Blick auf mw:Reading/Web/Desktop Improvements/Repository#Modifications of Vector 2022: new gadgets and user scripts, wenn man verschiedene Elemente des alten Vectors im neuen Vector nutzen möchte. --Johannnes89 (Diskussion) 09:49, 14. Mär. 2025 (CET)

und wenn auf der Disk etwas neues steht, dann kommt die Zahl bei dem anderen Symbol --0815 User 4711 (Diskussion) 13:13, 13. Mär. 2025 (CET)

@SGrabarczuk (WMF): You wrote: "legacy - it was frozen in 2019, it's not developed, and only Vector 2022 supports things like the banner at the top of the screen temporary users see" ← But why? The data you need for the banner content is the same. You only need to inmplement a banner into the skin. It's not a big thing and quick done. WMF's coders make very similar things within the code. That the skin is frozen is not a valid argument if you further provide the skin as selectable option. But you (WMF) make the rules and all users have to comply at all(?) It's highly undemocratic. Deal more with users' wishes, it should be a very important thing for WMF to avoid losing users. Thank you, --Doc Taxon (Diskussion) 15:52, 13. Mär. 2025 (CET)

WMF has supported both skins for years. It is wasted development time to continue doing so. WMF has asked for feedback multiple times since the beginning of development. So I don't think it's fair to say they didn't care about user's wishes. --Discostu (Disk) 16:51, 13. Mär. 2025 (CET)

Nicht so erbaut. Die englisch- und französischsprachige Wikipedia arbeiten bereits mit vergleichbaren Skins. Die künstlich so erzeugte Spaltenbegrenzung und die damit verbundene Auslagerung von Arbeitstools in die Seitenleisten machen das Ganze unruhiger und unübersichtlicher (speziell auch wegen der vielen Tabellen-Elemente, die so auf einem noch schmaleren Platz zusammengedrängt werden). Auch die Anwahl anderer Sprachausgaben via Popup-Menü finde ich unkommoder als im gegenwärtigen Skin. Andererseits sind Ankündigungen der Sorte eh keine, über die sich noch diskutieren ließe. Für mich als User sind die relevanten Fragen so, a) wie einfach sich die Oberfläche nach dem Launch auf ein selbstgewähltes Skin wieder umstellen lässt, b) wie gravierend die Summe unerwünschter Nebenwirkungen bzw. Bugs ausfallen wird. --Richard Zietz 08:57, 14. Mär. 2025 (CET)

Nicht nur die englisch- und französischsprachige Wikipedia, 97% aller WMF-Projekte haben bereits den neuen Skin als Standard, in dem Jahre an User Research und Feedbackschleifen mit den testenden Wikis stecken, bis Vector 2022 nun uns als eines der letzten Projekte erreicht.

Wenn du aktuell Monobook oder Timeless nutzt, wird dich die Umstellung nicht betreffen. Wenn du aktuell den Standard Vector 2010 nutzt, kannst du nach Änderung des Standards unter Spezial:Einstellungen#mw-prefsection-rendering wieder auf den alten Vector umstellen. Alternativ kannst du bereits jetzt einfach in Spezial:Globale Einstellungen#mw-prefsection-rendering Vector 2010 (oder Monobook/Timeless) auswählen, dann wirst du von der Änderung des lokalen Standards nichts mitbekommen, wenn du Vector 2022 nicht möchtest.

Als langjähriger globaler Nutzer des neuen Skins sehe ich kaum unerwünschte Nebenwirkungen/Bugs. Wäre auch sehr überraschend, wenn trotz Nutzung durch zehntausende Wikipedianer und Millionen von Lesern in anderen Sprachversionen noch größere unentdeckte Probleme auftreten. --Johannnes89 (Diskussion) 09:39, 14. Mär. 2025 (CET)

Den schmaleren Platz für den Inhalt hat man ja nur wenn man die schmale breite einstellt. Keine Ahnung warum diese schmale breite Standard heißt und auch der Standard erst einmal umgestellt werden muss. Mit eingeklappten Menüs hat man jetzt sogar deutlich mehr Platz für Seiten mit breiten Tabellen. Das einzige was daran stört ist, dass man die Menüs auf jedem Wiki einzeln einklappen muss weil es keine globale Einstellung dafür gibt. --GPSLeo (Diskussion) 10:11, 14. Mär. 2025 (CET)

Ich habe gestern alle alten Scripts (PDD, Fliegelflagel u.a.) radikal abgeschaltet aber unter "Helferlein" die "Toolserver-Intergration" konfiguriert (alles auf true) und bin alle Einstellungen durchgegangen. Und in der Tat: manches Neue hat erst jetzt Sinn und ist eine echte Erweiterung ;-) Lieblingslinks setzen schau ich noch, LA/SLA/VM "automatisiert" setzen ist das Einzige, was wirklich fehlt (aber schon nicht mehr funktionierte). Du hast halt später angefangen und bist das gewohnt - es ist aber normal, dass man "geliebte" Abläufe so verinnerlicht hat, dass jede Änderung erst mal stört. Bei Dir kommt das später :-) --Wortulo (Disk. * KI-Projekt) 10:16, 14. Mär. 2025 (CET)

Auch und: wenn ich meine Beiträge oder Beitragslisten anderer anschaue, hat Fliegelflagel die grün angezeigt, die noch keiner verändert hat - die andereren waren gelb. Bei "Vandalen" kann man z.B. so sehen, ob sich schon jemand drum gekümmert hatte. Gibts das auch anderswo einfach? "Aktuell" steht fett da, vielleicht gewöhne ich mich auch daran. --Wortulo (Disk. * KI-Projekt) 10:21, 14. Mär. 2025 (CET)

Fliegelflagel kann man bis auf sectionLinks, screenshot und syntaxhighlight überall nutzen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:47, 14. Mär. 2025 (CET)

Fliegelflagel hatte ich ja über PDD mit eingebunden, da gab es immer den Hinweis, dass das nicht die aktuelle Version ist. Fliegelflagel alleine einbinden und das mit der aktuellen Version würde ich tatsächlich mal versuchen. Hat jemand Erfahrungen und wo ist die aktuelle Version davon? Danke. --Wortulo (Disk. * KI-Projekt) 11:53, 14. Mär. 2025 (CET)

siehe Benutzer:Schnark/js/fliegelflagel. --Johannnes89 (Diskussion) 11:56, 14. Mär. 2025 (CET)

Danke, das versuche ich mal --Wortulo (Disk. * KI-Projekt) 12:21, 14. Mär. 2025 (CET)

Nicht ganz. Journal, ebenfalls aus Fliegelflagel, klappt mit Vector 2022 (zumindest bei mir) auch nicht mehr. Aber das ist ein zu verschmerzender Verlust. Alles in allem sind aus Fliegelflagel ja sowieso schon viele Scripte, mindestens unter gewissen Skins, nicht nutzbar. Vielleicht sollten wir einmal sammeln und jemanden beauftragen, die Dinge auf den heutigen Stand zu heben (sry). -- Martin _(Mpns/BD) 14:02, 14. Mär. 2025 (CET)

Wenn das Erstellen von überbreiten Tabellen, die Smartphone-Usern und Sehbehinderten das Erfassen der Informationen erschwert, durch den neuen Skin seltener geschieht, ist das doch eine Win-Win-Situation. --Discostu (Disk) 13:49, 14. Mär. 2025 (CET)

Tut es ja nicht mehr, weil die Devs den Fehler behoben haben (es gibt wie beim Timeless-Skin einen vertikalen Verschiebebalken, Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 20:16, 15. Mär. 2025 (CET)

Darf ich als eine, die von dieser Diskussion nahezu nichts versteht und sich altersbedingt immer vor Veränderungen fürchtet, mal eine unqualifizierte Frage stellen: bis zu welcher Altergruppe werden die Ehrenamtlichen mit den Neuerungen eigentlich mitgenommen? Schon im RL stehe ich mehrmals täglich wie blöd da. Fühlt sich für eine, die sich mal Mühe gab, der Gruppe der Dummies zu entkommen, nicht gut an, auch wenn ich weiß, times change... Mit gutem Gruß in die Runde! --Andrea (Diskussion) 10:06, 14. Mär. 2025 (CET)

Neue Skin auf die Hauptseite angewendet: Du kannst durch einfaches Umschalten von Spezial:Einstellungen#mw-prefsection-rendering die neue Skin ausprobieren (Hilfe). Wenn du die alte Skin dauerhaft behalten möchtest, kannst du dies unter Spezial:Globale Einstellungen#mw-prefsection-rendering festlegen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:54, 14. Mär. 2025 (CET)

+ 1 zu Andrea: ich hab gerade zufällig davon erfahren. Arbeite mit Vector2010 (ist für meine Augen leichter) und habe noch schnell über Globale Einstellungen (wie oben empfohlen) angepasst. Man müsste zumindest auch nach dem 31.3 noch die Möglichkeit haben, das zu ändern, falls man es nicht rechtzeitig mitkriegt. --Nadi (Diskussion) 13:22, 14. Mär. 2025 (CET)

Das ist auf jeden Fall weiterhin möglich. -- hgzh 13:39, 14. Mär. 2025 (CET)

Liebe @Andrea, um deine Frage zu beantworten: Das Alter der Benutzenden hat bei der Entwicklung von Vector 2022 keine Rolle gespielt. Es gab A/B-Tests, bei denen ermittelt wurde, wieviele eine Bedienoberfläche mit dem neuen Skin in welcher Weise benutzen. Dabei kann man nach dem Zeitraum unterscheiden, wie lange die Accounts, die in die Auswertung eingehen, schon registriert sind. Man weiß aber nicht, wie hoch das Lebensalter derjenigen ist, die die Accounts nutzen. Man kann sich auch anschauen, ob der Account nur gelegentlich benutzt wird oder ob es ein erfahrener Power-User ist. Ob er Adminrechte oder sonstige erweiterten Rechte hat. Es gab aber noch nie ein Projekt, sozusagen einen Senioren-Skin zu entwickeln, so ähnlich, wie es zum Beispiel Telefone speziell für Senioren am Markt gibt. Ich fände das übrigens einen erwägenswerten inklusiven Ansatz. --Viele Grüße, Aschmidt (Diskussion) 15:12, 14. Mär. 2025 (CET)

Es ist ja sogar so, dass Barrierefreiheit einer der Gründe für die Entwicklung des neuen Skins war. Es gibt es jetzt ja z.B. eine Schriftgrößenauswahl und der neue Skin unterstützt Spezialmodi für verschiedene Farbsehschwächen. Letztere sind zwar noch nicht implementiert worden, aber die technische Grundlage gibt es jetzt. --GPSLeo (Diskussion) 15:41, 14. Mär. 2025 (CET)

Das ist richtig – danke für deinen Hinweis! Aber die Frage, welche Bedürfnisse die Älteren haben, ist viel spezieller. Vielleicht wäre dabei tatsächlich herausgekommen, dass sie gar keine optischen Veränderungen haben möchten, sondern sich wünschen würden, dass solche technischen Features zur Barrierefreiheit ohne ein neues Webdesign eingebaut werden. Ich glaube, das ist tatsächlich eine Option, die von Anfang an nicht ernsthaft erwogen wurde: Dass alles optisch so bleiben könnte, wie es ist. --Viele Grüße, Aschmidt (Diskussion) 15:50, 14. Mär. 2025 (CET)

(I haven't read the latest comments yet, just wanted to reply to this one by Doc Taxon.)

I asked one of the engineers on the team, and this is what they had to say:

"As with any feature, of course with enough time it is possible to solve any problem. In the case of adding support for temporary account banners, the feature was built and it was non-trivial to enable it on legacy Vector. Feel free to tinker with this to get a sense of what work that might involve.

Legacy Vector makes heavy use of absolute positioning relative to the BODY element to layout its menus. While this was a good design decision to be made back in 2011, when IE6 was still being supported, this decision means it is impossible to add any element above the menus. This leaves us with two options: 1) redesign the banner for legacy Vector or 2) rewrite legacy Vector's layout code.

Given at this point legacy Vector serves a small fraction of our project's traffic and the intention with Vector 2022 was always to make it the default everywhere, it is really hard to justify any time spent on this when it could be spent on higher priority fixes that benefit everyone."

(End of quote) Hope this explains a bit. --SGrabarczuk (WMF) (Diskussion) 18:01, 14. Mär. 2025 (CET)

Feel free to tinker with this to get a sense of what work that might involve — after two minutes of tinkering:

body.skin-vector-legacy .mw-temp-user-banner ~ #mw-navigation #mw-head,
body.skin-vector-legacy .mw-temp-user-banner ~ #mw-navigation #mw-panel {
    top: 3em;
}

Not exactly rocket science as is presented both above and in the similar announcement to Russian Wikipedia.

Ich sende meine Solidarität an alle Benutzer von der deutschsprachigen Wikipedia. In der russischsprachigen Wikipedia gibt es auch ein Ultimatum von der Web-Team, um auf Vector 2022 ohne Zustimmung von der Gemeinschaft zu wechseln. Falls es passieren würde, der aktuelle Plan ist es, um ein Skript hinzufügen, damit alle aktive Benutzer auf Vector 2010 wechseln können (ru:Википедия:Голосования/Срочное включение Вектора-2022 (2025)). Der Programmcode vom Skript: ru:Участник:Stjn/vector2022KillSwitch.js. stjn 18:01, 18. Mär. 2025 (CET)

@OVasileva (WMF), SGrabarczuk (WMF): Hundreds of thousands of Wikipedia articles are specially designed so that they work with the existing Vector skin in terms of content and images, text, tables etc. being harmonised with each other. Your help in dealing with this huge number of problems would be greatly appreciated, because I don't really want to spend my spare time on such problems caused by WMF. I'm just afraid you meant other things when you wrote "Wir helfen euch auch, Dinge anzupassen, mit denen Vector 2022 möglicherweise nicht kompatibel ist." --DerMaxdorfer (Diskussion) 21:13, 17. Mär. 2025 (CET)

If some authors design their articles in a way that they can only be consumed with a specific skin (and not with a screen reader, in mobile view, or when printed), that is not the fault of the WMF. --Discostu (Disk) 22:12, 17. Mär. 2025 (CET)

It's probably true, @Discostu, but I think what @DerMaxdorfer meant to say is that when Wikipedia articles were written and enriched with images and tables, etc., editors were not able to consider that, e.g., the maximal width of future skins would be much narrower than it used to be which restricts the hitherto usual way to deal with such elements in a page. Yes, there are differences between language versions of Wikipedia in this respect. As most articles are in the long tail in most cases it will take quite a while till we find such unfavourable web design and fix it. It seems that most longtime editors are feeling lost at the amount of work they encounter, considering we also have to adapt German Wikipedia to dark mode. It would be greatly appreciated if you please could take this into account on behalf of the WMF. Thanks and --Viele Grüße, Aschmidt (Diskussion) 23:19, 17. Mär. 2025 (CET)

I know that one should "design" WP articles in a way that they "work" on every type of display, and I try to keep that in mind for my own articles, but that doesn't change the problems the new skin is causing in a whole lot of other articles (probably including the ones from my early years). Aschmidt explained it well. --DerMaxdorfer (Diskussion) 23:26, 17. Mär. 2025 (CET)

Thanks @DerMaxdorfer, I hear you, there is indeed some risk and work to be done. We have had similar conversations on other wikis before. In general, I totally get the sense of responsibility over the articles, especially the older ones. There are different "layers" of this situation:

1. Short-term, I think I can say "because other Wikipedias are fine, dewiki will also be fine", not to deminish your concern, but because on dewiki, you have lots of text, which is easy to manage, so to speak. It doesn't look odd with different interface settings.
2. Tables are more troublesome, and to my knowledge, our engineers have added some tweaks. Now, on their end, the situation is as good as it gets, and we can't make further investments before deploying Vector 2022 everywhere and without some coordinated effort of editors. Generally, we can have this conversation without a sence of urgency.
3. Vector 2022 does surface some problems with the "design" of articles. And yeah, articles shouldn't be designed to look good on the author's screen. It's a misconception that the "design" can be controlled. Users can set different widths, font sizes, etc. etc., so the recommended solution for communities is to adopt good practices. Our team has created Recommendations for mobile friendly articles on Wikimedia wikis and I hope we will be posting more about this as a standalone topic.

I hope this makes sense. Let me know if you'd like to learn more! --SGrabarczuk (WMF) (Diskussion) 23:30, 18. Mär. 2025 (CET)

Die sind größtenteils schon automatisch angepasst, weil es Bug-Reports auf phab: gab, um Probleme zu lösen. Das Poblem mit überlangen Tabellen z.B., dass am Anfang mit <div style="overflow:auto"></div>behoben werden musste (und auf meinen betreuten Seiten immer noch eingefügt ist, weil es auch eine Aufwertung von Vector-2010 bedeutet), muss für den Vector-2022 mittlerweile nicht mehr gesetzt werden, weil es endlich wieder (Timeless hatte ihn schon) einen automatischen vertikalen Scrollbalken bei Tabellen, die zu klein sind, gibt.
Das andere Problem sind Bilder, die durch |hochkant= größer als die Ränder von Vector-2022 sind. Bei diesen Bildern gab es bei sehr kleinen Bildschirmen auch bei Vector-2010 Probleme. Hier habe ich, wenn ich etwas gesehen habe, die Bilder etwas verkleinert. Das ist aber kein dringliches Problem, auch weil man als Leser notfalls die Linke Spalte einklappen (die Rechte wird ja sowieso meist eingeklappt sein) kann. Das ist aber hausgemacht und sowieso, insbesondere bei größer als mini, aber auch bei kleiner als mini keine gute Idee (aber immerhin eine bessere als feste Pixel), denn es gibt z.B. viele Menschen, die die Vorschaubilder in den Einstellungen auf 400px gesetzt haben. Für die konnten schon mit Vector-2010 die Bilder durch |hochkant=-Basteleien so übergroß werden, dass sie deutlich über den ganzen Bildschirm ragten und man somit nur die Bildmitte sah (ich nutze diese Einstellung, von daher versuche ich immer ein akzeptables Nivaeu zwischen der Vector-2022 mit der Einstellung, Vector-2022 in der Standardeinstellung und (bislang) Vector-2010 in der Standardeinstellung (dabei hatten bei mir natürlich Vector-2022 in der Standardeinstellung und (bislang) Vector-2010 in der Standardeinstellung Vorrang, denn das ist das, was die meisten Leser sehen) zu finden. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 11:15, 18. Mär. 2025 (CET)

Vector2022 hat die deutsche Wikipedia zerstört!

Sie hat jetzt dasselbe, schlechte Layout wie die englische WP. Jahrelang bemühte ich mich in vielen Artikeln um ein gutes, ausgewogens Layout, mit enormen Zeitaufwand - und nun wurde mit einem Schlag vieles zunichte gemacht! Diese Verschlimmbesserungen sind typisch für das 21. Jh. - genauso geschehen mit dem einstmals erstklassigen BayernAtlas im Nov. 2024. So verärgert oder vertreibt man Autoren, die in der Dt. WP nicht mehr wurden. Mein WP-Engagement muss ich jetzt zwangsläufig überdenken, weil gute Gestaltung in bisheriger Weise nicht mehr möglich ist. Ich erkenne meine Artikel nicht mehr. --Foxy5 (Diskussion) 01:24, 1. Apr. 2025 (CEST)

Artikel sollen niemals ein festgelegtes Layout haben, weil sie auf jedem Gerät (hängt mit Bildschirmgröße und -format zusammen) anders aussehen. Wenn du das wirklich so gemacht hast, hast du a) (wie viele andere Autoren) entgegen den WP-Prinzipien gehandelt und b) Nutzern anderer Geräte als dein eigenes einen kaum lesbaren Artikel angetan.
Nur my 2 cents. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 01:34, 1. Apr. 2025 (CEST)

Endlich hört der Unsinn mit Usern wie dir auf die alles auf genau eine Auflösung/Breite optimieren. Es liegt noch ein weiter weg vor uns das alles aufzuräumen. Bisher wurde ich dabei oft zurückgesetzt. --0815 User 4711 (Diskussion) 07:06, 1. Apr. 2025 (CEST)

Frage: Kann ich für mich selbst die Benutzeroberfläche so ändern, dass sie wie die alte Nutzeroberfläche aussieht? --Goroth Redebedarf? 08:19, 1. Apr. 2025 (CEST)

siehe Spezial:Einstellungen#mw-prefsection-rendering oder gleich für alle Projekte Spezial:Globale Einstellungen#mw-prefsection-rendering. --Johannnes89 (Diskussion) 08:22, 1. Apr. 2025 (CEST)

• Globale Einstellungen aufrufen
• unter „Benutzeroberfläche“ zuerst links das Häkchen aktivieren, um die folgende Einstellung für alle Projekte wirksam werden zu lassen
• daneben „Vector alt (2010)“ auswählen
• Einstellungen speichern

Gruß, -- hgzh 08:23, 1. Apr. 2025 (CEST)

oh vielen Dank für die Anleitung, @hgzh! Diese Änderung kam heute morgen völlig überraschend für mich (wieso sind solche Ankündigungen auf irgendeiner Projekt-Seite?), und ich hatte sehr zu kämpfen - vermutete + fand die "Einstellungen", aber es funktionierte nicht auf Anhieb.

Und generell als Feedback an die Macher hier: ich finde nur-grafische Anwahlen unpraktisch :-( um es dezent auszudrücken. Ich kann damit nix anfangen; ich möchte Wörter lesen. --DeeDelDum (Diskussion) 08:45, 1. Apr. 2025 (CEST)

Die Ankündigung kam deutlich im Voraus auf dieser Seite, stand im Kurier (Wikipedia:Kurier#Vector 2022 wird Standardskin) und wird seit gestern Abend allen angemeldeten Usern per Banner angekündigt (sieht so [18] aus). Wo/wie würdest du denn so eine Ankündigung erwarten? --Johannnes89 (Diskussion) 09:03, 1. Apr. 2025 (CEST)

An mir ist das auch vollkommen vorbei gegangen. Der Hinweis scheint zu dezent gewesen zu sein. --Gmünder (Diskussion) 09:08, 1. Apr. 2025 (CEST)

Ist mir schon klar, dass 'deutlich' Euer Ziel war, ist aber Deine Meinung, nicht meine: diese Projektseite kenne ich nicht (bis ich hier gepostet habe, nehme ich an? oder wie?), im Kurier hatte ich's gesehen, habe es aber nicht als eine Zwangs-Änderung wahrgenommen, das Banner habe ich nicht gesehen, sehe auch bei dem Link-18 nichts außer der Wiki-Hauptseite (bin jetzt schon eine Weile angemeldet + klicke die Banner sowieso meist ohne intensives Lesen weg, da so eine Art Werbung).

Wo/wie: wenn es sich auf uns alle bezieht, und eben eine ungefragte Zwangsänderung, dann würde ich einen Text über die Benutzerseite/Disk. erwarten - wie es xx andere, die Generelles mitteilen, auch machen - damit es eben nicht übersehen wird und zu solchen überfall-artigen Änderungen führt.

Wird es irgendwann womöglich eine nicht mehr änderbare Vorgabe werden? Könntet Ihr dann bitte auch eine TEXT-Darstellung einplanen? --DeeDelDum (Diskussion) 09:53, 1. Apr. 2025 (CEST)

im Kurier hatte ich's gesehen, habe es aber nicht als eine Zwangs-Änderung wahrgenommen – da ich den Hinweis im Kurier verfasst habe, interessiert mich: wie hätte ich es formulieren können, damit das klarer geworden wäre?

Wird es irgendwann womöglich eine nicht mehr änderbare Vorgabe werden? – unwahrscheinlich, es ist bspw. immer noch möglich, mit dem Skin zu arbeiten, der vor mittlerweile 15 Jahren Standard war.

Könntet Ihr dann bitte auch eine TEXT-Darstellung einplanen? – es gibt durchaus Möglichkeiten, das für sich anzupassen, wenngleich das auch immer ein Kompromiss ist: Benutzer:Hgzh/css/vectorUserMenuLabels.css; falls dich die Wirkung interessiert, kann ich eine kurze Anleitung verfassen, wie man das einbindet.

Zuletzt: ich und andere, die hier Fragen beantworten, haben keine offizielle Funktion, d.h. wir haben keinen direkten Einfluss auf die hier umgesetzten Maßnahmen. Wir „moderieren“ das Ganze lediglich in unserer Freizeit und können ggf. kleinere Probleme direkt lösen und Hinweise weitergeben, sind aber letztlich die falschen Ansprechpartner für das „große Ganze“. Gruß, -- hgzh 10:10, 1. Apr. 2025 (CEST)

nochmal besten Dank, hgzh :-) Eins vorweg: ist mir schon klar, dass die meisten hier Benutzer sind (deshalb wundere ich mich auch eher darüber, dass so viele so tun, als ob ihre Kenntnisse und Meinungen allgemeingültiges Wissen + Vorgaben wären). Zum einen habe ich wohl den hier schreibenden Johannes mit einem anderen Johannes verwechselt, vor allem aber habe ich - als ich diese Diskussion hier + heute gefunden habe - nicht alles gelesen, aber den ersten Satz: "Wir sind das Webteam der Wikimedia Foundation." - daher dann auch mein generelles Feedback "an die Macher" in der Hoffnung, dass die Gruppe hier noch mitliest.

Zu dem Kurier-Artikel, den ich mir dank Johannes' Link unten nochmal angeschaut habe: ich habe das "global" offenbar nicht verstanden (obwohl bei erster Erwähnung kursiv) und vermutlich auch nicht die "Spezialseiten". Ich weiß, dass ich in meine Einstellungen geschaut hatte, und dass es nicht das Ankreuz-Feld hatte wie in Deiner heutigen Beschreibung. Aber die Einstellung auf die 'alte' Version war da, + daher dachte ich, die Änderung trifft auf mich nicht zu. Daher habe ich mir auch die Disk. nicht weiter angeschaut, eben, weil die Wortwahl mit global + Spezial sehr programmier-technisch wirkten (und auch die Ankündigung hier nicht wirkte, als ob sie sich an Leser richtete). Die Ankündigung der Änderung habe ich daher nicht auf mich bezogen, schon gar nicht als nächtliche Zwangsänderung.

Jedenfalls sehr beruhigend, dass die Möglichkeit der Text-Darstellung noch eine Weile erhalten bleibt. Ich sehe das lediglich aus Nutzer/Leser-Sicht und finde wie erwähnt diese nur-grafische Darstellung furchtbar, da unverständlich - ist leider ein beliebtes Vorgehen, auch anderswo, in der Annahme, dass "jeder" Grafik besser versteht als Text.

Und ich werde mir Deinen css-Link anschauen, aber ich befürchte schon nach einem ersten Blick darauf, dass ich es nicht verstehe. Bei js und css steige ich aus. Von daher ein "Ja bitte" zu einer kleinen Anleitung (inkl.der Wirkung!), wenn Du dazu kommst - dort beobachten oder auf Deiner Disk.seite? --DeeDelDum (Diskussion) 11:15, 1. Apr. 2025 (CEST)

Danke für deine Antwort. Zum letzten: eine Kurzanleitung findest du auf Benutzer:Hgzh/css#Vector_2022, wenn du da nicht weiterkommst, melde dich gern auf meiner Disk. Gruß, -- hgzh 11:28, 1. Apr. 2025 (CEST)

Danke! und werde ich tun! 🖖 --DeeDelDum (Diskussion) 11:34, 1. Apr. 2025 (CEST)

> diese Projektseite kenne ich nicht
Die ist mit Wikipedia:Projektneuheiten genau für so etwas gedacht. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:43, 1. Apr. 2025 (CEST)

Danke für den Hinweis. Bei der Vielzahl der Projektseiten hier wäre ich nicht auf diese gekommen. Allerdings ist auch diese Seite mit ihrer sw-techn. Ausdrucksweise - auch wenn sie behauptet, für "Benutzer der deutschsprachigen Wikipedia relevant" zu sein - für mich weder verständlich noch interessanter als die Artikelseiten, auf denen ich normalerweise arbeitete. Auch mit nur wenig übersetzten engl. Seiten kann ich übrigens nix anfangen. Also, lassen wir's :-) --DeeDelDum (Diskussion) 11:28, 1. Apr. 2025 (CEST)

Das muss ein wohl ein schlechter Aprilscherz sein. Man kann von dem neuen Layout halten was man will, aber eine vorher vom Nutzer festgelegte Skin-Einstellung zu überschreiben ist einfach nur nervig. Wieder einmal will man dem Nutzer vorschreiben, was das Beste für ihn ist. Typisches Beispiel für Technikpaternalismus / Nudging. --Sinuhe20 (Diskussion) 09:59, 1. Apr. 2025 (CEST)

Geändert wurde die Standardeinstellung, die die meisten User nie ändern. Wenn man bereits einen anderen Skin ausgewählt hatte, wird man von der Änderung nicht erfasst. Und der zugehörige Kurierartikel wies doch bereits vor der Umstellung darauf hin, wie man seine Einstellungen vorher so anpassen kann, sodass sie nicht überschrieben werden. Es sind aber auch nur drei Klicks in den Einstellungen wieder zurück zu Vector 2010. --Johannnes89 (Diskussion) 10:27, 1. Apr. 2025 (CEST)

> Wenn man bereits einen anderen Skin ausgewählt hatte, wird man von der Änderung nicht erfasst.

Oh doch, das wurde man.

Ich habe damals, als Vector 2022 herauskam, extra meinen Account "wiederbelebt", weil ich dieses Theme mit jeder Faser meines Körper hasse.

Letzt Woche auf der Arbeit war ich, wie so oft, auf en.wikipedia.org und siehe da, ich musste mein Theme erneut ändern.

Jetzt gerade musste ich, wie erwartet, auch in der deutschsprachigen Wikipedia das Theme erneut auf Vector alt ändern. --H4ckerxx44 (Diskussion) 17:05, 1. Apr. 2025 (CEST)

Dann hast du es nicht global umgestellt, wie es notwendig war. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 17:07, 1. Apr. 2025 (CEST)

Sollte damit eigentlich nichts zu tun haben.

IUch hatte es ja vor Monaten bereits beides auf Vector alt gestellt, wurde dann aber wieder auf Vector 2022 umgestellt, was ein erneutes, nicht globales, setzen auf Vector alt erforderte. --H4ckerxx44 (Diskussion) 17:17, 1. Apr. 2025 (CEST)

Das kann nicht sein, ich habe den Skin sicher schon mehrmals geändert, zuletzt stand er auf Vector 2010. Als ich mich 2010 angemeldet hatte, gab es noch MonoBook. Schon damals war die Umstellung auf Vector schwierig, aber ich hatte mich jetzt langsam dran gewöhnt (und ich kann mich gut erinnern, dass ich mehrmals zwischen MonoBook und Vector gewechselt habe bzw. auch schon andere Skins wie Minerva ausprobiert hatte). --Sinuhe20 (Diskussion) 17:10, 1. Apr. 2025 (CEST)

> aber eine vorher vom Nutzer festgelegte Skin-Einstellung zu überschreiben ist einfach nur nervig
Das Problem, dass es nur global „Standard“ als Schaltfläche gibt. Lokal gibt es nur die einzelnen Skins als Auswahl (ja meiner Meinung nach eins sehr schlechtes Design @WMF). Wie soll dann die Software wissen, ob du möchtest, dass in diesem Projekt Vector-2010 angezeigt oder in diesem Projekt der Standard angezeigt wird?

> Typisches Beispiel für Technikpaternalismus / Nudging.
Im Übrigen wäre das der Fall, wenn die alte Oberfläche nicht mehr auswählbar wäre und man außerdem nicht irre viele Individualisierungsmöglichkeiten mittels js und css hätte. Die WMF ist eines der wenigen großen Protale, die kein „Technikpaternalismus / Nudging“ betreibt. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:43, 1. Apr. 2025 (CEST)

Vielleicht ist hier ein Fehler in der Programmierlogik, dass davon ausgegangen wird, Vector 2010 wäre eine nie geänderte Standardeinstellung. Vermutlich wird nicht berücksichtigt, dass man schon mehrmals hin- und hergewechselt ist, wie es bei mir der Fall war. --Sinuhe20 (Diskussion) 17:14, 1. Apr. 2025 (CEST)

Voll schlecht, diese nervige Vereinheitlichung mit internatioaler WP. Für mich ganz klar ein Grund hier ganz auszusteigen. (Erwarte keine Zustimmung, sehe nur die Verbesserung überhaupt nicht.) 21:52, 1. Apr. 2025 (CEST) --R.Tm01 (Diskussion) 21:52, 1. Apr. 2025 (CEST)

Als angemeldeter Nutzer kannst Du ja mit dem alten Layout weiterarbeiten: einfach unter Spezial:Einstellungen im Reiter "Aussehen" Vektor alt (2010) auswählen. --Magiers (Diskussion) 21:58, 1. Apr. 2025 (CEST)

Flächenverteilung der Standardoberfläche

Die neue Standardversion verschenkt unnötig viel Platz für zwei Seitenspalten. Zur Navigation in stark gegliederten Artikeln ist die Sichtbarkeit der Gliederung unverzichtbar. Daher wäre es sinnvoller, die Version "Breit" als Standardversion anzubieten.

Über Steuerlogo sollte allerdings auch der Commons-Link abzurufen sein. Bei er Suche nach informativen Fotos von Objekten, die bisher nur in anderen Sprachen als Deutsch beschrieben sind (die oftmals schon länger Vector 2022 verwenden) nervt es mich immer weider, nach dem Commons-Link suchen zu müssen, der irgendwo hinten unten steht, aber vor dem manchmal langen Fußnoten-Verzeichnis.--Ulamm (Kontakt) 02:23, 1. Apr. 2025 (CEST)

+1 Vector 2022 ist leider völlig fehldesignt. Die rechte Spalte sollte in die linke integriert werden, Werkzeuge und anderssprachige Artikel sollten standardmäßig aufgeklappt in der rechten (und einzigen) Seitenleiste angezeigt werden und und breit sollte ebenfalls Standard sein. Das Inhaltsverzeichnis sollte eigentlich auch dorthin zurück, wo es seit fast 2,5 Jahrzehnten immer war, aber da sehe ich wenigstens den Vorteil der neuen Lösung (nämlich dass es nun immer sichtbar ist, auch wenn man runterscrollt). -- Chaddy · D 02:20, 1. Apr. 2025 (CEST)

Sobald man die Werkzeugleiste rechts einmal ausklappt, bleibt sie ausgeklappt (bis man sie wieder eingeklappt). Dort findet man auch den Commons-Link des jeweiligen Artikels (wenn vorhanden). Ebenso ist die Sichtbarkeit der Gliederung gegeben, das Inhaltsverzeichnis befindet sich ja nun dauerhaft links. Wenn man das Inhaltsverzeichnis anders möchte: mw:Reading/Web/Desktop Improvements/Repository#Modifications of Vector 2022: new gadgets and user scripts nennt ein paar Skripte, die es ändern. --Johannnes89 (Diskussion) 08:28, 1. Apr. 2025 (CEST)

Hierzu folgende Rückfragen (zu beiden Vorrednern):

• Zur Navigation in stark gegliederten Artikeln ist die Sichtbarkeit der Gliederung unverzichtbar – die Gliederung des Artikels ist doch über das Inhaltsverzeichnis erschließbar, und das wird (in Standard-Desktopbreite) unabhängig von der Anzeigebreite gezeigt, oder geht es um etwas anderes?
• Was ist das Steuerlogo?
• Die rechte Spalte sollte in die linke integriert werden [...] Werkzeuge und anderssprachige Artikel sollten standardmäßig aufgeklappt in der rechten (und einzigen) Seitenleiste' – du meinst rechtenlinken (und einzigen), oder?

-- hgzh 08:29, 1. Apr. 2025 (CEST)

Ja, meine ich. Da bin ich durcheinandergekommen. Es sollte nur links eine Seitenleiste geben, so wie bei den älteren Skins auch, sonst verschwendet das unnötig viel Bildschirmbreite (und ich weiß, es ist ja eigentlich das Designziel, den Artikel möglichst nicht sehr breit anzuzeigen, aber das ist halt nicht sehr sinnvoll, wenn man am PC sitzt). -- Chaddy · D 17:13, 1. Apr. 2025 (CEST)

Welche Möglichkeiten gibt es...

...das alte Layout bei Bedarf weiter zu nutzen ? Der Hinweis zur Umstellung ist auch an mir vorbei gegangen, und der Schock heute morgen war um so größer. Das ist Mist ! --Koyaanis (Diskussion) 09:26, 1. Apr. 2025 (CEST)

Nachtrag: Hat sich erledigt. Aber der dezentee Hinweis, dass das "altertümliche" Vektor 2010 scheinbar doch noch mehr Anklang findet als dieses fragwürdige 2022er Update, sollte den Projekt-Programmierern ein wenig zu denken geben. CU --Koyaanis (Diskussion) 09:31, 1. Apr. 2025 (CEST)

Im Hauptmenü links (ggf. eingeklappt) ist übrigens für die Zeit der Umstellung eine fettgedruckte Schaltfläche „Umschalten zum bisherigen Aussehen“, die einen direkt auf Spezial:Einstellungen#mw-prefsection-rendering führt, wo man das ändern kann. Alternativ gleich für alle Projekte via Spezial:Globale Einstellungen#mw-prefsection-rendering. Einzelne Rückmeldungen hier halte ich nicht für repräsentativ als Aussage zu einem Skin, der bereits (überwiegend seit Jahren) in 99% aller WMF-Projekte aktiviert ist und noch mehr Jahre an Nutzungstests hinter sich hat. --Johannnes89 (Diskussion) 09:47, 1. Apr. 2025 (CEST)

Ich finde 2022 auch nicht prall. Mich hat es an anderer Stelle auch schon gestört. Ich war ebenfalls froh, herauszufinden, wo man wieder auf 2010 umstellen kann. Vielleicht bin ich nur Teil einer meckernden Minderheit. ;-) --Scientia potentia est [Dermartinrockt] (Diskussion) 09:50, 1. Apr. 2025 (CEST)

Du bist nicht in der Minderheit. Siehe Wikipedia:Umfragen/Vector 2022 als Standardskin. --Lupe (Diskussion) 09:54, 1. Apr. 2025 (CEST)

~150 Teilnehmer (von denen sich 76 für Vector 2010 aussprechen, der Rest für andere Optionen) einer Umfrage sind auch nicht die Mehrheit. Wikipedia wird von Millionen Menschen gelesen (die oft ganz andere Bedürfnisse haben, als die schreibenden Autoren), aber selbst unter den Autoren ist das nur ein Bruchteil – wir haben 17.000 User, die in den letzten 30 Tagen editiert haben. Den meisten scheint (nicht nur bei Vector 2022, sondern generell) relativ egal zu sein, wie die technischen Umstände sind, solange sie ungestört ihre Artikel bearbeiten können. --Johannnes89 (Diskussion) 10:14, 1. Apr. 2025 (CEST)

Man kann sich natürlich auch den Fakten verweigern. Und selbst Leute, die den neuen Skin nutzen, haben berechtigte Kritik, die ignoriert wurde. --Lupe (Diskussion) 10:18, 1. Apr. 2025 (CEST)

Die Fakten sprechen (gerade global betrachtet) eine deutliche Sprache. Hier schließen einzelne Poweruser, die sich an ihre präferierte Version gewöhnt haben, von sich auf andere. Bzgl. berechtigter Kritik bist hier an genau der richtigen Stelle, deine Verbesserungsvorschläge zu äußern, die WMF ließt diese Diskussion mit. --Johannnes89 (Diskussion) 10:22, 1. Apr. 2025 (CEST)

Die Umfrage ist eindeutig. Wie gesagt, ist denen egal. Sie hatten jahrelang Zeit nachuzubessern, die Diskussion ist müßig. --Lupe (Diskussion) 10:27, 1. Apr. 2025 (CEST)

>> Den meisten scheint (nicht nur bei Vector 2022, sondern generell) relativ egal zu sein, wie die technischen Umstände sind, solange sie ungestört ihre Artikel bearbeiten können.<<

'scheint zu sein' = also eine Annahme. Vielleicht äußern sie sich auch nur deshalb nicht über die - durchaus empfundene - Störung ihrer Arbeit, weil sie keine Stelle finden, wo sie das tun könnten - oder jedenfalls nicht einfach.

Und wir wissen auch nicht, wie viele deshalb Wikipedia verlassen haben oder werden.

Und relativ ist halt relativ. ;-)

Ich bin übrigens wahrhaftig kein Power-user.

Johannes, ich kann ja verstehen, dass Du nach der offenbar langen Disk.-Zeit hier allmählich genervt bist - also, sorry... --DeeDelDum (Diskussion) 10:26, 1. Apr. 2025 (CEST)

> Und wir wissen auch nicht, wie viele deshalb Wikipedia verlassen haben oder werden.
Das wissen wir aus den Auswertungen aller anderen Wikis außer unserer und der russischen Wikipedia: Und da gab es keine überproportionalen Inaktiven. Erst recht nicht wegen der Oberfläche. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:43, 1. Apr. 2025 (CEST)

Ich empfehle einen Blick auf mw:Reading/Web/Desktop Improvements und die dortigen Unterseiten. Die WMF hat sehr ausführliche Untersuchungen zu allem angestellt, was im neuen Skin nun anders ist, solche Untersuchungen zur User Experience sind deutlich repräsentativer als Einzelmeinungen hier oder in der Umfrage. --Johannnes89 (Diskussion) 11:00, 1. Apr. 2025 (CEST)

+ 1 Das übliche Forenphänomen: Nur der, der etwas zu beklagen hat, meldet sich. Den anderen, denen es egal ist oder die die Änderung wollen, melden sich nicht. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 10:25, 1. Apr. 2025 (CEST)

+1. --DeeDelDum (Diskussion) 09:56, 1. Apr. 2025 (CEST)

Bin froh, dass die Änderung endlich umgesetzt wurde. Im Übrigen: Kein Zwang, man kann den Skin weiterhin frei wählen. Viele Grüße, Aschmidt (Diskussion) 10:29, 1. Apr. 2025 (CEST)

Johannnes89, die Kritiker hier sprechen in diesem Moment nicht als "globale" Nutzer, sondern als normale de-Vertreter, die vielleicht tatsächlich aus Gewohnheitsgründen an alten Versionen festhalten - und bedauerlicherweise darin bestärkt werden, wenn die Programmierer an den Wünschen der weniger technikaffinen User vorbei exprimentieren...kennt von zur Genüge aus der WikiData-Story. --Koyaanis (Diskussion) 10:29, 1. Apr. 2025 (CEST)

Es ist ja auch völlig ok, wenn man mit dem alten Skin besser zurecht kommt. Wenn es ein konkretes Detail gibt, das stört, lässt sich vieleicht eine Lösung finden. Aber es bringt m.E. eher nichts, die große Grundkonzeption infrage zu stellen (also Seitenleiste rechts, Inhaltsverzeichnis links etc.), denn das ist ja genau der Ansatz, auf dem dieser Skin entwickelt wurde und deshalb wird man das auch nicht zurücknehmen. Für diejenigen, die das nicht haben möchten, wird der alte Skin auch mindestens die nächsten 15 Jahre weiterhin zur Verfügung stehen. -- hgzh 10:38, 1. Apr. 2025 (CEST)

Ohne hier alles gelesen zu haben: Ich ziehe Vector 2010 zwar persönlich vor - inzwischen, denn damals fand ich es auch gewöhnungsbedürftig -, aber finde Vector 2022 als Standardskin, so lange man sich angemeldet auch für V2010 oder einen anderen Skin seiner Wahl entscheiden kann, nicht schlimm. Mal ehrlich, "wir" fanden hier noch jeden neuen Skin grässlich, furchtbar, unpraktisch, das ist halt so eine Gewohnheitssache, vor der ich auch nicht gefeit bin. Ich bin daran gewöhnt, an einem PC mit diesem die ganze Bildschirmbreite ausnutzenden Skin zu arbeiten und habe kein Problem mit sehr breitem Text. Aber das kann ich ja weiterhin und können weiterhin alle, die das wollen. Gestumblindi 11:36, 1. Apr. 2025 (CEST)

Du kannst übrigens über Erscheinungsbild auch im Vector-2022 das Design auf „Breit“ stellen und die Werkzeuge ausklappen. Und dann (nach den Einstellungen) finde ich den neuen Vector-2022 besser: Es gibt ein mitlaufendes Inhaltsverzeichnis und gleichzeitig mitlaufende Werkzeuge. Gleichzeitig hat man aber auch noch einen ausrechend großen Inhaltsscreen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 11:51, 1. Apr. 2025 (CEST)

Ja, man kann Vector 2010 auch weiterhin nutzen, so wie man auch Monobook noch nutzen kann. Allerdings wird der Skin nicht mehr weiterentwickelt (ebensowenig wie Monobook). Mit der Zeit wird Vector 2010 also immer unbrauchbarer und irgendwann ist man dann doch gezwungen, Vector 2022 zu nutzen (oder vielleicht Vector 2035, je nachdem was die Zukunft so bringt). -- Chaddy · D 17:20, 1. Apr. 2025 (CEST)

Warum sollte der Skin mit der Zeit unbrauchbarer werden? Ich nutze nach wie vor Monobook und komme damit hervorragend klar. Den Standardskin habe ich bei einem meiner Zweitkonten eingestellt, den nutze ich hauptsächlich, um Neulingen zu helfen bzw. um nachzuvollziehen, was diese am Schirm sehen. -- Perrak (Disk) 17:34, 1. Apr. 2025 (CEST)

Nur Vector 2022 und MinervaNeu werden noch gepflegt, die anderen nicht mehr. Deshalb empfiehtlt es sich schon, mit einem der aktuellen Skins zu arbeiten, um sich daran zu gewöhnen, denn die älteren Skins wird es nicht auf Zeit und Ewigkeit geben. Der Aufwand für die Pflege eines Skins ist nämlich erheblich, da sich bei den Webbrowsern und den Webstandards ständig etwas ändert. Da fehlt übrigens nichts, die Bedienoberfläche ist nur etwas anders aufgebaut. Und wenn man sich einmal die Vorschläge zu Anpassungen hier durchliest, merkt man schnell, dass jede/r etwas anderes beanstandet und sich etwas anderes wünschen würde. Wie soll der Skin denn nun aussehen? Ich kann aber jedem Monobook-Fan sagen, dass ich damit nie klarkam, weil meine richtig aktive Zeit erst mit der Einführung von Vector begann, und auch damals hatte ich sofort gewechselt. Ich habe aber Verständnis für das Fremdeln, das viele zeigen, denn freilich bedeutet es Stress, wenn man sich in einem neuen Gelände erstmal zurecht finden muss, wenn es auch im Prinzip alles enthält, was man von früher kennt. Die hohe Fixierung auf Vector alt stammt einfach daher, dass diejenigen, die sich über den Wandel beschweren, so intensiv damit arbeiten. Vector 2022 wird aber ganz sicher den Neulingen den Einstieg erleichtern und Wikipedia moderner wirken lassen als bisher. --Viele Grüße, Aschmidt (Diskussion) 18:01, 1. Apr. 2025 (CEST)

Der Umstieg auf Vector 2010 fiel mir aber recht leicht. Bei Vector 2022 ist das schon ganz anders, da es hier einfach ein paar Punkte gibt, die fehlkonzipiert sind (die Sprachlinks so zu verstecken z. B. ist überhaupt nicht benutzer*innenfreundlich und entspricht auch nicht dem multilingualen Geist der Wikipedia). -- Chaddy · D 19:56, 1. Apr. 2025 (CEST)

Bedenke bitte, dass wir seitdem auch 15 Jahre älter geworden sind. Das bringt auch bei solchen Änderungen mehr Stress mit sich. --Viele Grüße, Aschmidt (Diskussion) 20:12, 1. Apr. 2025 (CEST)

Die alten Skins werden mit der Zeit immer mehr Fehler erzeugen und Probleme verursachen, die dann leider nicht behoben werden. Und neue Funktionen werden für diese alten Skins dann auch nicht zur Verfügung stehen. Das war dann ja auch der Grund, wieso ich dann irgendwann doch mal von Monobook zu Vector 2010 umgestiegen bin, obwohl ich lange Zeit entschiedener Monobook-Verfechter war. -- Chaddy · D 19:59, 1. Apr. 2025 (CEST)

+1. Einerseits wird es außerdem Probleme mit alten Userskripten geben; andererseits wird es leichter sein, Userskripte zu pflegen, je weniger Skins es geben wird. --Viele Grüße, Aschmidt (Diskussion) 20:18, 1. Apr. 2025 (CEST)

Okay, wenn man hier noch Verbesserungsvorschläge äußern können soll, hätte ich ein paar. Könnte man es irgendwie möglich machen, dass man die Interwikilinks auch in die linke Seitenleiste schiebt. Die andere Sache wäre die, ob man die Möglichkeit hat, bspw. auch die persönlichen Werkzeuge, wie Diskussion/Beiträge/Einstellungen auch in eine Seitenleiste schieben kann, anstatt sie immer mittels Drop-Down Menü auswählen zu müssen. Und das dritte wäre, ob es eine Option geben könnte, Verschieben wieder neben die Bearbeitungsfunktionem zu verschieben, statt der Option am Rand. Das sind Sachen, die ich jetzt bei einer mir selbst verordneten Testphase festgestellt habe, die wirklich nützlich wären. —Ichigonokonoha (Diskussion) 12:01, 1. Apr. 2025 (CEST)

+1 zu Interwikilinks: Die Interwikilinks sind das, was mich bisher am meisten gestört hat. --Scientia potentia est [Dermartinrockt] (Diskussion) 12:04, 1. Apr. 2025 (CEST)

Ist dir bereits bekannt, dass sie in der neuen mitlaufen Titelleiste oben rechts enthalten ist (also egal wo du dich auf der Seite befindest (also auch nach unten gescrollt), kommst du daran). Allerdings benötige ich die Interwikis auch nicht allzu häufig. Wenn man sie häufiger braucht, sollten sie lieber woanders zu finden sein. Ich meine dafür gibt es auch bereits ein CSS-Sheet. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:46, 1. Apr. 2025 (CEST)

Oben rechts kenne ich. Ich nutze die Interwikilinks relativ häufig, um Inhalte zu vergleichen. Das mache ich mehrmals wöchentlich. Außerdem vermittelt das dem Leser auf den ersten Blick, dass wir ein internationales Projekt sind. --Scientia potentia est [Dermartinrockt] (Diskussion) 12:53, 1. Apr. 2025 (CEST)

> Diskussion/Beiträge/Einstellungen
Findet man oben in der neuen Titelleiste. Das befinde ich für praktischer, weil man dann mehr Platz für die Werkzeuge hat. Wenn du lieber statt den Icons Text haben möchtest, ist das durch ein CSS-Sheet (@Hgzh ich finde grad den Link nicht) auch möglich. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:42, 1. Apr. 2025 (CEST)

Ich weiß, dass das alles in der Titelleiste ist. Da finde ich das aber unpraktisch. Es geht darum, dass ich diese Links gerne z.B. an der Seite hätte, anstatt die immer per Drop-Down Menü auswählen zu müssen. Die Werkzeuge brauche ich ansonsten eigentlich fast alle gar nicht. Aber die Links, die ich ansonsten per Drop-Down auswählen müsste, die wären gut, wenn die da hinkommen würden. Ähnlich bei den Interwiilinks links. Da nach Vorschlägen gefragt wurde, hier ein Vorschlag. --Ichigonokonoha (Diskussion) 12:51, 1. Apr. 2025 (CEST)

Wie gesagt, dafür gibt es bereits Style-Sheets. Allerdings würde ich dir empfehlen erstmal testweise für eine Woche nur einen Style-Sheet zu nehmen, der alles aus der Titelseite ausblendet, was du nicht möchtest (den könnte ich dir auch schreiben, wenn du mir sagst, was alles im Titelmenü zu viel ist)). Wenn man nämlich zu viel in die rechte oder linke Spalte packt, läuft nicht mehr alles vernünftig mit.
Auch ich fand den neuen Skin, als ich ihn vor drei Jahren aktiviert hatte, am Anfang ungewohnt (ja mein jetziger Account ist erst von 2023, aber ich hatte ja ein Vorgängerkonto). Aber mittlerweile erkenne ich an, dass er durch die ausgeklappten (wenn die eingeklappt sind, ist dieser Skin tatsächlich zum Arbeiten schrecklich; ich hatte auch während der Testphase vorgeschlagen, unterschiedliche Default-Einstellungen für abgemeldete und angemeldete Nutzer zu setzen) mitlaufenden Menü eine Zeitersparnis und einen angenehmeren Workflow bedeutet. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 13:00, 1. Apr. 2025 (CEST)

Für das Umgehen des Dropdowns gibt es en:User:Terasail/HeaderTextLinks. Gruß, -- hgzh 13:03, 1. Apr. 2025 (CEST)

und en:User:Terasail/HeaderIcons Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 13:06, 1. Apr. 2025 (CEST)

Danke sehr für diese Hinweise. Das (mitsamt dem Inhaltsverzeichnis und den Interwikilinks) erleichtert die Arbeit mit dem neuen Skin schon sehr gewaltig. Gibt es zufälligerweise noch ein Skript, was bei dieser mitlaufenden Leiste auch aus den Seitensymbolen - also Artikeldiskussion, Versiongsgeschichte, etc. Text statt Symbole macht? --Ichigonokonoha (Diskussion) 11:44, 3. Apr. 2025 (CEST)

Was mir bei dieser Fragestellung gerade noch aufgefallen ist. Warum sitzt der Stern für die Beobachtungsliste in der mitlaufenden Leiste in der Mitte er Arbeitssymbole anstatt wie am oberen Rand rechts außen? --Ichigonokonoha (Diskussion) 11:53, 3. Apr. 2025 (CEST)

en:User:Terasail/HeaderTextLinks Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:42, 3. Apr. 2025 (CEST)

Ich habe gerade Benutzer:Hgzh/css#vectorUserMenuLabels für den sticky header erweitert und so angepasst, dass es sich mit dem Skript von Terasail verträgt. -- hgzh 13:06, 3. Apr. 2025 (CEST)

Einen großen Dank dir! --Ichigonokonoha (Diskussion) 19:42, 3. Apr. 2025 (CEST)

Warum nur

Warum nur musste auf dieses Design umgestellt werden. Ich kenne es seit langen aus der englischen Wiki und fan es dort schon schrecklich. Heute habe erstmal geschaut, ob ich nicht zufällig auf der enlischen Seite gelandet bin. Rechts und links Dinge, die micht nicht interessieren. Vorallem rechts die Möglichkeiten der Einstellungen, die man verbergen kann. Wenn es dann funktionieren würde. Oder besser gesagt, die Infos sind weg, dafür eine großer, weißer Bereich. Gleiches gilt links für das Inhaltsverzeichnis. Im Endeffekt gehr mir die Hälfte der Bidlschirmbreite für weiße Bereich drauf. Auch fehlen wohl einige Funktionen oder ich habe sie in dem Wust von DropDown-Menüs noch nicht gefunden. Wo schalte ich zum Beispiel auf der Hauptseite auf andere Sprachen/Wikis um? Es gibt so ein schönes deutsche Wort "verschlimmbessern" --Istiller (Diskussion) 20:52, 1. Apr. 2025 (CEST)

Ach ja, ich habe eben den Schalter zum zurückschaöten auf die alte Oberfläche gefunden: Eine Wohltat fürs Auge. Muss jetzt bloß mal schauen, ob das nur für angemeldete Besucher geht, Was natürlich blöd wäre, wenn nicht --Istiller (Diskussion) 20:55, 1. Apr. 2025 (CEST)

Die Interwikilinks auf der Hauptseite sind jetzt sehr versteckt in einem Aufklappmenü rechts unterhalb der Box "Schwesterprojekte".

Und zurück zum alten Skin kann man nur angemeldet, ja. -- Chaddy · D 21:04, 1. Apr. 2025 (CEST)

Hier gibt es tatsächlich eine Inkonsistenz in der Bedienoberfläche: Die Interwikilinks wurden auf der Hauptseite unten rechts platziert, bei den Inhaltsseiten findet man sie aber oben rechts. Nur auf der Hauptseite der französischen Wikipedia wurden die Interwikilinks ebenfalls oben rechts platziert. --Viele Grüße, Aschmidt (Diskussion) 23:17, 1. Apr. 2025 (CEST)

Ja, das ist leider nicht sehr intuitiv gelöst. Evtl. ist das aber auch gar nicht so beabsichtigt? -- Chaddy · D 00:33, 2. Apr. 2025 (CEST)

Ich gehe eher davon aus, dass frwiki hier irgendwie ein Goodie bekommen hatte. Als ich das Problem auf mediawiki.org während der A/B-Tests angesprochen hatte, hatte niemand reagiert. Es war schon damals dort anders als in allen anderen Sprachversionen. Ich hätte den Sprachschalter gerne auch auf der Hauptseite oben rechts platziert, wo man ihn erwarten würde, um schnell zu wechseln. --Viele Grüße, Aschmidt (Diskussion) 01:42, 2. Apr. 2025 (CEST)

mw:Reading/Web/Desktop_Improvements/Frequently_asked_questions#How_to_make_the_button_with_language_links_appear_at_the_top_of_the_main_page? --Jdlrobson (Diskussion) 02:40, 2. Apr. 2025 (CEST)

Um das nochmal auszuführen: man müsste für die Hauptseite eine Titelzeile festlegen, wie das die Franzosen gemacht haben (Wikipédia:Accueil principal). Bislang gibt es bei uns keine Titelzeile, man könnte bspw. das Willkommen bei Wikipedia dorthin verschieben, fällt dann nur etwas aus dem bisherigen Layout. Sobald es eine Titelzeile gibt, kann man auch die Sprachlinks dort einblenden. -- hgzh 07:54, 2. Apr. 2025 (CEST)

Ja, dann machen wir das doch, und dann ist es einheitlich. Ein Willkommen an der Stelle ist ja auch nicht verkehrt. --Viele Grüße, Aschmidt (Diskussion) 09:21, 2. Apr. 2025 (CEST)

+1. Über die genaue Formulierung kann (bzw wird) man danach noch abstimmen. --0815 User 4711 (Diskussion) 09:33, 2. Apr. 2025 (CEST)

@Jdlrobson is there a reason why the main page title is required for the button to appear on top? https://de.wikipedia.org/wiki/Wikipedia:Hauptseite?vectorlanguageinmainpageheader=1 looks okay to me. -- hgzh 08:26, 3. Apr. 2025 (CEST)

Some projects hide the heading meaning there is a huge gap at top of page. German is not one of them so this can easily be fixed. --Jdlrobson (Diskussion) 16:27, 3. Apr. 2025 (CEST)

Oh I see that is logged in only.. not logged out. --Jdlrobson (Diskussion) 16:31, 3. Apr. 2025 (CEST)

> Die Interwikilinks wurden auf der Hauptseite unten rechts platziert
Das ist ein lokaler de-Hack, den ich ebenfalls nicht sinnvoll finde. Es gab da aber sehr viele Fans von. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:18, 2. Apr. 2025 (CEST)

Nicht lokal DE. --Viele Grüße, Aschmidt (Diskussion) 13:23, 2. Apr. 2025 (CEST)

Als ich kurz nach Mitternacht noch bei WP vorbeigeschaut habe und mit Vector 2022 „zwangsbeglückt“ wurde, habe ich wirklich gedacht, dass das ein ganz mieser Aprilscherz ist, und mir ist die Lust zum Editieren sofort vergangen. Ich hatte nichts, aber auch gar nichts davon mitbekommen, dass das ab jetzt standardmäßig so sein soll – ich habe per css nervige Banner abgestellt, aber normalerweise kriege ich wichtige Dinge auch ohne Banner mit! Hier Fehlanzeige. Auch bei Fragen zur Wikipedia war erstmal gar nichts diesbezüglich los und ich dachte schon, dass vielleicht mein Browser wieder mal spinnt. Ich finde mich bei Vector 2022 einfach nicht zurecht. Eh ich da die Einstellungen gefunden hab, um auf Vector 2010 wieder umzustellen, lagen meine Nerven schon wieder blank und ich hab vor mich her geschimpft wie ein Rohrspatz. Sowas muss echt nicht sein. Und da ich zwecks Bebilderung auch regelmäßig in zig anderen Sprachversionen unterwegs bin, wo dieses olle Vector 2022 schon länger implementiert ist (ja, ich weiß, dass ich das auch dort umstellen kann, was ich bei den meisten auch habe), wusste ich auch schon, was das für ein unpraktischer Mist ist. Die Navigation ist eine Katastrophe. Man muss viel mehr suchen (ist denn schon Ostern?), braucht zig mehr Klicks und muss viel mehr scrollen. Total unbrauchbar für meine Arbeitsweise, vor allem wenn ich schnell andere Sprachwikis in weiteren Tabs aufrufen will. Viele Neulinge gewinnt man so mit Sicherheit auch nicht und Gelegenheitsautoren, die gar nicht wissen, dass sie daran was ändern können, sagen dann auch erstmal Tschüss, 100 pro. Natürlich kann ich erstmal weiter Vector 2010 nutzen. Blöd ist nur, dass ich manches auch in einem anderen Browser unangemeldet testen muss und da habe ich jetzt Vector 2022. Bah. Auch wenn es von den Verantwortlichen sowieso niemanden interessiert, aber von mir gibt es für diese Aktion einen riesigen Daumen nach unten. /rant --SeptemberWoman 23:57, 1. Apr. 2025 (CEST)

Du sprichst mir aus der Seele. Hab sogar im (engl.) Wiktionary die Mitarbeit eingestellt, nachdem das auch dort gewechselt wurde; kann's auch nicht mehr lesen, als Benutzer ehrlichgesagt, also selbst (gerade) Wiktionary. Da kann ich mir Mühe geben wie ich will, vielleicht schlechte Augen, und Arme, es geht nicht. Und anmelden möcht ich mich nicht (mehr), das ist für mich hier der Stecker. Aber das ist dann auch Demokratie. Viel Spass damit. -2001:9E8:6A8D:4000:D4CB:2035:95C4:B691 00:43, 2. Apr. 2025 (CEST)

@Johannnes89, @Hgzh, @XanonymusX, @TenWhile6, sorry, ihr falllt mir gerade ein, als diejenigen, die ja offenbar einen gewissen Draht zu den Entwicklern haben. Als diese Ankündigung kam habe ich so ziemlich alle Punkte, die hier, bei FzW und auf der HS-Disk bemängelt werden bereits agesprochen. Diese Punkte sind schlecht und ich denke auch, diejenigen, die sagen, sie haben sich aus Bereichen bereits zurückgezogen werden das auch gemacht haben. Die Oberfläche ist nicht "intuitiv" zu benutzen und im Gegensatz zu der Ankündigung oben benötigt es auch nicht einfach nur ein Paar Tage oder Wochen, um sich daran zu gewöhnen. Dass alle zwangsweise umgestellt werden, dürfte ein Fehler gewesen sein. Mich wundert, dass angeblich alle anderen Sprachversionen es einfach nur toll gefunden haben sollen. Wird diese Kritik hier gelesen? Wird sie wie üblich nur als das normale Gemecker der deutschsprachigen abgetan? Wird das alles einfach nur ignoriert? Gruß --Itti 06:55, 2. Apr. 2025 (CEST)

Ganz plastisch (und stellvertretend)

• ich will meine persönlichen Verwaltungslinks (Bearbeiten, Beo etc.) unverpackt
• ich will die Interwikis übersichtlich und unverpackt als horizontale Spalte
• ich kann auf eine Spalte zur Screen-Einstellung gut verzichten - das ist Platzverschwendung und markiert eine Tätigkeit, die allgemein sehr selten genutzt wird.

Das kann gerne erweitert werden. --Koyaanis (Diskussion) 08:23, 2. Apr. 2025 (CEST)

WMF-Mitarbeiter lesen hier mit, denke ich, jedenfalls gab es bereits die ein oder andere Reaktion hier in diesem Abschnitt.

Ich hatte schon mal auf FzW versucht, zu formulieren: jeder Skin basiert auf einer gewissen Grundkonzeption, an der sich nichts entscheidend ändern wird, weil diese Neukonzeption und die dahinterstehenden Prämissen eben die Begründung für das Entwickeln des neuen Skins sind. Hier sind das meiner Meinung nach: die Trennung in rechte und linke Seitenleiste (Begründung: bessere Unterscheidung zwischen Links, die die ganze Website oder eine konkrete Seite betreffen) und ein auf Wunsch immer sichtbares Inhaltsverzeichnis (Begründung: einfachere Navigation in längeren Artikeln). Zudem hat Vector 2022 perspektivisch zumindest die Chance, auch als Skin für Mobilgeräte zu funktionieren, und damit einen Großteil der doppelten Pflege von Desktop- und Mobilversion aufzugeben. Ohne das ist man mehr oder weniger zurück bei Vector 2010, was ja weiterhin angeboten wird.

Die Oberfläche ist nicht "intuitiv" zu benutzen bleibt eine Entscheidung, die jeder für sich treffen kann, man kann es nicht verallgemeinern. Viele mögen zu genau diesem Schluss kommen und für diejenigen stehen Vector 2010 und sogar Monobook weiterhin als gewohntes Arbeitsumfeld bereit. Ich hatte das bei anderer Gelegenheit schon einmal gesagt: diese Wahlmöglichkeit ist im gesamten Internet und selbst eine ziemliche Ausnahme. Welche große Website kann man heute noch mit dem Aussehen von 2004 nutzen? Hier in Dresden ziehen bald 1500 Mitarbeiter der Stadtverwaltung in ein neues Verwaltungsgebäude mit „modernen Arbeitswelten“ - übertragen auf die Wikipedia könnten sie auch „in ihrem alten Büro sitzenbleiben“.

Zur Umstellung selbst: so richtig glücklich bin ich damit auch nicht, das Problem ist aber hier ein anderes: es lässt sich derzeit nicht unterscheiden, wer einfach den Standardskin nutzen will, und wer explizit Vector 2010 ausgewählt hat. Eine Auswahl „immer den Standard“ halte ich für sinnvoll, da muss ich mal auf die Suche gehen, ob das bereits vorgeschlagen wurde. Nachtrag: phab:T22553

Und natürlich waren nicht alle Projekte geschlossen begeistert: in der englischen Wikipedia gab es riesige Diskussionen, in deren Ergebnis übrigens durchaus auch Anpassungen vorgenommen worden sind: der „breite“ Anzeigemodus war so bspw. nicht von vornherein vorgesehen und entstand aus dem Feedback der enwp heraus. Auch die Entwicklung des Darkmode entstand aus einer Community-Initiative heraus. -- hgzh 08:30, 2. Apr. 2025 (CEST)

Danke für die vielen Erklärungen hier! Für die meisten Umstellungen, die hier als problematisch kritisiert wurden – Icons statt Texten, teils zudem versteckt im Dropdown-Menü; fehlendes (nummeriertes) Ausklappen des Inhaltsverzeichnis; Breite der Seite und von Tabellen – gibt es ja mittlerweile Lösungen (eine Vielzahl von dir, auch hier danke!). Tatsächlich finde ich zwar das Mitscrollen der Sprachlinks nützlich, finde die Konfigurierung kompliziert (ja, geht mit Babelboxe) und habe mir schon manchmal die Liste zurückgewünscht – sonst habe ich mich an fast alles mittlerweile gewöhnt. Gibt es dafür ebenfalls ein Tool? Vermutlich schwierig, es an den bisherigen Ort zu bringen, weil dort ja nun das Inhaltsverzeichnis vorgesehen hast. Vielleicht ja tatsächlich als horizontale Zeile, wie von Koyaanis geschrieben, – bspw. im unteren Bildbereich? Oder rechts unter „In anderen Projekten“? --—Martin (WMDE) (Disk.) 12:31, 2. Apr. 2025 (CEST)

Sorry, aber ich finde es nicht richtig, wenn Mängel, die eine neue Oberfläche zeigen, per "privater" Tools und Skripte behoben werden. Die kennt zunächst mal kaum jemand. Die findet dann auch kaum jemand. Wenn die Tool- oder Skripteschreibenden nicht mehr da sind, werden diese nicht angepasst. Das sind Fehler, die wir eigentlich schon viel zu oft gemacht haben und meine Meinung ist, die Oberfläche muss all diese Probleme selbst gelöst bekommen, durch die Programmierer, die auch später dafür "hauptamtlich" verantwortlich sind. Fehler sollte man nicht immer neu machen. Viele Grüße --Itti 12:37, 2. Apr. 2025 (CEST)

Das dauert aber sehr lange. Die Entwicklung von Vector 2022 begann vor über fünf Jahren, und jede Community wird andere Wünsche haben. Es wird nur ein kleinster gemeinsamer Nenner für alle Wikis zentral gepflegt werden. --Viele Grüße, Aschmidt (Diskussion) 13:25, 2. Apr. 2025 (CEST)

Dann sollten sie solche Mängel schneller beheben. Fakt ist, Benutzer, die Skripte geschrieben haben gehen. Siehe Schnark, siehe PDD, siehe Merl, siehe Apper und weitere. Diese funktionieren manchmal noch eine Zeit, oder sie sind direkt weg. Viele wurden nie ersetzt. Wenn hier Mängel aufgezeigt werden, ist es an den Entwicklern, diese abzustellen. Das ist ihr Job, schließlich haben sie ja eine neue Oberfläche entwickelt. Dafür werden sie bezahlt. Es ist nicht an den ehrenamtlichen sich irgendwie zu behelfen um einen Bug auszugleichen. Das hatten wir schon und das hat uns eben nichts als Schwierigkeiten gebracht. --Itti 13:32, 2. Apr. 2025 (CEST)

Die sind eher aus anderen (nämlich dem sozialen Umgang miteinander) Umständen als aufgrund der Software gegangen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 13:38, 2. Apr. 2025 (CEST)

Warum jemand gegangen ist, ist dabei egal. Das Problem stellt sich eben ein, wenn diese Skripte, usw. nicht weiter gepflegt werden. Von ehrenamtlichen kannst du keine Kontinuität verlangen. Das kann nur hauptamtlich geleistet werden und darum geht es. --Itti 13:41, 2. Apr. 2025 (CEST)

Es hat, wie gesagt, fünf Jahre Gelegenheit gegeben, die neue Oberfläche zu testen und Rückmeldung zu geben. Ich habe das gemacht. --Viele Grüße, Aschmidt (Diskussion) 13:45, 2. Apr. 2025 (CEST)

Ich auch. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 13:48, 2. Apr. 2025 (CEST)

Dann waren eure Rückmeldungen offensichtlich aber wenig gut. --Itti 13:54, 2. Apr. 2025 (CEST)

Die meisten wurden erhört und hatten zu Änderungen geführt, einige nicht. Jedenfalls war von Anfang an Klar, dass der neue Skin nicht fürs Software-Repositorium entwickelt wird, sondern dass das die neue Arbeitsumgebung wird. --Viele Grüße, Aschmidt (Diskussion) 14:02, 2. Apr. 2025 (CEST)

Es sind ja eher subjektiv empfundene (= für die eigene Arbeitsweise als hinderlich angesehe) Mängel als tatsächliche Bugs – da die Ansprüche jedes einzelnen verschieden sind, wird es leider niemals möglich sein, allen gerecht zu werden und deshalb gibt es die lokalen Anpassungsoptionen über CSS und JavaScript. So gesehen erlaubt Vector 2022 eigentlich sogar eine individuellere Arbeitsweise, denn in Vector 2010 war es weder möglich, die Seitenleiste oder das Inhaltsverzeichnis auszublenden, noch bei Bedarf auf eine fixierte Textbreite umzustellen, die Schriftgröße anzupassen oder einen Darkmode zu aktivieren. -- hgzh 13:51, 2. Apr. 2025 (CEST)

Dann wäre es eventuell eine Idee gewesen in den Einstellungen die Oberfläche generell flexibel Einstellen zu können, ohne das man mit Skripten arbeiten muss. Will man languagelinks oder die Inhaltsangabe links? Will man quasi das alte Design haben (mit ein paar definierten Boxen links und rechts denen man dann Inhalten zuweist, wäre das wohl machbar gewesen). Wollte man nicht, man wollte von Seiten der Designer bzw. deren Vorgaben die sie erhalten haben einen Weg hin zu mehr lesen weniger Arbeiten. Es ist halt auf Konsum gedrillt worden, weniger auf Produktivität (wie eben schon bei der Mobilversion). Man hätte viel mehr können wenn man wollte, aber das war nicht das Ziel dieser Umstellung (und ja, ich war bei den gesprächsangeboten der Designer und hatte das mit denen diskutiert).--Maphry (Diskussion) 14:16, 2. Apr. 2025 (CEST)

Das ist nicht richtig. Es wurden jahrelange Tests gemacht, in denen es auch darum ging, bei welchem Webdesign, welcher Platzierung der Elemente usw. sich Autoren beim Editieren leichter tun, was dazu führt, dass weniger oder mehr editiert wird, aufgegliedert nach erfahrenen und neuen Autoren usw. Was wir heute vorfinden, hat mit Vector 2022, wie er ganz zu Anfang war, nur noch im Grundsatz etwas zu tun. Es wurde sehr viel verändert und ausprobiert. Und das war auch für mich sehr interessant, denn ich hatte die neue Oberfläche die ganze Zeit hinweg aktiviert und habe deshalb ständig Neuerungen testen können. --Viele Grüße, Aschmidt (Diskussion) 14:21, 2. Apr. 2025 (CEST)

Na ja, die Oberfläche ist schon deutlich flexibler:

• Hauptmenü: ausblendbar, wenn nicht benötigt. In Vector 2010 immer angezeigt.
• Inhaltsverzeichnis: ausblendbar, wenn nicht benötigt, von jeder Scrollposition aus abrufbar. In Vector 2010 immer am Artikelanfang und schnell nicht mehr im Blickfeld.
• Werkzeugleiste: ausblendbar, wenn nicht benötigt, ausgeklappt von jeder Scrollposition aus abrufbar. In Vector 2010 immer links und bie langen Artikeln irgendwann nicht mehr im Blickfeld.
• Seitenbreite: vollbreit oder mit Maximalbreite, bei Ausblenden der Seitenleisten maximaler Raum für Text möglich, in Vector 2010 immer vollbreit.
• Schriftgröße: dreistufig einstellbar, in Vector 2010 fixiert.
• Anzeigemodus: hell/dunkel, in Vector 2010 nur hell.

-- hgzh 07:59, 3. Apr. 2025 (CEST)

> braucht zig mehr Klicks und muss viel mehr scrollen
Eigentlich muss man viel weniger scrollen, weil die Sprachlinks immer oben rechts mitlaufen. Rechts in der Seitenleiste laufen die Werkzeuge und die Links zu anderen Projekten mit (das muss man allerdings erst freischalten) und links das Inhaltsverzeichnis. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:21, 2. Apr. 2025 (CEST)

Aber gerade die Sprachlinks sind ein Riesenproblem. Die "vorgeschlagenen Sprachen" sind untauglich. Es wird ganz schlicht das Angebot einer vollständigen, alfabetisch geordneten Liste benötigt, die schnell zu erreichen ist. Aber egal, ich bleibe eh bei Monobook. --Mautpreller (Diskussion) 14:08, 2. Apr. 2025 (CEST)

Ich habe seit mal probeweise auf Vector 2022 umgestellt. einiges kann man individuell einstellen, das finde ich gut. Kann man die Sprachlinks alphabetisch sortieren? Und zwar nach dem lateinischen Alphabet? Zurzeit sehe ich zuerst Arabisch, dann Persisch, dann Chinesich und Japanisch, dann kyrillische und erst am Schluss Sprachen mit Lateinschriften. Ich möchte die Sprachen aber nicht nach Schriftarten sortiert, sondern so, dass ich sie finde: Arabisch unter ar, Persisch unter fa, Chinesisch unter zh usw. -- Perrak (Disk) 14:14, 2. Apr. 2025 (CEST)

Also wenn ich im Vector 2022 bis hier ans Seitenende scrolle, um dir zu antworten Mautpreller, wird mir durchgehend oben im Header die Option angeboten, diese Seite in 263 weitern Sprachen aufzurufen. Wenn ich im Vector 2010 bis hier ans Seitenende scrolle, ist die Leiste links schon nach kurzem scrollen außer Sichtweite. Schneller zu erreichen ist die Sprachauswahl für mich also im Vector 2022.

Alphabetisch sortiert sind die 263 Sprachen bei mir auch im Vector 2010 nicht (bis auf die ersten 9 Vorschläge). Wenn ich im Vector 2010 auf „254 weitere“ klicke erhalte ich eine durchsuchbare Liste (die ich auch vollständig durchscrollen kann), die unterhalb der Vorschläge (die meines Erachtens angemeldet darauf basieren, welche WP-Sprachversionen ich zuletzt besucht hab) nach Weltregionen sortiert ist. Innerhalb dieser Regionen sind alle Sprachen alphabetisch sortiert – exakt so ist es auch im Vector 2022. Die Suchfunktion funktioniert übrigens auch mit Sprachcodes @Perrak, du kannst also sowohl „fa“ als auch „Persisch“ eingeben und dir wird die gewünschte Sprache vorgeschlagen. --Johannnes89 (Diskussion) 14:23, 2. Apr. 2025 (CEST)

Alles richtig. Die Idee bei der Sortierung der Interwikilinks ist wohl, dass die Sprachauswahl in allen Sprachversionen dieselbe ist, so dass man sich leichter zurecht findet, wenn man hin und her wechselt. Mir wäre hier aber auch eine Personalisierung lieber, also eine Option in den Einstellungen, in der ich vorgeben kann, welche Sprachversionen ganz oben stehen sollten. Und hier könnte man dann auch eine alphabetische Sortierung oder eine nach den Vorlieben der jeweiligen Community vorsehen. Machbar wäre das wohl. --Viele Grüße, Aschmidt (Diskussion) 14:30, 2. Apr. 2025 (CEST)

Nachteilig wäre freilich, dass der Vorteil der universellen Oberfläche dann sehr schnell wieder verloren ginge. Ich bin mir unsicher, welche Lösung besser wäre. Habe mich mittlerweile an die Sortierung gewöhnt … --Viele Grüße, Aschmidt (Diskussion) 14:34, 2. Apr. 2025 (CEST)

Das mit den Weltregionen ist aber eben Mist. Das habe ich schon kritisiert, als es eingeführt wurde (ich weiß nicht mehr, wie das hieß, irgendwas mit Universal Langage Generator oder so ähnlich). Damit hat man massenhaft Dopplungen (Englisch gibts natürlich überall) und es ist keineswegs unmittelbar klar, wo man suchen will. Es fehlte bereits in der alten Vector-Version das Angebot einer ganz einfachen alfabetisch geordneten, vollständigen Liste ohne "Weltregionen" und "Vorgeschlagene Sprachen"-Schnickschnack, die man schlicht so nutzen kann, wie man will. Alle Varianten, die dies nicht bieten, sind für mich unbrauchbar. --Mautpreller (Diskussion) 14:34, 2. Apr. 2025 (CEST)

Es ist übrigens ganz offensichtlich nicht so, dass die vorgeschlagenen Sprachen den zuletzt besuchten Wikipedia-Sprachversionen entsprechen. Da müsste für mich mindestens Schwedisch dabei sein, stattdessen find ich da Türkisch. Aber das ist mir eigentlich auch egal. Ich will wissen, in welchen (evtl. auch exotischen) Sprachen ein Artikel existiert, weil es mich interessiert (unter anderem wegen der Übersetzungen). "Weltregionen" oder sonstige Vorgaben interessieren mich nicht und ich will dort auch nicht auf die Suche gehen. Monobook bietet mir eine Antwort, Vector in gleich welcher Version aber nicht. Das muss auch nicht default sein, ein simpler Knopf "vollständige Liste" würde völlig genügen. --Mautpreller (Diskussion) 14:57, 2. Apr. 2025 (CEST)

Ich schau mal, was ich machen kann. Gruß, -- hgzh 15:01, 2. Apr. 2025 (CEST)

Schritt 1: Benutzer:Hgzh/css#ulsCompact – blendet die vorgeschlagenen Sprachen aus und stellt alle Sprachen in den jeweiligen Kategorien untereinander dar (noch keine Sortierung o.Ä.). -- hgzh 15:22, 2. Apr. 2025 (CEST)

Ich will weder eine bestimmte Sprache suchen noch eine Sortierung nach Weltregionen - die ist höchstens was für Leute, die die WP nir sporadisch nutzen und nicht wissen, welche Sprachen es gibt. Unter Monobook habe ich eine Liste, die nach den Kürzeln der Sprachprojekte sortiert ist, eine solche Sortierung hätte ich hier auch gerne. Die alphabetische Sortierung ist momentan nicht korrekt, sondern sortiert vermutlich nach Unicode, das heißt, nach Schriftarten. Ich möchte Russisch nicht am Anfang, sondern nach Rumänisch und vor Schwedisch haben.

Solange das in Monobook korrekt ist, kann ich natürlich jeweils umstellen, aber komfortabel ist das nicht. -- Perrak (Disk) 15:05, 2. Apr. 2025 (CEST)

Hmm nutzt ihr dafür irgendein Skript? Ausgeloggt in verschiedenen Skins getestet ist das mit den Sprachen bei mir identisch bei Vector 2010 und Monobook und (bis auf die Positionierung oben + die ersten paar Vorschläge) auch identisch im Vector 2022, inkl. Sortierung nach Weltregionen und erst innerhalb der Regionen alphabetisch.

Persönlich find ich es ja ganz praktisch, wenn ich neugierig durch alle verschiedene Sprachen scrolle, sie geographisch halbwegs zuordnen zu können, falls sie mir unbekannt sind. --Johannnes89 (Diskussion) 15:21, 2. Apr. 2025 (CEST)

Das ist eine Einstellung, siehe Spezial:Einstellungen#mw-prefsection-rendering ganz unten bei „Sprachen“. -- hgzh 15:25, 2. Apr. 2025 (CEST)

Ahh danke, kann mich nicht dran erinnern, das je anders gesehen zu haben, das erklärt, warum ich in der Hinsicht keinen nennenswerten Unterschied zu den älteren Skins wahrgenommen hab. mw:Universal Language Selector/Compact Language Links für interessierte, auch bzgl. der Auswahlkriterien für die Sprachvorschläge. --Johannnes89 (Diskussion) 15:35, 2. Apr. 2025 (CEST)

Es geht hier um den "Universal Language Selector", vgl. https://www.mediawiki.org/wiki/Talk:Universal_Language_Selector/Compact_Language_Links/2017 und Wikipedia Diskussion:Kurier/Archiv/2017/10#Interwikilinks werden zukünftig anders angezeigt. Die vollständige Liste erhält man (unter Monobook), wenn man unter Einstellungen/Aussehen/Sprachen das Häkchen bei "Eine kompakte Sprachliste mit für Dich relevanten Sprachen verwenden" rausnimmt. Leider funktioniert das unter Vector 2022 nicht (im alten vector aber schon). --Mautpreller (Diskussion) 15:50, 2. Apr. 2025 (CEST)

Nochmal ganz simpel: Wenn ich einen Artikel anklicke, will ich nicht nur wissen, in wie vielen Sprachen es den gibt, sondern vor allem, in welchen. Ich möchte sehen, wieso es einen Artikel in Aserbaidschanisch gibt, den ich dort nie vermutet hätte, und checken, ob das wahrscheinlich schlicht per Übersetzungstool geklaut ist. Dabei interessieren mich ALLE Sprachen. Ich käme gar nicht auf die Idee, eine bestimmte Weltregion oder Sprache zu (durch)suchen, weil ich gar noch nicht weiß, welche Sprache vielleicht interessant wäre. Vielleicht hab ich von der noch nichtmal gehört. Ich will nichts anderes als eine "plain list" alfabetisch. Wenn das nicht default ist, ist es nicht tragisch, aber die muss ohne Tricks leicht zugänglich sein. --Mautpreller (Diskussion) 16:09, 2. Apr. 2025 (CEST)

Geht mir so ähnlich. Da ich die meisten Sprachen, in denen es WP-Versionen gibt, zumindest dem Namen nach kenne, ist die Listung nach Kontinenten für mich eher störend als hilfreich. -- Perrak (Disk) 16:50, 2. Apr. 2025 (CEST)

So, bitteschön: Benutzer:Hgzh/js/vectorLanglinkSidebar – zeigt eine Sprachliste in der rechten Werkzeugleiste an, sortierbar nach verschiedenen Kriterien. Gruß, -- hgzh 22:36, 2. Apr. 2025 (CEST)

Ich probiers aus. Danke! --Mautpreller (Diskussion) 00:10, 3. Apr. 2025 (CEST)

Ich finde es super - danke dir sehr dafür. --Ichigonokonoha (Diskussion) 11:35, 3. Apr. 2025 (CEST)

Ich bin mit dem neuen Layout auch nicht wirklich zufrieden. Mein Problem mit der Nichtanzeige des Inhaltsverzeichnisses habe ich zwar inzwischen gelöst und das lag zumindest teilweise auch an der von mir verwendeten Software. Ich habe allerdings in der deutschsprachigen Wikipedia noch weitere Probleme, die mir vorher bereits die Nutzung der englischsprachigen Wikipedia verleidet haben, und die grundsätzlich leider immer mehr im WWW anzutreffen sind, insbesondere auf kommerziellen Seiten. Insgesamt ist die Navigation mit der Tastatur in Wikipedia schwieriger geworden (ich benutze Firefox mit Vimium). Bisher festgestellte Probleme sind:

• Die Elemente in der Seitenleiste stellen eigene Bereiche dar, die z.B. separat gescrollt werden müssen. Das erfordert einen expliziten Wechsel zwischen den einzelnen Bereichen und somit mehr Tastendrücke.
• Umgeht man das erste Problem, indem man die Elemente einklappt, können diese anders als z.B. die Artikelseite, die Diskussionsseite, die Versionsgeschichte etc. nicht direkt per Tastenkürzel angesteuert werden. Nicht alle Unterpunkte haben jedoch ihre eigenen Kürzel, insbesondere natürlich beim Inhaltsverzeichnis. Das Problem besteht auch weiterhin bei der Sprachauswahl.
• Auch das Schließen der Elemente erfordert einige Tastendrücke. Ich bin kein Programmierer, aber ginge das nicht auch einfach per Escape?

Wenn mir noch mehr auffällt, werde ich die Liste ergänzen. --2001:9E8:5934:7000:41B5:8195:F256:AEFA 16:57, 2. Apr. 2025 (CEST)

Gerade die Steuerung über die Tastatur wurde in Vector 2022 erheblich verbessert. Zweimal TAB drücken, und der Cursor wird im Suchfeld platziert. Es wurde sehr viel für Barrierefreiheit getan. --Viele Grüße, Aschmidt (Diskussion) 19:20, 2. Apr. 2025 (CEST)

Danke für Deine Antwort. Das hilft mir aber nicht. Die Änderung bzgl. Suchfeld ist natürlich zu begrüßen, ich profitiere davon aber gar nicht, da ich ohnehin über die Schlüsselwortsuche meines Browsers in der Wikipedia suche. Für mich persönlich ist diese Änderung also weder eine Verbesserung noch eine Verschlechterung. Die beschriebenen Probleme machen die Navigation ohne Maus in der Wikipedia dagegen deutlich schwerer und sollten zügig gelöst werden. Wenn ich nicht bereits existierende Lösungen übersehe, aber dann sollten diese auch entsprechend kommuniziert werden. Lieben Gruß --2001:9E8:5934:7000:5C2E:56CD:55B1:EE1B 19:59, 2. Apr. 2025 (CEST)

Verstehe. Aber du wirst sicherlich auch einräumen, dass die Art, wie du deinen Firefox steuerst, nur von sehr wenigen so gehandhabt wird. Und ich bin immerhin Netscape-/Firefox-/Thunderbird-User seit Netscape Gold.   --Viele Grüße, Aschmidt (Diskussion) 20:33, 2. Apr. 2025 (CEST)

Ist es so Retro, wenn man noch auf seine kabellose Maus vertraut ? :-) --Koyaanis (Diskussion) 20:43, 2. Apr. 2025 (CEST)

Die Mehrheit der Leute kann ja auch mit der Maus navigieren. Aber sollte man sich immer nach der Mehrheit richten, danach womit man bei der Masse die beste Rückmeldung bekommt, wenn dabei bereits marginalisierte Menschen weiter marginalisiert werden? Von kommerziellen Anbietern kennt man das und es ergibt leider auch Sinn. Aber von Anbietern wie Wikimedia finde ich, sollte man anderes erwarten können. Seit das Layout bei der englischen Wikipedia eingeführt wurde, habe ich diese kaum noch benutzt. Aber auf jegliche Sprachversion kann ich dann doch nicht verzichten. Wo sind eigentlich die ganzen Wikipedia-Klone hin, mit denen man früher überschwemmt wurde? Das wäre für eine Übergangszeit ja noch eine Alternative. Längerfristig muss Wikimedia hier aber reagieren. Lieben Gruß --2001:9E8:5934:7000:5C2E:56CD:55B1:EE1B 20:56, 2. Apr. 2025 (CEST)

Unabhängig von der aktuellen Diskussion zu den "Mängeln" mal eine Frage zum Einführungsprozess. Wie war der angedacht? 5 (?) Jahre entwickeln und dann ausrollen? Klar kommen jetzt überall "Meckerer", die vorher kein Wort zur Entwicklung gesagt haben, obwohl sie die Möglichkeit gehabt hätten (?). Aber eigentlich ist doch sehr gut, was gerade passiert. Die Leute testen es und es gibt Feedback. Hätte ich das früher schon tun können, wenn ich irgendein Beta-Dingens angeklickt hätte? Egal. Man wird "Später-Meckerer" wie mich schwierig mit Vorab-Irgendwas erreichen. Warum aber das, was gerade passiert, nicht prozessual nutzen? Man könnte entwickeln, zeitlich begrenzt einführen (ja, auch das würde für Verstimmungen sorgen), Feedback sammeln, zurückschalten, noch eine Entwicklungsrunde drehen und frühestens dann scharf schalten.--Scientia potentia est [Dermartinrockt] (Diskussion) 20:45, 2. Apr. 2025 (CEST)

Es gab kleine, mittlgroße und große Testwikis, jahrelange A/B-Tests, Studien, Befragungen, Auswertungen. Dann die Verfügbarkeit als Beta-Feature zum Selbst-Einschalten. Mehr kannst du auf mw:Reading/Web/Desktop Improvements nachvollziehen. Alles begann im Mai 2019. --Viele Grüße, Aschmidt (Diskussion) 21:02, 2. Apr. 2025 (CEST)

Und dann das Aktivieren des finalen Skins in zahlreichen Sprachversionen. Anschließend wurde der finale Skin (vor allem anhand von Feedback aus en) mehrmals weiter verbessert. Wir erhielten zusammen mit den Russen (und wenigen anderen) als die Letzten ein ausgereiftes Produkt (auch hier wurde bereits Wochen vorher die Umstellung angekündigt). Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 00:06, 3. Apr. 2025 (CEST)

Was du als "finalen Skin" bezeichnest, ist aber tatsächlich noch im Umbau begriffen:

• Gestern blieb das Inhaltsverzeichnis, wenn man es angeklickt hatte, dauerhaft als linke Spalte stehen, auch in der "breit" Version. Man konnte wahlweise das Fenster zu 100% für den Artikel nutzen, oder sich links dauerhaft das Inhaltsverzeichnis anzeigen lassen, die rechte Spalte aber mittels "breit"-Einstellung aber ausgeblendet lassen.

Das war brauchbar, aber jetzt wird dasInhaltsverzeichnis nur als pop-up Fenster anegzeigt und verdeckt dann einen teil des Hauptfensters.

• in der französischen WP enthält die rechte Seitenspalte, wenn auch leider weit unten routinemäßig den Commons Link, und zwar grafisch hervorgehoben. In der deutschen WP zeigt die Standard-Oberfläche derzeit zwei leere Seitenspalten – verschwendete Bildschirmfläche.--Ulamm (Kontakt) 00:50, 3. Apr. 2025 (CEST)

  > Gestern blieb das Inhaltsverzeichnis, wenn man es angeklickt hatte, dauerhaft als linke Spalte stehen, auch in der "breit" Version. Man konnte wahlweise das Fenster zu 100% für den Artikel nutzen, oder sich links dauerhaft das Inhaltsverzeichnis anzeigen lassen, die rechte Spalte aber mittels "breit"-Einstellung aber ausgeblendet lassen.
  Das liegt daran, dass du das Ding irgendwann ausgeblendet hast. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:31, 3. Apr. 2025 (CEST)

Das dauerhafte Anzeigen des Inhaltsverzeichnisses links ist auch weiterhin möglich. Im Popup müsste es einen Knopf „In die Seitenleiste verschieben“ geben, der das Inhaltsverzeichnis wieder links fixiert. Erscheint dieser nicht, nutzt du mglw. eine recht schmale Anzeigebreite, dann ist es in der Tat aus Platzgründen stets eingeklappt.

Die Bildchen bei den Schwesterprojektlinks sind eine Eigenentwicklung der französischen Kollegen, ich finde das auch recht charmant. Gruß, -- hgzh 07:31, 3. Apr. 2025 (CEST)

Letzteres jetzt mit Benutzer:Hgzh/css#vectorSisterprojectIcons auch hier verfügbar. -- hgzh 08:41, 3. Apr. 2025 (CEST)

+1. frwiki hat noch weitere schöne Features. Umfangreiche Fußnotenapparate werden dort nicht mehrspaltig ausgegeben, sondern über einen Scrollbalken begrenzt. Darüber könnten wir auch mal nachdenken. – Übrigens Danke für deine Mühe! Ich könnte mir vorstellen, dass wir deine Anpassungen später in ein Helferlein schön verpacken könnten. --Viele Grüße, Aschmidt (Diskussion) 10:17, 3. Apr. 2025 (CEST)

Das "neue" Design is totaler MIST und ich war sehr erfreut das die DE Wiki den Mist so lange nicht verwendet hat - AUS GRüNDEN!!! Warum man jetzt doch noch den Murks mitmachen muss is mir schleierhaft. Eine massive Verschlechterung. Ich möchte noch ergänzen das ich A stolz auf euch bin. Quasi ALLE Kommentare sind RICHTIGERWEISE ANTI!!! B Warum mans dan TROTZDEM zwangsweise einführt versteh wer will.. wieder äusserst unschön in der ach so demokratischen WP --217.162.58.72 23:08, 3. Apr. 2025 (CEST)

Es ist schlichtweg nicht praktikabel, zwei verschiedene Oberflächen für Leser gleichzeitig zu betreiben, deshalb war von vornherein klar, dass die Umstellung früher oder später kommt.

Die Abfolge war außerdem umgekehrt: zunächst wurde umgestellt, danach wurde die Änderung ablehnend besprochen. -- hgzh 12:45, 4. Apr. 2025 (CEST)

Letzteres stimmt nicht: [19]. -- Chaddy · D 19:06, 4. Apr. 2025 (CEST)

Ich glaube, das größere Problem dürfte nicht sein, ob das Ei oder das Huhn zuerst kam, sondern dass die ganze Diskutiererei um den Skin nicht konstruktiv ist. Jede/n stört etwas anderes, aber niemand möchte an der Verbesserung des neuen Skins wirklich aktiv mitarbeiten. So kann das nichts werden. Es sollte klar werden, dass der Weg nach vielen Jahren Entwicklung, bei der enorme Anstrengungen unternommen wurden, die Comminities einzubeziehen, nun aber auch mal abgeschlossen ist. Der Rest kann in kleineren Projekten, communitybezogen und persönlich noch getuned werden. Aber Vector 2022 ist gekommen, um zu bleiben. Und zwar länger zu bleiben als die älteren, die heute schon obsolet geworden sind. Ich schreibe das übrigens aus einer Haltung heraus, die Änderungen gegenüber vielleicht ganz besonders sensibel gestimmt ist. Gerade deshalb hatte ich die Einführung verfolgt und aktiv begleitet, um mich möglichst langfristig auf den neuen Skin einstellen zu können. So hatte ich sehr viel Zeit, um mich und meine Workflows einzuüben, meine Userskripte anzupassen und dergleichen. Ich sehe aber auch, dass Softwaremuseen heutzutage aus technischen Gründen nicht mehr gehen. Mit meinem alten System, das ich auf dem Jahr 2014 stehen gelassen hatte, kann ich heute Wikipedia schlicht nicht mehr bearbeiten. Die Welt dreht sich weiter. --Viele Grüße, Aschmidt (Diskussion) 20:53, 4. Apr. 2025 (CEST)

An der alten Umfrage haben einige Leute teilgenommen, manche Kritikpunkte wurden beachtet. Warum die Interwikilinks versteckt werden und so leserunfreundlich wie möglich sortiert werden erschließt sich mir nach wie vor nicht.

An "der Verbesserung des neuen Skins wirklich aktiv mitarbeiten" würden vermutlich einige, aber die Möglichkeit hat man als Freizeit-Wikipedianer nicht wirklich. Bzw. wie soll man das machen, außer dass man mitteilt, was einem an weniger gut Gelungenem auffällt? -- Perrak (Disk) 21:35, 4. Apr. 2025 (CEST)

Es ist ja nicht so, als gäbe es keine FAQ oder Design-Dokumentation, in der neben zahlreichen anderen auch diese Frage beantwortet ist. --Discostu (Disk) 21:46, 4. Apr. 2025 (CEST)

Da ist was dran. Ich kann dir aber versichern, dass sie über viele Jahre hinweg soviel ausprobiert hatten, es gab so viele Studien, dass das, was wir heute vorfinden, tatsächlich eine optimierte Lösung ist. Das alles ist weder zufällig noch abwegig. Was das Menü für die Interwikilinks angeht, bin ich absolut deiner Meinung. Ich hatte mich damit arrangiert, als ich bemerkt hatte, dass das Menü in allen Sprachversionen gleich ist, so dass ich mich zurecht finde. Außerdem kann man es durchsuchen. Mir wäre es auch lieber, wenn ich die ersten Links personalisieren könnte. – Bräuchten wir ein WikiProjekt, um den Skin zu verbessern? (BK) --Viele Grüße, Aschmidt (Diskussion) 21:46, 4. Apr. 2025 (CEST)

In der FAQ steht nichts davon, warum die Interwikilinks nicht mehr alphabetisch nach Sprachkürzeln sortiert sind, sondern anscheinend nach Schriftarten. Wem soll das nützen? Das ist einfach Unfug. Dass man nach einer Sprache suchen kann, mag ja für manche Benutzer nützlich sein, aber besser wäre es, wenn man einstellen könnte, welche zwei oder drei Sprachen man bevorzugt angezeigt bekommen möchte - das würde fast jedem Leser helfen, der mehr als eine Sprache lesen kann. Die Sortierung nach Kontinenten hingegen -was soll das? Ich kann kein Ungarisch, auch wenn ich in Europa lebe. Und den meisten Japanern wird der Link auf Tagalog ebensowenig helfen. -- Perrak (Disk) 22:25, 4. Apr. 2025 (CEST)

Das ist einfach die Oberfläche, die sie für die Sprachauswahl allgemein entwickelt hatten. Das Modul wurde wiedeverwendet. Wie schon gesagt, ich hätte hier auch lieber eine Personalisierung. Die einzige fertige Lösung dafür gibt es derzeit auf Wikidata und bezieht sich auf die Babel-Bausteine auf der Benutzerseite. Müsste also neu entwickelt werden.

Wie könnten wir solche Anregungen sammeln, priorisieren und am Ende umsetzen? --Viele Grüße, Aschmidt (Diskussion) 22:39, 4. Apr. 2025 (CEST)

Das ist mir schon klar. Ich verszehe nur nicht, wie man auf die Idee kommen kann, das wäre nützlich ;-)

Man könnte zum Beispiel eine Unterseite von Wikipedia:Projektdiskussion anlegen, um Vorschläge zu diskutieren und zu sammeln. -- Perrak (Disk) 22:54, 4. Apr. 2025 (CEST)

Das war ganz zum Schluss Anfang 2022 passiert und setzte zuerst voraus, dass die compact language list in den Beta-Einstellungen aktiviert war. Ich vermute, da haben sie gespart, um fertig zu werden, und da sich das Finish in der englischen Sprachversion abspielte, hat es niemand interessiert, weil EN kaum Interesse an den Interwikilinks hat. FR wohl auch nicht wirklich. Das sind Sprachen, die sehr bei sich bleiben. DE kam als Testwiki nicht in Betracht, weil wir schon immer alles abgelehnt und blockiert hatten, das ist nicht zielführend, wenn man vorankommen will. Damit navigiert man sich ins Absseits.

Ich bin mir noch nicht sicher, wie man die weitere Entwicklung betreiben könnte. Es wird einen toten Punkt geben, und dann geht erfahrungsgemäß gar nichts mehr. Ich wäre für einen hauptamtlichen Projektmanager bei WMDE, ähnlich wie die Technischen Wünsche, der immer wieder antreibt, Meilensteine definiert und überwacht, kommuniziert, informiert, zusammenfasse und der auch direkte Kontakte zur WMF hat und dafür sorgen kann, dass dabei auch technisch wirklich etwas herauskommen kann. WMDE hat auch eine eigene Abteilung für die Softwareentwicklung und viel Ahnung von MediaWiki. Das spräche dafür, die Leitung nicht beim Ehrenamt zu platzieren. --Viele Grüße, Aschmidt (Diskussion) 23:11, 4. Apr. 2025 (CEST)

Die Erklärung leuchtet ein, ja.

Die Leitung jemand vom Verein zu überlassen ist eine gute Idee. Als Ehrenamtlicher kann einem immer etwas dazwischen kommen, ein(e) Hauptamtliche(r) sollte im zweifel Vertreter haben, wenn sie bzw. er mal ausfällt. -- Perrak (Disk) 23:48, 4. Apr. 2025 (CEST)

Da das Interwiki-Modul unabhängig von Vektor 2022 entwickelt wurde, hat es eine eigene FAQ, in der auch die Sortierung begründet wird. --Discostu (Disk) 06:19, 5. Apr. 2025 (CEST)

Danke für den Link.

Wenn man eine FAQ-Seite aufstellt, sollte man versuchen, alle Fragen dort zu beantworten. -- Perrak (Disk) 12:13, 5. Apr. 2025 (CEST)

Tut man ja. Das ist ja aber eine Frage, die das (auch im alten Vector eingebundene) Sprachmodul betrifft. Da ist also das Vector-2022 FAQ einfach der falsche Ort zu suchen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:47, 5. Apr. 2025 (CEST)

Außerdem ist das Projekt abgeschlossen. Es bräuchte ein neues, um etwas Grundlegendes zu ändern. --Viele Grüße, Aschmidt (Diskussion) 13:13, 5. Apr. 2025 (CEST)

Interessant ist, dass Details im Quelltext der aufgerufenen Seite Einfluss darauf haben, welche Sprachen vorgeschlagen werden. Abgesehen davon ist für mich, auch nach dem Studium von [20] und der dort verlinkten weiterführenden Erläuterungen, inklusive dieser Tabelle auf Unicode.org, nicht nachvollziehbar, wie bei mir die Auswahl dieser "vorgeschlagenen Sprachen" im Detail zustande kommt. Der Algorithmus ist offenbar so sophisticated, dass er teilweise abstruse Resultate zeitigt - in meinem Fall zum Beispiel Arpitan, obwohl ich weder in dessen Verbreitungsgebiet lebe noch mein Rechner oder ich einen sonstigen Bezug dazu hätten. Gruß, --Yen Zotto (Diskussion) 17:26, 5. Apr. 2025 (CEST)

Mir ging es um die Diskussion hier auf dieser Seite, jedenfalls den Großteil davon. -- hgzh 08:49, 7. Apr. 2025 (CEST)

Leider keine Verbesserung

Die neue Oberfläche ist leider keine Verbesserung, sondern ein klarer Rückschritt! MEHR Übersichtlichkeit beitet die akt. Darstellung jedenfalls nicht - was ja das Hauptziel sein sollte.

Im Übrigen ändert man Schnittstellen nicht unnötig, und das betrifft auch Grafische Schnittstellen für die Nutzerinteraktion. Ich kann jedenfalls keine Notwendigkeit für eine derart - zudem massive - Änderung erkennen.

Sorry, aber das Umstellen war ein Griff ins Klo!

--45.148.53.5 11:03, 4. Apr. 2025 (CEST)

Die Bewertung, ob die Änderung unnötig wäre, hängt zu einem signifikanten Teil auch von subjektiven Standpunkten ab. Jedenfalls erfolgte der Wechsel nicht unbegründet, siehe mw:Reading/Web/Desktop_Improvements?uselang=de#What_was_our_objective? (auf Englisch). Ob sich daraus in ausreichendem Maß eine Notwendigkeit begründet, mag jeder unterschiedlich einschätzen.

Darüber hinaus wäre hilfreich, zu erfahren, was die Übersicht mindert. Mglw. lässt sich ja daran arbeiten. -- hgzh 12:42, 4. Apr. 2025 (CEST)

Stimmt, die Einschätzung ist subjektiv.

ABER das gilt genauso für die Axiome (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements#What_was_our_objective?) und der angeblichen Änderungsnotwendigkeit daraus:

didn't match the expectations. …was cluttered and not intuitive. …didn't highlight the community side. …wasn't consistent with the mobile version.

Woher kommen diese Behauptungen denn und wie sind sie unterlegt? Und falls, wo sind die Parameter und Ergebnisse??

--45.148.53.5 14:23, 4. Apr. 2025 (CEST)

P.s.: schade, dass es keine Gegenüberstellung des neuen Designs zu dieser Darstellung gibt: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/de#/media/File:Annotated_Wikipedia_Vector_interface_(logged-out).png

Ich sehe da zumindest auf den ersten Blick keine klarere Strukturierung des neuen "Skins"!

--45.148.53.5 14:26, 4. Apr. 2025 (CEST)

siehe die Schema-Skizzen hier: Hilfe:Skin/Vector 2022#Unterschiede alter/neuer Vector --0815 User 4711 (Diskussion) 14:42, 4. Apr. 2025 (CEST)

Supi, Danke!

Aber da sieht man doch deutlich, dass das nicht übersichtlich ist. Warum wurde das also dennoch eingeführt???

:-/

--45.148.52.5 14:54, 4. Apr. 2025 (CEST)

> nicht übersichtlich
Ist wohl eindeutig Ansichtssache. Ich finde es nicht unübersichtlicher, wenn nicht sogar ein kleines bisschen übersichtlicher. Vor allem erspart es aber unnötiges Scrollen, weil alle Menüs dauerhaft mitlaufen. Und das war die wichtigste Prämisse des Skins. Zusätzlich sollte es responsiv werden, sodass der klassische Skin besser auf mobilen Geräten bedienbar ist und auch uneingeloggte Nutzer sollten mehr Anpassungsmöglichkeiten haben (was sie haben). Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:58, 4. Apr. 2025 (CEST)

Ich habe mir jetzt nicht alles durchgelesen, aber mglw. wirst du hier fündig: mw:Reading/Web/Desktop_Improvements/Repository/Research_and_design:_Phase_1 bzw. bei den Links unter mw:Reading/Web/Desktop_Improvements/Repository#Other_documentation. Gruß, -- hgzh 08:52, 7. Apr. 2025 (CEST)

Hinweis: Wikipedia:Umfragen/Wie findet ihr das neue Design?

Benutzer:Lothaeus hat gestern die oben genannte Umfrage gestartet. Ich wollte hier nur mal darauf verweisen, vielleicht möchte sich ja jemand beteiligen. --slg (Diskussion) 15:51, 4. Apr. 2025 (CEST)

Die Umfrage verläuft sehr eindeutig. Das neue Design findet wie erwartet keinen großen Anklang. Dieses Feedback sollte auch den Entwickler*innen zukommen, so dass sie zumindest mal dazu angeregt werden, darüber nachzudenken, die Kritikpunkte zu beheben. -- Chaddy · D 17:54, 7. Apr. 2025 (CEST)

Die Umfrage ist aber kaum aussagekräftig, da sie nicht repräsentativ für die Benutzer oder die Leser ist. --Viele Grüße, Aschmidt (Diskussion) 17:57, 7. Apr. 2025 (CEST)

Dann wäre allerdings auch keines unserer MBs aussagekräftig (und durch die legen wir immerhin unsere Richtlinien fest). -- Chaddy · D 18:20, 7. Apr. 2025 (CEST)

Das ist etwas ganz anderes. Die allermeisten, die sich hier beteiligt haben, haben das genutzt, um ein Monitum oder einen Verbesserungsvorschlag zu hinterlassen, weil sie keines anderen Kanals gewahr sind. Wer zufrieden ist, arbeitet einfach weiter und freut sich über den neuen Skin und wird keinen Grund haben, sich zu beteiligen. --Viele Grüße, Aschmidt (Diskussion) 18:29, 7. Apr. 2025 (CEST)

Unvollständige Interwiki-Liste auf der Hauptseite

Auf der WP:Hauptseite erscheinen Links nur auf 51 der anderen Sprachversionen, obwohl es natürlich viel mehr gibt. Das ist mit Vector 2010 und Vector 2022 gleichermaßen so. Der Unterschied ist aber, dass die übrigen Sprachen mit Vector 2010 auffindbar sind, weil unter der letzten aufgelisteten Sprache ein Link "Alle Sprachen" erscheint, der auf Wikipedia:Sprachen führt. Zwar muss man dort dann etwas suchen, bis man die Links zu den anderssprachigen Hauptseiten findet, aber immerhin: sie sind da. Mit Vector 2022 scheint es aber einen solchen Link nicht zu geben. Noch schlimmer: wenn man in dem Sprach-Suchfeld die gesuchte Sprache eingibt, sagen wir mal "Okzitanisch", dann bekomment man die Auskunft: „Diese Seite ist nicht in der gewünschten Sprache verfügbar“. Was natürlich nicht stimmt. Habe ich nur mal wieder Tomaten auf den Augen, oder ist es tatsächlich so, dass die vielen anderen Sprachversionen nicht mehr zugänglich sind und noch nicht einmal ein Hinweis auf ihre Existenz gegeben wird? Gruß, --Yen Zotto (Diskussion) 17:43, 5. Apr. 2025 (CEST)

Das neue Sprachmenü ist eine der schlimmsten Neuerungen des neuen Skins. Das geht so nicht. Hier muss auf jeden Fall zum alten System zurückgekehrt werden. -- Chaddy · D 19:04, 5. Apr. 2025 (CEST)

Schuld sind meines Erachtens Wikipedia:Hauptseite/Interwikis + Wikipedia:Interwiki-Links auf der Hauptseite. Das magische Wort {{noexternallanglinks}} in WP:Hauptseite/Interwikis verhindert, dass die Verlinkungen angezeigt werden [21], stattdessen werden nur die 51 manuell ausgewählten Interwikilinks angezeigt. Eine Lösung, die für Vector 2010 oder Monobook wohl sinnvoll war, um nicht durch 300+ Sprachen zu scrollen, aber im Vector 2022 ist das Quatsch. In anderen Sprachversionen, die sowas nicht machen (z.B. frwiki [22]) funktioniert alles wunderbar. Da erscheint die Sprachauswahl übrigens auch oben, weil sie die entsprechende Empfehlung der WMF umgesetzt haben [23][24]. @Hgzh ist es möglich, Wikipedia:Hauptseite/Interwikis für Vector 2022 nicht anzuwenden? --Johannnes89 (Diskussion) 20:16, 5. Apr. 2025 (CEST)

Nein, da sehe ich keinen Weg.

Der Link zu „allen Sprachen“ wird für die übrigen Skins mit MediaWiki:Gadget-Hauptseite-Sprachen.js erzeugt. Dieser Ansatz funktioniert aber für Vector 2022 mit der Sprachauswahl (die im übrigen so neu nicht ist, sondern schon gute zehn Jahre auf dem Buckel hat) nicht. Gruß, -- hgzh 08:47, 7. Apr. 2025 (CEST)

Dann sollte man das wohl besser abschaffen, um unseren Lesenden von nun an nicht 300+ Hauptseitenlinks vorzuenthalten? Mir erschließt sich auch nicht ganz, weshalb man damals überhaupt ne Begrenzung eingeführt hat, ist doch heutzutage eines der Argumente gegen den Vector 2022, dass Monobook/Vector 2010-User anscheinend am liebsten durch eine vollständige Sprachleiste scrollen möchten? --Johannnes89 (Diskussion) 09:06, 7. Apr. 2025 (CEST)

Ich denke mal, es ging darum, dass die Hauptseite durch die Vielzahl an Sprachlinks in der linken Leiste sehr lang gewesen wäre und man das vertikale Scrollen begrenzen wollte. Das dürfte jetzt vermutl. nicht mehr relevant sein, deswegen könnte man das Konzept nach Konsultation der HS-Disk aufgeben. Gruß, -- hgzh 09:11, 7. Apr. 2025 (CEST)

Die Auswahl der Sprachlinks auf der Hauptseite war mal ein sehr heikles Thema und es wurde intensiv diskutiert. Die heutige Auswahl ist ein lange ausgefochtener Kompromiss. Und da viele auch weiterhin ältere Skins nutzen, bleibt die Auswahl auch relevant. Ich würde das also nicht so leichtfertig einfach über Bord werfen. -- Chaddy · D 17:41, 7. Apr. 2025 (CEST)

Buggy (Firefox?)

Disclaimer: Falls es in Hilfe Diskussion:Skin/Vector 2022 besser aufgehoben ist, Bescheid sagen! Liegt das am Firefox oder empfinde nur ich das neue Vector, vor allem Artikelentwurf als extrem buggy? Wenn ich einen Versionsvergleich machen will, komme ich nicht mehr in den Editiermodus zurück, im Dark-mode wird die linke Seite in hell angezeigt, Differenz-Vorschau ist aufgrund der Font-Vorder- und Hintergrundfarben komplett unlesebar. Falls nicht nachvollziehbar, mach ich mal Screenshots.

Die Position des Icons für die Beobachtungsliste finde ich inkonsistent. Mal ist es oben rechts, mal im Profil-Manü versteckt. Wünsche mir konistent ersteres.

Werde wohl wieder zum alten Vector zurückwechseln. LG -- Escla ^¿! 19:15, 5. Apr. 2025 (CEST)

> im Dark-mode wird die linke Seite in hell angezeigt, Differenz-Vorschau ist aufgrund der Font-Vorder- und Hintergrundfarben komplett unlesebar.
Bitte mal genau mit angegebenen Skripten (und am besten Screenshots) auf der zugehörigen Projektseite das Problem beschreiben. Es wird vermutlich durch irgendwelche lokalen Skripte, die noch nicht umgestellt wurden, ausgelöst.
> vor allem Artikelentwurf als extrem buggy
Meinst du damit das Bearbeiten? Das hat nichts mit dem neuen Vector zu tun. Der neuste Editor ist der Visual Editor von 2013 und der zugehörigen 2017-Quelltext-Editor. Ansonsten gibt es noch den 2010er- und den 2006er-Quelltexteditor Editor Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 00:47, 6. Apr. 2025 (CEST)

Benutzer:Escla/vector-2022.css L63. --Jdlrobson (Diskussion) 20:29, 6. Apr. 2025 (CEST)

Demografischer Fortschritt in Tabellenform für besiedelte Gebiete der Slowakei

Ich möchte hinzufügen: Demografische Entwicklung in Tabellenform nach Orten in der Slowakei. Hat jemand etwas dagegen?

Dies ist Teil eines Multiprojekts (Modul:SK & Template:SK). Beispieltabelle: Fintice#Bevölkerung. (automatische Übersetzung) --Dušan Kreheľ (Diskussion) 12:24, 8. Apr. 2025 (CEST)