Wikipedia

Wikipedia Diskussion:Projektneuheiten/Archiv/2020

< Wikipedia Diskussion:Projektneuheiten | Archiv
Letzter Kommentar: vor 2 Jahren von Wetterwolke in Abschnitt Beta-Feature: Replying

Zusätzliche Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten

Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Hi, wir denken, dass dieser Abschnitt auf WP:NEU gehört, wissen jedoch nicht in welchen Abschnitt er inhaltlich gut reinpasst. Habt ihr einen Vorschlag?

Hallo Max, danke für den Vorschlag, ich habe den Text umseitig in einen neuen Abschnitt "Feedback erwünscht" gesetzt. — Raymond Disk. 18:50, 26. Feb. 2020 (CET)

Neue Unicode-Software bringt Änderungen bei Kleinbuchstaben-Lemmata

Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Vorbemerkung: Wie ihr wisst, können in der deutschsprachigen Wikipedia eigentlich keine Lemmata mit Kleinbuchstaben beginnen. Durch eine Lücke im Unicode wurde in der Vergangenheit einige Dutzend Lemmata mit Kleinbuchstaben angelegt. Vermutlich meistens Weiterleitungen.

Bevor ein Wartungsscript die Umbenenungen automatisch durchführt, haben wir die Möglichkeit, vorher aufzuräumen. Geht aber natürlich auch noch später. — Raymond Disk. 21:26, 6. Apr. 2020 (CEST)

Übersetung von mailarchive:wikitech-ambassadors/2020-April/002281.html:

„MediaWiki wird eine neuere Version von Unicode verwenden. Einige Zeichen, die bisher keine Entsprechung in Großbuchstaben hatten, werden jetzt verwendet. Titel, die mit einem dieser Zeichen beginnen, werden verschoben. Eine Liste dieser Titel ist auf Phabricator zu sehen. Die Titel werden durch ein MediaWiki-Wartungsskript umbenannt. Dies wird am 13. April 2020 beginnen. Du kannst sie vorher umbenennen, wenn du es wünschst, und der neue Titel kann sich von demjenigen unterscheiden, in den das Skript ihn umbenennen würde.“

– Übersetzung mit DeepL

Kopie von Phab:P10817$291:

Es wäre zu prüfen, ob bei den Weiterleitungen die Groß- und Kleinschreibungen das gleiche Ziel haben. Und ich nehme an, dass später die Kleinschreibung ɱ → Ɱ automatisch aufgelöst wird, sodass keine Rotlinks entstehen? Mir leuchtet allerdings nicht komplett ein, wieso die Ligaturen verschoben werden. Da scheint es ja z.B. Nj, NJ und nj zu geben. Nj scheint also auch eine „Kleinschreibung“ zu sein? Wir sollten abwarten, bis die Seiten verschoben wurden und die Klammerweiterleitungen dann löschen, da bis zur Umstellung sonst Links ins Leere laufen. -- hgzh 21:18, 7. Apr. 2020 (CEST)
Was mich irritiert: Ƚ kam mit Unicode 4.1 dazu, der Kleinbuchstabe war schon vorher Bestandteil von Unicode und wurde spätestens mit Unicode 5.0 als korrespondierender Buchstabe genannt. Ꞩ und sein Kleinbuchstabe kamen mit Unicode 6.0 und waren bereits 2013 in phab:T55670 berücksichtigt (sah damals so aus: Broken/Ꞩ). Warum war das hier nicht der Fall bzw. warum konnte noch 2016 eine Kleinbuchstabenweiterleitung angelegt werden? -- 32X 02:50, 8. Apr. 2020 (CEST)

Mobile Hauptseite

Letzter Kommentar: vor 4 Jahren44 Kommentare8 Personen sind an der Diskussion beteiligt

Das Styling auf der mobile Hauptseite müsste vermutlich angepasst werden, siehe Task 254287: Final warning: Mobile main page special casing will be disabled July mit Anleitung. Mag vielleicht schon erledigt sind, aber sicher ist sicher. — Raymond Disk. 09:57, 5. Jun. 2020 (CEST)

Darauf bin ich auch gerade gestoßen; sieht für mich so aus, als wäre hier noch etwas zu tun. Es wäre die Frage, ob wir in diesem Zusammenhang gleich alles hauptseitenbezogene aus der Common.css auslagern wollen. -- hgzh 08:59, 16. Jun. 2020 (CEST)
Vielleicht hat Fundatus mit der Seite Wikipedia:Informationen zu COVID-19 auf Basis unserer Hauptseite und der Auslagerung eines wesentlichen Teiles nach Vorlage:COVID-19-Artikel in Verbindung mit Vorlage:COVID-19-Artikel/styles.css schon nützliche Vorarbeit geleistet. --Wiegels „…“ 10:10, 16. Jun. 2020 (CEST)
Bin gerne behilflich, falls es etwas zu tun gibt! Hatte mich schon gefragt, wie es die Startseite schafft, mobile-friendly zu sein. Das Mysterium scheint jetzt geklärt zu sein. :-) Fundatus (Diskussion) 11:31, 16. Jun. 2020 (CEST)

Ich wäre schärfstens für die Auslagerung aus dem MediaWiki-Namensraum.

  • Mittel der Wahl sind TemplateStyles; weil nur für eine einzige Seite relevant.
  • Vorlage:Hauptseite gibt es aber schon.
  • Würde heißen:
    • Wikipedia:Hauptseite/styles.css – unter Vollschutz
    • Wikipedia:Hauptseite/styles – zur Dokumentation
    • @XanonymusX: Deine Sichtungserfahrungen? Angenommen, das ist nach ein paar Tagen oder einer Woche robust und stabil, gibt es danach noch Sichtungszank?
  • Ggf. auch EInbindung auf einigen Unterseiten mit zugelieferten Komponenten zum vorherigen Testen, also AdT und so Zeugs.
  • Zurzeit wird auf jeder der -zig Millionen URL-Konstellationen versucht, das CSS auf die HTML-Elemente in der Seite anzuwenden, was logischerweise nur mit miserabler Trefferchance unter allen URL greifen kann. Wobei natürlich die Abruffrequenz der Hauptseite deutlich über der anderer URL liegt.

VG --PerfektesChaos 12:19, 16. Jun. 2020 (CEST)

