Du hast Fragen zur Bearbeitung der Wikipedia und keine Antwort auf Hilfe:FAQ gefunden? Dann bist du hier richtig! Fragen werden nicht per E-Mail beantwortet, sondern nur auf dieser Seite. Bei aktuellen Themen findet sich hier oft schon eine passende Diskussion, die deine Frage beantworten kann. Bitte diskutiere dann dort und lege keinen neuen Abschnitt zum selben Thema an.
Abschnitte, deren jüngster Beitrag mehr als vier Tage zurückliegt oder die seit zwei Tagen mit dem Baustein {{Erledigt|1=~~~~}} gekennzeichnet sind, werden automatisch archiviert. Möglicherweise findest du auch im Archiv die Antwort auf deine Frage. (Gesamtarchiv • diese Woche)
Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 2 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sindoder deren jüngster Beitrag 4 Tage alt ist.
Letzter Kommentar: vor 15 Stunden11 Kommentare5 Personen sind an der Diskussion beteiligt
Ich hoffe, ich bin mit der Frage hier richtig. Im Quellcode der Wikipedia ist ein div-Element für den Seitenheader mit der Suchleiste usw. Durch diesen werden Shortcuts wie z.B. in Portalen leider überdeckt. Kann man etwas dagegen unternehmen oder sollte man das irgendwo reporten? --Entgegner (Diskussion) 12:52, 31. Mai 2026 (CEST)Beantworten
Das erste Mal aufgefallen ist es mir im Portal:Informatik, aber es kann gut sein, dass es überall so ist, wo so ein Shortcut oben drin ist, zumindest laut meinen Stichproben. Ich bin jetzt entnervt auf Monobook gewechselt, da hats das Problem nicht. --Entgegner (Diskussion) 06:19, 1. Jun. 2026 (CEST)Beantworten
Ich hatte vorher beide Vector-Skins ausprobiert. Man sieht dann nur das abgeschnittene, ausgefranste untere Ende von etwas Text. Schriftgröße ist 20 wegen meiner hohen Pixeldichte. Wenn ich auf 16 runterstelle, kann ich die Shortcuts vollständig sehen, aber das ist mir zu klein. --Entgegner (Diskussion) 18:47, 1. Jun. 2026 (CEST)Beantworten
Also ich kann den oben beschriebenen Fehler so bei mir nicht nachstellen. Bei mir sieht es in allen Skins richtig aus. Wo hast du denn die Schriftgröße von 20 bzw. 16 eingestellt? Kannst du eventuell einen Screenshot von dem Fehlerfall machen? Gruß --Guardian of Arcadia (Diskussion) 08:34, 4. Jun. 2026 (CEST)Beantworten
In den Firefox-Einstellungen. Ich hoffe, man erkennt es im Screenshot.
Die Anzeige der Shortcuts in der ersten Zeile einer Seite (also idR noch über der Überschrift) ist ein "Hack" von uns, der bei der Entwicklung der Skins gar nicht bedacht wurde, weil so nicht vorgesehen. In der Standardansicht passt es, wenn man im Browsereinstellungen verändert nicht mehr, aber dann ist das Problem die Browsereinstellung und nicht die Wikipedia. Wobei es sicherlich besser wäre, wenn wir den Shortcuts allgemein eine bessere Position geben würden (auf Vorlage:Shortcut wird die Abkürzung z.B. erst unterhalb der Überschrift angezeigt). --Johannnes89 (Diskussion) 07:13, 5. Jun. 2026 (CEST)Beantworten
Wie Johannes und PC bereits ausführlicher erklärt haben, ist die Positionierung der Shortcuts lediglich ein „Hack“, mit dem der Shortcut-Text einfach absolut zum Inhaltsbereich positioniert wird und dann um x Pixel nach oben raus verschoben wird, so, dass er (so die Hoffnung) an der richtigen Stelle landet. Leider verträgt sich das aber nicht sonderlich gut mit vom Standard abweichenden Einstellungen.
Eine generelle „Lösung“ dieses Problems, die für alle funktioniert, wird es so schnell nicht geben. Damit es bei dir aber trotzdem nicht abgeschnitten wird, könntest du dir je nach Skin (z. B. für Vector 2022) eine benutzerdefinierte CSS-Datei in deinem BNR (Spezial:Meine Benutzerseite/vector-2022.css) mit folgendem Inhalt anlegen:
#shortcut{top:-8em!important;}
Der Standardwert bei Vector 2022 ist -9em. Mit -8em sollte der Text wieder weiter nach unten rutschen und dann bei dir hoffentlich nicht mehr überdeckt werden. Falls es noch nicht reicht, kannst du den Wert auch noch weiter korrigieren. Bitte beachte aber, dass, falls du Wikipedia auf mehreren Endgeräten (mit unterschiedlichen Einstellungen) nutzen solltest, du mit dieser Lösung ein Problem bekommen wirst. Gruß --Guardian of Arcadia (Diskussion) 22:55, 5. Jun. 2026 (CEST)Beantworten
Das geht nicht so simpel.
Auf allen Hilfeseiten und Unterseiten von WP:Technik klappt es anstandslos.
Damit es in richtiger Technik, also floatend, in den Inhalt integriert werden kann, muss an der Stelle der Seite eine geeignete Gelegenheit vorhanden sein.
Unsere Projektseiten im Design der Nuller Jahre haben einen Rahmen um das gesamte Intro.
Der vergeudet Platz auf dem Smartphone, ist auf kleineren Bildschirmen ohnehin nicht um alles erkennbar, und verhindert Shortcuts.
Portale haben ebenfalls Rahmen um alles.
Auf vielen Disk-Seiten steht zu Anfang ein Kasten.
Sobald es einen Kasten in voller Inhaltsbreite gibt, wird es erforderlich, dass der erst ein Stück weiter unten anfängt, und damit ist links eine riesige Leerzeile sichtbar.
Alle Kästen dieser Art müssen abgebaut oder ganz anders gelöst werden, weil sie sich um dieselbe Ecke rechts oben streiten.
Das Element muss floatend irgendwo rein, wo es gestalterisch auch passt.
Das muss für jede einzelne Seite individuell sichergestellt werden. Viel Spaß.
Die „Seitenindikator-Technik“ ist mal extra für Smartphones erfunden worden, aber nach einem Dutzend Jahren immer noch nicht auf Mobilgeräten (Hälfte der Abrufe) implementiert worden. Die Design-Abteilung der WMF grübelt seit über einem Jahrzehnt über das zukünftige Mobil-Design, das alle Aspekte berücksichtigen soll.
Das ist ersichtlich ein Holzweg, und das GUI eines Mobilgeräts wird vorhersehbar keine großartigen Platzreserven haben, um das zuzutexten.
Unsere Inhalte gehören in unseren Inhaltsbereich und nicht in fremde Bereiche exportiert.
Die Idee ist 2003/2004 unkritisch aus der enWP übernommen worden.
Die Leute in der enWP sind die allersmartesten, und was die programmieren, ist das Goldene vom Ei und unübertrefflich weise.
Man hatte bereits im vorigen Jahrhundert gewusst, dass man derartige absolute Positionierung dann und nur dann vornehmen darf, wenn man selbst auch immer die volle Kontrolle über den Zielbereich hat.
Es wird ein Element oben drüber über den vorhandenen Inhalt gelegt, völlig egal ob da schon was steht oder nicht. Es gibt kein Layout, der sonstige Inhalt wird nicht zur Seite geschoben.
Die Verantwortlichen waren sich ganz ganz ganz sicher, und hatten das hier bei uns auch so diskutiert, dass es immer ein paar Pixel zwischen zwei Zeilen geben würde, und wenn man ganz klitzeklitzeklein schreiben würde, dann würde man in Ewigkeit immer unseren Inhalt statt in unserem Inhaltsbereich irgendwo nach da draußen verschieben können. Und diese Pixelposition würde man ja kennen und kann den Zeilenabstand „ausnutzen“.
Das ist schon deshalb ein Denkfehler, weil Vector 2010 und erst recht Vector 2020 ein dynamisches Layout haben, Elemente ein- und ausgeklappt werden, je nach Bildschirmbreite in Menüs gesteckt werden. Das Weltbild der Nuller Jahre war jedoch starr und statisch gewesen, und manche Mitwirkende aus dieser Zeit haben das bis heute.
Letzter Kommentar: vor 4 Tagen7 Kommentare4 Personen sind an der Diskussion beteiligt
Vielleicht finde ich ja hier eine Antwort..: Aus einem kleinen Mediawiki (nicht aus unserem Wikiversum) mit ~1000 Artikeln im Hauptnamensraum hätte ich gern eine Tabelle mit den Spalten Lemma und URL (ods, xls, csv). Wie könnte ich da vorgehen? und wie müsste die Abfrage lauten? (vermutlich ist das ja in jedem Mediawiki gleich?) Gruss, --Markus (Diskussion) 16:35, 1. Jun. 2026 (CEST)Beantworten
Ok, danke. Wenn ich die Abfrage mit deinem Link mit den 7 Code-Zeilen in quarry.wmcloud.org laufen lasse, bekomme ich die ersten 100 Artikel aus Wikipedia. Woher weiss "quarry", dass er in der WP-DB suchen soll? bzw. wie sage ich ihm, dass er in "tolleswiki.org" im NR-0 suchen soll? Wie kann ich auch noch ausgeben lassen, wieviele Einträge gefunden wurden? Gruss, --Markus (Diskussion) 00:44, 2. Jun. 2026 (CEST)Beantworten
Quarry ist ein Wikimedia-Projekt und hat nur Zugriff auf die Wikimedia-Server und -Datenbanken. Die SQL-Abfrage müsstest du so in einer Datenbankumgebung des fremden Wikis laufen lassen, sofern du darauf Zugriff hast. -- hgzh09:27, 2. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 45 Minuten8 Kommentare6 Personen sind an der Diskussion beteiligt
Hallo zusammen, früher wurde bei der Google-Suche immer auf eine bestehende Wikipedia-Seite verwiesen, oder die rechts in einem Kasten irgendwie angezeigt. Ich habe beobachtet, dass das nicht mehr der Fall ist, so als ob Wikipedia irgendwas zur Suchindizierung verloren hätte. Bug or Feature? --Julius Senegal (Diskussion) 08:58, 2. Jun. 2026 (CEST)Beantworten
Google ist gerade daran sich „vom Wegweiser zum Ziel“ umzubauen, siehe etwa diesen Kommentar dazu: https://www.heise.de/meinung/Google-Suche-Le-Web-c-est-moi-11302565.html - d.h. Google möchte seinen Nutzern immer mehr Inhalte direkt bei sich selbst anbieten und die Leute nicht mehr unbedingt auf andere Websites lotsen. Dazu gehört wohl auch, dass die Wikipedia je nach Suchanfrage jetzt weniger prominent verlinkt wird. Es kommt aber aufs Thema an. Wenn ich etwa nach Island suche, dann ist in der Infobox oben rechts tatsächlich kein Link auf die Wikipedia mehr zu finden. Bei Goethe hingegen immer noch... - Die Wikipedia hat hier nichts „zur Suchindizierung verloren“, das ist einfach der neue Ansatz von Google. --Gestumblindi09:03, 2. Jun. 2026 (CEST)Beantworten
Wenn ich nach Island suche, erhalte ich keinen Link mehr zu Wikipedia. Ich werde in Urlaub geschickt: Link4 führt mich zu Wikivoyage. Und ein Flug dauert dreieinhalb Stunden. --Viele Grüße, Aschmidt (Diskussion) 09:27, 2. Jun. 2026 (CEST)Beantworten
Die Erwartungshaltung ist schon falsch. Warum sollte Google Wikipedia bevorzugen? Es gibt mittlerwile eine ganze Reihe ähnlicher Angebote da draußen. Außerdem kann Google nicht ahnen, dass jemand einen Enzyklopädieeintrag sucht und keine Gebrauchsanleitung, keine Einkaufsvorschläge oder dergleichen. Wenn Google/Alphabet etwas damit verdienen könnte, dass es Wikipedia vorschlägt, wäre das vielleicht anders. --Entgegner (Diskussion) 23:57, 2. Jun. 2026 (CEST)Beantworten
Eine Google-Suche nach WP:VWS bringt als erstes die KI-Zusammenfassung:
„WP:VWS“ steht in der Wikipedia für Wikipedia:Vandalismusmeldung.
Auffällig ist, dass Suchmaschinen (ich nutze Google nur selten) derzeit den Anriss unter dem Link auf einen WP-Artikel nicht mehr mit der Einleitung beginnen, sondern mit dem ersten Satz aus dem ersten Abschnitt des Artikels. --Viele Grüße, Aschmidt (Diskussion) 13:25, 6. Jun. 2026 (CEST)Beantworten
Noch einmal auf Los! Was ist mit dem Syntax-Problem eingangs gemeint? Weblink tadellos oder eben nicht abrufbar??
https://aws.amazon.com/de/s3/ hat oben einen Button Konto erstellen. Ob das hilft, weiß ich nicht. Mit dem Dokument sind lt. Error-Meldung keine Style-Informationen verknüpft und: Request has expired. Und ob dieses Dokument so verlinkt werden kann, dass es auch ohne Anmeldung abrufbar ist, steht dahin. Wieso das, wie oben geschrieben, zuerst tadellos funktionierte, bleibt unklar.
Eine Alternative hätte der Jahresbericht 2025 sein können, doch dieser schweigt sich, soweit gesehen, zu den Mitarbeiterzahlen aus.
Hilft wohl nur, nach einem anderen Weblink zu suchen.
Jetzt hat's "geklickert", herzlichen Dank! - ich dachte, den Link bei WP melden, sorry. Ich schau's mir in Ruhe an, melde dann mein Ergebnis/Misserfolg/Erfolg. (Gov.uk kam übrigens aus der Suchmaschine und dort hatte ich nach Naim Audio 2022 gesucht ...) Viele Grüße, --Wikisympathisant (Diskussion) 19:48, 3. Jun. 2026 (CEST)Beantworten
wie ...? Ich kam über die Suche Naim Audio und den (bei der englischsprachigen WP im Naim-Artikel genannten) Cedric Magnaud 2022, bei Gov.uk dahin (gab da eine Dokument-PDF-Liste); offenbar, das zeigt ja auch der lange Link, hinterlegt Gov.Uk. die Dokumente extern ... Aber (!) ich testete gerade nochmal den langen Link und bekomme (möglicherweise auch durch Rechner-Neustart am Morgen) die Fehlermeldung, heißt, er ist tatsächlich abgelaufen .... Ich fürchte, ich nehme den Dokument-Name, wie oben angedeutet ... Viele Grüße, --Wikisympathisant (Diskussion) 20:39, 4. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 2 Tagen9 Kommentare6 Personen sind an der Diskussion beteiligt
Hatten wir das nicht schon einmal? Irgend so eine Opt-in-Option, die besser Opt-out wäre? Seit heute Mittag habe ich jede Menge Köpfe in meiner Beo, die ich bitteschön wieder weg haben möchte. An welchem Rädchen muss ich dafür drehen? ※Lantus13:38, 3. Jun. 2026 (CEST)Beantworten
Ist meines Wissens nicht möglich. Man kann Bots und kleine Änderungen (Markierung "K") ausblenden, aber keine Blacklist für einzelne Benutzer anlegen. Das Problem ist auch, dass man auch bei Ausblendungen leider nicht die davorliegenden Edits angezeigt bekommt, die man nicht ausblenden möchte, d. h. der letzte Edit pro Artikel entscheidet letztlich über anzeigen oder komplett ausblenden. lg --Invisigoth67(Disk.)14:14, 3. Jun. 2026 (CEST)Beantworten
Vielleicht habe ich mich missverständlich ausgedrückt. Ich will nicht einzelne Leute ausblenden, sondern diese Symbole mit den Köpfen (bei allen). ※Lantus14:22, 3. Jun. 2026 (CEST)Beantworten
Ja, das wurde standardmäßig wieder deaktiviert (ist also opt-in). Zitat aus Hilfe:Benutzer/Infokarte: Um diese Funktion nutzen zu können, wurde sie zunächst in den Einstellungen als optional bereitgestellt. Die Einführung als standardmäßige Aktivierung, die bei Bedarf abgeschaltet werden kann, wurde wieder deaktiviert. Gruß --Guardian of Arcadia (Diskussion) 08:42, 4. Jun. 2026 (CEST)Beantworten
... womit wir unter den großen Wikis mal wieder eine absolute Ausnahme sind, in anderen Projekten ist die Infokarte eine opt-out Funktion. Ich nutze sie gerne – zwar übersehe ich sie im Regelfall, aber von Zeit zu Zeit ist sie praktisch, um beispielsweise zügig nen Überblick zu nem temporären Konto zu erhalten. --Johannnes89 (Diskussion) 09:03, 4. Jun. 2026 (CEST)Beantworten
Die globale Einstellung ist dazwischengegrätscht. Lokal hatte ich es bereits ausgeschaltet. Danke für die Info. Solche Sachen muss ich immer wieder neu suchen … ※Lantus15:00, 3. Jun. 2026 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. Für mich ist das erledigt. ※Lantus 20:02, 5. Jun. 2026 (CEST)
Verwendung fremdsprachiger vs. deutscher Städtenamen etc.
Letzter Kommentar: vor 2 Tagen2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich meine mich zu erinnern, dass es eine Seite im Hilfebereich gab/gibt, wo Verwendungsempfehlungen für deutsche vs. fremdsprachige (ggf. transskribierte) geografische Namen zu finden waren. In meiner Erinnerung waren da auch Aspekte wie Einwohnerzahl berücksichtigt.
Kann mir bitte wer auf die Sprünge helfen und sagen, wo das Dokument liegt?
Mir editiert seit gestern ein Bot nach, der <references responsive /> in <references responsive="1" /> ändert. Was hat es damit auf sich, und wo ist das dokumentiert, was dieser Parameter macht? -- Escla¿!00:38, 4. Jun. 2026 (CEST)Beantworten
WP:Technik/Werkstatt#VE tut ungefragt Dinge (3) hat damit nichts zu tun – da ging es darum, dass VisualEditor (VE) für einige Zeit ungewollt <references /> in <references></references> geändert hat. Der Fehler ist nun gelöst und der TaxonBot hat den Wikitext dankenswerterweise in betroffenen Artikeln korrigiert (hatte zwar keine sichtbare Auswirkung, aber die meisten finden den Quelltext deutlich schöner so, wie sie es ursprünglich geschrieben hatten).
WP:Technik/Werkstatt#VE tut ungefragt Dinge (2) und phab:T101841 beschreiben das hier vorliegende Problem: VE kann den Unterschied nicht erkennen zwischen <references responsive /> und <references responsive="" />. Das zu beheben ist relativ komplex und auf absehbare Zeit nicht ersichtlich. Seit Jahren hat der TaxonBot deshalb jedes Mal, wenn VE aus <references responsive /><references responsive="" /> gemacht hat, das wieder zurückkorrigiert. Aber nachhaltig ist das nicht und bläht perspektivisch die Versionsgeschichte auf. Mit <references responsive="1" /> lässt VE alles in Ruhe und sorgt nicht für weitere ungewollte Difflinks. Ich persönlich halte das für pragmatischer, als anhaltend den Bot zur Nachkorrektur auf die eigentlich gewünschte Form zu bringen, mit Blick darauf, dass nicht absehbar ist, ob/wann VE irgendwann beigebracht werden könnte, mit <references responsive /> umzugehen. --Johannes Richter (WMDE) (Diskussion) 08:01, 4. Jun. 2026 (CEST)Beantworten
Warum editieren wir dem VE hier eigentlich überhaupt hinterher? Wenn der VE den Code <references responsive /> bei einigen Änderungen in <references responsive="" /> ändert, dann finde ich das zwar nicht sonderlich gut, aber einen extra Edit, um das wieder zurück zu biegen, braucht es da meiner Meinung nach auch nicht. Falls mich der Syntax als (Haupt-)Autor eines Artikels stört, dann kann ich das ="", wenn ich das nächste Mal wegen etwas anderem eine Änderung am Artikel vornehme, ja auch einfach wieder entfernen.
Stattdessen jetzt aber überall – also auch in Artikeln, die vielleicht nie oder nur selten mit dem VE bearbeitet wurden – den Code in <references responsive="1" /> zu ändern, halte ich nicht für besonders sinnvoll, zumal ja alle drei Varianten das gleiche Ergebnis erzielen. --Guardian of Arcadia (Diskussion) 09:18, 4. Jun. 2026 (CEST)Beantworten
Ansgesichts der finanziellen Mittel der Foundation ist wenig einsichtig, wieso wir eine Pseudo-Lösung einer richtigen Problemlösung vorziehen sollten. -- Chaddy · D12:26, 4. Jun. 2026 (CEST)Beantworten
Ich kann nicht für die WMF sprechen, aber angesichts von über 50.000 offenen Phabricator-Tasks ist klar, dass unmöglich alle Probleme und Wünsche bearbeitbar sind. Bei den Technischen Wünschen müssen wir ja auch immer wieder priorisieren, weil Budgets halt Grenzen haben. Perfekt aussehender Wikitext hat dann womöglich geringere Priorität als andere Baustellen.
Das gilt in diesem Fall vermutlich auch deshalb, weil wir eines der wenigen großen Wikis sind, die <references responsive /> überhaupt nutzen. In der Englischsprachigen Wikipedia – aber auch den meisten anderen großen Sprachversionen – wird <references /> bei mehr als 10 Einzelnachweisen automatisch zweispaltig dargestellt (wer das nicht will, nutzt <references responsive="0" />). Weil VE sowohl <references /> als auch <references responsive="0" /> nicht anrührt, ist die Änderung von <references responsive /> auf <references responsive="" /> primär bei uns ein Thema, Wikis mit automatischer zweispaltiger Darstellung nutzen <references responsive /> ja nicht wirklich. --Johannes Richter (WMDE) (Diskussion) 13:31, 4. Jun. 2026 (CEST)Beantworten
Diese Bot-Aktion ist Unfug und sollte unverzüglich beendet werden.
Sie schafft mindestens einen sinnfreien Eintrag in jeder VG, bei manchen, die Bots nicht ausblenden, schlägt das auch noch auf der Beo auf.
H:KÄ (grüner Kasten) verbietet ausdrücklich serienmäßige absolut wirkungslose Edits wie diese reine Quelltext-Kosmetik.
Es führt nur zu Irritationen wie jetzt diese hier, und an diversen anderen Stellen.
Es gibt kein Problem, es gibt nichts zu lösen, es wird nichts verbessert.
Beide Formen, der momentane VE-Geschmack mit responsive="1" und responsive als langjähriger deWP-Standard und kürzeste, einfachste und übersichtlichste Form funktionieren mit allen Parser-Varianten gleichermaßen.
Ich habe von dieser Bot-Aktion erst jetzt hier auf FZW etwas inhaltlich mitbekommen.
Der VE tut ungefragt etliche Dinge, seit einem Dutzend Jahren schon, und wir haben uns doch eigentlich längst daran gewöhnt und ignorieren es, sofern die Darstellung wenigstens hinterher wie beabsichtigt aussieht.
Für derartige Schalter-Attribute ist sich die globale XML-HTML-Philosophie seit Jahrzehnten nicht recht einig geworden und kam nie zu einem endgültigen von allen akzeptierten definitven Standard.
Eiiiiiigentlich wäre die wirklich korrekte Form: <referencesresponsive="responsive">
Im Wiki funktioniert offenbar ziemlich jede der nachstehenden Notationen mit gleicher Wirkung:
Es gibt offenbar nur eine einzige Ausnahme durch den Wiki-Parser bzw. die Extension, bei denen das Vorhandensein des responsive nicht auch die Mehrspaltigkeit auslöst:
Dort heißt es nur <referencesresponsive> an zwei Stellen.
Oder aber: <referencesresponsive="0">
Die Leutchen in der WMF arbeiten seit immer recht unkoordiniert aneinander vorbei. Jeder „Produkt Manager“, alle in der Entwicklung basteln so wie es ihnen grad passt und am wenigsten Arbeit macht. Einen echten Standard und eine übergeordnete Instanz gibt es nicht.
Die VE-Programmierer fanden halt schon vor mehreren Jahren, dass sie es am einfachsten haben, wenn sie responsive="1" generieren.
Es gibt Hunderte Bugs oder zumindest Absonderlichkeiten, teils schon seit über zehn Jahren, bei denen der VE merkwürdige Syntaxkonstrukte baut. Wenn sie dann halt zu korrekter Darstellung führen, ist das eben so.
Jeder macht es so, wie im Heimatwiki erlernt und abgeguckt. Die meisten Entwickler hatten intensiven enWP-Kontakt; also wird alles so gemacht wie es sich Leute in der enWP angewöhnt haben.
Die vor einigen Tagen erfolgte Veränderung unserer Hilfeseite H:EN war nirgendwo abgesprochen, unzulässig und steht im Widerspruch zu unserer langjährigen Praxis, der Syntax aller anderen Schalter-Attribute in Tags sowie der Forderung nach kürzestmöglicher einfachster Syntax.
Wenn es niemand anders gemacht hatte, werde ich das in den nächsten Tagen revertieren.
Der Botlauf ist dazu da, um Inkonsistenzen zu reduzieren, bis die Parsoid-Korrektur geschehen ist. Ein erneuter VE-Dirty-Diff, siehe Phab-Task, wird durch eine explizite Wertdefinition künftig verhindert. Bis dahin sind sowohl responsive als auch responsive="" und responsive="1" funktional äquivalent, ein leerer Wert wird aber nicht mehr selbstständig vom VE eingefügt werden, T212340, und das ist das, was erreicht werden soll. So macht der VE in diesem Fall keinen Quatsch mehr. Fügen wir nur references responsive ein, wie das mal auf H:EN stand, wird der VE das fälschlicherweise wieder ändern. Dem wird hiermit vorgebeugt. --Doc Taxon (Diskussion) 11:22, 4. Jun. 2026 (CEST)Beantworten
Das ist aber kein Problem den man im Wikicode löst, sondern im VE. Sorry, aber ohne ankündigung diese Massenspamaktion der Beos ist absolut fehl am Platz. Bitte Bot stoppen und diskutieren. Danke.--Maphry (Diskussion) 11:25, 4. Jun. 2026 (CEST)Beantworten
Der Ansatz des Botlaufs:
TaxonBot ändert die Vorkommen von <references responsive> zu <references responsive="1" />
VE lässt explizite nicht-leere Werte in Ruhe → kein oft unbemerkter Dirty Diff mehr wie <references responsive="">
der VE wird auch künftig keine Dirty Diffs mehr erzeugen
ja, das ist ein Problem des VE, lässt sich aber beruhigen, bis er korrigiert wird (in vielleicht hundert Jahren mal)
Mich hatte es nur insofern "geärgert", dass ich den Sinn nicht verstanden hatte, weil kein Unterschied zwischen vorher/nachher im Aussehen. Grüße -- Escla¿!14:01, 4. Jun. 2026 (CEST)Beantworten
Okay, möglicherweise ist das zu heftig, ich habe das mal soweit heruntergefahren, dass der Bot nur noch <references responsive=""> anfasst, denn das sind tatsächlich VE-entstandene und eher keine manuellen Eingaben. --Doc Taxon (Diskussion) 11:53, 4. Jun. 2026 (CEST)Beantworten
Du kannst ihn auch selbst korrigieren, insbesondere Rechtschreib-, Grammatik- oder Zeichensetzungsfehler. Bei der Korrektur von Sachfehlern solltest du auf jeden Fall eine Quelle angeben. --Brettchenweber (Diskussion) 14:56, 4. Jun. 2026 (CEST)Beantworten
Die Kilometrierung muss nicht zwingend mit der tatsächlichen Länge übereinstimmen, es kann Lücken oder Doppplungen geben etc. – Und tatsächlich, laut Artikel Bundesautobahn 3#Doppelte Kilometerbezeichnung: "Die Kilometerauszeichnung beginnt zum einen an der niederländischen Grenze, zum anderen am Dreieck Heumar bei Köln nach Süden erneut, sodass etwa 140 km als Auszeichnung doppelt vergeben sind." 628,2 km + 140 km ≈ 769 km. --Luftschiffhafen (Diskussion) 15:43, 4. Jun. 2026 (CEST)Beantworten
Wir haben seit einer Woche ein neues Captcha-System: WP:NEU#26. Mai, zuvor wurde es u.a. in der Englischsprachigen Wikipedia getestet. Ausführlicher dazu WP:TW#Verbesserte Boterkennung und Ersatz unseres CAPTCHA-Systems. Zusammenfassung der Änderungen: Das alte System (ein Wort eingeben) ist für heutige Bots spielend leicht überwindbar, aber nicht barrierefrei für Menschen. Deshalb wird nun hCaptcha genutzt. In 98% aller Fälle wird gar kein Captcha mehr ausgespielt, sondern das Programm erkennt auch ohne, ob es sich wohl um einen Bot handelt – im Vergleich zu früher (gerade bei Einfügung von Weblinks) sehen unangemeldete User jetzt also deutlich seltener die Aufforderung, ein Captcha zu lösen – für fast alle somit eine spürbare Verbesserung. Ich weise das zuständige WMF-Team auf den Thread hin, also sowohl die Übersetzungsprobleme, als auch die schlecht erkennbaren Bilder. --Johannnes89 (Diskussion) 17:15, 4. Jun. 2026 (CEST)Beantworten
... und bitte nicht zu vergessen die sonstigen Fehlfunktionen: den Vorwurf, ich hätte das Captcha nicht richtig ausgefüllt, obwohl mir gar keins angezeigt worden war. Und als Krönung die Endlosschleife, in der man gefangen ist. Was nützt das schönste Captcha, wenn es einem nach Lösung der Aufgabe einfach nur unendlich weitere Captchas vor die Nase setzt? Damit ist das eine nicht lösbare Totalblockade. Anstelle eines Captchas hätte man mir genausogut die Weiterarbeit unter der IP-Adresse sperren können, das wäre aufs selbe hinausgelaufen.
Übrigens, wie ich im anderen Thread schon schrieb, ich hatte ein ähnliches Problem mit diesem Captcha-Programm vor nicht allzu langer Zeit schonmal auf Commons. Es liegt also wirklich an diesem Programm. Und für den deutschsprachigen Markt ist es definitiv nicht gemacht.
Und das Spielchen geht weiter.:-( Offenbar haben die irgendwas an den Einstellungen gedreht, denn heute morgen muss ich bei jeder Bearbeitung ein Captcha eingeben. Nein, nicht eins, sondern, zwei, drei, vier.
Bei den "barrierefreien" (ich setz' das mal in Anführungszeichen, denn eine Barriere durch eine andere ersetzen ist nicht mein Verständnis von Barrierefreiheit) Aufgaben dieselbe Sorte Aufgaben mit idiotischer Formulierung wie gestern. Bei den Bildern muss ich heute die eine Form rauserkennen, die nicht passt. Also im Prinzip eine Kindergartenaufgabe, aber bei mittelfliederfarbener Figur auf zwischen hellmittelfliederfarben und dunkelmittelfliederfarben changierendem Hintergrund doch nicht so einfach, wie's klingt. Und wenn das blöde Ding einen dann wieder in Wiederholungsschleifen schickt, dann sagt es doch bitte lieber gleich offen, dass die unangemeldete Bearbeitung nicht mehr erwünscht ist. Frustrierte Grüße, --~2026-33361-62 (Diskussion) 10:39, 5. Jun. 2026 (CEST)Beantworten
Ich kann die geschilderten Probleme nachstellen. Bei drei Testedits mit völlig harmlosen Textergänzungen durfte ich dreimal jeweils zwei Captchas ausfüllen. Die „Herausforderung“ war „Klicken Sie genau die in der Anleitung angeforderten Tiere an“. Als Optionen gab es u.a. „Zugänglichkeits-Cookies“ und „Herausforderung der Barrierefreiheit“. Also die Übersetzungen sind schon übel. Das Ganze sowohl im Firefox, privater Modus als auch im Edge-Browser ohne besondere Privatspäreeinstellungen. Die „Herausforderung der Barrierefreiheit“ war dann die schon benannte holprig formulierte Buchstabenentfernung. -- hgzh13:00, 5. Jun. 2026 (CEST)Beantworten
Ich habs weitergegeben, WMF Product Safety and Integrity schaut sich das an.
Jetzt eben wurde kein Captcha abgefragt. Bin mal gespannt, wann das nächste auftaucht und wie es sich dann verhält.:-) Danke für Euer Bemühen!
Übrigens, ergänzend zu dem, was hgzh sagt: Heute morgen hatte ich auch die Tierbildchen. Und die Aufgabenstellung widerspricht total dem, was man im Kindergarten gelernt hat: unter zehn Teddybär-Bildchen das eine zu finden, wo der Teddybär genau die Arm- und Beinhaltung aufweist wie im Beispielbild. Hier dagegen hatte man neun Nicht-Teddybären und einen Teddybär in völlig anderer Haltung als den im Beispielbild. Sehr verwirrend für alle, die im Kindergarten aufgepasst haben.:-(
Zu den Übelsetzungen: "Herausforderung der Barrierefreiheit", das ist es wohl eher für die Hersteller dieses Programms. Ich finde die Auflage, "Zugänglichkeits-Cookies" zuzulassen, durchaus problematisch: Das ist nichts anderes als eine Sonder-Auflage für Menschen mit Behinderung. Für Sehbehinderte bedeutet dies, dass sie ihre grundlegenden Browser-Einstellungen auf die originellen Ideen dieser Firma einstellen müssen. Mit meinen Browser-Einstellungen wäre das gar nicht möglich. --~2026-33361-62 (Diskussion) 17:20, 5. Jun. 2026 (CEST)Beantworten
Dass es neben den Bildern jetzt auch eine Alternativmöglichkeit gibt (für die man einen Cookie zulassen muss), ist eine deutliche Verbesserung im Vergleich zum alten Captcha-System (wo man z.B. sowas abtippen musste) – da gab es nämlich keine Alternative für Menschen mit visuellen Einschränkungen. Die Browsereinstellungen kann man ändern, das ist also keine Sonderauflage, sondern ein ein Schritt zu Barrierefreiheit. Würde man die rein textbasierten Captcha ohne Cookie zulassen, hätte man wieder wie zuvor das Problem, dass Bots spielend leicht dran vorbei kommen.
Hätte der Teddy exakt die gleiche Haltung, hätten es Bots auch bei den Bildern zu leicht. Als mir vorhin im Test der Teddy gezeigt wurde und sämtliche anderen Tiere keine Teddys waren, wars für mich jedenfalls kein Problem, den Teddy trotz anderer Haltung zu finden. Aber wie gesagt im Normalfall sollte dir auch eigentlich gar kein Captcha angezeigt werden, melde dich, falls sich das wieder ändert. --Johannnes89 (Diskussion) 19:25, 5. Jun. 2026 (CEST)Beantworten
Ja, verstehe ich. Mit dem Teddy werde ich zur Not auch klarkommen. Ich muss halt etwas üben, um mein Kindergarten-Ich zu überlisten.:-)
Das mit den Browsereinstellungen werden Sehbehinderte möglicherweise anders sehen - jedenfalls die, die ich kenne. Die wissen schon sehr genau, was sie am Computer wie einstellen, und sowas wie Browsereinstellungen wählt man ja mit Bedacht. Sehbehinderte haben mit dieser Vorgabe nicht mehr die Freiheit wie ich, beim Verlassen des Browsers automatisiert alle Cookies löschen zu lassen.
Es wird jedenfalls nicht langweilig: Gerade habe ich einen - zugegebenermaßen für einen unangemeldeten Nutzer etwas gewagten - Bearbeitungsversuch gemacht, nämlich in diesem Artikel zwei sachfremde Abschnitte zu entfernen. Da kriege ich jetzt die sinnreiche Auskunft: "Es gab bereits zu viele Versuche, das Captcha zu lösen. Bitte warte einen Moment, bevor du es erneut versuchst." Ähm... es gab überhaupt keine Versuche. Es gab nämlich überhaupt kein Captcha.
Immerhin, beim zweiten Versuch geht die Bearbeitung durch. Ganz ohne Captcha. --~2026-33361-62 (Diskussion) 20:19, 5. Jun. 2026 (CEST)Beantworten
Bleibt noch die Frage, wie weit einem einzelnen Veranstaltungsbericht einer regionalen Tageszeitung vertraut werden darf? Alle anderen Quellen nennen nur Berlin ohne weitere Unterscheidung oder lassen den Geburtsort ganz weg, lediglich der MAZ-Bericht erwähnt beiläufig West-Berlin, ohne uns zu verraten, wo genau und woher die Information stammt. --Burkhard (Diskussion) 14:23, 5. Jun. 2026 (CEST)Beantworten
Beachte den Kontext: eine persönliche Begegnung, ein Interview, aus dem die Angabe zu West-Berlin als Geburtsort berichtet wird. Und: „Als Kind liebte sie Zeichentrick von Heidi oder Captain Future, einem Raumschiffkapitän mit breiten Schultern.“ Das deutet eher auf West-Berlin, auch wenn in Ost-Berlin „Westfernsehen“ geschaut werden konnte und wurde.
Und um die Antwort abzukürzen: In ihrem Blog schreibt Melanie Garanin unter 41/100 am 21. August 2018 selbst: „Früher, wenn wir aus Westberlin in die Ferien gefahren sind, erst Richtung Westen, dann vielleicht sogar in den Süden, auf der Autobahn die Landschaft entlang, gab es irgendwann den Moment, wo es ganz stark nach Kuhkacke roch.“
Btw sind Regionalzeitungen wie die MAZ, die die Hälfte des Bundeslandes Brandenburg abdeckt, nicht selten das Beste, womit wir etwas belegen können. Und wurde nicht gerade in einer überregionalen Zeitschrift damals relocisiert?! Ohne AGF kommen wir oft nicht weit.
Zustimmung zu Wi-luc-ky. Das TK hat in seinem Kommentar zur Änderung neben dem Verweis auf die MAZ auch auf genau das Blog verwiesen, das Wi-luc-ky hier zitiert, leider nicht so genau wie nötig. Und ebenso bedauerlich ist, dass die Blogsoftware keine IDs setzt, so dass man eben nicht so einfach direkt auf einen Beitrag verweisen kann. —Speravir – 22:30, 5. Jun. 2026 (CEST)Beantworten
Ahaa, es gibt außerdem einen Eintrag vom 27. September 2018. Also kann man sehr wohl auf einen einzelnen Eintrag verweisen, wenn man weiß, wie. Der andere wäre dann 21. August 2018 – und während ich das aufschreibe, fällt mir auf, dass hinter dem fetten schwarzen Text mit der Nummerierung über jedem Eintrag ein Link versteckt ist, hmpf. Burkhard, fühle dich frei, einen Beleg hinter dem Geburtsort zu setzen, wenn es dir wichtig ist. —Speravir – 22:41, 5. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 1 Tag4 Kommentare3 Personen sind an der Diskussion beteiligt
Wie kann man in einem Nicht-Wikimedia-Wiki Bilder finden, die nicht angezeigt werden bzw. nur ein Rotlink erscheint? Kann man das im Quellcode der geparsten Seite sehen? Wie? Wie geht das per Skript? (Mach eine Liste aller Seiten mit Bilder-Rotlink und gib den Bildlink und die Fehlerursache an;-) ) oder gibt es ein Mediawiki-Tool? Gruss, --Markus (Diskussion) 02:27, 5. Jun. 2026 (CEST)Beantworten
Danke:-) Ich verstehe aber das Intro nicht... Wenn ich das Tool auf WP anwenden, sehe ich auf Platz 6: "Datei:Flag of Germany.svg (142.389 Links)" als Link, blau durchgestrichen. Die Datei gibt es aber sowol auch Commons, als auch auf de:WP, das Bild fehlt aber in 140.000 Artikeln? Wenn ich das Tool auf ein fremdes Mediawiki anwende, sehe ich blau durchgestrichene Links und Rotlinks - was ist der Unterschied? Gruss, --Markus (Diskussion) 11:17, 5. Jun. 2026 (CEST)Beantworten
Die Deutschlandflagge liegt auf Commons und wird hier überschreibend eingebunden, das heißt einerseits gibt es die Datei (lokal!) nicht, andererseits wird sie aber trotzdem dargestellt, weil sie aus dem zentralen Mediendienst Commons übernommen wird (= Durchstreichung). Für Wikimedia-Wikis ist diese Spezialseite weitestegehend nutzlos.
1860 war das Jahr für die (Neu-) Gründung von Turnvereinen, siehe Sportjahr 1860. In Zeitungsartikeln werden Vereinsteams wie „TV Fürth 1860“ des Öfteren als „60er“ bezeichnet, siehe hier. Eine WP-Suche kann aber nicht wissen, welcher Verein mit 1860 im Namen gemeint ist, und müsste alle aufzählen, was unpraktisch ist, z.B. TSV 1860 München, TV 1860 Aschaffenburg, TSV 1860 Ansbach, TSV 1860 Hanau, TSV 1860 Rosenheim, TSV 1860 Stralsund, TSV 1860 Weißenburg, TSV Hagen 1860, TSV Spandau 1860, TuS 1860 Magdeburg-Neustadt, TuS 1860 Neunkirchen, TV 1860 Lich, TV Fürth 1860, VfL 1860 Marburg und MTV 1860 Altlandsberg. --T. Wirbitzki (Diskussion) 12:28, 5. Jun. 2026 (CEST)Beantworten
Ich verstehe die (noch dazu kommentarlose) Zurücksetzung auch nicht, das war eine korrekte und sinnvolle Ergänzung des Begriffsklärungshinweises, wie hier ja auch von Wi-luc-ky vorgeschlagen. --Luftschiffhafen (Diskussion) 15:18, 5. Jun. 2026 (CEST)Beantworten
Hier werden zwei unterschiedliche Fragen vermischt. Die ursprüngliche Frage von ~2026-33338-24 lautete, warum der (korrekte und sinnvolle) BKH von 60er auf Sechziger zwei Mal zurückgesetzt wurde. Welche Sportvereine man unter Sechziger listen sollte, ist eine ganz andere Frage, die vom Fragesteller überhaupt nicht gestellt wurde. --Luftschiffhafen (Diskussion) 23:14, 5. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 42 Minuten9 Kommentare7 Personen sind an der Diskussion beteiligt
Mit welchen Tools kann man unsere Artikel auf Textverständlichkeit prüfen/messen? Gab es dazu schon oder laufen derzeit Studien? Projekte? Anwendungen? Wer, was, wo? Gibt es eine KI die das kann? Wünschenswert wären konkrete qualifizierende quantifizierte Aussagen, die gewichtet werden - gefolgt von ebenso konkreten Verbesserungsvorschlägen... Gruss, --Markus (Diskussion) 16:23, 5. Jun. 2026 (CEST)Beantworten
Hallo, könnte um Umständen durch Anpassung des Prompts in
Vortrag 96. DTA (Juni 24) Man muss bei der Analyse auch aufpassen, zu kurze, einfache Sätze sind auch schlecht geeignet, da sie abgehackt und stakkatoartig wirken. Den Link von der WikiCon hat @Gimli21 oben schon geteilt. --Salino01 (Diskussion) 21:56, 5. Jun. 2026 (CEST)Beantworten
Eher nicht, wenn man Wortliga glauben kann. "Wir berechnen die Lesbarkeit aus verschiedenen Faktoren: aus der durchschnittlichen Wortlänge, der Satzlänge, der Anzahl zu langer Sätze und aus weiteren Meldungen der Checkliste" (https://wortliga.de/textanalyse/). Also das Übliche: Silben zählen, Wörter zählen. Mit Verständlichkeit hat das wenig bis nichts zu tun. --Mautpreller (Diskussion) 11:53, 6. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 20 Stunden1 Kommentar1 Person ist an der Diskussion beteiligt
Wer kann in diesem Artikel mal helfen, das Problem zu lösen, an dem die QS sich gerade die Zähne ausbeißt? Es geht darum, die Noten so zu platzieren, dass der Text vernünftig drumherum fließt und für die Mehrzahl der Bildschirme lesbar bleibt, ohne dass man mit Hilfskrücken wie mehreren erzwungenen Leerzeilen arbeiten muss. Danke, --~2026-33361-62 (Diskussion) 17:39, 5. Jun. 2026 (CEST)Beantworten
Letzter Kommentar: vor 12 Stunden8 Kommentare6 Personen sind an der Diskussion beteiligt
Das ist keine Frage zur Wikipedia, sondern ein persönliches Meinungsbild. Nach meiner Meinung müsste alle 2/3 Jahre eine etwa 10-köpfige Benutzergruppe beauftragt werden alle Artikel die von einer Bebilderung unterstützt werden nachzusehen ob die alte (mitunter nicht optimale) Bebilderung durch neuere bessere Fotos aktualisiert und optimiert werden können. Aber so wie es scheint ist noch niemanden in der Wikipedia-Community dies in den Sinn gekommen. Ein trauiger Umstand, Grüsse von der weitgehend inaktiven --Ricardalovesmonuments (Diskussion) 18:35, 5. Jun. 2026 (CEST)Beantworten
Da wir ein Gemeinschaftsprojekt sind, ist es an der Gemeinschaft, nicht nur Texte zu schreiben und diese zu bebildern, sondern auch die Inhalte - natürlich auch die Bilder - zu aktualisieren. Wer sonst soll das tun außer wir, die Gemeinschaft, selbst? Sei mutig! --Wosch21149 (Diskussion) 18:42, 5. Jun. 2026 (CEST)Beantworten
Wenn es eher um eine eher allgemeine Fragestellung und die mögliche Organisation eines solchen Vorgehens geht, würde ich antworten: Auf commons kann automatisiert abgefragt werden, wo ein Bild eingebunden ist, ebenso, ob das Bild einer spezifischen Kategorie zugeordnet ist, die mit dem Artikelnamen oder dessen Kategorie übereinstimmt. Nun könnte es eine automatisierte Abfrage geben, ob es zu dieser Commons-Kategorie aktuellere Bilder gibt. Daraus könnte eine automatische Liste generiert werden, die solche Artikel auflistet. Dann wäre händisch durchzugehen, ob das oder die neuen Fotos passen und geeignet sind, passen und ausgetauscht werden sollten. Es gibt bei Portraitfotos in Artikeln in anderen Sprachversionen eine automatische Aktualisierung, wenn ein aktuelleres Foto auf Wikidata eingefügt wird. Das nur als Hinweis, dass dort zumindest in einigen Sprachversionen eine (halb-)automatische Aktualisierung via WD stattfindet. --Jensbest (Diskussion) 18:56, 5. Jun. 2026 (CEST)Beantworten
Ok und diese 10 Personen sollen dann geschätzt 1 Mio Artikel durchgehen? Wie lange sollen die damit beschäftigt sein und was sagst du denen, wenn sie deine Bilder gegen bessere austauschen? --Itti19:13, 5. Jun. 2026 (CEST)Beantworten
Ich könnte mir vorstellen, dass man die Abfrage auf ein bestimmtes Artikelcluster anwendet. Dann bleibt die Zahl vermutlich auch hoch, aber innerhalb eines Rahmens, der ein Anfang und ein Ende hat. Außerdem helfen solche Cluster-Rahmen sicher für diese Arbeit thematisch oder regional interessierte Mit-Editor:innen zu gewinnen. --Jensbest (Diskussion) 19:23, 5. Jun. 2026 (CEST)Beantworten
Ricardas Vorschlag ist eher nicht praktikabel: Die Zahl der zu begutachtenden Artikel ist einfach zu groß, und der Ablauf auch schwer zu organisieren. Ricardas Vorschlag ist aber auch nicht sinnvoll: Man muss schon etwas vom Artikelgegenstand verstehen, um zu entscheiden, welche Bilder mit welchen getauscht werden sollen, bzw welche Bilder neu in den Artikel eingesetzt werden sollen. Es geht ja schließlich nicht darum, die schönsten, neuesten, höher aufgelösten usw Bilder zu finden, sondern die für einen enzyklopädischen Artikel am besten geeigneten. Übrigens: Schon der Respekt vor der Arbeit der Kollegen gebietet es, dass man einen Austausch immer fundiert begründet. ----Rufus4623:00, 5. Jun. 2026 (CEST)Beantworten
Es stimmt, dass in vielen Artikeln nicht die besten oder aktuellesten Bilder eingebunden sind, aber das lässt sich m.E. nur individuell und nicht irgendwie automatisiert beheben. Neuer heißt nicht automatisch besser geeignet. Ich achte beim Einbinden von Bildern in Artikel normalerweise nicht auf das Aufnahmedatum. Wenn Bauwerke in dieser Zeit nicht verändert wurden, kann auch ein zwanzig Jahre altes Bild noch aktuell sein. --Luftschiffhafen (Diskussion) 01:36, 6. Jun. 2026 (CEST)Beantworten
Ich habe mir den konkreten Fall nicht genau angeguckt, aber die in der Disk erwähnte Wiki-interne Suchmaschine halte ich persönlich für recht unausgegoren. Merke häufig, dass ich ein Lemma für einen Wikilink suche, aber nicht finde. Lege daraufhin häufig eine Weiterleitung an. -- Escla¿!00:18, 6. Jun. 2026 (CEST)Beantworten
--Entgegner (Diskussion) 06:52, 5. Jun. 2026 (CEST)
Wi-luc-ky, könntest Du mir bitte einen Anmelde-Ziellink hier noch einstellen ... Dankeschön. Grüße, --Wikisympathisant (Diskussion) 17:01, 3. Jun. 2026 (CEST)
(CallMyCenter) Der Kampf geht weiter! 13:43, 4. Jun. 2026 (CEST)
.