Volle Zustimmung von meiner Seite. Da wir uns hier nur innerhalb des WPNR bewegen (zum Glück steht unsere Hauptseite nicht im ANR), brauchen wir uns wegen des Sichtungsbugs keinen Kopf zu machen. Gruß—XanonymusX (Diskussion) 13:07, 16. Jun. 2020 (CEST)
Äh, ja, stimmt, danke. Ist ja so wie geplant; Projektseite-CSS eingebunden in andere Projektseite und nicht das Abenteuer neulich mit Projektseite-CSS eingebunden in Artikel usw. VG --PerfektesChaos 13:36, 16. Jun. 2020 (CEST)
Habe mal Wikipedia:Hauptseite/styles.css angelegt, ein mitlesender Admin möge bitte das ContentModel auf Sanitized CSS stellen! Ist aktuell nur eine Kopie der common.css, muss dann entsprechend angepasst/ergänzt werden (kann ich machen, wenn ich mich eingelesen habe, aber vermutlich wissen hier einige schon besser Bescheid). Gruß–XanonymusX (Diskussion) 16:58, 16. Jun. 2020 (CEST)
Vielleicht bekommt man bei der Gelegenheit die ollen Layout-Tabellen weg. Und die allgemein gehaltenen Bezeichner .intern .inhalt .main .portale sollten mE noch ein hauptseite- davor spendiert bekommen. Gruß, -- hgzh 17:32, 16. Jun. 2020 (CEST)
Danke! Ja, Bezeichner ist klar. Layouttabellen lösen wir derzeit auch an anderen Stellen auf, das sollte zu schaffen sein.–XanonymusX (Diskussion) 17:38, 16. Jun. 2020 (CEST)
Zur Entwicklung: Wikipedia:Hauptseite/Neu. –XanonymusX (Diskussion) 17:42, 16. Jun. 2020 (CEST)

Ist soweit alles im Trockenen (bis auf die gesperrte Wikipedia:Hauptseite/Wikipedia aktuell, müsste dann beim Liveschalten ebenfalls ein hauptseite- vor die Klassen bekommen). Es stellen sich allerdings Fragen nach der genauen Gestaltung der mobilen Hauptseite.

  1. Wo wurde denn damals beschlossen, wie die mobile Hauptseite auszusehen habe und welche Elemente dort entfernt werden sollten? Wäre es denkbar, wie aktuell ausprobiert, einen reduzierten Begrüßungsblock vor dem Artikel des Tages einzublenden (nach Vorbild der enWP)? Fehlen dann weiterhin WP aktuell und die Schwesterprojekte.
  2. Soll die extrem reduzierte Gestaltung wirklich beibehalten werden? Man könnte genausogut die Blöcke bei gleichbleibendem Design einfach nur untereinander setzen, das würde den Kontrast zwischen mobiler und klassischer Startseite deutlich reduzieren.
  3. Ich spiele aktuell ein bisschen mit Bildschirmbreite vs. Skin. Die mobile Hauptseite sollte erst ab 720px Bildschirmbreite Anwendung finden, nicht wie jetzt bei jeder Breite, aber nur in Minerva. Das Ausblenden einzelner Blöcke lasse ich hingegen weiterhin nur in Minerva zu (man sollte ja doch die Möglichkeit bekommen, durch Umschalten der Ansicht auf alle Inhalte zuzugreifen). Gibt es Widerspruch, die Hauptseitendarstellung vor allem breiten- statt skinabhängig zu machen?

Fragt sich natürlich, ob man das hier im Hinterzimmer beschließen kann (aber mir scheint, das wurde bei Einführung ähnlich gemacht, oder?). Bitte um ein paar Rückmeldungen! Gruß–XanonymusX (Diskussion) 20:19, 16. Jun. 2020 (CEST)

Ich möchte gern, dass die beiden Versionen noch als dieselbe de-Wikipedia wiedererkannt werden können.
  • POLS
  • Wenn von Desktop → mobil → Desktop → mobil gewechselt wird, dann soll man sich nicht auf einem anderen Planeten wiederfinden.
  • Heißt: Auf einem sehr schmal gezogenen Desktop müsste die gleiche Anordnung der Blöcke wie mobil entstehen. Momentan zwangsweise zweispaltig; hier erwarte ich umflutschen auf einspaltig.
  • Farben der Blöcke und Titelzeilen sollen beim langjährig gewohnten Design bleiben.
Was sich ändern darf, wären möglicherweise Abstände oder Schriftgrößen, aber die bilden sich eigentlich von selbst geeignet ab.
  • Unterschiedliche Elemente gäbe es bei aktiven Formularen; aber auf der Hauptseite ist nix aktiv.
  • Wenn, dann läuft das andersherum: Spezial:Anmelden@Desktop ist gerade ein einspaltiges vertikales Smartphone.
Navigation mag anders sein, vielleicht ein eingeblendetes statisches Rubriken-Inhaltsverzeichnis mobil, das aber auch ein schmaler Desktop sehen würde.
  • Auf schmalen Bildschirmen könnte man die oberste Kiste mit den Rubriken ggf. entrümpeln; d.h. die Themengebiete verschwänden. „Mitmachen“ ist fundamental und muss dort bleiben, „Statistik“ und „Sprachversionen“ wären auf schmalem Bildschirm verzichtbarer, „Archiv der Hauptseite“ kann wegflutschen. Konzentration auf das Wesentliche bei schmaler Breite im Kopfbereich. Die Schwesterprojekte im Seitenfuß stören nicht.
  • Alle Rubriken-Boxen blieben erhalten; stehen halt nur in einer Spalte untereinander.
Im Wesentlichen erwarte ich dynamisches grid-flex-float-flow-Dingens-Zeug für die bisherigen Boxen, die ab hinreichender Bildschirmbreite zweispaltig werden wie bisher.
  • Tablet mag mobil sein, kann aber ggf. zweispaltig ab.
Von Begrüßungen anonymer Leser durch herzausgießende Umarmungen halte ich wenig. Es soll klarwerden, wo ich bin, Jubelschreie zum Willkommen brauchen wir nicht. Glaubt sowieso niemand, dass jahrelang identische Gefühlsausbrüche an Millionen Besucher ehrlich gemeint wären.
Die Hauptseiten-Diskussionsseite wäre dann Entscheidungsgremium nach Erstellung der technischen Musterlösung. Wenn Desktop inhaltlich und vom Basis-Design unverändert bleibt, und mobil sich nur aus Platzgründen geringfügig von Desktop unterscheidet, gibt es da nicht viel rumzubeschließen.
VG --PerfektesChaos 21:11, 16. Jun. 2020 (CEST)
Okay, WP:Hauptseite/Neu leistet vom Layout und von den angezeigten Elementen aktuell schon mehr oder weniger, was du dir wünscht. Wenn ich dich richtig verstehe, möchtest du aber lieber eine gleichbleibende Formatierung der Blöcke (betrifft Titelzeile und Rahmen, sonst wird da ja nicht sehr viel gemacht) in beiden Ansichten, abweichend von der bisherigen Praxis. Das wäre auf jeden Fall eine Umstellung, deshalb war ich da noch zögerlich. So wie ich es im Moment umsetze, bilde ich die bisherige reduzierte Formatierung nach; würde mich wirklich interessieren, wie die damals zustandegekommen ist.
Thema Begrüßung: Ich hab nicht herausgefunden, wie in der aktuellen mobilen Minerva-Hauptseite die Zeile „Willkommen, BENUTZER!“ im pageHeading erzeugt wird, die bleibt wohl weiterhin unabhängig von unserer sonstigen Hauptseitengestaltung.
Ach so, und Titel und Kategorien müssen wohl weiterhin via Common.css ausgeblendet werden, da TemplateStyles darauf nicht zugreifen können; sonst kann dort alles raus.
Gruß–XanonymusX (Diskussion) 21:45, 16. Jun. 2020 (CEST)

Sieht ganz gut aus. Der Unterschied ist jetzt, dass auch auf dem Desktop bei geringer Breite die Kästen wegfallen. Halte ich aber für sinnvoll, denn in der Anordnung übereinander braucht man diese optische (horizontale) Gliederung nicht mehr und sie nehmen sowieso Platz weg, außerdem werden nur wenige die Dektopansicht dermaßen schmal anzeigen. Würden wir jetzt auch schmal-mobil die Kästen darstellen, gäbe es wieder ellenlange Diskussionen und es würde zurecht auf fehlenden Konsens für diese Änderung hingewiesen. Also Zustimmung zu Punkt 3, die Darstellung breiten- statt skinabhängig zu machen. An den Inhalten der Hauptseite Dektop/mobil würde ich aus dem gleichen Grund wie zuvor erstmal auch nichts ändern, angepasst wäre das später ja schnell. Optimierungspotenzial gibt es noch beim obersten seitenbreiten Kasten (hauptseite-oben): der wird bei breiten Dektopbildschirmen nicht auf 100% expandiert. Jedenfalls vielen Dank für deinen schnellen Einsatz in der Sache. -- hgzh 22:50, 16. Jun. 2020 (CEST)

Ah, stimmt, ist jetzt stabil auf 100%!–XanonymusX (Diskussion) 22:59, 16. Jun. 2020 (CEST)
Aus meiner Sicht kann das so übernommen werden. Dass der Begrüßungstext mit dem Hinweis auf Mitarbeit jetzt immer angezeigt wird, ist vielleicht gar nicht schlecht, denn bisher ist die Mobilversion da ja sehr spartanisch. Und wie gesagt, ausgeblendet ist es schnell. Lassen wir mal die anderen noch ausgeschlafen drüberschauen, dann kann ich das auf die Haupt-Hauptseite rüberschaufeln (wollte die schon immer mal bearbeiten ;)) Gruß, -- hgzh 23:16, 16. Jun. 2020 (CEST)
Wäre mir recht, ich finde das aktuell einen guten Kompromiss, erstmal minimalinvasiv! :) Wenn die Minerva-Willkommensnachricht am Anfang bleibt, ergänzt sich das auch gut mit dem reduzierten Begrüßungstext. Gruß—XanonymusX (Diskussion) 23:21, 16. Jun. 2020 (CEST)
Diese 3.500+ Fälle dürften für eine komplette Auslagerung aus der Common.css übrigens noch ein Problem darstellen … —XanonymusX (Diskussion) 12:36, 17. Jun. 2020 (CEST)
Also, ich sehe da viele Sprungziele.
Es gibt übrigens keine Gewährleistung, dass ein speziell für eine ganz bestimmte Projektseite vorgesehenes Design auf ewig auch dazu geeignet sein muss, irgendwelche Portale und Wikiprojekte kompatibel zu gestalten.
Wer das Design unbedingt haben will, kann die TemplateStyles einbinden und seine ID anpassen.
Es gab niemals eine Zusicherung, dass dies offizieller Projektstil für alle möglichen Seiten sein würde, der auf ewig unterstützt und für irgendeine andere als die eine vorgesehene Seite bereitgestellt und gepflegt werden würde.
Ist wie mit den Leutchen, die sich die MediaWiki-Klassendefinition vom TOC-Stil abgreifen und erwarten, dass dies auf ewig ihr Zeugs gestalten würde. MediaWiki darf den TOC-Stil von einem Tag auf den anderen ändern, und die Klassennamen komplett ändern, und muss niemanden fragen und es sind auch keine Beschwerden zulässig.
Irgendwann später, vermutlich in kühlen Nachtstunden, mehr von mir zur Designstruktur.
VG --PerfektesChaos 12:47, 17. Jun. 2020 (CEST)
Der Löwenanteil davon entfällt auf die Hauptseitenarchive, die man relativ einfach per Bot umstellen könnte. Aber du hast Recht, das wird dauern. Kommen sich die Common.css und die TemplateStyles in die Quere? -- hgzh 12:53, 17. Jun. 2020 (CEST)
TemplateStyles gleicher Spezifität kommen in der Kaskade dahinter und haben Vorrang.
Es gibt keinerlei Grund, die optische Aufbereitung archivierter Seiten irgendwie konstant zu halten; wenn überhaupt ginge es um die Inhalte.
Wenn ich das richtig deute, dann ändern sich auch die Selektoren, und die auf der produktiven Hauptseite wirksamen Elemente (Tabelle, div usw.) und deren Attribute. Eine Kompatibilität zu irgendwas ist nicht relevant; die produktive Hauptseite hat robust und effizient gestaltet zu sein. Der Rest fliegt dann aus der Common.css und wer das mit Ausnahme an der aktullen produktiven Gestaltung beteiligter Unterseiten anguckt sieht halt nur stillose Inhalte; Ende.
LG --PerfektesChaos 13:33, 17. Jun. 2020 (CEST)
Inkompatibilitäten sind kein Problem, also kann man das nach und nach ausmerzen. Was die Hauptseitenarchive angeht, würde ich vorschlagen, über Wikipedia:Hauptseite/Archiv/Vorlage für alle Seiten vor dem Stichtag ein eigenes Stylesheet nur mit den bisherigen Styles einzubinden; beim Hauptseitenarchiv geht es ja nicht nur um die Inhalte, sondern es soll eigentlich eine Momentaufnahme gezeigt werden. Wenn wir die archivierten Seiten einfach so lassen, fehlen dann bei sämtlichen alten Versionen die Rahmen- und die Überschriftformatierung, was einfach nicht dem Aussehen der Hauptseite zu dem Zeitpunkt entspricht. Würde ich dann einrichten, wenn die aktuelle Hauptseite umgestellt ist; erspart uns einen Botlauf. Andere Seiten, die mit div#hauptseite gespielt haben, dürfen hingegen je nach Bedarf selber nachziehen, aber sind zum Glück nicht viele. Gruß–XanonymusX (Diskussion) 16:13, 17. Jun. 2020 (CEST)
Naja, wenn irgendein Herz dranhängt, dann Wikipedia:Hauptseite/Archiv/styles.css mit dem eingefrorenen Common.css von heute, und einer kurzen Erläuterung auf Wikipedia:Hauptseite/Archiv/styles, und diese dann ggf. datumsabhängig vor/nach Stichtag einbinden Wikipedia:Hauptseite/Archiv/styles.css → Wikipedia:Hauptseite/styles.css und dann mögen auch die Wikihistoriker damit glücklich werden.
Wobei das über die Jahrzehnte auch nicht 1:1 sicher ist; aber in das vor Stichtag stehen alte Selektoren und alte styles, und danach andere Elemente mit anderen Selektoren.
VG --PerfektesChaos 16:26, 17. Jun. 2020 (CEST)
Genau. Ganz pingeligen Historikern steht dann ja immer noch die Möglichkeit offen, selbst auszuforschen, wie sich die Styles in der Common.css mit der Zeit geändert haben und entsprechend wechselnde Stylesheets einzubinden; ich werde es auf diesen einen Wechsel beschränken. Gruß–XanonymusX (Diskussion) 16:35, 17. Jun. 2020 (CEST)
Ist noch irgendwo Verbesserungspotenzial vorhanden? Sonst würde ich die Hauptseite morgen über den Tag umstellen. -- hgzh 18:50, 17. Jun. 2020 (CEST)
Ich selbst bin noch gar nicht zum reingucken in die Details gekommen, und zur Vermeidung von Zwergenaufständen müsste anschließend die hier im Hinterzimmer abgestimmte technische Lösung für wenigstens drei Tage auf WD:Hauptseite einem anderen Personenkreis angekündigt werden, sonst kommt mal wieder Zwergenaufstand.
Ich erwarte keine dramatischen Änderungswünsche von irgendeiner Seite, aber eine Umstellung sollte möglichst mit einem Wurf gelingen, vielleicht noch mit kleiner Nachpolltur in nicht vorhergesehenen Details. Aber kein Zickzack und wiederholtes Umschmeißen aller Konzepte.
Ich habe den WMF-Ankündigungskram nicht im Detail mitgelesen, wie eilig sind die denn? Gibt es morgen eine Deadline? will be disabled July klingt nach noch einer Woche Zeitpuffer.
VG --PerfektesChaos 19:25, 17. Jun. 2020 (CEST)
Es eilt erstmal überhaupt nicht, falls das so rübergekommen sein sollte. Andererseits halte ich die Änderungen letzten Endes auch für so trivial, dass sie auch eher umgesetzt werden könnten. Gruß, -- hgzh 19:33, 17. Jun. 2020 (CEST)
(BK) Konkrete Deadline ist der 13. Juli! Mit der jetzigen Lösung wäre die einzige nennenswerte Änderung der hinzukommende kurze Begrüßungsblock für Mobilgeräte, kann man meinetwegen auch gerne noch an anderer Stelle ankündigen. Ich hab keinen Stress, Umsetzung innerhalb einer Woche klänge aber vernünftig. Gruß–XanonymusX (Diskussion) 19:35, 17. Jun. 2020 (CEST)

Wenn schon, dann ein einziger großer Wurf mit kompletter technischer Reorganisation 2020, statt monatelang viele kleine Frickeleien, durch die am Ende niemand mehr durchblickt.

  • Einmalig großen technischen, für Normalbenutzer kaum wahrnehmbaren Umbau durch die HS-Community absegnen lassen, statt fünfmal damit anzudackeln.

Die Hauptseite sollte webdesigntechnisches Vorbild für state of the art werden. Nachstehend teils bereits umgesetzte, teils noch zu realisierende weitere Änderungen in den Bereichen:

  • Ein- oder mehrspaltig
    • Es geht weniger um mobil./.Desktop, sondern mehr um breiter./.schmaler und damit die Frage: ein- oder mehrspaltig; knapp an Platz oder nicht.
    • Kann man @media nicht auch auf rem statt px basieren? Das würde die individuelle Schrifteinstellung besser abbilden, und uns geht es weniger um Pixel als um die Menge an Buchstaben in einer Zeile. Leute mit schlechten Augen haben vielleicht viele Pixel, aber wenige Buchstaben. Kriegt das @media eine Zoom-Funktion mit und arrangiert neu? 25rem oder sowas mögen einen schmalen Bildschirm meinen.
    • Kinoleinwand
      • Es sollte bei dieser Gelegenheit statt nur 1-/2-spaltig auch vielspaltig unterstützt werden.
      • Auf HD können Webseiten in abenteuerlicher Breite dargestellt werden.
      • Die Boxen müssten eine Maximalbreite analog zur Zeilenlänge erhalten, vielleicht 50em ≈100 Buchstaben/Zeile
      • Es müsste dann ein grid-flex-dings-Layout werden, mit dem Einleitungsabschnitt zentriert und in begrenzter Zeilenlänge über allen, und darunter als dynamisches Puzzle die Rubriken-Boxen auch in vier oder fünf oder was weiß ich wie vielen Spalten nebeneinander. Also nicht mehr hauptseite-links und hauptseite-rechts.
      • Ziel ist, dass auf HD-Großbildfernseher die komplette Hauptseite ohne zu scrollen dann nebeneinander gelesen werden kann, statt wie bisher zweispaltig nach unten scrollend.
      • Die Schwesterprojekte können dann zu einer einzeiligen zentrierten Box zusammenschrumpeln.
    • Es gibt mit TemplateStyles dann keine Aufspaltung in Minerva./.Commons mehr, sondern nur noch in schmal oder breit. Ob Tablet, Timeless oder sonstwie ist egal.
  • Barrierefreiheit
    • Auf der zentralen und maximal abgerufenen Seite müssten dann auch die in den letzten Jahren stärker umgesetzten Techniken zur Barrierefreiheit genutzt werden. Felder sind:
      • Keine Icons, keine Bilder, nur noch Nettotext, weil es auf der HS keine enzyklopädisch wichtigen Illustrationen gibt.
      • breadcrumb für Navigation
      • role=contentinfo/navigation wo zutreffend
      • Keine Layout-Tabellen, aber das scheint ja bereits umgesetzt zu sein.
    • Die Icons bei der Navigation über die Themenfelder müssen als redundant markiert werden.
    • Illustrationen (eye-catcher) in AdT usw. müssten per Vorlagenparameter eingebunden werden, können damit zentral attribuiert werden. Siehe etwa ICON@Vorlage:Hinweisbaustein.
    • Die Navigation über die Themenfelder und Schwesterprojekte per breadcrumb, siehe Vorlage:Subpage/styles. Diese aber ausschnittsweise kopieren, unter Beibehaltung der Klassennamen, aber nicht einbinden, sonst wird mir das kaskadierend lahmgelegt.
    • Schwesterprojekt-Icons als redundant markieren; breadcrumb.
    • <section>section</section> dürfen wir ja noch nicht. Beißt sich sowieso mit MW-Elementnamen, superschlauerweise. <nav>nav</nav> haben wir auch nicht.
  • Platzmangel-Version straffen
    • Die Auswahl über Icon+Themenfelder bei einspaltig raus; es navigiert sowieso niemand von Geo → Kontinente → Staaten → Städte → Zürich, sondern gibt das ins Suchfeld ein.
    • Ist auch nichts anderes als die Haupteinstiegspunkte eins drunter; „Artikel nach Themen“ + „Artikel nach Kategorien“.
    • Die einleitenden Sätze ggf. teilweise ausblenden; was ist wesentlich, was ist redundant?
    • Service-Links reduzieren; Mitmachen ist sehr wichtig, Presse sicher auch; Statistik ist Selbstlobhudelei die keinem hilft und das Archiv habe ich noch nie wahrgenommen; mindestens letztere beiden ausblenden. MP und Kontakt, Gesprochene Wikipedia sind hochrangig.
    • Rahmen-Linien sind auf einspaltig redundant, wie oben von hgzh schon völlig richtig angemerkt; kosten nur Platz. Blieben also nur die (noch umrandeten) helblauen Titelleisten beim Durchscrollen.
    • Schwesterprojekte stehen im Fußbereich und stören dort nicht.
  • Platzmangel-Version um Elemente ergänzen
    • Die einspaltige Version noch vor der Einleitung mit breadcrumb-TOC über die Rubriken ausstatten.
    • Ggf. wichtige Sidebar-Elemente hinzufügen oder das für die Zukunft einplanen; aber „Mitmachen“ wird dort bereits gelistet. Mehr?
    • Platzmangel-Version mit #top-Links in den titlebars?
  • Einleitungsabschnitt
    • Braucht der einen Rahmen? Zumindest einspaltig nicht.
    • Unsere Artikel haben an der Stelle auch keinen Rahmen.
    • Bei 3- oder 4-spaltig wäre es die Frage.
  • Begrüßung
    • Ein schlichtes „Hallo“ oder „Willkommen“ mag angehen.
    • Das ist aber nur als Reaktion auf das Login sinnvoll und signalisiert mir, dass der Anmeldevorgang erfolgreich war.
    • Ich kann schon eine Viertelstunde in anderen Artikeln gewesen sein und komme dann auf die Hauptseite, und werde jetzt als frisch eingetroffen begrüßt. Das ist gaga.
    • Die Titelleiste des Einführungsabschnitts schadet nicht, hilft aber auch nichts.
    • Psychologen raten von herzlichsten Gefühlsausbrüchen ab, weil kontraproduktiv. Jeder Besucher weiß, dass das vor Jahren mal ein Programmierer getippt hatte, der noch gar nicht wissen konnte, wer da mal hinkommt. Den jetzt als alten Kumpel übervertraulich abzuknutschen, und das neben Millionen anderer Leute gleichermaßen, ist dissonant und schadet eher.
  • Wir können ja auch mehrsprachig.
    • Einleitungsabschnitt auf Englisch wenn keine bekannte Deutsch-nahe Benutzersprache?
    • Ggf. Unterseiten /Einleitung/en und /Einleitung/fr usw.
  • Weil oben angefragt: Mobil-Design
    • Das war hier mal erarbeitet worden, als Mobilgeräte mit online ganz neu waren.
    • Bis dahin war auf Mobilgeräten ein statischer offline-Dump installiert worden.
    • Kaum jemand hatte Online-Mobil, und eine Handvoll Nerds hatten mit damaligen Mitteln was gebastelt.
    • Ich sehe keinerlei Notwendigkeit, stilistische Fummeleien von damals zu konservieren; außer der Überschrifts-Ausblenderei bleibt da nix. Breit oder schmal und gut ist.
  • Sieht mir nach Entwicklung auf BETA aus, wobei der Seitenname dort bereits blockiert wäre.

Nachdem hierorts technische Realisierung abgenommen, dann Präsentation auf WD:HS für die dortigen Mitleser; dabei Aufzählung der neuen Features plus Deadline.

  • Dort 3–7 Tage aushängen.
  • Wenn keine wesentlichen neuen Aspekte dann fristgerecht umsetzen, kleinere Verfeinerungen unbürokratisch einarbeiten.

Viel Spaß --PerfektesChaos 13:02, 18. Jun. 2020 (CEST)

Puh, ambitious much! o.O Ich schau mir das im Lauf des heutigen Tages alles noch im Detail an … —XanonymusX (Diskussion) 13:39, 18. Jun. 2020 (CEST)
Also, kurz und ungeordnet:
  • Breiten: Ich halte mich an die MediaWiki-Standard-Breakpoints, bis 720px (oder genauer 719px, wenn ich das richtig lese, aber das finde ich vernachlässigbar) wird ein Mobilgerät angenommen. Bis jetzt habe ich alle responsiven Styles in Vorlagen etc. mit diesem Wert angelegt, das würde ich gern beibehalten. Wenn sich sonst auf einer Seite verschiedene Breakpoints überschneiden, ergibt das unschöne Effekte.
  • Vielspaltig: Klingt interessant, dann wären die „Spalten“ ganz aufzulösen. Bei der geringen Anzahl Elemente, die wir auf der Hauptseite haben, ist das sicher kein Kunststück, kann ich mal probieren; bloß „Wikipedia aktuell“ stört da ein bisschen.
  • Barrierefreiheit: Kann (und sollte) man alles machen, ich kenne mich damit freilich nicht besonders gut aus, da müsstest dann eventuell du vor Fertigstellung noch mal ran. Aber schaue ich mir auch noch genauer an.
  • Breadcrumbs: Hab ich nicht wirklich verstanden, was genau soll damit dargestellt werden und wo?
  • Begrüßung: Falls phab:T255682 gelöst wird, würde ich dafür plädieren, die Begrüßungszeile ganz zu entfernen. Bis dahin müssen wir die für Minerva mal mit einkalkulieren.
  • Top-Links: Wenn wir die bislang ausgeblendeten Elemente tatsächlich für die Mobilversion zurückholen, dann sicher sinnvoll.
Von wie auch immer gearteten sichtbaren Änderungen der klassischen Hauptseite (also bei Normalbreite) rate ich dringend ab, dann wird das nämlich nie umgesetzt. Der schmalen Version die formatierten Titel und ein paar mehr Inhalte zurückzugeben, dafür bin ich offen. Mehrsprachigkeit kann man gerne auch machen (das aber natürlich breitenunabhängig).
Ich mach mich mal ans Werk. Gruß–XanonymusX (Diskussion) 15:13, 18. Jun. 2020 (CEST)
Vorab zu einigen Punkten:
  • Breiten – mich interessieren keine Pixel, keine Bilderchen, und auch nicht, als was für ein Smartphone etwas klassifiziert wird.
    • Mich interessiert, wie man vielleicht 50 Buchstaben Proportionalschrift in einer Zeile dargestellt bekommt.
    • Wenn jemand nicht gut gucken kann und sich sein Was-auch-immer-Gerät auf eine Schriftgröße von 24px oder 30px eingestellt hat, dann muss sich die Länge der Textzeilen nach der Anzahl der üblichen Buchstaben richten, wurscht wie viele Pixel das auf welchem Gerät wären.
    • Da kommt bauchmäßig was wie 20rem oder auch 25rem für unsere textbetonte Hauptseite als Mindest-Zeilenlänge heraus.
    • Es interessiert mich nicht die Bohne, was irgendwer auf irgendwelchen MediaWiki-Standard-Breakpoints für allgemeines Bildchen-Text-Design schreibt; ich pflege mit eigenem Kopf zu denken.
  • Spaltenkonzept – ich hatte mir letzte Nacht schon durchaus einen Weg zurechtgelegt, sonst würde ich kein absolut unrealisierbares Konzept vorschlagen.
    • Brauche aber die kommenden kühlen Nachtstunden, um das näher zu skizzieren; jetzt bin ich groggy, überhitzt, sonnenverwöhnt und müde und formatier nur noch auf Sparflamme.
    • Code-Details und Erprobung habe ich nicht auf dem Zettel, aber eine Konzeption.
  • Barrierefreiheit – helfe ich gern praktisch, Routine für mich
    • Spezial:Diff/201092490 ist schon erster Ansatz. (Wieso konnte ich das denn bearbeiten? Ich dachte immer, was auf der HS eingebunden sei, hätte kaskadierenden Vollschutz?)
    • Heute nacht auf BETA etwas auch zu Breadcrumbs als Muster; habe ich im Hinterkopf schon bis auf das letzte Byte kodiert, bekomme aber bei Sonnenschein nichts mehr auf die Kette und in die Tasten.
    • Wikipedia:Hauptseite/Schon gewusst müsste eine einzubindende Mustervorlage für alle Tage werden ähnlich Vorlage:AdT-Vorschlag, die für alle Tage die einheitliche Formatierung übernimmt.
  • Breadcrumbs
    • Anzuwenden auf:
      • TOC bei einspaltig
      • Themengebiete
      • Wichtige interne Seiten
      • Schwesterprojekte
    • Ich mache da mal heute nacht ein Muster.
  • Top-Links – ich dachte da eher an unseren eigenen kleinen Pfeil; theoretisch mit geeignetem Begleittext für Screenreader. Wobei die aber eigene Möglichkeiten hätten, mittels Tasten an einen Startpunkt zu navigieren; die brauchen den eher nicht und sind auch selten mit einem Mauszeiger zugange.
Bis dann --PerfektesChaos 16:11, 18. Jun. 2020 (CEST)
Einschub: Die Hauptseite ist schon seit ziemlich genau zehn Jahren nicht mehr kaskadierend geschützt. Gruß, -- hgzh 10:53, 19. Jun. 2020 (CEST)
Mein angepasstes Konzept ist jetzt auch wieder auf WP:Hauptseite/Neu live. Gruß–XanonymusX (Diskussion) 17:04, 18. Jun. 2020 (CEST)
Nachtrag: Habe mich übrigens doch getraut, eine sichtbare Änderung einzubauen: Die beiden Spalten in der klassischen Ansicht sind jetzt gleich hoch, entstehender Leerraum wird zwischen den einzelnen Kästen aufgeteilt. Ist die Frage, ob das alle mögen, ich fand es aber jedenfalls sinnvoll. Müsste aber noch wegen Browserkompatibilität getestet werden.–XanonymusX (Diskussion) 18:27, 18. Jun. 2020 (CEST)
Also bei mir kriegt die neue Hauptseite bei 1750px Bildschirmbreite plötzlich einen Schlaganfall und wird sechsspaltig. Das ist übrigens das Erscheinungsbild, was auf den meisten modernen Desktop-Computern zu erwarten ist (etwa 1900px Bildschirmbreite). Das sieht wirklich nicht gut aus (Zeilenumbrüche etwa alle 4 Wörter) und ist vielleicht auch nicht so gedacht. Die Spalten sind extrem nicht gleich hoch (wenn die raumfüllend nach unten wären, fände ich das noch akzeptabel). 3 Spalten fände ich da vielleicht einen besseren Ansatz. --MGChecker – (📞| 📝|  ) 01:56, 19. Jun. 2020 (CEST)
Ja, ich kann leider nur mit Zoom-Stufen testen, große Bildschirme hab ich keine. Mein Ansatz ist der, die zwei Grundspalten beizubehalten und innerhalb derer umzustellen. Der Breakpoint kann natürlich noch beliebig angepasst werden (irgendwo um 1700px läge wohl einer, liest man online, aber wie gesagt, mir sind solche Bildschirme unbekannt). Die unausgeglichenen Höhen gefallen mir auch nicht. Alles beweglich zu machen ist möglich, halte ich aber für riskant, denn das führt höchstwahrscheinlich zu sichtbaren Veränderungen für zu viele Benutzer, und das kriegen wir hier dann nicht einmal mit einem MB durch. Ich warte da mal lieber auf Alternativvorschläge, sonst können wir immer noch zur Vorversion mit maximal zwei Spalten zurückkehren. Gruß–XanonymusX (Diskussion) 03:05, 19. Jun. 2020 (CEST)
Ich wäre sehr dafür, die zwei Spalten beizubehalten, denn diese Sechseranordnung ist nun wirklich alles andere als ansehnlich. Können wir nicht einfach eine Maximalbreite definieren, ab der nicht mehr expandiert wird? -- hgzh 10:53, 19. Jun. 2020 (CEST)
Ja, das ist sicher auch ein Ansatz; hab das bei den Kästen Willkommen und Schwesterprojekte schon eingebaut, man könnte die zwei Spalten dann einfach so begrenzen, dass der gesamte Inhalt mit oben und unten einen ausgeglichenen Block bildet.—XanonymusX (Diskussion) 11:26, 19. Jun. 2020 (CEST)

Das Problem haben die Leute mit einem sehr breiten aber niedrigen Browser-Bildschirm, insbesondere HD.

  • Bei denen sieht zweispaltig wirklich matsche aus, und dort muss vertikal gescrollt werden und links und rechts oder nur rechts sind riesige Freiflächen.
  • Man kann aber die Limits für die Zeilenlängen so hoch setzen, dass drei Zeilenlängen von vielleicht 100 Buchstaben nebeneinander auf einem „normalen“ Desktop nicht mehr auftreten würden, und wer halt ein Browserfenster für eine Zeilenlänge von 350 Buchstaben hat, der kann auch dreispaltig ab.
  • Richtig ist grundsätzlich und unabhängig von zwei- oder dreispaltig, dass bestimmte Boxen immer ein Breitenlimit bekommen sollten, damit nicht 200 oder 300 Buchstaben in einer Textzeile stehen, sondern die Boxen irgendwann begrenzt werden. Ich bin ja grad an den projektweiten Standard-/Hinweisbausteinen dran, und überlege akut eine Breitenbeschränkung von 50em oder 60em.
  • Wobei unsere Artikel aber auch keine Breitenbeschränkung haben, sondern die Leser sich das auf eine ihrer Lesekompetenz angemessenen Breite mit 80, 100, 120, 140 Buchstaben/Textzeile beliebig einstellen können. Die HS ist aber kein normaler Artikel, und anders als in Artikeln hat sie für die Vielspaltigkeit geeignete Boxen, während Artikel primär einspaltig konzipiert sind.
  • Wobei sich HD-Leser für Artikel auch eine Maximalbreite der <p> von 60em oder was persönlich einstellen könnten; aller Fließtext hat dann noch eine menschenfreundliche Zeilenlänge, während Tabellen und Galerien beliebig breit werden dürfen. Wobei Minaturbilder auf HD dann etwas verloren am rechten Rand jenseits des Fließtextes stünden.

VG --PerfektesChaos 13:54, 19. Jun. 2020 (CEST)

Zur Info an die ohne 4K Bildschirm: 3840 4K / größer ca. 1700 / kleiner ca. 1700 / die bisherige / Mit 1700 sieht es zu gedrängt aus. Wird dann immer besser, je breiter das Bild wird. Mit Win10 2004 FF 77 und 100% Standard-Einstellungen --2001:16B8:22AD:5500:A463:E68C:BCCF:EAA 20:29, 19. Jun. 2020 (CEST)

Danke! Ja, müsste nur jemand einen Breakpoint fürs sechsspaltige Layout austüfteln, meine 1750px waren mehr geraten. Aber in dieser Konzeption gibt es halt keinen Übergang, nur zweispaltig vs. fünf-/sechsspaltig (wir sollten nicht vergessen, dass der Wikipedia-aktuell-Kasten die meiste Zeit gar nicht vorhanden ist, das bringt das symmetrische Breitenkonzept dann natürlich ganz durcheinander). Wie gesagt, mir fehlt es an alternativen Ideen, aktuell tendiere ich dazu, bei meinem ersten Vorschlag ohne Überbreitenberücksichtigung zu bleiben, aber mich betrifft die Geschichte halt auch nicht; mir ist nur wichtig, dass mobil ordentlich gelöst ist. Gruß–XanonymusX (Diskussion) 20:44, 19. Jun. 2020 (CEST)
Sehr breite Bildschirme sind auch einigermaßen hoch. In diesem Fall würde die Hauptseite bei zweispaltiger Anordnung der Kästen mit eingeschränkter Gesamtbreite (Breite des oberen und unteren Kastens) noch auf den Bildschirm passen und einen weniger zersprengten Eindruck machen. --Wiegels „…“ 01:03, 20. Jun. 2020 (CEST)

Kategorie:Seiten mit nicht-numerischen formatnum-Argumenten

Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Moin Moin zusammen, augenscheinlich eine neue Kategorie. Kann jemand was dazu sagen und ggf. auch eine Beschreibung anfügen, was zur Abarbeitung zu tun ist? Vielen Dank im Voraus. PS.: Schon in über 6.000 Artikeln aufgefallen. mfg --Crazy1880 12:22, 25. Sep. 2020 (CEST)

Siehe umseitig: „Seiten, die die Parserfunktion formatnum mit nicht-numerischen Zeichen verwenden, werden in eine Wartungskategorie sortiert. Der Name der Kategorie kann über MediaWiki:Nonnumeric-formatnum festgelegt werden.“ Wir verwenden formatnum i.A. nur in Vorlagen, d.h. man muss die Vorlagen suchen, in denen versucht wird mit formatnum etwas zu formatieren, das keine Zahl ist. --Count Count (Diskussion) 12:31, 25. Sep. 2020 (CEST)
Moin Moin Count Count, danke für die schnelle Rückmeldung, augenscheinlich kommt es auch aus Vorlagen wie z.B. {{Infobox Gemeinde in Deutschland}}, aber ich kann in der Vorlagenprogrammierung nicht erkennen, wo ist da suchen sollte. mfg --Crazy1880 12:40, 25. Sep. 2020 (CEST)

ad Neuheiten 14. Oktober - multiple BEO

Letzter Kommentar: vor 4 Jahren8 Kommentare5 Personen sind an der Diskussion beteiligt

dazu gleich eine Frage: unter "für Programmierer" steht da "Seiten können nun zeitlich befristet auf die Beobachtungsliste gesetzt werden. Nach Ablauf ... ..." - darauf warte ich seit Jahren, irgendwann noch auf die uralte Bug-Liste gesetzt. Was heißt hier "für Programmierer" - OttoNormalUser können es nicht nutzen? -jkb- 00:38, 19. Okt. 2020 (CEST)

Wo siehst du "Für Programmierer"? Bei mir steht das Feature direkt unter 14. Oktober. Und jeder registrierte Benutzer kann es nutzen, unabhängig von den Benutzergruppen in denen man ist. XenonX3 – (☎) 00:45, 19. Okt. 2020 (CEST)
Oh. Time to visit Fielman once again :-) ... Aber wie aktiviert man das? -jkb- 00:52, 19. Okt. 2020 (CEST)
Ach so, im Ausrufer – 43. Woche ist es unter "für Programmierer". -jkb- 00:55, 19. Okt. 2020 (CEST)
Moin, wenn ich bei mir unten in die Zeile schaue, steht dort: Die Seite beobachten: Dauerhaft. Da kann ich die Dauer ändern, und z.B. auf 6 Monate stellen. Auch wenn ich eine Seite neu aif Beo setze, kommt bei mir ein Popup das mich fragt, wie lange das erfolgen soll. Versuch es mal so. Eine besondere Aktivierung braucht es nicht, wer es nicht nutzen will, den wird es nicht groß stören: Wenn ich eine Seite neu raufsetze ist die üblicherweise Dauerhaft drauf, bis ich das anpasse. Viele Grüße, Luke081515 06:38, 19. Okt. 2020 (CEST)
Siehe auch Hilfe:Beobachtungsliste#Seiten beobachten / nicht mehr beobachten → Seite temporär beobachten --Liebe Grüße, Lómelinde Diskussion 07:59, 19. Okt. 2020 (CEST)
Aha. Man muss damit ert einmal etwas spielen, aber es scheint das zu sein, das i ch seit Jahren haben wollte! Danke an beide! -jkb- 18:45, 19. Okt. 2020 (CEST)

Ich finde es etwas seltsam, dass Visual Editor und neuer Wikitext-Editor das Auswahlfeld offenbar nicht anbieten.–XanonymusX (Diskussion) 18:49, 19. Okt. 2020 (CEST)

Seitenerinnerung

Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

@Raymond: Ist die Funktion Seitenerinnerung [in x Tagen]“ schon in irgendeiner Weise einsatzfähig oder testbar? --Count Count (Diskussion) 14:26, 19. Nov. 2020 (CET)

@Count Count: Das ist eine gute Frage... Ich bin sicher, dass ich damals, bei umseitiger Meldung kurz im Betawiki getestet habe. Nun kann ich dazu nichts mehr finden :-( Dieser Kommentar im Task macht mir nicht viel Hoffnung. Ist wohl an der Zeit, die Position umseitig rauszunehmen :-( — Raymond Disk. 15:46, 19. Nov. 2020 (CET)
Ich denke, das ist eine sehr sinnvolle Funktion, aber leider scheint niemand aktuell daran zu arbeiten. Auf der enwp hat DannyS712 das jetzt mit Botunterstützung implementiert, aber da sind die Erinnerungen für alle öffentlich einsehbar. Das halte ich für problematisch. --Count Count (Diskussion) 15:56, 19. Nov. 2020 (CET)

Wartungskat syntaxhighlight

Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Ich habe inzwischen per A/A die neuen Kat-Auslöser der bestehenden Kategorie:Wikipedia:Seite mit Syntaxhervorhebungsfehlern zuordnen lassen.

  • Es wird nach Aktivierung eine einmalige Welle an Altbeständen geben, insbesondere im BNR. Der Rest ist eigentlich schon seit fünf Jahren gesäubert.
  • Nach Aufräumen, mutmaßlich auch mit Bot-Unterstützung, wird die Summe aller drei Fehlertypen wieder nahe Null liegen, und es werden nur noch gelegentlich einzelne Seiten aufschlagen. Deshalb lohnt sich keine differenzierte Aufgliederung in lauter einzelne Kategorien.

VG --PerfektesChaos 14:22, 10. Apr. 2020 (CEST)

fehlerkat fast leer. kann damit wohl demnächst ins archiv. --Wetterwolke (Diskussion) 13:21, 16. Aug. 2021 (CEST)

Beta-Feature: Replying

Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Ich finde ja das Replying Tool als Teilprojekt des Talk pages project ziemlich spannend und sicherlich auch nützlich für die deutsche Community. Warum wird dies nicht in den größeren Sprachversionen wie der deutschen oder englischen Wikipedia angeboten? Als Beta Feature tut es ja niemandem weh    Vielen Dank für die Einblicke im Voraus. --FNDE 01:50, 1. Nov. 2020 (CET)

seit einiger zeit jetzt vorhanden. beitrag kann damit ins archiv. --Wetterwolke (Diskussion) 10:15, 13. Okt. 2022 (CEST)
Abgerufen von „https://de.wiki.x.io/w/index.php?title=Wikipedia_Diskussion:Projektneuheiten/Archiv/2020&oldid=227416593“