Wikibooks:Verbesserungsvorschläge

(Weitergeleitet von Wikibooks:VV)
Letzter Kommentar: vor 7 Tagen von MGA73 in Abschnitt Neulizenzierung von GFDL auf CC-BY-SA

Häufig gestellte Fragen · Ich brauche Hilfe · Meinungsbilder · Verbesserungsvorschläge
Rundschau · Schwarzes Brett · Bots  · Import · Projektentwicklung

Abkürzung:
WB:VV
Willkommen

Du hast Verbesserungsvorschläge zu Wikibooks? Hier kannst du sie vorstellen. Bedenke, hier arbeiten alle freiwillig: Forderungen sind daher unhöflich und unerwünscht. Traust Du Dir die Umsetzung Deines Vorschlags selbst zu? Dann biete es direkt mit an.

Für folgende Punkte gibt es eigene Seiten:

Neuer Vorschlag
Archive

Ältere Vorschläge und Diskussionen: 2006200720082009201020112012201320142015201620172018201920202021

Archivierung: Themen, die ausdrücklich als erledigt bezeichnet wurden, sind über das Archiv zu finden. Gleiches gilt für Themen, die „eingeschlafen“ sind und seit mindestens zwölf Monaten nicht mehr besprochen wurden. Genutzt wird das Archiv des Jahres, in dem der letzte Beitrag veröffentlicht wurde. Ein Thema ist in der Regel nur über die Begriffe der Überschrift, nicht über den Inhalt zu finden.

Editor überarbeiten

Bearbeiten

Eingabeprobleme wurden auch bei Ich brauche Hilfe angesprochen. Diese Probleme und die hier genannten Vorschläge sind so wichtig, dass sie möglichst erst nach einer vollständigen Lösung archiviert werden sollten. -- Jürgen 10:06, 31. Jan. 2016 (CET)Beantworten

Ich habe vor den Editor etwas zu überarbeiten, Diskussionen dazu sollen unter dieser Überschrift geführt werden. Ausgangspunkt dazu war das Hinzufügen des Unicode Zeichens  , welches ein Leerzeichen mit der Breite einer Ziffer erzeugt. Jürgen hat bereits auf meiner Diskussion ein paar Anmerkungen hinterlassen, die ich hier auch gleich einfüge um alles beieinander zu haben:

Zu MediaWiki:Edittools habe ich noch ein paar Anmerkungen:

  • Seit ein paar Wochen kann ich die Liste der Sonderzeichen nicht mehr ausklappen, siehe Wikipedia und meine Diskussionsseite.
  • Direkt in die Liste kann wohl kein Tooltip eingebaut werden. (Ich habe nicht danach gesucht, aber da es sich um eine „normale“ Systemnachricht handelt, kann ich es mir nicht vorstellen.)
  • Wikipedia hat inzwischen eine völlig andere Lösung (mit Tooltips) über Onlyifediting.js, die mir gefällt. Aber dazu müssten wir unser System komplett überarbeiten; ob sich das bei unserer sehr aktiven Gemeinschaft lohnt?

Gruß Jürgen 14:39, 13. Aug. 2015 (CEST)Beantworten

Beim Durchschauen unserer Gadgat-Infrastruktur ist mir aufgefallen, dass das alles nicht mehr auf dem aktuellen Stand ist, seit der ResourceLoader eingeführt wurde. Ich schau erst mal ob ich das beheben kann, dann geht es an den Editor.

Ich würde vorschlagen MediaWiki:Edittools komplett zu entfernen und in die Erweiterte Bearbeiten-Werkzeugleiste zu integrieren. Außer in sehr alten Browsern wird diese inzwischen überall unterstützt und ehrlich gesagt schweren mich Uralt-Browser wie Firefox 1 oder IE 6 nicht mehr. Wer so was noch benutzt, sollte ich ohnehin überlegen, was er im Internet zu suchen hat, allein schon aus Gesichtspunkten der Sicherheit. --Prog 19:59, 15. Aug. 2015 (CEST)Beantworten

Diesen Punkt habe ich in letzter Zeit leider total übersehen. In Zusammenhang mit Ich brauche Hilfe bin ich wieder darauf gestoßen. Deshalb hierzu ein paar Anmerkungen.
Die Inhalte der Edittools werden grundsätzlich weiterhin benötigt. "Zu alte" Browser müssen wirklich nicht berücksichtigt werden. Selbst Standardzeichen wie die geschweiften Klammern gibt es wohl nicht auf jeder Tastatur, gehören also unbedingt dazu. Ein Teil der sprachbezogenen Sonderzeichen wie IPA werden bereits jetzt über die Standardleiste erreicht; an dieser Stelle sind Doppelungen sicher nicht nötig. Die Elemente zur Wiki-Syntax sind oft nützlich. Zusätzlich kann ich mir auch eine Liste für TeX wie \cdot \sqrt \frac vorstellen; also müssen sowohl die Zusammenstellung als auch der Aufbau flexibel sein. -- Jürgen 12:08, 24. Okt. 2015 (CEST)Beantworten
@Prog Wirst du dich mit diesen Problemen noch befassen, oder ist eine Adhoc-Lösung mit einem größeren Kasten vorzuziehen? -- Jürgen 10:06, 31. Jan. 2016 (CET)Beantworten
Moin Jürgen, ich werde mich zumindest in näherer Zeit nicht damit befassen können, bin mal wieder ein wenig knapp mit der Zeit. Viele Grüße --Prog 15:54, 10. Mär. 2016 (CET)Beantworten

Danke für den Hinweis. Als Ersatzlösung habe ich erstmal   und die Wiki-Syntax sichtbar gemacht. -- Jürgen 16:50, 10. Mär. 2016 (CET)Beantworten

Vorlage:Dokumentation kann auch externe Dokumentationen einbinden

Bearbeiten

Hallo zusammen,

nach Vorbild von w:en:Template:Documentation habe ich bei Vorlage:Dokumentation die Möglichkeit eingebaut, externe Dokumentationen einzubinden. Siehe Vorlage:!) für eine Anwendung. Siehe auch Benutzer_Diskussion:Stephan_Kulla#Vorlage_.E2.80.9EDokumentation.E2.80.9C für alle Details.

Wenn es eurer Seite Änderungswünsche gibt, gebt Bescheid.

Viele Grüße, Stephan Kulla 23:05, 19. Mär. 2017 (CET)Beantworten

Normalerweise zeigt die Vorlage "Dokumentation" sobald eine Seite "/Doku" existiert den Satz: "Die Dokumentation befindet sich auf einer eingebundenen Unterseite" an. Mit der externen Dokumentation sollte auch ein entsprechender Hinweis da stehen, wo die Dokumentation ist, statt dessen steht da: "Es muss noch eine Dokumentation auf der eingebundenen Unterseite erstellt werden." Auf diese Änderung habe ich dich aber auch schon hingewiesen, als ich auf deiner Diskussionsseite die Erweiterung der Vorlage vorgeschlagen habe. --Axel Prignitz 20:11, 22. Mär. 2017 (CET)Beantworten

Noch nicht archiviert, weil der von Axel Prignitz genannte Mangel weiterhin besteht und durch relevant ist. -- Jürgen 17:13, 28. Dez. 2018 (CET)Beantworten

Ich habs mir mal angeschaut und hoffe ich habs behoben. Ist aber in der Doku noch nicht beschrieben. Guck ich vielleicht demnächst auch mal drüber. Viele Grüße, HirnSpukDisk03:52, 24. Jul. 2021 (CEST)Beantworten

Hilfe Sammlungen

Bearbeiten

Die Seite Hilfe:Sammlungen beschreibt Funktionen und Eingenschaften die heute nicht mehr vorhanden sind. Ich bin der Ansicht, dass sie überarbeitet werden sollten. Das Problem ist nur, dass ich keinen hinreichenden geistigen Abstand zu der Sache habe um sie selbst so bearbeiten zu können das sie hinterher nicht aussieht wie Dresden 1945.

Ich würde mich daher sehr freuen wenn irgendwer das übernehmen könnte.

Nun zu den einzelnen Punkten:

  • Aus Sammlungen können mit über den Buchgenerator keine PDFs mehr erstellt werden. Auch sonst können mit dem Buchgenerator keinerlei herunterladbare Dateiein erzeugt werden. Die betrifft insbesondere auch EPUB und ODT.
  • Es gibt eine offizielle Bekanntgabe der WMF, dass alle Resourcen für eine Reperatur oder Neuentwicklung derartiger Funktionen seitens der WMF abgezogen wurden. mw:Reading/Web/PDF_Functionality#Update_on_PDF_rendering,_July_15_2019 Zitat: In terms of books, we've left it in the hands of volunteer developers and PediaPress. We'll be glad to reach out to them with questions, but we're not planning any involvement in terms of the technical implementation.
  • Die geschilderten Funktionen werden von mediawiki2latex (Multi Format Export im linken Seitenmenü) zur Verfügung gestellt.
  • Man kann Sammlungen auch ohne Buchgenerator als Wiki Quelltext erzeugen. Hierzu kann ggfs. die Syntax beschrieben werden.
  • Man kann sich von Sammlungen gebührenpflichtig Bücher ausdrucken und zusenden lassen.
  • Der Buchgenerator wurde auf der englischen Wikipedia mittels CSS abgeschaltet eine serverseitige Abschaltungen folgt in den nächsten Tagen auf der englischen Wikipedia phabricator:T241683

Ich kann die Änderungen zur Not auch selber machen. Aber wir sollten uns dann hier wenigstes darüber ausgetauscht haben wie das aussehen könnte.

Viele Grüße Dirk Hünniger 21:43, 11. Jan. 2020 (CET)Beantworten

Ich habe nun entsprechende Änderungen durchgeführt. Gerne dürfen diese weiter verbesser werden. Dirk Hünniger 12:07, 18. Jan. 2020 (CET)Beantworten

"Multi Format Export" kann ich im linken Seitenmenü gar nicht finden (da gibt es allenfalls 'Buch erstellen', 'Als PDF herunterladen', 'Druckversion'). Somit ist es doch besser, du gibst explizit die Verweise zu den beiden Seiten in der Hilfe an. Kann ja nicht schaden, selbst wenn die Option irgendwann mal im linken Seitenmenü auftauchen sollte. Ansonsten wohl eher "Multi-Format-Export" oder "Multiformatexport" oder "Mulitformat-Export", sonst gibt es an der Schreibweise noch unerfreuliche Kritik. Ansonsten ist die Hilfe doch so in Ordnung. ;o) Doktorchen 13:19, 18. Jan. 2020 (CET)Beantworten

Ändere das am besten selbst so wie du es für richtig hältst. Zur Schreibweise kannst du gerne hier einen Verbesserungsvorschlag hinschreiben. Die kann nämlich nur ein Admin ändern und dafür braucht man wohl wieder einen Gemeinschaftsbeschluss. Mir ist die Schreibweise vollkommen gleich. Es kann auch nur "Export" oder "herunterladen" oder sonst irgendwie heißen. Das es bei dir nicht angezeigt wir liegt möglicherweise daran dass du Java Skript nicht an hast. Die Lösung ist hier den Link direkt in die MediaWiki Software einzubauen hierzu wäre dann ein Antrag auf Phabricator zu stellen. Als Beispiel kann der Antrag auf Entfernung des Buchgenerators dienen phabricator:T241683. Viel Vergnügen und fröhliches beantragen. Dirk Hünniger 14:16, 18. Jan. 2020 (CET)Beantworten

Titel von Unterseiten verändern

Bearbeiten

Hallo,

Wenn ich in meinem Browser die Seiten Wahrscheinlichkeitstheorie und Wahrscheinlichkeitstheorie/_Die_elementarsten_Gleichungen_und_Ungleichungen aufrufe und in zwei verschiedenen Tabs habe, und dann eine dritte Seite aufrufe, so kann ich anhand der Tab-Überschrift (die nämlich zu klein ist, um den Gesamttitel zu fassen) nicht ablesen, welcher Tab was beinhaltet.

Daher schlage ich vor: Bei Unterseiten möge zuerst der Unterseitentitel kommen und dann erst der Oberseitentitel. Ich habe das Ganze mal beispielhaft mit {{DISPLAYTITLE:}} gemacht: Wahrscheinlichkeitstheorie/_Martingale_mit_diskreter_Zeit. --Mathmensch 09:10, 9. Nov. 2020 (CET)Beantworten

Hallo Mathmensch, guter Hinweis, danke. Das ist auch bereits in Hilfe:Buch_in_Kapitel_untergliedern#Seitentitel_anpassen beschrieben. Machen müsste das so dann jeder Autor selbst. Andere Optionen wären ein Bot (halte ich für nicht sinnvoll), eine Vorlage (müsste man probieren, dürfte aber gehen, hielte ich für sehr sinnvoll, bedürfte aber auch eines Bots, um das Wikibooksweit umzusetzen) oder wenigstens eine prominentere Platzierung als Hinweis. Man könnte das in die FAQ aufnehmen? Ob es für die hiesige Gemeinschaft Eingriffsmöglichkeiten in die Darstellung gibt, sowas global einmal zu machen, müssen andere Leute beurteilen und sich ggf. kümmern. Wenn das geht, wäre ich auf jeden Fall dafür. Wenn es nicht geht, bin ich dafür erstmal alles so zu lassen, wie es ist, weil für größere Änderungen keine Voraussetzungen bestehen. @Stephan, Du hast doch bestimmt schonmal über sowas nachgedacht für MfnF, oder? Gruß --HirnSpuk 20:35, 9. Nov. 2020 (CET)Beantworten

Mit unseren aktuellen Mitteln ist es erst einmal das Beste, wenn du dies händisch in deinen Büchern mit {{DISPLAYTITLE:}} vornimmst. Bei Mathe für Nicht-Freaks übernimmt diese Aufgabe unsere Header-Vorlage, die du für deine Bücher selbst anlegen kannst (eine bucheigene Vorlage ist hier die beste Lösung). Mit Hilfe von der Funktion "titleparts" kannst du dies ggf automatisch erzeugen. Nun sind die Überschriften bei Büchern auf Wikibooks durchaus individuell. Es gibt keine einheitliches Format und deswegen sehe ich keine einfache Möglichkeit, es global zu lösen. Wir haben bspw. "/" und ":" als Trenner für Unterseiten, die von der MediaWiki Software auch unterschiedlich interpretiert werden (bei "/" wird eine Unterseite auch technisch als Unterseite erkannt und bei ":" nicht). Auch ist der Anfangspart vor dem "/" und ":" nicht bei allen Büchern gleich dem Buchnamen. Unter w:Wikipedia:Technische Wünsche/Wunschparkplatz kannst du auf dieses Problem hinweisen. Ich kann mir vorstellen, dass es hierfür andere elegantere Lösungen gibt. Beispielsweise kann man den <title>...</title> bei Unterseiten anders generieren. -- Stephan Kulla 18:32, 10. Nov. 2020 (CET)Beantworten

Visueller Editor + MediaWiki neues Design

Bearbeiten

Liebes Wikibooks-Team,

ist schon absehbar, wann der zur Zeit noch in der Beta-Funktion getestete visuelle Editor standardmäßig aktiviert wird (wie in der Wikipedia)? Wir wollen bei Open Rewi möglichst viele Menschen einbinden. Die Hauptverantwortlichen eines Projektes arbeiten natürlich mit der Wiki-Syntax im Quelltext. Gerade für die vereinzelt mitwirkenden Studierenden oder andere Externe wäre der visuelle Editor jedoch extrem hilfreich, um einen niedrigschwelligen Einstieg zu schaffen.

Außerdem würde mich interessieren, ob sich die Überarbeitung der Wikipedia auch auf Wikibooks auswirken wird?

Viele Grüße --Maximilian.Petras 12:33, 11. Nov. 2020 (CET)Beantworten

Moin!

  1. Es gibt kein Wikibooks-Team in dem Sinne. Wir alle sind das Wikibooks-Team :-)
  2. Der visuelle Editor ist für jeden Nutzer vorhanden: Einstellung (oben rechts, neben dem Nutzernamen) → Registerkarte Beta-Funktionen → 3. Punkt: "Visuelles Bearbeiten"
    Einmal so aktiviert (und gespeichert!), lässt er sich für angemeldete Nutzer benutzen, wie in der Wikipedia und bleibt auch aktiv, wenn man sich aus- und wieder einloggt. Ein standardisiertes Einschalten auch für anonyme Nutzer ist meines Wissens nach nicht geplant. Beachtet bitte auch, dass die Typografie im visuellen Editor schwieriger zu kontrollieren ist (vgl. meinen Kommentar dort). Darüber hinaus, wenn Ihr motivieren wollt "anonym" als IP zu arbeiten, bedenkt: 1. eine IP ist weniger anonym, als ein Nutzername (bis hin zum Standort des PCs in der Uni) und 2. die Änderungskontrolle wird sehr aufwendig, da die Prüfung: Ist das ein niedrigschwellig motivierter Student oder doch ein Vandale, länger wird. Das wird hier niemand tun (gerade mangels Fachwissen bei Rechtsthemen), es bliebe also bei "Euch" das zu tun.
  3. Natürlich wird sich der neue Vector-Skin auch auf Wikibooks auswirken, wenn er alternativlos freigeschaltet wird. Soweit ich das überblicke ist das jedoch frühestens Ende 2021 geplant. Die Darstellung weicht aber nur marginal ab (siehe dort: franz. Wiktionary). Eine Renovierung ist hier also nicht dramatisch. Wir müssen sehen, wie sich das auf vorhandene Vorlagen auswirkt, sonstige Probleme sehe ich jetzt spontan erstmal nicht. Die anderen Skins bleiben wohl erhalten und werden nicht vom redesign betroffen sein.
  4. Die richtige Seite für solche Anfragen ist: Wikibooks:Ich brauche Hilfe. Nur fürs nächste Mal ;-). Ich lasse das hier aber mal stehen, weil ich es interpretiere als: "Wir hätten gern den visuellen Editor standardmäßig eingeschaltet!" Ich persönlich halte das zwar nicht für eine Verbesserung ;-), aber ja vielleicht jemand, der Lust hat das anzuleiern oder ein Meinungsbild draus zu machen.

Gruß --HirnSpuk 20:21, 11. Nov. 2020 (CET)Beantworten

Falls es jemanden interessiert: Das neue Design ist optional anschaltbar über Spezial:Einstellungen#mw-prefsection-rendering-skin-skin-prefs. Alle Autoren, die Ihr Buch auf Kombatibilität überprüfen möchten können das also schon jetzt tun. Da wohl in einem Jahr auf jeden Fall eine Aktivierung ansteht, empfehle ich das schnellstmöglich anzuschauen und sich darauf vorzubereiten. --HirnSpuk 12:36, 17. Nov. 2020 (CET)Beantworten

Verbesserte Klärung unterschiedlicher deutscher Rechtschreibung (AT/CH/DE/Alt/Mundart)

Bearbeiten

Beispiel: Bogenbau, Schweizer Rechtschreibung, vgl Bogenbau/ Organisation

Effekt: Spezial:Diff/837879

Lösungsvorschlag: Kategorien zur Symbolisierung der verwendeten Rechtschreibung/Mundart (vgl. z. B. auch w:nds:Hööftsiet, auch Rheinfränkisch, Bayrisch, etc.). Ohne Kategorie -> aktuell gültige dt. RS. Keine "alte deutsche Rechtschreibung" für Sachbücher, die sich an Kinder und Jugendliche unter 18 Jahren richten.

Vorteil: Bei beliebiger Seite ist die Rechtschreibung ersichtlich ohne die Projektbeschreibung zu suchen.

Wenn sich niemand für den Punkt interessiert, könnte man ihn auf eine Liste schreiben, ähnlich dem gelöschten Wunschzettel. Der Effekt oben zeigt ja, dass es ein Problem gibt. Außerdem würde man so inklusiver für den gesamten deutschen Sprachraum, was ich grundsätzlich für erstrebenswert hielte. --HirnSpuk 12:28, 12. Nov. 2020 (CET)Beantworten

Vorlagen-Sortierung

Bearbeiten

Moin,

ich finde das aktuelle Sortierungssystem für Vorlagen (Hilfe:Vorlagen) überaus unglücklich.

  • für bucheigene und regaleigene Vorlagen muss (bucheigen) ODER kann (regaleigen) bei der Verwendung ein Doppelpunkt vorangestellt werden. Diese Nutzung ist zwar in der Hilfe beschrieben, aber durch bloßes draufgucken nicht ersichtlich. Wie verwirrend sowas sein kann, ist auf der Hilfeseite verwenden zu sehen, vgl. Spezial:Diff/873191/938302, das ist niemandem die letzten 6 Jahre aufgefallen.
  • Die Namen der Vorlagen werden länger, z. B. {{Regal:Programmierung: Vorlage:Code}} statt {{Programmierung/Code}} oder vielleicht {{Regal:Programmierung/Code}}.
  • Durch die Übertragung der Nomenklatur für Bücher entstehen Leerzeichen wo sie nicht nötig und nicht unmittelbar einsichtig sind.
  • Bei Verwendung von TemplateStyles wird das ganze noch schwieriger: bucheigenen und regaleigenen Vorlagen kann kein CSS in dieser Art mitgegeben werden, da dafür mindestens Admin-Rechte, wenn nicht gar Oberflächen-Admin-Rechte erforderlich sind.
  • Eine Substitution von normalen Seiten ist auch möglich. Dort ergibt es Sinn, dass ein Doppelpunkt vorangestellt wird, sodass man erkennt, dass es sich nicht um eine Vorlage handelt. Dieser Nutzen entfällt aktuell und wird substituiert durch die Nutzung des Wortes Vorlage.

Folglich schlage ich vor Unterseiten von Vorlagen zu benutzen, um die Zuordnung von Vorlagen zu realisieren:

  • [[Vorlage:Buch/Vorlagenname]] eingebunden mit {{Buch/Vorlagenname}} statt [[Buch/ Vorlage:Vorlagenname]] eingebunden mit {{:Buch/ Vorlage:Vorlagenname}}
  • [[Vorlage:Fachgebiet/Vorlagenname]] eingebunden mit {{Fachgebiet/Vorlagenname}} statt [[Regal:Fachgebiet/ Vorlage:Vorlagenname]] eingebunden mit {{(:)Regal:Fachgebiet/ Vorlage:Vorlagenname}}. Eine Benennung nach dem Muster [[Vorlage:Regal:Fachgebiet/Vorlagenname]] ist nicht möglich, wegen oben genannter oder-Bedingung bei Namensraumeinbindungen. Schlimm finde ich das nicht, weil so mit einer Nomenklatur Fach-, Themen-, Funktions- und Buchspezifische Vorlagen bedient werden können.

Dass das funktioniert ist an Seiten ersichtlich, wie Vorlage:Bot/Text, die als Vorlage eingebunden ist in Vorlage:Bot

Weitere Vorteile zusätzlich zur Beseitigung oben genannter Nachteile:

  • Nutzung von [[Vorlage:Unterseiten]] zur sortierten Anzeige aller Vorlagen von z. B. [[Vorlage:Regal:Fachgebiet]] möglich, Bsp.:
  • Für Menschen, die tippen, statt Copy&Paste zu machen wird das tippen deutlich schneller und konsistenter.

Nachteile:

  • Das System sollte robust genug sein, auch Vorlagen zu berücksichtigen, die selbst Unterseiten haben. Hier entsteht Potential für Verwirrung und wahrscheinlich Wartungsaufwand. Außerdem schätze ich, ist hier das Potential für noch nicht absehbare Komplikationen am größten.
    • Bspw.: {{Überschriftennummern/Rechtswissenschaften}}, {{Überschriftennummern|Regal=Rechtswissenschaften}} oder {{Rechtswissenschaften/Überschriftennummern}}, letztere beiden sind im vorgeschlagenen System kein Problem. Ersteres Beispiel ist aktuell nicht berücksichtigt. Dennoch halte ich alle drei Varianten für legitim und akzeptabel. (Anm.: Die Vorlage existiert noch nicht. Der Wunsch Ihrer Erstellung hat genau diesen Abschnitt bei den Verbesserungen ausgelöst.)
  • Eine Migration vom alten System müsste nach und nach erfolgen UND beide Systeme müssten für die Übergangszeit auf den Hilfeseiten beschrieben werden. Eine Funktionsfähigkeit von Vorlagenweiterleitungen zur Vereinfachung der Migration könnte geprüft werden.
  • Die Hilfe-Seiten sind entsprechend auf Stand zu bringen.
  • Was Vorrang hat, wenn Bücher heißen (sollen), wie ein Regal ([[Programmierung]] und Regal:Programmierung) oder wie eine Funktion, Beispielsweise [[Überschriftennummerierung]] ist zu diskutieren.

Für mich überwiegen die Vorteile deutlich.

Fallen jemandem Probleme ein, die ich übersehen habe? Kann jemand die Auswirkungen auf den visuellen Editor einschätzen?

--HirnSpuk 14:17, 27. Nov. 2020 (CET)Beantworten

Hallo HirnSpuk! Wenn ich das gut verstehe, das würde dann bedeuten, dass alle Einbindungen der bucheigenen Vorlagen und von eingebundenen Seiten im Text-Editor korrigiert werden müssen, oder? Yomomo 16:34, 27. Nov. 2020 (CET)Beantworten

Hallo Yomomo, wenn man unbedingt migrieren will und eine Weiterleitung nicht funktioniert, es also nicht egal ist, WANN man das macht, ja. regaleigene Vorlagen sind nicht viel, vgl. Kategorie:Regaleigene Vorlage. Kategorie:Bucheigene Vorlage sind schon deutlich hässlicher in der Migration. Es spricht aber nichts dagegen dauerhaft beide Varianten parallel zu betreiben, in Büchern können Autoren ja mehr oder weniger frei tun und lassen, was sie wollen, wenn sie also Vorlagen-Unterseiten für Ihre Bücher bauen wollen und das System der Einbindung verstanden haben, kann man sie ja lassen, man nimmt lediglich die Beschreibung auf den Hilfeseiten raus. Die Regalweiten Vorlagen würde ich aber so oder so migrieren. Auch über Abkürzungen von Buchtiteln kann man sicher mal sprechen, Vgl. https://de.wikibooks.org/w/index.php?title=MathGymOS&redirect=no

Im Grunde lässt sich die Idee auf folgendes zusammenfassen: Nutzung von Unterseiten im Vorlagennamensraum zur kategoriefreien sprechenden Zuordnung von Vorlagen zu bestimmten Büchern/Funktionen/Fachbereichen/... für mehr Konsistenz und Vereinfachung. --HirnSpuk 17:07, 27. Nov. 2020 (CET)Beantworten

Hallo Hirnspuk! Ehrlich gesagt, hab ich nie ganz genau die Anleitungen geschaut. Ich hab geschaut, was andere gemacht haben, Codes aus Wikipedia und andere Projekte, Html Codes im Internet und das ganze weiterentwickelt. Meiner Erfahrung nach gilt: mit den zwei Punkten am Anfang {{:NameWasAuchImmerMit oder ohne Leerzeichen}} kannst du alles als "Vorlage" benutzen, so bald du im Quelltext eine {{{Variable}}} definierst. Diese Möglichkeit gibt es sogar auch für Teile einer Seite, wenn du in dieser Seite Unterkapitel hast oder "section" definiert hast, mit {{#lst:NameWasAuchImmerMit oder ohne Leerzeichen|Section Name}} oder {{#lsth:NameWasAuchImmerMit oder ohne Leerzeichen|Untertitel}}. Das gibt eine erhöhte Flexibilität bei der Programmierung, wenn wir die etwas begrenzten Möglichkeiten von vorhandenen Befehlen betrachten (if, switch und ein paar andere). Das Wort Vorlage dient daher (meiner Erfahrung nach) vor allem der Sichtbarkeit: "Hey, diese Seite wird als Vorlage benutzt, also etwas (genauer gesagt: viel) vorsichtiger mit der Sache umgehen!". Die Länge der Namen spielt letztendlich keine Rolle (es gibt ja Copy-Paste). Ich bin sogar gerade eher für längere Namen, wenn jemand (und auch ich) Abkürzungen benutzen will, finde ich auch OK (das mache ich ja auch  ...). Dass wir dann, in bucheigenen Vorlagen das Wort Vorlage benutzten ({{:Buchname: Vorlage: Vorlagename}}), finde ich nicht problematisch. Letztendlich, wenn jemand will, kann er/sie eine bucheigene Vorlage ohne das Wort "Vorlage" im Titel erstellen ({{:Buchname: Vorlagename}}) und eine Dokumentation dafür erstellen, wo man ablesen kann, dass es um eine Vorlage geht (probiere einfach in einer zufällige Seite <noinclude>{{Dokumentation}}</noinclude> am Anfang oder am Ende hinzuzufügen). Der einzige Unterschied wird dann nur diese zwei Punkte ":" am Anfang der Einbindung sein. Wenn jemand nicht will, braucht sie/er nicht das Wort "Vorlage" im Seitenname benutzten. LG! Yomomo 10:54, 28. Nov. 2020 (CET)Beantworten

Hallo Yomomo,

alles, was Du erklärst, ist mir bekannt. Darauf gehe ich ja oben quasi auch ein. Ich sage ja nicht, dass das aktuelle System nicht funktioniert, ich finde nur es hat Mängel. Die Hälfte davon sind zugegebenermaßen nicht funktioneller Natur und meine persönliche Ansicht. Ich finde es mangelt an Konsistenz, was ich als Nachteil ansehe.

Da Du vermutlich der einzige bist, der sich hier melden wird, Jürgen hat schon geäußert, dass es ihn eher nicht betrifft: Dann mach einen Gegenvorschlag, wie wollen wir verfahren mit:

  • TemplateStyles für buch- und regaleigene Vorlagen?
  • Unterseiten im Vorlagennamensraum, die Vorlagenfunktionalität bereitstellen?

Gruß --HirnSpuk 14:01, 28. Nov. 2020 (CET)Beantworten

Hallo Hirnspuk! Gegen folgende Vorschläge von dir:

  • [[Vorlage:Buch/Vorlagenname]] eingebunden mit {{Buch/Vorlagenname}} statt [[Buch/ Vorlage:Vorlagenname]] eingebunden mit {{:Buch/ Vorlage:Vorlagenname}}
  • [[Vorlage:Fachgebiet/Vorlagenname]] eingebunden mit {{Fachgebiet/Vorlagenname}} statt [[Regal:Fachgebiet/ Vorlage:Vorlagenname]] eingebunden mit {{(:)Regal:Fachgebiet/ Vorlage:Vorlagenname}}. Eine Benennung nach dem Muster [[Vorlage:Regal:Fachgebiet/Vorlagenname]] ist nicht möglich, wegen oben genannter oder-Bedingung bei Namensraumeinbindungen. Schlimm finde ich das nicht, weil so mit einer Nomenklatur Fach-, Themen-, Funktions- und Buchspezifische Vorlagen bedient werden können.

hab ich selbstverständlich nichts. Im Gegenteil bin ich auch für diese Idee. Wäre ich nicht gegen diese Art von Anwendung angesprochen, als ich hier angefangen hatte, hätte ich es genauso gemacht  . Letztendlich muss es nicht sein, dass die alten bucheigene Vorlagen ersetzt werden müssen. Sie können ruhig ihre Namen behalten und weiter so benutzt werden (mit Doppelpunkt und alles). Wer dann will, kann seine neue Vorlagen nach deinem Vorschlag von nun an definieren. Ich kann dir allerdings nicht besonders hilfreich in so einem Projekt sein (also Hilfeseiten ändern usw.), ich muss gerade mehr als 40 h wöchentlich arbeiten und dazu das Projekt Mathematrix weiterentwickeln, sorry dafür (ich meine: sonst würde ich gern mitmachen).

PS: Falls du dich für eine Realisierung deiner Idee entscheidest, bitte informiere auch Benutzer:OpenRewi, damit sie direkt Vorlagen mit dem Namen in der von dir vorgeschlagenen Form entwickeln.

LG! Yomomo 14:28, 28. Nov. 2020 (CET)Beantworten

Hallo Yomomo, ich dachte, Du hättest es verfolgt, genau wegen OpenRewis Vorlagen komme ich ja drauf. Wenn Du etwas Zeit hast, schaust Du auf Benutzer Diskussion:OpenRewi Letzter Abschnitt. Mal schauen, welchen Weg wir dann einschlagen. Die Gruppe dort muss sich auch erstmal einigen und wir müssen natürlich auch noch etwas abwarten, vielleicht kommt ja noch eine Meldung von jemand anderem. Viele Grüße --HirnSpuk 20:20, 28. Nov. 2020 (CET)Beantworten

Sorry, ich hab das offenbar nicht verfolgt, ich beobachte diese Seite nicht mehr. Toll das du dich damit beschäftigst und super Arbeit Chapeau! Was die Vorlage Klappbox betrifft, ich benutze sie ziemlich oft, alle Probleme, die ich bis jetzt festgestellt habe, kann man doch umgehen, mit Vorlagen wie {{!}}, aber das weißt du sicher schon. Falls diese Vorlage ändert, bitte mich auch warnen  ! Yomomo 20:38, 28. Nov. 2020 (CET)Beantworten

Danke! Ich musste erstmal nachgucken, was Du meinst  , aber jetzt hats geklingelt. Keine Sorge, das ist einzwischen ein Magic Word und keine Vorlage mehr, ergo wird es sich nicht ändern.  ... ich benutz zu wenig smileys   LG --HirnSpuk 22:19, 28. Nov. 2020 (CET)Beantworten

Hallo HirnSpuk! Sorry, hatte mir nicht gedacht, sonst hätte ich direkt darauf hingewiesen. Schau dir hier kurz auch den Text-Editor, um ein paar Lösungen zu sehen:

  1. #Nummerierung hat auch Probleme
  2. zumindest der erster Schritt
  3. und wenn sie vor dem Klappbox steht, funktioniert das "verborgen" nicht

und Tabelle auch (Probiere ich hier nicht, das verursacht erhebliche Probleme)

{{{2}}}

Hier Lösungen:

  1. span funktioniert nur als Vorlage Eigenschaft für den ganzen Titel mit bg1 und tc1, lässt aber einige Möglichkeiten zu, klicke hier um den Rest zu sehen
    1. Nummerierung
    2. zproblemlos
    3. und das "verborgen"

    und Tabelle auch

    hier Tabelle

    gleiches gilt für den Inhalt mit tc2 und bg2...

LG! Yomomo 10:22, 30. Nov. 2020 (CET)Beantworten

Hallo HirnSpuk, hallo Yomomo, ich habe keine Einwände gegen jedwede Art, die Vorlagen zu notieren. Qwertz84 23:46, 30. Nov. 2020 (CET)Beantworten

Ich habe soeben noch einen sehr wichtigen Vorteil entdeckt: Wenn man die Vorlagen im Vorlagennamensraum erstellt, kann der visuelle Editor direkt darauf zugreifen. Sonst nicht. Ich werde also noch eine Woche abwarten und dann entsprechend verfahren. Gruß --HirnSpuk 23:08, 1. Dez. 2020 (CET)Beantworten

Mir ist noch ein weiterer Vorteil aufgefallen, aber auch ein Nachteil:

Vorteil: Bei Klick auf zufälliges Kapitel sollten keine Vorlagen auftauchen, was im Moment jedoch geschieht.

Nachteil: Es gibt ein paar Bücher mit einer nicht unerheblichen Menge an Vorlagen. Das würde den Vorlagennamensraum dann doch sehr belasten (rein von der schieren Menge und deren Wartbarkeit, von der Server- und Speicherbelastung sehe ich keinen Unterschied).

Ich sehe die Vorteile ganz klar überwiegen. Mangels Widerspruch werde ich das für das OpenRewi-Projekt also so einrichten. Gruß --HirnSpuk 16:50, 27. Dez. 2020 (CET)Beantworten

Das Minimal-Verfahren ist jetzt auf den Hilfeseiten eingebunden. Kann entsprechend dort: Hilfe:Vorlagen + Unterseiten angeschaut werden. Ich hoffe ich hab nichts vergessen. Gruß --HirnSpuk 18:36, 8. Jan. 2021 (CET)Beantworten

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: diskutiert, keine Einwände, Minimalergebnis umgesetzt. --HirnSpuk 18:36, 8. Jan. 2021 (CET)Beantworten

Umgang mit Theoriefindung, Falschem und Experimenten

Bearbeiten

Moin,

Auslöser: Benutzer:Rho/Recht, siehe auch zugehörige Disk + Versionsgeschichte.

Ebenfalls betroffen (nicht ausschließlich):

Nochmal, diese Liste ist nicht ausschließlich! Ich hab nur mal ein paar Sachen raus gesucht, die mich relativ direkt angesprungen haben. Nach aktuellen Regeln müsste/sollte/könnte man sicher eine Löschdiskussion führen. Vieles davon hat schon die ein oder andere (Lösch-)diskussion "überlebt". Ich halte es auch nicht für "grundfalsch" diese Dinge hier zu haben, ich halte es nur für mit zweierlei Maß gemessen, wie gelegentlich mit soetwas verfahren wird.

Ich hätte durchaus ein paar Lösungsideen anzubieten, die nicht mit einer Löschung einhergehen müssten, dafür bedarf es aber Menschen hier, die das interessiert. Wenn sich also drei Interessierte finden, die auch bereit sind, sich ein wenig Arbeit zu machen, um einen möglichen Konsens umzusetzen, bin ich gerne bereit zu erläutern, ansonsten werde ich die aktuell gültigen Regeln anwenden und evtl. Löschanträge stellen (insbesondere für den oben genannten "Auslöser" der schlichtweg falsch ist).

Gruß --HirnSpuk 20:36, 19. Dez. 2020 (CET)Beantworten

Hier in aller Kürze meine Meinung zu den Büchern und Kapiteln:

Die obige Liste würde ich gerne noch um folgende Auswahl ergänzen:

Ich finde grundsätzlich, dass man bei allerlei Regeln auch oft die Regel selbst als die den Regeln zum Opfer fallenden Bücher im Blick haben sollte, meint: Vielleicht sind auch nur die Regeln schlecht und man sollte den Autoren mehr Spielraum geben. Qwertz84 13:37, 20. Dez. 2020 (CET)Beantworten

Danke für die Erweiterung der Liste. Autoren mehr Spielraum geben und die Regeln im Auge behalten/ändern, wäre genau mein Wunsch. Das aktuelle System gibt das in meinen Augen nicht her. Und eins zu etablieren in dem das geht, benötigt Arbeit und Zeit. Daher meine Frage: Hat jemand Interesse und würde mitmachen. Deine Meinung interpretiere ich richtig, als "Nein, ich habe kein Lust"?

Wenn Du Zeit und Lust hast erläutere mir (gern auf meiner Diskussionsseite oder auf den Diskseiten der Kapitel selbst, wenn sie falsch sind), was an den Elektrotechnik-Kapiteln falsch ist. Eins hab ich versucht grade zu ziehen und bei dem anderen sehe ich keine Fehler. Und bedenke, dass Du mit Deinem Absatz "könnte aus... Feder stammen" genau das tust, was Du oben kritisierst ("..."unkonventionellen" oder "unstrukturierten" Arbeitsweise anzugehen... falsch"). Gruß --HirnSpuk 14:36, 20. Dez. 2020 (CET)Beantworten

Hier Regeln zu ändern, nun, das Thema ist für mich vorerst erledigt. Dasselbe gilt für Verbesserungen an Büchern für mich. Die Menge an Diskussionen für eine harmlose Änderung steht in keinem Verhältnis zum zu erwartenden Ertrag.

Ich halte die Bücher von Rho grundsätzlich für verbesserungswürdig. (Er auch.) Das gilt für fast alle Bücher hier, also den Teil bitte nicht falsch verstehen. Der Spruch "könnte aus Rhos Feder stammen" war humorvoll an dich gerichtet. Dieser Humor zündete wohl nicht und so habe ich ihn gestrichen. Qwertz84 00:26, 21. Dez. 2020 (CET)Beantworten

Ich will auch Porcorn (oder noch besser Cockporn, wie eine Ex von mir so sagte  ). Nää, passch scho... Erstens, was Esoterik und so betrifft, wäre für mich eine Lösung, am Anfang der entsprechenden Seiten eine Warnung zu stellen. Zweitens, was ich in Wikipedia sehe (und hier bei uns nicht, was ich gut finde), ist einen Quellen-Kult. Viele Quellen (wie Esoterik) werden gar nicht akzeptiert. Das finde ich OK. Problematisch finde ich allerdings, dass manche Quellen akzeptiert und vorangetrieben werden, andere gar nicht. Was beispielsweise Nachrichten betrifft, werden oft Quellen von Aktivisten nicht akzeptiert (mit der "Begründung", dass sie voreingenommen sind) und "offizielle" Quellen werden nicht mal kontrolliert (als ob sie nicht von eindeutigen wirtschaftlichen Interessen betrieben wären und nicht diese Interesse vertreten würden). Genauso ist es mit wissenschaftlichen Quellen (als ob sie vom sozialen Zusammenhang völlig isoliert wären, obwohl es schon Studien gibt, die zeigen, dass so was überhaupt nicht stimmt). Mein Begriff des Bildungsziels des Wikiprojekts ist, das Wissen so darzustellen, dass es von möglichst vielen Menschen verständlich wird und dadurch es durch so viele Menschen wie möglich überprüfbar (und widerlegbar) zu machen. Ich rechne damit, dass ich ab Ende Februar etwas mehr Zeit haben werde, um mich auch mit Änderungen in dieser Richtung zu beschäftigen, ich kann allerdings nichts versprechen. Gern könnt ihr dann auch eure Meinung darüber schreiben. LG! Yomomo 14:51, 23. Dez. 2020 (CET)Beantworten

Das Problem "Quellenkult" sehe ich ähnlich. Wir sollten aber der Versuchung widerstehen Wikibooks mit der Wikipedia zu vergleichen. Du sagst ab Ende Februar hättest Du Zeit Dich damit zu beschäftigen. Ich wünsche mir, dass wir uns dann vorher einigen, wie wir damit verfahren wollen, damit wir eine gemeinsame Linie fahren. Und ich wünsche mir auch, dass wir mehr Leute würden, die sich dafür interessieren. Wenns soweit ist, schreib mich an, dann kann ich Dir meine Ideen erklären.

Eine Warnung, wie Du sie vorschlägst, halte ich ebenfalls für angemessen. Weitere Wünsche von mir (nicht erschöpfende Liste):

  • Eine Entfernung aus den Bücherregalen (aber nicht aus Wikibooks!).
  • Keine Bücher mit Warnungen in Bücherregalen. (?)
  • Klare Qualitätsstandards zur Aufnahme in Bücherregale. (?)

Gruß --HirnSpuk 14:39, 27. Dez. 2020 (CET)Beantworten

Einordnung von "schwierigen" Themen

Bearbeiten

Bezüglich dieses Edits: Spezial:Diff/848882/941607; ich stimme dem Kommentar nicht zu. Es wurde jedoch ein wichtiger Punkt aufgezeigt: Die Einordnung des Buchs in das "Regal:Hobby" halte ich für diskussionswürdig. Der Umfang und der Inhalt des Buches rechtfertigen in meinen Augen keine weiter gehende Diskussion im Sinne einer Entfernung aus Wikibooks. Eine Idee könnte, in Anlehnung an die Kategorien der Wikipedia Regal:Subkultur sein? Oder vielleicht Regal:Kontroverse Themen? [[Regal:Sexualpräferenz]] ist wohl unangemessen. Gruß --HirnSpuk 14:14, 27. Dez. 2020 (CET)Beantworten

"Zurücksetzen" bestätigen

Bearbeiten

Ich habe mich verklickt und versehentlich einen Beitrag zurückgesetzt. Dieses wurde ohne Abfrage sofort durchgeführt. Dabei wollte ich mich nur bedanken. Zum Glück konnte ich meinen Fehler wieder korrigieren. Kann man bei der "Zurücksetzen"-Funktion eine Abfrage zwischenschalten, ob man wirklich die letzte Version des Vorgängers wiederherstellen will? Das könnte das Procedere beim versehentlichen Verklicken erleichtern. --mjchael 11:31, 30. Dez. 2020 (CET)Beantworten

Ist mir gestern auch passiert  . Ich finde leider nichts hilfreiches... Yomomo 12:40, 30. Dez. 2020 (CET)Beantworten

Das scheint ein exklusives Admin-Problem zu sein  . Wenn ich versuche zurückzusetzen geht erstmal ein Bearbeiten-Fenster auf. Gruß --HirnSpuk 13:46, 30. Dez. 2020 (CET)Beantworten

Na ja, man muss eben genau hinschauen:

  • "Rückgängig machen" kann jede/r Nutzer/in. Dann wird das Eingabefenster mit dem vollständigen Quelltext geöffnet ohne die letzte Änderung, dazu eine vorbereitete Zusammenfassung. Wichtig ist, dass die Zusammenfassung bei Bedarf noch eine Begründung erhalten kann.
  • Wenn ein Nicht-Admin (z.B. nach Vandalismus) mehrere Versionen entfernen will, muss er/sie die letzte „saubere“ Version aufrufen, mit einer passenden Zusammenfassung versehen und als aktuelle Version neu speichern.
  • "Danken" kann wohl auch jede/r Nutzer/in für eine Bearbeitung, allerdings nicht für IP-Änderungen.
  • "Zurücksetzen" ist eine Vereinfachung nur für Admins, mit der bei Bedarf mit einem Klick auch mehrere Versionen entfernt werden können. Hier fehlt tatsächlich die Kontrollfrage, aber auch die Möglichkeit einer Begründung.

Andererseits tritt das Problem von mjchael des vorschnellen oder versehentlichen Klicks so selten auf, dass ich es nicht für nötig halte, das zu ändern und eine Abfrage einzuführen. -- Gesundes Neues Jahr! Jürgen 11:23, 2. Jan. 2021 (CET)Beantworten

Gesichtete Versionen - Neuauflage

Bearbeiten

Moin!

Vor ein paar Jahren hat @Stephan Kulla bereits die Frage aufgeworfen, ob das Feature aus der Wikipedia zur Sichtung von Änderungen auch hier eingeführt werden sollte. Wenn ich das richtig sehe, hat die englische Version von Wikibooks es implementiert.

Neben den damals aufgeführten Vandalismus-Argumenten hat sich im Kontext von OpenRewi noch ein weiterer Punkt aufgetan. Wir versuchen, bis jetzt erfreulicherweise sehr erfolgreich, Wikibooks in die Wissenschaftscommunity zu tragen. Deshalb stehen die Autor:innen mit ihrem Klarnamen für die Inhalte auf den ihnen zugeordneten Seiten. Sie haben deshalb ein besonderes Interesse an der Qualität der Beiträge.

Dazu kommt, dass wir im Sommersemester Studienanfänger:innen aktiv in die Bearbeitung der Beiträge einbinden wollen. Gleichzeitig sollen die Bücher aber als Lehrmaterialien funktionieren. Es kann also vorkommen, dass die Kapitel gezielt von vielen Personen gleichzeitig gelesen und im besten Fall sogar geändert werden. Das wäre natürlich kein Vandalismus, bräuchte aber eine gewisse redaktionelle Arbeit.

Ich fände es sehr toll, wenn wir das umsetzen könnten und wäre natürlich auch bereit zu helfen. Übrigens in der zweiten Jahreshälfte auch als Admin, falls hier Bedarf besteht.

Herzliche Grüße Max --Maximilian.Petras 21:34, 19. Mär. 2021 (CET)Beantworten

Moin Max, erstmal vorweg: Ich bin kein Freund der Sichtung, weil es in der Wikipedia meiner Ansicht nach falsch benutzt wird. Und auch zu einer Falschnutzung einläd. Dennoch verstehe ich den Wunsch nach Werkzeugen Inhalte von Wikibooks besser redaktionell bearbeiten zu können.

Ich glaube jedoch ebenfalls, dass es eines längeren Gesprächs bedarf, bevor wir hier eine sinnvolle Entscheidung treffen können. Dazu zählt zuerst: Aufarbeiten und präsentieren, was die Sichtung alles leisten könnte und wie sie eingestellt werden kann. Meine ersten Recherchen führen mich zu der Überzeugung, dass administrativ ein Bürokrat von Vorteil wäre. Kannst Du Details nennen? Und kannst Du sagen, wie die Sichtung Euch bei der redaktionellen Arbeit helfen soll?

Wenn ich en:wb richtig verstehe, dann bekommt man dort sehr schnell den passiven Sicherstatus. Außerdem scheint es mir dort nicht wie in der Wikipedia zu sein, dass die Änderungen erst nach der Sichtung angezeigt werden, sondern direkt. Und wenn ich Deinen Wunsch hier richtig deute, dann wollt Ihr das eher, wie in der Wikipedia?

Kannst Du wie gesagt bitte nochmal darstellen, worum es Euch genau geht?

Ich hatte z. B. auch noch eine andere Idee: "Auflagen". Kapitel die redaktionell bearbeitet sind, werden als "Auflage" vollgesperrt und erhalten eine Bearbeitungskopie, die erst auf eine Art "Antrag" zur nächsten Auflage aufrückt. Vielleicht könnte man dafür sogar einen eigenen Namensraum einrichten, so wie "Diskussion:..." → "Arbeiskopie:...". (Anm.: Die Idee ist auch schwierig, weil es Lizenzverstrickungen gibt!)

Aber zurück zu meiner Meinung: Ich glaube es bedarf einer längeren Diskussion. Mich würde vor allem auch die Meinung von anderen Wikibookianern interessieren, die ich dann gezielt ansprechen würde. Voraussetzung dafür ist aber, dass Wunsch und vorgeschlagenen Werkzeuge möglichst kurz und sinnvoll dargestellt sind, dass alle auch eine qualifizierte Meinung abgeben können, ohne für sich selbst zu viel Zeit investieren zu müssen.

Wie schnell möchtet Ihr das denn entschieden sehen? Und welche Konsequenzen ergeben sich für Euch, wenn die Gemeinschaft "zu lange braucht"/ablehnt?

Viele Grüße --HirnSpuk 13:12, 20. Mär. 2021 (CET)Beantworten

@HirnSpuk: Welche Kritik hast du konkret an Sichtungen?

@Maximilian.Petras: Ich befürworte sowohl die Einführung von Sichtung, insbesondere in deinem Kontext, wie auch die Adminkandidatur. Als Admin könntest du ohnehin Artikel sperren und wenn ich mich recht erinnere, auch halbsperren (beschreibbar nur für angemeldete Benutzer). Damit ließen sich Hirnspuks "Auflagen" unmittelbar realisieren und der Vandalismus in engen Grenzen halten. Qwertz84 14:27, 20. Mär. 2021 (CET)Beantworten

@Qwertz84

  1. Sichtungen in der Wikipedia finden inhaltlich statt und nicht nur bloße Form, wie ich die Beschreibung des Werkzeugs   Wikipedia:Gesichtete_Versionen verstehe (vgl. offensichtlicher Vandalismus).
  2. Eine Sichtung, wie sie in der Wikipedia durchgeführt wird (und selbst dort genug Rückstau zu haben scheint) ist hier quasi unmöglich, wegen zu geringer Personaldecke und zu wenig Fachwissen je potentiellem Sichter.
  3. Eine Sichtung, wie sie scheinbar gerne gesehen wird (redaktionelle Durchsicht und nicht bloß reine "hat jemand f****n geschrieben"-Durchsicht) widerspricht in gewisser Weise dem "omniösen Wikiprinzip".

Solange es einen Fach-Redakteur pro Kapitel gibt, ist das kein Problem. Und wie ich sagte, ich sehe den Wunsch danach und hätte auch gerne eine Lösung für dieses Problem. Das sehe ich für OpenRewi durchaus (aktuell! Kann ja durchaus sein, dass sich das mal ändert) für gegeben, aber Gesamtwikibooks gesehen habe ich da so meine Bauchschmerzen. In meinen Augen ist das zumindest nichts, was man "mal kurz eben" macht.

Das Sperren und Halbsperren, was Du ansprichst, halte ich für die bessere Lösung und das ist genau das, was ich diesbezüglich auch im Kopf habe. Das können wir aber auch nicht einfach so machen, weil es der Wikimedia zuwider läuft. Wir sollten dort zumindest nachfragen, ob es in Ordnung geht, wenn wir eine solche Regelung einführen. Ich werde mal dort vorsichtig nach einer Meinung anfragen. Gruß --HirnSpuk 16:45, 20. Mär. 2021 (CET)Beantworten

Gute Punkte. Vielleicht lassen sich hinsichtlich der gesichteten Versionen einige Vorbehalte durch die konkrete Implementierung des Tools lösen. Ich habe dazu mal ein Meinungsbild erstellt, in dem ich eure Argumente und Positionen versucht habe, zusammen zu fassen. Ich hoffe, das war richtig so. Wenn ich die Richtlinien richtig verstanden habe, durfte ich das :) --Maximilian.Petras 21:22, 20. Mär. 2021 (CET)Beantworten

Ich halte das Meinungsbild für verfrüht. Ich hätte mir hier mehr Details erhofft insbesondere Antworten auf meine konkreten Fragen. Aber nu isses so, ich verlagere meine Äußerung also dortrüber. Gruß --HirnSpuk 21:35, 20. Mär. 2021 (CET)Beantworten

Die Funktion der Meinungsbilder hatte ich so verstanden, dass sie auch zur Diskussion der Frage selbst dienen. Auch um die Diskussion einer so wichtigen Frage übersichtlicher zu machen. Tut mir leid, wenn ich das falsch verstanden habe. LG --Maximilian.Petras 14:36, 21. Mär. 2021 (CET)Beantworten

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: Der Wunsch nach "gesichteten Versionen" wie in der Wikipedia mündete nach kurzem Gespräch im Meinungsbild Wikibooks:Meinungsbilder/_Gesichtete_Versionen. Die Erweiterung wird von der Wikimedia nicht mehr installiert. Entsprechende Recherchen sind im Meinungsbild nachzulesen. Damit ist die Sache gesichtete Versionen leider erstmal vom Tisch. --HirnSpuk 00:11, 12. Apr. 2021 (CEST)Beantworten

Sanierung von Wikibooks:Bücherregale

Bearbeiten

Ich habe mal ein wenig gebastelt. Schaut bitte mal drüber, testet mit diversen Geräten, ob es sinnvoll funktioniert und äußert Bugs und Kritik. Wenns Euch gar nicht gefällt können wirs auch revertieren.

Warum, weshalb, wieso:

  • Regal:Design mit aufgenommen
  • Fachbereiche neu aufgeteilt (inclusive teils neue Logos)
  • bessere Darstellung zwischen mobil und PC (hoffentlich, bitte testen), bessere Darstellung für das neue Vector-Design
  • Einbindungsmöglichkeit vorbereitet für Hauptseite/ Debug (das war der eigentliche Auslöser)
    • Vorteil: Regalpflege nur noch an einer Stelle

Weitere Details zu Hauptseite/ Debug, wenn ich fertig bin.

Danke und Gruß --HirnSpuk 17:25, 21. Mär. 2021 (CET)Beantworten

Sehr hübsch, HirnSpuk. Das gefällt mir sehr. Vorschlag: Statt der gestrichelten Linien unter den Rubriken einfach insgesamt mehr Platz lassen. Diese gestrichelten Linien machen das Gesamtbild unruhig. Qwertz84 19:32, 21. Mär. 2021 (CET)Beantworten

Schöne Änderung, hab mich schon bedankt!   Yomomo 19:38, 21. Mär. 2021 (CET)Beantworten

Sieht gut aus! Hab es gerade mobil getestet. Funktioniert auch da. Die Navileiste ist dort ziemlich starr und passt sich nicht an das mobile Design an. Aber da hast Du ja ohnehin nicht dran gearbeitet :) --OpenRewi 20:36, 21. Mär. 2021 (CET)Beantworten

Danke. Wie ich unten schrieb: Der mobile Skin ist leider eine Krücke und nicht Hauptinteresse der Entwickler, daher werden wir damit leben müssen. Mein Wunsch für die Zukunft ist hier aber definitiv abhilfe. Das ist aber nichts für mal eben schnell ein paar Tabellen neu machen  . --HirnSpuk 20:45, 21. Mär. 2021 (CET)Beantworten

Finde ich sehr schön. Mich stört die Navi oben, ich habe deswegen mal einen Test mit der Navi unten gemacht (und natürlich wieder revertiert). Könnt ihr euch in der Versionsgeschichte anschauen. --Scantasyundfiencefiction 20:27, 21. Mär. 2021 (CET)Beantworten

Sieht ohne strichel tatsächlich besser aus. Mehr Platz würde ich aber nicht lassen. Das soll auch noch auf der Hauptseite einbindbar sein.

Die Navi unten hab ich mir angeschaut, find ich nicht schlecht. Als ich angefangen habe, bei Wikibooks, fand ich die Navi oben allerdings gut; da sie mich oben nicht stört bin ich eher dafür sie erstmal da zu lassen. Ich bin aber sehr für ein neues Navigationskonzept. Ich finde die Portalseiten weder schön, noch übersichtlich. In diesem Zuge wird man sicher die Bücherregalseite nochmal anfassen.

Tut mir bitte den gefallen und testet auch mal mobil. In meinem Browser sieht es mobil käse aus. Schon blöd, dass wir keinen vernünftigen mobilskin haben, aber an dieser Krücke werden wir nichts tun können. Ein reiner Text-Browser frisst die Seite jedenfalls ordentlich. Gruß --HirnSpuk 20:39, 21. Mär. 2021 (CET)Beantworten

Da die mobile Version viele Funktionen nicht unterstützt, benutze ich in Mathematrix Projekt standardmäßig div class="nomobile" (am Anfang, mit /div am Ende). Man soll dann ein "Button" klicken und ooops, da erscheint die standardversion. Ich weiß jetzt nicht, ob das eine gute Idee fürs ganze Projekt wäre. Hier der Code:
<div class="noprint">
{|class="center" style="background:#AAFF99; text-align:center; float:right" border="1"
|[[File:KlickenHandy.png|x35px|link=https://de.wikibooks.org/w/index.php?title={{PAGENAMEE}}&mobileaction=toggle_view_desktop|frameless|]]
|}</div>

<div  class="nomobile">

INHALT (kein vergessenes </div> dazwischen)

</div>
Ich hab damals gefragt, ob es möglich wäre, eine Version für Mobile und eine für Standard zu bekommen (dann wäre so ein Code wie hier nicht mehr notwendig), das war damals nicht möglich (es gab keine "only mobile" oder ähnliche Funktion). Ich weiß nicht, ob das inzwischen geändert hat, wenn ja, wäre die Lösung wirklich einfach. Vielleicht geht es, in css ein only mobile funktion hinzuzufügen, da soll Stephan (Kulla) uns helfen. LG! Yomomo 21:13, 21. Mär. 2021 (CET)Beantworten

Das sind alles nur Krücken. Meines Wissens nach geht das nach wie vor nicht. Ich setze sehr große Hoffnungen in den neuen Vector-Skin. Der sieht mobil schon ziemlich schick aus. Und auf den müssen wir ja hoffentlich nur ein Jahr warten. Dann kann man vielleicht Minerva ganz deaktivieren, wenn dann noch jemand da ist, der sich damit auskennt  . Mobil die alte Desktopversion zu benutzen ist schon ziemlich heftig. Das würde ich niemandem zumuten wollen. Gruß --HirnSpuk 21:59, 21. Mär. 2021 (CET)Beantworten

Bei meinen Schülern ist die jetzige Standard (nicht die mobile) Version kein Problem, man kann das Bild ja ganz leicht jeder Zeit vergrößern... Aber egal, wie schon gesagt, finde ich auch diese Lösung nicht ideal... Ich finde sie allerdings besser, als die jetzige mobile version zu benutzen (wo ich kaum was machen kann, z.B. kein Klappbox benutzen...). Krücken mir lieber als nichts :-) . Bis wir selbstverständlich was besseres finden. LG! Yomomo 08:31, 22. Mär. 2021 (CET)Beantworten

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: Die Sanierung der Übersichtsseite der Bücherregale Vgl. Spezial:Permanentlink/903731 und Spezial:Permanentlink/952394 wurde nicht mit Gegenwehr bedacht. --HirnSpuk 00:15, 12. Apr. 2021 (CEST)Beantworten

Ich befürchte, wir haben mehrere Probleme

Bearbeiten

Tach zusammen,

Von mir empfundene unschöne Situationen:

  1. es gibt nur einen aktuell aktiven Admin
  2. es gibt für mich gefühltes Durcheinander in Wikibooks
    • Bücher die nicht in die Regale einsortiert sind
    • Bücher die einsortiert sind, aber so schmalbrüstig, dass Menschen anfangen darauf Löschanträge zu stellen, oder zweifelhaft aber so umfangreich, dass niemand Lust auf einen Löschantrag hat
    • Vorlagen die aus Bequemlichkeit genutzt werden, aber einen ziemlich unhöflichen Eindruck hinterlassen
    • Nicht konsistente Zusammenhänge auf den Gemeinschaftsseiten
    • Regeln sind im Hilfenamensraum in langen Texten verbuddelt
    • Die Kategorien sind alles andere als aufgeräumt
  3. Wikibooks verharrt in einem status quo (aka "Das hamwa schon immer so gemacht")

Diese Liste ist sehr wahrscheinlich nicht vollständig.

Ich möchte jetzt nicht, dass alle die Lust haben wild durcheinander laufen und einfach irgendwo anfangen. Das macht im Zweifel mehr kaputt als besser.

Ich sehe mehrere Möglichkeiten:

  1. Wir lassen alles wie es ist, "sollen sich die Admins drum kümmern oder wer auch immer sich berufen fühlt"; Zusammenarbeit, was ist das, wir wollen Bücher schreiben, oder zumindest daran herum nörgeln  
  2. Wir gehen, wie aktuell üblich "extrem" kleinschrittig vor, wer auch immer Lust hat und zu großflächig vorgeht, geht das Risiko ein, sich von einem alt-eingesessenen einen Rüffel abzuholen.
  3. Wir fragen mal alle aktiven Autoren aktiv nach Ihrer Meinung und laden sie ein unten stehende Fragen zu beantworten
  4. Wir reaktivieren die Benutzer:HirnSpuk/ Wikibooks Projektentwicklung/ 2018 und sprechen dort weiter

Diese Liste ist mit Sicherheit nicht vollständig.

Es gibt bereits aus der Vergangenheit zwei(drei) Positionen:

  1. Rigoros löschen und neu machen
  2. Vorsichtig evaluieren was da ist und sortieren, schon allein aus Rücksicht auf die Arbeit der Vorgängergenerationen (Das ist mein präferierter Wunsch)
  3. (Wikibooks ist ohnehin im Niedergang begriffen, außerdem gibt es niemand Aktiven, ergo lohnt es sich nicht irgendwas zu machen)

Diese Liste ist, glaube ich, relativ vollständig.

Wie ich oben bereits schrieb, arbeite ich an Hauptseite/ Debug. Dabei sind mir diverse Dinge aufgefallen, die das Fass bodenlos erscheinen lassen. An sich ist das nicht schlimm. Es macht nur wenig Sinn mit etwas anzufangen, wenn alle sagen: "Spinnst Du, ist doch voll super hier!"

Alle die hier mitlesen: Ich bitte um Kommetare durch kurze Ein-Wort- oder Ein-Satz-Beantwortung der folgenden Fragen (Kopiervorlage für den Wikiquelltext). Daraus werde ich ableiten, ob ich a) einfach mache oder b) ein Meinungsbild versuche zu erstellen oder c) aufhöre nachzudenken:

-->
{{-|{{Kommentar}} --~~~~

# –
#; Siehst Du auch strukturelle Probleme auf Wikibooks?
#: Antwort: ...
#; Falls möglich; Welches siehst Du als dringendstes Problem?
#: Antwort: ...
# –
#; Findest Du, Wikibooks sollte renoviert werden?
#: Antwort: ...
# –
#; Möchtest Du mitentscheiden, wie es wird?
#: Antwort: ...
# –
#; Möchtest Du daran arbeiten, wie es wird?
#: Antwort: ...
# –
#; Gibt es ergänzende Anmerkungen, die Du mit in der Diskussion haben möchtest?
#: Antwort: ...

Ende Kommentar --~~~~}}

Zu 1): Ich möchte gerne wissen, ob ich der einzige bin, der hier Handlungsbedarf sieht.

Zu 2): Ich möchte rausbekommen, ob die gesehenen Probleme strukturell optisch, oder rein persönlich/Umgang sind. (Ich finde beides)

Zu 3): Ich möchte wissen, wer sich alles an einer Abstimmung über Neuerungen beteiligen würde. (Ich definitiv)

Zu 4): Ich möchte wissen, wer Interesse hat, daran zu arbeiten; mit diesen Personen würde ich mich im Nachgang zusammensetzen, wenn Frage a) überwiegend als notwendig angesehen wird.

Zu 5): Falls alle vorigen Fragen entsprechend beantwortet werden, möchte ich gerne wissen, ob dem oder der Antwortenden etwas besonders unter den Nägeln brennt. (Selbst wenn ich allein, ohne Rückmeldung weiter machte, bin ich da auf Hinweise angewiesen)

Ich bin gespannt auf Eure Rückmeldungen. Gruß --HirnSpuk 15:07, 28. Mär. 2021 (CEST)Beantworten

  Kommentar --Qwertz84 16:56, 28. Mär. 2021 (CEST)Beantworten

  1. Siehst Du auch strukturelle Probleme auf Wikibooks?
    Antwort: JA
    Falls möglich; Welches siehst Du als dringendstes Problem?
    Antwort: (1) Chaos bei den Hilfeseiten, diese enthalten gelegentlich von einzelnen Admins ohne Community-Rücksprache erfundene "Regeln". Für mich sollten Hilfeseiten lediglich technischer Natur sein, also beispielsweise: Wie erzeuge ich eine Tabelle? oder Wie kommen Bücher ins Regal und auch wieder heraus? oder ähnlich. (2) Gliederung der Hilfe kann deutlich verbessert werden. (3) Alle Wikimedias benötigen dieselbe oder ähnliche technische Hilfe. Da muss sich doch was machen lassen?
  2. Findest Du, Wikibooks sollte renoviert werden?
    Antwort: JA
  3. Möchtest Du mitentscheiden, wie es wird?
    Antwort: Wenn es lediglich um Abstimmungen geht: ja. Bei Anregungen und Meckerei bin ich auch gerne dabei.
  4. Möchtest Du daran arbeiten, wie es wird?
    Antwort: Nö
  5. Gibt es ergänzende Anmerkungen, die Du mit in der Diskussion haben möchtest?
    Antwort: (1) Ich finde, dass es seit Mitte Januar netter wird hier. (2) Ein bisschen Humor tut uns allen gut. (3) Dass man Sorge vor Rüffeln haben muss, liegt an genau zwei Personen. Von denen ist einer kein Admin mehr, der Andere kein "aktiver Admin" mehr. (4) Niemand erwartet Perfektion -- hoffe ich wenigstens. (5) Wenn man ein Klima des ständigen Wandelns akzeptiert, dann kann Hauptseite/ Debug doch einfach die Hauptseite ersetzen weil Debug schöner und klarer ist. Die nächste Debug-Seite kann selbiges in einem Jahr auch wieder tun.

--Qwertz84 16:56, 28. Mär. 2021 (CEST)Beantworten

  Kommentar Yomomo 21:27, 28. Mär. 2021 (CEST)Beantworten

  1. Siehst Du auch strukturelle Probleme auf Wikibooks?
    Antwort: JA
    Falls möglich; Welches siehst Du als dringendstes Problem?
    Antwort: Wie Qwertz84 und dazu: Ich halte die Quellenangabe NICHT für eine heilige Regel. Diese Art von "Quellerei" haben wir mit jeglichem religiösen Schrift gehabt (ja, auch mit der Bibel  ). Ich frage mich auch, wie in Wikipedia sich durchgesetzt hat, Zeitungen als wichtiger Quelle als wissenschaftlichen Artikel zu halten. Ich bin für Dialog. In Zweifelsfälle bin dafür, dass die Argumente von beiden Seiten da bleiben, auch wenn sie nicht aufeinander gehen (also auch wenn die eine Seite nicht direkt auf die Argumente der anderen eingeht). Aber das ist jetzt ein Vorschlag und sicherlich nicht das Dringendste.
  2. Findest Du, Wikibooks sollte renoviert werden?
    Antwort: JA
  3. Möchtest Du mitentscheiden, wie es wird?
    Antwort: Je nach Zeit und Lust
  4. Möchtest Du daran arbeiten, wie es wird?
    Antwort: Je nach Zeit und Lust. Vor allem: wer arbeitet, sollte respektiert werden, also positive Punkte betonen und höflicher Umgang.
  5. Gibt es ergänzende Anmerkungen, die Du mit in der Diskussion haben möchtest?
    Antwort: Siehe Qwertz84. Seine 2. Bemerkung hier betrifft, glaube ich, seine "ha ha" Reaktion. Aber wie Hirnspuk kommentiert hat (ich hoffe ich miss-interpretiere dich jetzt nicht), es gibt auch Personen, die überempfindlich sind und das ich auch gut so  . Was die Umsetzung betrifft, bin ich eher für weniger Planung (aber selbstverständlich nicht ohne Planung) und mehr für Lernen durch Action. Wer dann mit Rat und Tat helfen kann, sehr gern, das haben wir auch mit Hirnspuk und Dirk in OpenRewi gesehen, das war SUPER!

LG! Yomomo 21:27, 28. Mär. 2021 (CEST)Beantworten

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: Ich entscheide mich für Option D: Ich werde versuchen eine generelle Nutzerbefragung zu planen und durchzuführen. --HirnSpuk 04:04, 16. Mai 2021 (CEST)Beantworten

Wikibooks Abstellraum

Bearbeiten

Moin,

leider kein Verbesserungsvorschlag, weil ich keine Idee habe. Aber etwas, wo ich nicht wusste wohin damit. Da es tendenziell aber einer Verbesserung bedarf, habe ich mich für diese Seite für diesen Hinweis entschieden.

Problem: Kürzlich stellte eine IP einen SLA auf Allgemeiner Teil des BGB/ Grundprinzipien des Anspruchaufbaus. Laut Hilfe:Löschregeln ist das zulässig, sowohl der Antragsteller, als auch der SLA als solcher, weil Hilfe:Löschregeln#Schnelllöschungen, Pkt. 4.

Ihr kennt mich: da ist doch das Neue noch nicht von und auf Vorhandenem aufbauen find ich geiler als immer alles neu machen. Das soll ja in einem Wiki auch grade so sein.

Nichtsdestotrotz: Wer guckt schon in den Abstellraum? Außer mir  ... Ab und zu mal  

So zu den zu verbessernden Fragen:

  • Wollen wir weiterhin einen Abstellraum haben?
  • Die Schnelllöschregeln definieren den Abstellraum eigentlich als überflüssig, da (üblicherweise) alles darin "sehr kurze Seiten ohne Definition oder Kontext" sind (vgl. Hilfe:Löschregeln#Schnelllöschungen, Pkt. 4), hieße, Seiten, die in den Abstellraum kämen wären direkt zu löschen.
  • Wenn wir ihn erhalten wollen, wie präsentieren wir den Inhalt dort so, dass er auch find- und nutzbar wird?

Solange hier niemand was beizutragen hat, müssen wir wohl mit dem Status Quo leben, heißt: Der SLA bleibt stehen und irgendwann entscheidet ein Admin, wie mit dem Inhalt umzugehen ist.

Ich befürworte den Status Quo, da ich einen Abstellraum für sinnvoll halte und ich ihn einfach nur, wie alles andere auch, für schlecht gepflegt halte. Solange also die sonstige Struktur nicht in besserer Spur ist, sollten wir den Abstellraum weder umbauen noch abschaffen. Meine Meinung.

Viele Grüße --HirnSpuk 16:38, 3. Apr. 2021 (CEST)Beantworten

Anmerkung am Rande: Bzgl der verlinkten Seite: Habe sie gelöscht, weil sie damals tatsächlich bei der Löschung von Allgemeiner Teil des BGB vergessen wurde. (Die letzte Löschung von Allgemeiner Teil des BGB war 2010 und nachdem 2007 Allgemeiner Teil des BGB/ Grundprinzipien des Anspruchaufbaus in den Abstellraum verschoben wurde)

Wenn ich schon da bin, hier meine Meinung: Ich persönlich kann mich in meiner Zeit bei Wikibooks an keinen Fall erinnern, in dem Inhalte vom Abstellraum wiederbelebt wurden oder in andere Projekte übernommen wurden. Gleiches gilt insbesondere auch für unser Projekt Mathe für Nicht-Freaks in dem wir auch einen Abstellraum haben. In meiner Tätigkeit als Autor habe ich auch festgestellt, dass es einfacherer ist, neue Texte zu schreiben, als fremde Texte zu übernehmen und zu verbessern. Insofern sehe ich den Abstellraum als eine Art "bequemeres Löschen" an. Eine Entscheidung, etwas in den Abstellraum zu verschieben, ist nicht so hart wie die Löschentscheidung und kann deswegen leichter getroffen werden.

Mein Vorschlag: Alles was länger als X Jahre im Abstellraum war, kann schnellgelöscht werden. So haben die Inhalte noch eine Chance, einen neuen Autor / eine neue Autorin zu finden. 3 oder 5 Jahre sind für mich eine gute Zeit. -- Stephan Kulla 15:50, 13. Mai 2021 (CEST)Beantworten

Ich denke das macht es sich ein bisschen zu leicht. Nur weil jemand eine Arbeitsweise hat, die gegenteilige nicht zu sehen, passt nicht. Ich habe bei Wikijunior lieber vorhandenes bearbeitet statt neu zu schreiben. Wenn jemand wie ich kommt, hat er oder sie quasi gar keine Chance den Inhalt aus der Abstellkammer zu finden und zu verbessern. Daher wird die AK derzeit in der Tat eingesetzt, wie "bequemes" löschen. Das macht es aber nicht besser.

Seit dem 9.4. hab ich eine Idee und arbeite daran. Wer Interesse hat darf sich gerne melden. Gruß --HirnSpuk 16:19, 13. Mai 2021 (CEST)Beantworten

@HirnSpuk: Cool, dass du da eine Idee für den Abstellraum hast. Von mir aus hast du gerne freie Hand, den Abstellraum neu zu gestalten / aufzuräumen / umzugestalten. Schreib mir, wenn du irgendwie administrative Hilfe dabei benötigt (gerne per Nachricht auf meiner Diskussionsseite). -- Stephan Kulla 13:41, 15. Mai 2021 (CEST)Beantworten
Bearbeiten

Moin, aufgrund dieser Diskussion Benutzer Diskussion:HirnSpuk#Was meinst du? hier an alle die Frage: Völlig unabhängig vom tatsächlichen bisherigen Umgang: Was ist Link-Spam und wie soll damit umgegangen werden?

Hierbei gibts ein paar Probleme:

  1. Links setzen können wir "eigentlich nicht" untersagen.
  2. "Eigentlich" müssten wir das unter Umständen. Meine Prüfung bei Spanisch/ Weblinks war ziemlich ernüchternd. Über ~30 – 40% der Links war entweder tot, anderer Kram, verändert oder übernommen.
  3. Kann jemand einschätzen, wie das rechtlich ist?

Ich sehe Yomomos restriktiven Ansatz (vgl. unten), aber wie wollen wir Links überprüfen? Und wie gehen wir in so einem Fall mit sowas um: Baltische Länder: Von der singenden Revolution bis zur Gegenwart?

Es stehen hier vermutlich noch weitere Waffen zur Verfügung, wie Nutzerrechte, Eingabeprüfungen, etc. die ich aber nicht einschätzen kann. Dennoch befürworte ich eine sinnvolle Regelung und die Frage ist, ist die aktuelle Regelung ausreichend?

Das dichteste, was ich schnell finden konnte ist

  1. Wikibooks:Vandalensperrung/ Richtlinien – "mehrfaches Einfügen von kommerziellen Links" und
  2. Hilfe:Links/_Auf_eine_Website – "kommerzielle Angebote nur in Ausnahmefällen (z. B. wenn es keine kostenlosen Angebote gibt oder das Angebot besonders gut zum Thema passt)"
  3. sowie Hilfe:Was Wikibooks ist – "Wikibooks ist keine Linksammlung. Links zu anderen Webseiten sollten nur als Ergänzung dienen und nicht Hauptbestandteil eines Lehrbuches sein."

Vielleicht meldet sich ja auch jemand der die aktuellen Linkregeln aus dem Hilfenamensraum besser zusammenfassen kann. Bei den englischsprachigen Kollegen nebenan konnte ich auf die Schnelle keine Richtlinie finden.

Wenn ich das richtig interpretiere, dann decken diese Seiten meine unten geäußerte Meinung.

Wer sich berufen fühlt daraus ein Meinungsbild zu erstellen, nur zu! Gruß --HirnSpuk 13:23, 9. Apr. 2021 (CEST)Beantworten

Meinungsäußerung: Was ist Linkspam?

Bearbeiten
  1. Alles, was Bezahlung verlangt
    •   Ja glaub ich schon Yomomo
    •   Ja ziemlich eindeutig. Es gibt aber Ausnahmen! Es gibt nunmal Dinge, die gelernt werden müssen, die aber in der Welt draußen nicht kostenfrei erhältlich sind. Ein Link hier halte ich für angemessen. Diese Links fallen aber eher nicht auf, weil sie voraussichtlich von Nutzern gemacht werden, die kein werbendes Interesse haben. Alle anderen dürfen auch durchs Raster fallen, weil Sie vermutlich werbendes Interesse haben. Ich wollte damit nur sagen: Ich für meinen Teil drehe einer Autorin, die hunderte Stunden in ein Buch gesteckt hat keinen Strick aus einem sinnvollen kommerziellen Link. HirnSpuk
  2. Alles, was zwar gratis ist, aber von Werbung abhängt
    •   Nein aber mit striktem Hinweis, dass Werbung i.d.R. NICHT gratis ist Yomomo, siehe z.B. hier
    •   Neutral kommt drauf an; z. B. Youtube hängt von Werbung ab, muss aber nicht unmittelbar welche enthalten und kann lehrreich sein, daher würde ich das nicht prinzipiell ausschließen. Könnte man aber machen, wenn alle dafür sind. HirnSpuk
  3. Alles, außer was unter CC veröffentlicht wird
    •   Nein siehe oben Yomomo
    •   Nein, eher, denn nicht alles, was kostenlos veröffentlicht wird, wird unter CC gestellt. Wenn wir uns diese Links versagen, dann nehmen wir uns eine Option. Dann bleibt allerdings die Wartungsfrage. HirnSpuk

Wie soll mit "Spammern" im oben gemeinten Sinn (einzig hinzufügen von unerwünschten Links) umgegangen werden?

  1. sofort dauerhaft sperren
    •   Nein HirnSpuk
    •   Ja unter Umständen: Fremdsprachig UND spam (und gar kein anderer Beitrag). Man darf nicht vergessen, dass wenn eine Person sich anmeldet und gesperrt wird, immer sich wieder mit einem anderen Namen melden kann, falls sie sich beschweren will.
  2. Ein Strike (nach dem zweiten Vorfall für drei bis sechs Monate sperren)
    •   Ja HirnSpuk
    •   Ja unter Umständen: Wenn nur eines von beiden, dann irgendwie markieren (andere Version von Schnelllöschen, die höflicher sein kann..) Ich hab wirklich keine Ahnung, wie ich unter Umständen mehrere Benutzer unter ausreichender Beobachtung halten könnte.
  3. Zwei Strikes (nach dem zweiten Vorfall eine Warnung und nach dem dritten Vorfall für drei bis sechs Monate sperren)

Löschungen

Bearbeiten

Ich wollte nur mal darauf hinweisen, dass Löschungen keine "Platzersparung" in den Servern schaffen. Die Sache bleibt gespeichert. Vielleicht wäre es sinnvoller, bei Artikeln die nicht Regeln wie z. B. Urheberrechte verletzen, etwas anderes zu benutzen, z. B. dass der Artikel ein "Stub" ist oder dass er nicht wissenschaftlich/belegt oder was auch immer ist, oder seine Qualität manchen Standards nicht entspricht usw. Nur so als Frage... LG Yomomo 09:32, 11. Apr. 2021 (CEST)Beantworten

Ich für meinen Teil weiß das, verfechte diese Position schon seit Jahren und ich arbeite dran. Wenn sich jemand beteiligen möchte freue ich mich über Nachricht auf meiner Diskussionsseite. (Wir müssen halt darauf achten, dass wir die Strukturübersicht behalten. Sonst sind irgendwann so viele unstrukturierte Seiten vorhanden, dass man nicht mehr durchblickt, geschweige denn aktiv aufräumen kann.) Gruß --HirnSpuk 13:13, 11. Apr. 2021 (CEST)Beantworten

Bin bei euch. Tatsächlich ist es so, dass die Löschung eines Artikel Speicherplatz verbraucht, weil zusätzliche Einträge in der Datenbank hinterlegt werden. Jedoch ist die Frage nach Speicherplatz komplett irrelevant. Speicherplatz ist so billig und Quelltext nimmt so wenig Speicherplatz ein, dass Wikibooks sich in der Artikelanzahl ohne Probleme verzehnfachen / verhundertfachen kann. Es gibt aber andere Argumente fürs Löschen, die ich noch nennen möchte:

  • Wikibooks hat keine Möglichkeit, mehrere Artikel unter denselben Namen anzulegen. Wenn also jemand ein Buchanfang beginnt, kann niemand anderes diesen Namen für sich und sein Projekt nutzen.
  • Mehr Artikel bedeutet mehr Wartungsaufwand und mehr Aufwand, eine übersichtliche Navigation zu erstellen. Hier gibt es Namensräume, wo ich die Löschung oder Verschiebung in den Abstellraum / ins Archiv stark empfehle:
    • Hilfeseiten: Je weniger Hilfeseiten wir haben, desto einfacher haben es neue Autor:innen
    • Lua-Module: Je weniger Code zu pflegen ist, desto besser (weniger Bugs zu fixen, weniger Änderungen in der Zukunft, bessere übersicht). Gerade in der Software gilt: Weniger ist mehr.
    • Vorlagen: Stellt euch vor, es gäbe 5 verschiedene Vorlagen, um eine Info-Box anzuzeigen. Wenn neue Web-Technologien genutzt werden sollen (wie besseres CSS oder eine bessere Darstellung auf mobilen Endgeräten) müssen 5 Vorlagen angepasst werden. Auch für Autor:innen ist es unübersichtlicher. Wir haben viel weniger Aufwand, wenn es nur eine globale Vorlage gibt. Autor:innen haben mit projektspezifischen Vorlagen immer noch die Möglichkeit, ihr eigenes Ding zu machen.

Wohlgemerkt: Bei keinen der obigen Gründe ist eine Löschung unbedingt das Mittel der Wahl. Artikel in einen Abstellraum zu verschieben oder alte Artikel in ein Archiv zu verschieben, macht bspw auch einen Artikelnamen wieder frei und für andere deutlich, dass der Inhalt veraltet / nicht mehr aktuell ist. -- Stephan Kulla 13:59, 15. Mai 2021 (CEST)Beantworten

tldr: Wir werden das Problem nicht hier und nicht jetzt lösen. Wer Bock auf ein paar Ideen hat, liest weiter.

Ich bitte zu bedenken: Eine Verschiebung macht Arbeit! Bei den Inhaltsnamen (ich sage bewusst nicht Kapitel), sehe ich ein generelles Problem. Gerade im Mathematik-Bereich, wo Ihr ja her kommt, haben sich viele parallele Namen entwickelt. Wie sieht es aus mit Information oder Entropie? Könnte nicht ein "Wer zuerst kommt malt zuerst"-Prinzip gelten? Ich habe diese beiden Beispiele bewusst gewählt, denn gerade der Gurkeninhalt (Entschuldigung, aber so sehe ich es) "blockt" die Bezeichnung für andere Autoren. Im Regal:Informationswissenschaft wird die ganze Sache hochtrabend "Über das Wesen der Information" genannt. Welche "Ansprüche" hätte nun eine Autorin, die ihr Buch "Über das Wesen der Information" nennen will? Und welches Buch ist in der Internetsuche besser findbar? Es gibt ja im Prinzip 3 Fragen:

  1. Wie wird das Kind genannt? (Sind zum Beispiel auch Abkürzungen erlaubt? Und warum lässt man Sonderzeichen in der URL nicht weg?)
  2. Wie kann es gefunden werden? (Haben die Inhalte von MfnF online die gleiche Wahrscheinlichkeit wie die Inhalte von Mathematrix? Stichwort SEO)
  3. Wie ist die beste Balance aus Nutzbarkeit und Korrektheit? (Nützlichkeit und "usability", kein Mensch tippt im Browser ernsthaft: Das Mehrkörperproblem in der Astronomie/ Allgemeine Lösungsmethoden/ Prädiktor-Korrektor-Verfahren: Leapfrog und Hermite-Polynome)

Namenskonventionen? {{PAGETITLE}}? [[Information-2004-A]] statt Information? Der Nächste schreibt halt [[Information-2021-A]]. Damit ließen sich auch Auflagen und Forks direkt mit abbilden. Oder man vergibt wie in einer Bibliothek pro Buch eine Signatur, z. Bsp. [[IW-2004-001]] (Regalkürzel-Jahr-lfd.Nr.)? Ließe sich sowas sinnvoll kategorisieren? Würde das als Link ausreichen um der CC-Lizenz zu genügen (das wäre ein weiterer Vorteil)? Oder man verlangt grundsätzlich Titel + Untertitel + Jahr? Unterseiten dürfen abgekürzt werden?

  • Grundsätzlich bin ich bei Stephan was die Hilfe angeht. Aber jetzt hektisch Hilfe-Seiten zu löschen wäre falsch, insbesondere, da dort ALLE aktuellen Regeln kodiert sind. Zu Hilfeseiten hätte ich einen klaren Wunsch: Jede Seite und jede Funktion, die Wikibooks-spezifisch ist, hat eine Hilfeseite. So kann man z. B. Regel (Wikibooks:Namenskonventionen – wie ist es) und Erklärung (Hilfe:Namenskonventionen – warum ist es) trennen. Jede Funktion und jede Seite, die Wikimedia-spezifisch ist sollte auf meta verweisen und jede Seite oder Funktion die Mediawiki-spezifisch ist, sollte aufs Mediawiki verweisen sowie jeweils dort gepflegt werden.
  • Lua ist für mich ein Grauen. Durch die Dokumentation blicke ich nicht durch. In der Wikipedia auch nicht. Einzige Chance für mich, wär die Sprache zu lernen.
  • Vorlagen: Ganz bei Stephan. Wobei die importierte Info-Vorlage ja auch einen anderen Zweck hatte, als wie es hier eingesetzt wurde.

Gruß --HirnSpuk 04:02, 16. Mai 2021 (CEST)Beantworten

Wokeness – PC – Politische Korrektheit – wie auch immer...

Bearbeiten

Moin,

jahrelang habe ich mich selbst gesträubt!

Ich hab nichts gegen Menschen, ein paar meiner besten Freunde sind Menschen!

Ich gehe davon aus, dass wir um diese Diskussion und eine entsprechende Richtlinie früher oder später nicht drumrum kommen werden. Insbesondere, wenn ich mir die aktuelle Stoßrichtung der Wikimedia anschaue (vgl. m:Universal Code of Conduct). Und seien wir doch mal ehrlich: Das ist auch gut so!

Meine eigene Entwicklung mal geschildert: Früher hab ich gedacht, die Diskussion ist doch überflüssig, niemand nutzt das so, wie es kritisiert wird. Der Fehler den ich hierbei gemacht zu haben glaube ist: ich habe von mir auf andere geschlossen!

Im Laufe der Zeit glaube ich Folgendes verstanden zu haben: Selbst wenn Menschen, wie ich, das machen, leisten wir den Leuten Vorschub, die das wirklich ernst meinen (die Blauen?).

Als vermuteter Angehöriger einer Minderheit, die "nur selten" auffällt (das braucht jetzt hier nicht diskutiert zu werden!), wünschte ich es gäbe eine Lobby für Menschen wie mich. Die gibt es nicht. Und auch das ist gut so, denn nicht jede Minderheit muss zwingend um jeden Preis berücksichtigt werden, solange sie nicht als Beleidigungssubstitut (z. B. "Das ist doch schw***") benutzt wird oder unter historischen Gegebenheiten zu leiden hat (z. B. Kolonialismus) etc.

Nundenn: seit ich im Radio darüber nicht stolpere gegenderte Texte zu hören und ich mir bewusst ein vierhundertseitiges vollständig durchgegendertes Buch gekauft habe (was sich auch mit den Problemen von PoCs beschäftigt, um hier dem Einseitigkeitsvorwurf gleich mal den Wind aus den Segeln zu nehmen), um zu sehen, ob es meinen Lesefluss tatsächlich stört (tut es nicht!), habe ich meine Meinung geändert.

Grundlage ist also: Niemand bricht sich einen Zacken dabei aus der Krone achtsam zu sein, für bestimmte Personengruppen hat es aber massive Auswirkungen, ob man es auf die eine oder andere Weise macht.

Folglich werde ich die kürzlich angelegte Seite Kochbuch/Negerkuss in zwei Wochen zu Kochbuch/Schokokuss verschieben (denn das deutsche Lebensmittelrecht ist mir im Gegensatz zu gegenseitigem Respekt eher wurscht), falls sich hier keine nennenswerte Debatte entwickelt oder es der initiale Autor nicht selbst tut. Jeder der meint Schaumkuss ist die Schokolade betreffend der schokolitisch korrekte Begriff darf diese Verschiebung selbstverständlich gerne machen  .

Noch eine Randnotiz: Wer hier in der Diskussion meint, den vom reinen Sinn her ja eigentlich positiven Begriff w:Gutmensch in den Mund nehmen zu müssen, dem empfehle ich sich mit diesem Begriff und seiner Geschichte umfassend auseinander zu setzen.

Soviel von meiner Seite. Ping@Benutzer:SchlauFuchs. Gruß --HirnSpuk 14:47, 11. Apr. 2021 (CEST)Beantworten

Ich bin nicht dagegen, ich bin auch nicht dafür, ich würde aber schon in beiden Fällen eine Weiterleitung auf den anderen Namen lassen und unbedingt einen kurzen Bericht über den alten Namen schreiben und auf die abwertende Anwendung des Wortes Neger hinweisen, auch mit Links zu historischem Hintergrund und Menschenrechte... Mir ist es wichtiger, so weit möglich, die Haltung als das Wort im Sinne der Menschenrechte zu ändern. Und wenn das Wort verschwindet, verschwindet die Haltung (leider) nicht (oder nicht unbedingt).   LG!
@HirnSpuk: Dank dir für dein Vorstoß. Ich war mal so frei, das umzusetzen. Eine Weiterleitung von Kochbuch/ Negerkuss auf Kochbuch/ Schokokuss ist auch erstellt. LG -- Stephan Kulla 14:08, 15. Mai 2021 (CEST)Beantworten

{{erledigt|"Negerkuss" verschoben nach "Schokokuss" und entsprechend mit Hinweis versehen. Erledigt von [[Benutzer:Stephan Kulla|Stephan Kulla]]. Merci vielmals --[[Benutzer:HirnSpuk|HirnSpuk]] 02:40, 16. Mai 2021 (CEST)}}

Neger ist kein abwertender Begriff, genausowenig wie "Weisser Mann" es ist, denn es ist nichts anderes als eine Feststellung der Hautfarbe. Wer eine dunklere Hautfarbe als abwertend empfindet, nutzt meist andere Worte. Dasselbe gilt fuer Mauren, oder Mohren, was nur ein altertuemlicher Begriff für Mauretanier ist. Ich bin generell dagegen dass eine Minderheit von PC-empfindlichen Menschen an der Spracher herumfurwerkt. Die Unterbindung von Worten hilft nicht, die Menschen besser zu machen, welche selbst rassistisch eingestellt sind. Und die Schwarzen werden nicht ein mal gefragt. SchlauFuchs 22:14, 22. Mai 2021 (CEST)Beantworten

Nun, es gibt ja auch korrespondierende Bezeichnungen wie Kartoffel oder Weißbrot für den 'Weißen', was schon als Retourkutsche gelten mag ;o) Ich halte es nun auch für schlecht, etwa den Negerkönig aus Pippi Langstrumpf zu streichen, das bietet ja inhaltlich allerhand Möglichkeiten für Interpretationen über den gesellschaftlichen Kontext oder die Einstellung oder Herkunft oder Lebensweg der Protagonisten.
Bei aktuellen Bezeichnungen von Sachen stellt sich indes schon die Frage, ob sich nicht Provokationen gut vermeiden lassen, darum muß man nun nicht gleich Hamburger, Frankfurter, Berliner, Florentiner, Thüringer, Amerikaner, Pekinesen etc ebenfalls umbenennen, solange sich damit keine Personengruppen direkt angegriffen fühlen.
Von der Herkunft, historischer Assoziationen bin ich mit bei einigen Wörtern auch nicht so sicher. Nun gibt es allerdings nicht bloß im angelsächsischen Kulturraum weiterhin Irrungen um Rassen, historische Bewertungen von Kolonialismus etc, insbesondere Deutschland hatte ja einst ebenso mit einem tausendjährigen Reich den Gipfel der 'Rassenkunde' erklommen, mit bekannten Folgen, insofern steht es uns gut an, eher darauf zu gucken, wer sich aktuell angepißt fühlt durch Bezeichnungen als darauf, was mal vor zwei oder mehr Jahrhunderten aktuell gewesen sein mag. Bedeutungen aus dem angelsächsischen Kulturraum schwappen überdies herüber, was sowieso kaum abzuwehren ist, jedenfalls fehlt es da schon an der Konsequenz, bereits verfügbare deutsche Begriffe zu verwenden, da kann es nicht wundern, wenn bei ähnlichen Begriffen Bedeutungsverschiebungen eintreten oder entsprechend verstärkt werden. Hilft ja wenig, wenn bloß du für deine Sprache die Harmlosigkeit der Assoziation feststellst, es vielen anderen jedoch nun anders ergeht, egal was man vor Jahrhunderten einmal damit assoziiert haben mag. Beim deutschen 'geil' hat sich ja nun über die letzten hundert Jahre gleichfalls eine deutliche Bedeutungsverschiebung ergeben, sinnlos, dies nun bei heutiger Verwendung komplett zu ignorieren.
Ein Problem bleibt trotzdem die Vereinnahmung von Begriffen für bestimmte oder weniger bestimmte Ideologien. In diesem Zusammenhang bei der Vokabel kann man das allerdings getrost gelassen sehen. Doktorchen 11:45, 23. Mai 2021 (CEST)Beantworten

Moin, "Neger – Weisser Mann(sic)"? Merkste selbst? Ich habe Menschen mit anderem Aussehen (und weitere Minderheitsangehörige) durchaus gefragt. Und bin zu dem Schluss gekommen: Die Minderheit, die sich davon gestört fühlt, hat es verdient, dass sich die große Mehrheit gefälligst an Geringfügigkeiten gewöhnt. Vollkommen egal, wie die Worte historisch, etymologisch oder emotional einzuordnen sind. Es handelt sich hierbei ja um Betroffene und nicht um "PC-empfindliche Menschen die an der Spracher herumfurwerken(sic!)".

Darüber hinaus stehe ich auf dem Standpunkt, ein Wort, das auf bloße Äußerlichkeiten abstellt um eine Person zu charakterisieren, das aus der Nutzung im Kolonialismus herrührt und von dem bekannt ist, dass es einige Angehörige besagter Personengruppen als unangenehm empfinden, hat in unserem aufgeklärten Sprachgebrauch nichts zu suchen. Schon gar nicht, wenn es adäquaten Ersatz gibt. Das Wettessen erzeugt die schönen Erinnerungen an den Kindergeburtstag nicht die Bezeichnung des Nahrungsmittels. Ich rede nicht davon es zu "tilgen". Im Gegenteil, wir müssen uns daran erinnern dürfen, daher stimme ich Yomomos Meinung und der Aktion von Stefan zu.

Dennoch sehe ich das Argument "Sensibilisieren der Sprache führt nicht zur Verbesserung von Gedanken!" Ich bin kein Freund von Mitgliederinnen, Vorständinnen, Quoten und übertriebenen Empfindlichkeiten (auch wenn ich selbst darunter leide, wie ja bekannt ist). Lasst uns das (alles) aber bitte als Anlass nehmen über die Umsetzungen der entsprechenden Richtlinien nachzudenken, denn die Wikimedia hat hier Hausrecht und wir haben uns an den CoC zu halten. Und ich rede nicht davon "Kochbuch/ Negerkuss" zu löschen, das ist auch nach aktueller Lage nicht der Plan!

Wer sich entsprechend damit beschäftigen möchte dem sei folgende ZDF-Produktion ans Herz gelegt (verfügbar bis 13.7.2021): https://www.zdf.de/comedy/die-anstalt/die-anstalt-vom-14-juli-2020-100.html (Das sollte mal in Schulen gezeigt und diskutiert werden, nicht immer nur "Die Welle"!)

Und dem geneigten Rollenspieler kann ich auch "Roll Inclusive: Diversity und Repräsentation im Rollenspiel" sehr ans Herz legen (was nicht heißt, dass ich den dortigen Inhalten zu 100% zustimme).

Und der Vollständigkeit zu Kartoffel und Weißbrot sei noch Alman hinzuzufügen. Ich fänd Alber auch nicht schlecht. Und bei Hamburgern bis Pekinesen, reden wir üblicherweise über aus oder vermutlichen Fantasiebezeichnungen. Aber aus welchem "Negerland" kommen denn die "Negerküsse"? Wir können nach entsprechenden Reparationen an die Herero (  Völkermord an den Herero und Nama) gerne als ehrendes Erinnerungsgebäck Hereroküsse einführen. Aber wie wirkt das dann? Nur weil sich keiner mehr dran erinnert heißt es nicht, dass es nicht doof sein kann.

Gruß --HirnSpuk 03:38, 24. Mai 2021 (CEST)Beantworten

Eigentlich kann man jetzt beide Seiten auch löschen: Der Fokus ist weit weg vom eigentlichen Rezept hin zur Erziehung gewandert. Stephan hatte es ursprünglich richtig gemacht: Link setzen und fertig, damit wird der Schaumkuss unter verschiedenen Namen gefunden. Die weiteren Anmerkungen im Rezept halte ich für übertrieben und wirken auf mich anders als gewünscht: Ich fühle mich genervt. Qwertz84 12:25, 24. Mai 2021 (CEST)Beantworten

Von der Textmenge her dominiert doch eindeutig das Rezept samt Zubereitung. Eine Einordnung der Bezeichnungen ist doch bei jedweder Rezeptur eine gute Idee zur Einleitung sowie zur allgemeinen Erbauung des Publikums. Ich finde auch gelegentliche Dokumentationen über die Herkunft von Gerichten, Kulturpflanzen ganz interessant, insofern sind derlei Anmerkungen doch durchaus passend, nehmen ja hier im Beispiel auch keineswegs den Hauptteil des Textes ein, dies wäre dann eher in einem wikipedia-Artikel angemessen. Auf solche wird ja für weitere Ausschweifungen fürderhin korrekt verwiesen, um das Kernthema Rezeptsammlung/Kochbuch nicht zu verlieren. Doktorchen 12:38, 24. Mai 2021 (CEST)Beantworten

Kein Problem mit mir. Ich habe keine Lust auf diese Art zu diskutieren. Dann möge sich jemand anders kümmern. Gruß --HirnSpuk 18:08, 24. Mai 2021 (CEST)Beantworten

Ich möchte an dieser Stelle für eine Umbenennung in Zucker-Eiweiß-Wasser-Kuvertüre-Waffel-Gelatine-Süßspeise plädieren, um diesem süßen Genuß gleich per Namen angemessen Respekt zu zollen; durch die Reihenfolge wird zudem die mutmaßliche Massenverteilung bei der Benennung gut berücksichtigt, was eine relevanter Information ist, um sofort einordnen zu können, ob dies nachbereitet werden sollte - gerade aufgrund des vorangestellten Zuckers unter gesundheitlichem Aspekt sehr relevant - es ist ja kein bißchen Kuß oder Mensch drin, insofern ist die historische Bezeichnung schon problematisch bis irreführend. Da gibt es doch ähnlich abschlägige Beurteilungen für veganen Käse-, Schnitzel- oder Milchersatz, welcher irreführend als Käse-, Schnitzel oder Milch bezeichnet wurde. Sollen mit dem Rezept ernsthaft Beschwerden riskiert werden, sobald irgendwelche kritischen Nachbäcker dahinterkommen, daß weder Kuß noch Mensch mit überdurchschnittlich dunklem Teint enthalten ist? Wenn jetzt immerhin angegeben würde, daß statt des Spritzbeutels wenigstens der Mund verwendet wird, könnte man immerhin noch den Kuß als halbwegs nachvollziehbar halten, aber so? ;o) Doktorchen 11:03, 25. Mai 2021 (CEST)Beantworten

Pro: Ich bin auch für die Umbenennung in "Veganer Brathering". Qwertz84 19:42, 26. Mai 2021 (CEST)Beantworten

Universeller Verhaltenskodex

Bearbeiten

Moin,

nochmal ein letzter Hinweis, ein paar Tage sinds noch, falls sich jemand damit auseinandersetzen möchte und evtl. sogar Kommentare zur Umsetzung zu geben gedenkt. :

Das wird uns auch betreffen. Hier wäre zum Beispiel neben dem oben gegebenen Bsp. Hilfe:Sei grausam zu diskutieren. Gruß --HirnSpuk 14:32, 1. Mai 2021 (CEST)Beantworten

Neues Vector-Design als Default. Interesse?

Bearbeiten

Tach, ich hatte es schonmal erwähnt, es gibt ja demnächst ein neues Vector-Design. Ich wurde gefragt, ob die wb-de-Community Interesse daran hätte den neuen Skin als Default-Skin gesetzt zu bekommen. Hiermit leite ich diese Anfrage weiter. Wenn sich in den nächsten vier Wochen eine Mehrheit (mindestens 3 Nutzer ohne Widerspruch) hier meldet, geb ich das entsprechend weiter. Wer ein anderes Abstimmprozedere wünscht, möge das kund tun und entsprechend managen. Mir wurscht. Ich werde am ~20.6. schauen, wie die Stimmungslage ist, das Ergebnis zusammenfassen und ~4 Tage hier zur Beurteilung stehen lassen, zur Fehlerbeurteilung. Danach geb ichs dann weiter.

Ich habe den Skin für mich persönlich angeschaltet (das geht in den Einstellungen). Ich find ihn schick und wir kriegen ihn wohl so oder so geliefert. Viele Grüße --HirnSpuk 18:19, 24. Mai 2021 (CEST)Beantworten

Das geht mir ähnlich. Bitte sehr gerne anschalten. Maximilian.Petras 16:33, 28. Jun. 2021 (CEST)Beantworten

Beta-Funktionen als default?

Bearbeiten

Hallo ihr Lieben,

ab wann wird eigentlich entschieden, wann eine Beta-Funktion als default eingesetzt wird? Für die Arbeit bei OpenRewi wäre sowohl das Tool zu "visuellen Unterschieden" sehr sinnvoll (wir überarbeiten unsere Texte sehr stark gegenseitig im Peer Review). Als auch das Werkzeug für erweiterte Kommentarfunktionen (aus denselben Gründen). Letzteres auch, weil wir zu externem Feedback anregen wollen und Nicht-Wikibookianer:innen auf der Seite prompt mit Quelltext konfrontiert sind. @Yomomo@HirnSpuk@Juetho

Daneben bin ich immer noch der Meinung, dass die automatische Aktivierung des visuellen Editors eine nette Sache wäre. Wenn es dadurch zu vermehrtem Vandalismus kommen sollte (wie in obigen Diskussionen angemerkt), können wir die Aktion immer noch rückgängig machen (oder andere Schritte ergreifen). Ansonsten finde ich die Barrieren gerade für Studierende, die nur mal schnell etwas anmerken möchten, relativ hoch, wenn sie mit einem Meer aus Wiki-Syntax konfrontriert werden und Angst haben, etwas kaputt zu machen. All die Oberflächen auf ihren Endgeräten sind ansonsten so bunt und selbsterklärend ;)

Herzliche Grüße! Maximilian.Petras 16:44, 28. Jun. 2021 (CEST)Beantworten

Naja, wer dies Werkzeug braucht, kann es doch in seinen Einstellungen aktivieren. Als Voreinstellung könnte dies ja selbst eine Barriere darstellen, wenn sich Erläuterungen darauf beziehen, dies könnte Leute verschrecken, wenn lediglich eine Funktion beschrieben wird, welche dann nicht passiert, etwa wenn Skriptinterpretation, wie in meinem Falle, erst einmal per Voreinstellung am Brauser deaktiviert ist. Bei einem Test jedenfalls konnte ich keinerlei Unterschied feststellen, was eben bei Beschreibungen von Bearbeitungshinweisen berücksichtigt werden muß. Ansonsten wird vermutlich über den Stand der Testungen dort entschieden, wohin auch Dokumentation und Diskussion verweisen, also wohl nicht in speziellen wiki-Projekten. Die Historie von visuellen Editoren hat bislang jedenfalls gezeigt, daß diese technische/semantische Probleme verursachen können, weil sie natürlich den Textinhalt nicht verstehen, insofern ist ein gewisses technisches Verständnis der jeweils verwendeten Textauszeichnung für Autoren sowieso immer förderlich, ähnlich wie eine grobe Kenntnis der Rechtschreibregeln bei Autoren wohltuend für das spätere Publikum ist. Insofern haben derartige Editoren durchaus das Potential, Dinge einfacher zu machen, als sie sind, was allerdings auch bereits auf die wiki-Syntax selbst zutrifft, letztlich wird ja hinten heraus (X)HTML produziert. Doktorchen 19:11, 28. Jun. 2021 (CEST)Beantworten

Mathjax für's Rendern der Formeln und Notationen

Bearbeiten

Habt Ihr mal darüber nachgedacht, zumindest langfristig, die Bilder, die mit den Formeln und Notationen in den Text eingefügt sind, durch Mathjax Elemente zu ersetzen? Mathjax erlaubt es inline Latex Formeln zu notieren (ähnlich, wie ihr das jetzt bereits macht), nur dass das Resultat direkt in HTML gerendert wird, auf der Seite ist es Text, lässt sich also markieren und kopieren und skaliert mit der Schriftgröße, ist also besser für Besucher mit Sichtschwierigkeiten.

-- F7f7u7f7 13:00, 23. Nov. 2021 (CET)Beantworten

Danke für die Idee. So wie ich es sehe haben wir keine Möglichkeit das hier aus der Community zu machen, da das vom Seitenbetreiber installiert werden müsste. Ping@Benutzer:Stephan Kulla, wie siehst Du das? Viele Grüße, HirnSpukDisk14:16, 28. Nov. 2021 (CET)Beantworten
@F7f7u7f7: Dies ist eine Frage an die Entwickler:innen hinter MediaWiki. Wende dich am Besten mal an User:Physikerwelt, der sich viel mit dem Formel-Rendering beschäftigt hat. Ansonsten kannst du auch eine Angfrage unter Extension talk:Math stellen. -- Stephan Kulla 09:35, 8. Mär. 2022 (CET)Beantworten

Erweiterte Parser-Funktionen

Bearbeiten

Ich würde gerne String-Manipulationen nutzen können. Die entsprechende Erweiterung ist installiert, benötigt aber noch ein administratives Einschalten, vgl. mw:Help:Extension:ParserFunctions/de#StringFunctions: ...are only available if an administrator sets $wgPFEnableStringFunctions = true; in LocalSettings.php. Falls jemand Zeit und Muße findet, würde ich mich sehr freuen. Viele Grüße, HirnSpukDisk19:46, 27. Jan. 2022 (CET)Beantworten

Verstehe ich es richtig, dass der erste Hinweis aus mw:Extension:StringFunctions/de überholt ist, weil die betreffenden Funktionen „jetzt“ (seit längerer Zeit) Teil von Extension:ParserFunctions sind? Dann plädiere ich eindeutig für die Nutzung der String-Funktionen! Ich weise darauf hin, dass der erste Hinweis auf Beschränkungen in Vorlagen erstellen zu ändern ist. Ich erinnere mich nicht daran, ob an anderer Stelle in der Hilfe auf solche Funktionen eingegangen wird.

Bitte beachte, dass als Systemadministrator, der die LocalSettings.php ändern darf, keiner unserer Admins oder Bürokraten fungiert. Wenn ich mich richtig erinnere, müssen wir dazu jemanden auf WMF bitten. Am ehesten ist ein Kontakt in einem Archiv zu finden; aber bei einem schnellen Durchgang der Archive von Ich brauche Hilfe ist mir kein passendes Thema aufgefallen. Vielleicht erinnert sich Klaus Eifert an eine richtige Kontaktadresse.

Hier hatte ich übrigens schon mal über String-Funktionen gesprochen: Spezial:Diff/595382#mw:Extension:StringFunctions

-- Jürgen 16:09, 28. Jan. 2022 (CET)Beantworten

So verstehe ich das. Falls jemand auf das Gleiche reinfällt, wie ich: LocalSettings.php nutzt nichts, vgl. mw:Manual:LocalSettings.php. Meine Nachfrage nach einem Admin hier bringt wohl also nichts. Manchmal nervt mich diese Dualität von "MediaWiki"-"WikiMedia" [[Datei:|x20px|alt=facepalm]]. Wenn Klaus nichts weiß, vielleicht weiß ja auch Benutzer:Stephan Kulla als Oberflächenadmin was? Ich weiß noch nicht, ob mein Plan funktioniert (Vorlagengesteuerte Unterschriftengestaltung für die Rundschau bei Nutzung der Tilden.), aber ich würds gern mal probieren. Weiß jemand was Packer in Jürgens Link mit "teuer" meinte? Serverrechenzeit? Wäre das noch ein Ding heutzutage? Wenn ich es richtig sehe, wäre die Suche wohl möglicherweise vergeblich. Wenn ich Phab:T8455 richtig verstehe, würde es mit Hinweis auf LUA eh nicht aktiviert werden. Ich glaube Yomomo hatte da mal was importiert. Ich bin ja kein großer Lua-Freund. Ich werde beizeiten mal weiter recherchieren. Viele Grüße, HirnSpukDisk19:05, 28. Jan. 2022 (CET)Beantworten

Ich erinnere mich nicht, einen geeigneten Kontakt zu kennen. Auch nicht, wer damals den Kontakt hergestellt hatte. Viele Grüße, Klaus 11:38, 29. Jan. 2022 (CET)Beantworten

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: So, wie ich es sehe, ist es nicht möglich das zentral anzuschalten. Die einzige Option scheint aktuell Modul:Str zu sein. Beispiele auf Modul Diskussion:Str, Viele Grüße, HirnSpukDisk17:25, 21. Feb. 2022 (CET)Beantworten

Ja, richtig: Hier sind die Server-Admins gemeint. LocalSettings.php ist nämlich eine lokale Datei auf den Server, die man da ändern muss. Hier bräuchte man einen Request direkt bei der Wikimedia, wobei ich vermute, dass sich der Hinweis eher an die richtet, die die MediaWiki selbst für ihre lokales Wiki nutzen. -- Stephan Kulla 09:27, 8. Mär. 2022 (CET)Beantworten

»Theoriefindung« als Löschgrund

Bearbeiten

Moin allerseits,

dieser Verbesserungsvorschlag hat das Ziel, »Theoriefindung« als Löschgrund zu den Hilfe:Löschregeln#Löschungsgründen explizit hinzuzufügen. Bücher, Kapitel und Abschnitte sollen mit diesem Löschgrund gelöscht werden dürfen.

Theoriefindung liegt immer dann vor, wenn ein Gegenstand nicht unabhängig belegt werden kann. Auf keinen Fall soll dieser Löschgrund dazu benutzt werden, alles belegen zu müssen, eher soll das als Aufforderung verstanden werden, Behauptungen im Zweifelsfall belegen zu können. Qwertz84 21:44, 16. Mär. 2022 (CET)Beantworten

Siehe auch

Diskussion

  • Kurzfassung:   Neutral mit Tendenz zu   Contra. Auf kurze Sicht finde ich den folgende Abschnitt in den Löschregeln hinreichend: "...Löschkandidaten [...] sind insbesondere [...] Bücher, die hauptsächlich die Meinung des Autors widerspiegeln (siehe Neutraler Standpunkt)". Auf lange Sicht habe ich kein Problem mit einer Diskussion und/oder Änderung. Ich würde den Löschgrund nicht im "Schnellverfahren" hinzufügen. Insbesondere auch, da sich eine "Regel" auf Hilfe:Gesichertes_Wissen befindet, die nicht sonderlich klar formuliert ist, seit 2016 existiert und eine Doublette von Hilfe:Was_Wikibooks_ist/_Kommentare#Gesichertes_Wissen ist. Viele Grüße, HirnSpukDisk12:31, 17. Mär. 2022 (CET)Beantworten
    Langfassung: An sich finde ich den Vorschlag nicht schlecht, insbesondere, da ich die Formulierung auch des Öfteren (zu oft unbedacht) einsetze. Ich habe aber Gründe gegen die explizite Festschreibung:
    1. Wikipedia sollte kein Maßstab sein: An der Wikipedia orientieren können wir uns hier – finde ich – nur begrenzt, da Diskussionen in meinen Augen immer Bestandteil von Lehrbüchern sein können sollten. Bis hin zu Belletristik als Stilmittel.
    2. Theoriefindung in gewissen Grenzen ist akzeptabel: Theoriefindung als solche darf in meinen Augen gerne Platz auf Wikibooks bekommen, solange die neutrale Darstellung gewährt ist und nicht "unverrückbare Tatsachen behauptet" oder "krude Thesen in den Raum gestellt" werden. Schreibt man Theoriefindung als Löschgrund explizit fest, entstehen diverse Abgrenzungsprobleme, die die Diskussion und flexible Lösung von "Problemfällen" erschweren. (Vgl. auch Punkt vier dieser Liste)
    3. Werkzeuge zur Lehre werden eingeschränkt: Eine Diskussion und die Motivation zu eigenem Denken innerhalb von Lehrbüchern wird mit einem "Verbot" von "Theoriefindung" vermutlich schwieriger.
    4. Grenzfall-Diskussionen werden härter: Es gibt Grenzfälle, die nahezu nicht entscheidbar werden: "Das ist doch Theoriefindung!" – "Ich habs ausprobiert, das geht!" – "Ohne Nachweis glaub ich Dir das nicht, das wird gelöscht!"... Wer würde sowas entscheiden wollen? Finde ich schwierig.
    5. Risiko der vorschnellen "Beweislastumkehr": Lehrtexte, die von Fachautoren mit entsprechender Sachkenntnis geschrieben worden sind, können von Laien grundlos einfach anhand von "Theoriefindung" angezweifelt werden, was die entsprechenden Fachautoren in Zugzwang brächte Quellen nachzuliefern. Das ist diesen natürlich zuzutrauen aber in meinen Augen nicht unbedingt uneingeschränkt zuzumuten.
    Als Konkurrenz-/Kompromissvorschlag bis zu einer eleganteren Lösung könnte ich mir eine Warnungsvorlage analog der Vorlage:Neutralität gut vorstellen oder man könnte diese anpassen und häufiger einsetzen.
    Viele Grüße, HirnSpukDisk12:31, 17. Mär. 2022 (CET)Beantworten

Da wir hier sicher die Einzigen Diskutanten sein werden, können wir an der Stelle auch schließen. Bezüglich guter und schlechter Theoriefindung sehe ich es eher umgekehrt Qwertz84 19:48, 18. Mär. 2022 (CET)Beantworten

Nur damit ich das richtig verstehe: Du meinst die Etablierung des Begriffs "Zufallsinformation" ist in Ordnung, aber eine saubere Darstellung eines archäoastronomischen Zusammenhangs nicht? Warum schließen? Die Erfahrung zeigt, dass gelegentlich auch später immer noch mal Input kommt. Und beim grundsätzlichen Ansinnen sind wir uns ja einig, nur nicht in der Ausgestaltung. Viele Grüße, HirnSpukDisk20:04, 18. Mär. 2022 (CET)Beantworten
Dem Absatz "Zufallsinformation" fehlte nur eine stilistische Überarbeitung. Die Begrifflichkeiten waren unklar, aber der Sinn ist keine Theoriefindung. Information:_Zufall#Was_ist_eine_Zufallsfolge_?. Fühlt euch frei, meine Überarbeitung selbst noch einmal zu verbessern. An anderen Stellen habe ich mehr Bedenken gehabt. Meiner Ansicht nach reicht es, den Autor gelegentlich darauf aufmerksam zu machen, wo er übers Ziel hinausschießt. --mjchael 10:50, 5. Apr. 2022 (CEST)Beantworten
Deine Verbesserungen machen es tatsächlich etwas angenehmer (wenn auch die "Zufallssequenz" ebenfalls schwierig belegbar ist, vgl. w:Portal:Mathematik/Qualitätssicherung/Archiv/2014/Juni#Zufallssequenz). Allerdings hat "der Autor" diese "Zufallsinformation" über das gesamt-Wikibooks verteilt, vgl. Spezial:Suche/Zufallsinformation. Ich habe schon öfter Zeit damit zugebracht "den Autor aufmerksam zu machen". Eine Änderung/Verbesserung wäre hier so grundlegend notwendig, dass sie für mich persönlich nicht in Frage kommt. Diese Theorie muss in meinen Augen komplett verschwinden, da sie hier keinen Platz bekommen kann. Und sie schlägt – im Gegenteil – unbeobachtet in die wissenschaftliche Gemeinschaft zurück, vgl. Spezial:Permanentlink/118927#Zufall_und_Entropie von 2006 sowie https://publishup.uni-potsdam.de/opus4-ubp/frontdoor/deliver/index/docId/1427/file/gutschow_diss.pdf, S. 186 (Anhang, vii) von 2007): "Die Entropie ist ein Maß für die Menge an Zufallsinformation, die in einem System oder einer Informationsfolge steckt...". Ob da jetzt irgendwer von irgendwem abgeschrieben hat, möchte ich nicht beurteilen, aber der zeitliche Zusammenhang und die sonstige "Unauffindbarkeit" des Begriffs "Zufallsinformation" ist in meinen Augen deutlich. Wollen wir sowas weiter Vorschub leisten? Wer sich weiter mit dem Thema Information beschäftigen möchte, ein Beispiel, wie man es machen könnte ist unter Umständen: https://epub.uni-regensburg.de/10483/1/ZeichenInfoKomm.pdf. Hier werden die entsprechenden Stichpunkte (Entropie, Zufall, Chaitin, Stonier...) übrigens sehr schön in Kontext gesetzt. Viele Grüße, HirnSpukDisk15:10, 8. Apr. 2022 (CEST)Beantworten
Die Erfahrung von wikipedia zeigt, daß der Begriff gerne als Totschlagargument verwendet wird, wenn jemand Inhalte gerne streichen möchte - oder auch keine Lust hat, oftmals leicht selbst prüfbare Informationen selbst zu verifizieren. Bei Lehrbüchern ist diese Verwendung jedenfalls noch alberner als bei wikipedia-Artikeln, bei denen man noch darüber streiten kann, ob man ausführliche Informationen zu einem Thema nicht besser in ein wikibook auslagern sollte. Wenn dies das Ergebnis einer dortigen Diskussion ist, wäre es gewiß schlecht, hier ein Lehrbuch mit brauchbarem Inhalt gleich wieder zu löschen.
Im Sinne von Verschwörungsglaubenstheoremen gibt es allerdings auch wirklich abenteuerlich Konstrukte, welche dem Kriterium eines Fachbuchs/Sachbuchs/Lehrbuchs nicht standhalten, weil sie allein ins Phantastische abgleiten.
Was man nun als triviale Fakten ansieht, welche leicht selbst prüfbar oder Allgemeinbildung sind, hängt wohl auch etwas vom Bildungsstand ab, von daher bleibt die Lage knifflig. Die Behauptung oder Unterstellung kann schon etwas über den Bildungsstand des Unterstellers offenbaren. Auf der anderen Seite ist ja wirklich viel Blödsinn im Umlauf. Insgesamt bleibt eine Löschung ohne Diskussion sowieso heikel. Nun gibt es ja ohnehin das Kriterium, daß es sich nicht um ein Lehrbuch handelt, was doch vermutlich für die Argumentation ausreicht? Doktorchen 17:38, 8. Apr. 2022 (CEST)Beantworten

Umstellung der Verbesserungsvorschläge auf Kategorien

Bearbeiten

Da meinen Eintrag bei den Kategorien unter Umständen nicht alle gesehen haben: Ich würde für die Verbesserungsvorschläge gerne Kategorien und Einzelseiten analog den Meinungsbildern ausprobieren. Die erhofften Vorteile:

  • Es gibt Verbesserungsvorschläge die gut waren aber "aus Mangel an Arbeitskraft" nicht umgesetzt sondern archiviert wurden, es gibt Verbesserungsvorschläge, siehe z. B. ganz oben, die über Jahre über die Seite "geschleppt" werden, ohne, dass sie geschlossen oder voll bearbeitet werden.
  • Die Kategorieliste der Verbesserungsvorschläge wird auf anderen Seiten mit den Überschriften einbindbar. (Mir schwebt da die Rundschau vor)
  • An dem Verbesserungsvorschlag könnte "direkt auf der Seite" gearbeitet und dokumentiert werden, ohne eine zentrale Seite mit Diskussionen und Vorschlägen zu "fluten".
  • Wichtigster Vorteil in meinen Augen: Das Archiv muss nicht mehr händisch gepflegt werden, sondern "entsteht automatisch" sobald ein Verbesserungsvorschlag mit einer Kategorie z. B. [[:Kategorie:WB:Verbesserung:geschlossen|20190213]] abgeschlossen werden würde.

Die Liste ist wohl nicht vollständig. Ich mache mir geringfügig Sorgen,

  • dass sich die Verwaltungsarbeit erhöhen könnte, deren Verringerung ich eigentlich im Auge habe (ohne konkrete Ideen zu haben, wo es klemmen könnte)
  • und dass natürlich der "Klickaufwand" für diejenigen steigt, die sich umfassender beteiligen wollen.

Ich denke aber, der Vorschlag ist vielversprechend genug, um ihn auszuprobieren. Falls jemand gute begründete Einwände in den nächsten vier Wochen hat oder die Liste der Vorteile erweitern kann, freue ich mich sehr über fruchtbare Gespräche. Danke und Viele Grüße, HirnSpukDisk15:03, 10. Apr. 2022 (CEST)Beantworten

Werden Neulinge schnell und intuitiv mit Kategorien als Verbesserungsvorschlägen klarkommen? --mjchael 08:17, 15. Apr. 2022 (CEST)Beantworten
Mein Plan wäre, dass davon ja maximal dejenige etwas merkt, de einen Verbesserungsvorschlag per "Kategorieänderung" schließt. Ich denke man könnte da auch mit einer Vorlage arbeiten. Ansonsten ist es ja quasi "nur" eine "Aufteilung" von Abschnitten (aktuell) auf Einzelseiten (geplant), deren "Inhaltsverzeichnis" und "Archiv" sich damit automatisch pflegt und auf denen am Problem gearbeitet werden kann, ohne eine größere Seite zur "Unübersichtlichkeit" zu verdammen. Hast Du konkrete Bedenken, wie ein Zugang erschwert werden könnte? Viele Grüße, HirnSpukDisk02:38, 16. Apr. 2022 (CEST)Beantworten
Ich kann mir noch nicht richtig vorstellen, wie du die Änderungswünsche mit Kategorien umsetzen willst. Mir schwahnt da eine Art Ticketsystem vor. Vielleicht denke ich da aber auch zu kompliziert. Ich bemerkte nur, dass ein paar Benutzer sich schwer tun, für ihre Todo-Listen die Todo-Vorlage richtig zu verwenden, obwohl die sich nahezu von allein verwaltet. Ich bemerke gerade, dass das Buch Mathe für Nicht-Freaks sich die Bedienungsanleitung nicht richtig durchgelesen hat. Also befürchte ich ähnliches bei den Verbesserungsvorschlägen. Immer an die DAUs denken.
( p.s. Frohe Ostern! 🐰 ) --mjchael 11:54, 16. Apr. 2022 (CEST)Beantworten
Könnte es sein, dass der Verweis der Erklärungsseite von der Vorlage:Todo als nicht mandatorisch genug wahrgenommen wird? Dass dort Kategorien automatisch erzeugt werden sieht man da nicht. Wenn also jemand unbedarft, vielleicht sogar im VE, die Vorlage einsetzt könnte so ein Problem entstehen. Viele Grüße, HirnSpukDisk13:02, 16. Apr. 2022 (CEST)Beantworten

Weitere Erläuterungen zum Vorschlag

Bearbeiten

Bezugnehmend auf Mjchaels Kommentar oben: Die Assoziation Ticketsystem ist gar nicht so falsch. Stells Dir einfach vor wie die Meinungsbilder. Nur, dass alles über Vorlagen und Vorgaben automatisiert ist. Es werden aber anders als im ToDo-System keine Kategorien automatisiert. Natürlich könnte jemand das "System" "falsch" nutzen. Aber auch im aktuellen System können die Leute ja Fehler machen, die händisch korrigiert werden müssen. Beim Schnelllöschen funktioniert die Kategorisierung ja einwandfrei.

Mein Wunsch basiert auch darauf die Rundschau als "Landeplatz" zu etablieren. Und dafür bedarf es der Möglichkeit dort – ich nenns jetzt statt Ticket mal wahllos – Blob-Listen zu erstellen (1. ich mag "Ticketsysteme" nicht und 2. suggeriert die Bezeichnung Ticket, dass sich "schon jemand kümmert". Das wäre hier ja nicht der Fall). Also Listen mit Seiten, auf denen man tätig werden kann.

Zukünftig könnte man ein ähnliches System für andere "Blobs" integrieren. Dafür ist es aber von Vorteil erstmal Erfahrungen in einem begrenzten Bereich zu sammeln. Die Meinnugsbilder sind zu wichtig (und zu selten), um damit zu spielen, das Löschsystem zu komplex, "Ich brauche Hilfe" braucht niedrigschwelligen Zugang, dafür eignet sich das System nicht, das schwarze Brett bietet sich ebenfalls nicht an, daher halte ich die Verbesserungsvorschläge prädestiniert für einen Versuch. Im folgenden ein Beispiel (anhand von ausgewählten Löschkandidaten), wie sowas dann in der Rundschau aussehen könnte.

Viele Grüße, HirnSpukDisk13:02, 16. Apr. 2022 (CEST)Beantworten

Ich will mich eigentlich nicht einmischen, aber wäre es nicht einfacher, erstmal alles zu Archivieren wo seit einem Jahr keiner mehr etwas geschrieben hat (dazu gehört auch diese Diskussionsseite) und dann von oben nach unten abzuarbeiten? --NilsLindenberg 08:04, 28. Apr. 2022 (CEST)Beantworten
@NilsLindenberg, Meinungen sind dazu da, um sie zu äußern  , also wegen mir bitte gerne einmischen. Was meinst Du mit "diese[r] Diskussionsseite"? Archivieren möchte ich hier nicht vorschnell. Die Seiten Ich brauche Hilfe und das Schwarze Brett hab ich Anfang des Jahres mal gemacht, hier sehe ich aber die Möglichkeit Zusammenarbeit zu fördern, das möchte ich nicht ungenutzt lassen. Und wenn ich die Umstellung vornehme, würde ich die aktuell abgehakten Themen direkt im neuen System archivieren wollen, so bekommt man direkt eine sinnvolle Übersicht, wie das werden soll. Viele Grüße, HirnSpukDisk12:34, 28. Apr. 2022 (CEST)Beantworten
Wikibooks_Diskussion:Verbesserungsvorschläge. Meiner Meinung nach fördert es die Zusammenarbeit nicht, wenn ich mich durch eine Menge an Themen wühlen muss, Themen, die entweder steinalt oder schon erledigt sind. Ich würde eher den gegenteiligen Weg gehen: eine Diskussionsseite auf der alle Themen diskutiert (und auch abgearbeitet) werden. Anderseits muss ich es ja auch ncith umsetzen ;) NilsLindenberg 18:00, 28. Apr. 2022 (CEST)Beantworten
Aber die Diskussionsseite wird doch gar nicht aktiv benutzt? Ich nehme an, Du meinst diese Seite, also Wikibooks:Verbesserungsvorschläge? Oder meinst Du schlicht diese Seite und die Diskussionsseite? Der Hinweis auf die Diskussionsseite ist aber nicht schlecht. Die sollte ich mir in dem Zusammenhang dann auch mit vornehmen. Dort wird ja aktuell quasi nicht diese Seite diskutiert, sondern es ist gleichsam eine "zweite" Seite mit Verbesserungsvorschlägen. Viele Grüße, HirnSpukDisk00:01, 29. Apr. 2022 (CEST)Beantworten
Letzteres aus genau dem Grund. NilsLindenberg 10:01, 29. Apr. 2022 (CEST)Beantworten

Kurz mal eine Wasserstandsmeldung: Es haben sich unvorhergesehene Probleme ergeben, vgl. mw:Topic:X7ug48cyvc96go88

Ein bisschen Spielerei (aus der Vergangenheit und für die Zukunft):


Viele Grüße, HirnSpukDisk19:45, 29. Nov. 2022 (CET)Beantworten

Namenskonventionen und Hilfetexte bezüglich der Trennzeichen.

Bearbeiten

Moin, es geht um Hilfe:Namenskonventionen, sowie um 76 Verschiebungen vom 16.10. Spezial:Logbuch/move (ggf. den 16.10.22 als Datum auswählen) von 1234qwer1234qwer4. Mir ist ähnliches in den letzten Jahren immer mal wieder augefallen.

Bin ich der Einzige, den es stört, dass hier jede Menge Arbeit aber kein Nutzen generiert wird? Gibt es wirklich handfeste und konkrete Beispiele wo das wirklich ein ernst zu nehmendes Problem war? Als ich Beispielhaft eine entsprechend verschobene alte Buchseite von OpenRewi überprüft habe, habe ich festgestellt, dass hier scheinbar korrekter Umbruch erfolgt. Das könnte aber auch dem Sonderzeichen geschuldet sein, hier scheint es ein Problem zu geben (was aber nicht mobil aufzutreten scheint und hier nun auch eher egal ist).

  • Vor einigen Jahren hat mal ein Nutzer versucht diese Seite anzulegen (bitte nicht abspeichern, man kann den Umbruch auch beurteilen, wenn man im Bearbeiten-Modus ist!).
  • Ich konnte keine wirklich konkrete "Regel-Einigung" finden.
  • Außerdem gibt es inzwischen {{DISPLAYTITLE:title}}.
  • Die Seite Hilfe:Namenskonventionen sagt sogar "Nochmals: Es handelt sich hier nur um Empfehlungen. Bei der Erstellung von guten, qualitativ hochwertigen Lehrinhalten sollten diese daher nicht im Wege sein. Kommt man mit den gut gemeinten Empfehlungen nicht zurecht, sollte man eigene Wege gehen dürfen und darf dies hinsichtlich der Namenskonvention im Rahmen der sonstigen Wikibooks-Regeln auch."

Aber ich mein, im Endeffekt ist das Leerzeichen doch egal und sollte "*Autorentscheidung[1]" sein? Mir ist schon klar, warum es eingeführt wurde, aber ist der hiermit entstehende Verwaltungsaufwand nicht höher als der Nutzen? Das Inhaltsverzeichnis muss nun angepasst werden, weitere Links müssen überprüft werden und schließlich werden 76 alte Seiten gelöscht (die in der Datenbank aber trotzdem erhalten bleiben).

Diese Verfahren ist in der Vergangenheit natürlich immer strikt umgesetzt worden, aber nach obigen Angaben schließend: könnte man es nicht einfach sein lassen? Auf fruchtbare Gespräche, Viele Grüße, HirnSpukDisk22:50, 16. Okt. 2022 (CEST)Beantworten

  1. Das vorangestellte Asterisk ist hier Inklusionszeichen

Viele Grüße, HirnSpukDisk22:50, 16. Okt. 2022 (CEST)Beantworten

Moin, meine Meinung dazu: (1) Ja, das kann man sein lassen. (2) Ich bin fürs ersatzlose Löschen der Seite Hilfe:Namenskonventionen. (3) Dass die Wiki-Software Mängel hat - gelöschte Seiten werden nicht wirklich aus der DB gelöscht - soll niemanden vom Löschen abhalten. Qwertz84 09:37, 25. Okt. 2022 (CEST)Beantworten

Zukunft der Erfassung von PDF-Versionen und PDF-Katalog

Bearbeiten

Moin, durch Zufall stieß ich gerade auf einige gefühlte Widersprüche. Kurze Problembeschreibung, damit ich es nicht vergesse:

Wir haben:

  1. Vorlage:PDF-Hinweis mit Spezial:Linkliste/Vorlage:PDF-Hinweis – verlinkt auf den PDF-Katalog und setzt die Kategorie
    hat ~23 Einträge, dabei Fehler z. B. Gitarre: Grundhaltung der Gitarre, der Katalog hat 33 Einträge
  2. Vorlage:Hinweis_PDF mit Spezial:Linkliste/Vorlage:Hinweis_PDF – verlinkt das PDF selbst und setzt die Kategorie
    hat keinen "Kontakt" zum PDF-Katalog
  3. Kategorie:Buch mit PDF-Version – wird von obigen Vorlagen oder manuell versorgt
    hat 115 Einträge, Kategorie:fertiges Buch hat 85. Heißt das wir pflegen die fertigen Bücher zu wenig, oder wir erstellen unfertige PDFs?
    Es gibt hier mehr Einträge als in den Links über die Vorlage, folglich benutzen nicht alle Bücher die Vorlage
  4. Wikibooks:PDF-Katalog – muss manuell eingetragen werden
    hat zwei Darstellungsfehler
    soll vermutlich mehrere Versionen erfassen, das geschieht aber über die Datei-Seite ohnehin (vgl. z. B. Datei:Mathematik_Stochastik.pdf
  5. Hilfe:Fertigstellen/ PDF-Versionen – beschreibt wie PDFs erzeugt werden können
    mischt "Druckversion" und "PDF-Version"
  6. Hilfe:Fertigstellen/ Das fertige Buch – beschreibt, dass ein Eintrag in den PDF-Katalog erfolgen soll

Bitte gerne ergänzen, keine Ahnung, ob ich alles gefunden habe. Irgendwann muss man da mal was dran tun. Mein erster Reflex war ein Löschantrag auf den PDF-Katalog, andererseits ist eine Übersichtsliste mit PDFs keine schlechte Sache. Vielleicht den PDF-Katalog durch die Einbindung der Kategorie leichter pflegbar machen? Also, 1 und 2 vereinen, 3 in 4 einbinden und dabei 4 großzügig stutzen sowie 5 und 6 jeweils entsprechend überarbeiten? Keine Ahnung. Ich hab im Moment dafür keine Kapazitäten, aber ich wollte das Problem und meine Recherchen erfassen. Viele Grüße, HirnSpukDisk23:11, 24. Okt. 2022 (CEST)Beantworten

GFDL als empfohlene Lizenz entfernen

Bearbeiten
 
Warum GFDL keine gute Lizenz ist.

Hallo!

GFDL ist laut der Abbildung rechts keine gute Lizenz für Mediendateien.

MediaWiki:Licenses generiert das Dropdown-Menü, das Benutzer sehen, wenn sie Dateien hochladen. Die GFDL wird tatsächlich als eine der empfohlenen Lizenzen angesehen und sogar als „das Beste“ hervorgehoben.

Ich schlage vor, GFDL aus MediaWiki:Licenses zu entfernen, damit es den Benutzern beim Hochladen von Dateien nicht vorgeschlagen wird.

Die neueste Version von Creative Commons ist die Version 4.0, daher schlage ich vor, diese zur Liste hinzuzufügen. Vielleicht zuerst zur Liste hinzuzufügen. MGA73 19:56, 29. Jul. 2024 (CEST)Beantworten

Da MGA73 kein Muttersprachler ist, und wir länger darüber auf meiner Diskussionsseite gesprochen hatten, kurz zur Erläuterung: Der letzte Satz meint CC-4.0 an erste Stelle zu setzen, wie ich es verstehe, nicht etwas nacheinander zu tun.
Ich unterstütze den Vorschlag. Wir müssen ohnehin nach und nach Anpassungen hier vornehmen, wegen der Lizenzänderungen und der Effekt auf Wikibooks ist quasi nicht vorhanden. Eine Doppellizensierung für Bilder ist in meinen Augen nicht nötig und die GFDL ist für Bilder schlecht geeignet. Auch wenn wir bei wb wenig Probleme mit der Doppellizensierung haben, haben wir ohnehin hier keinen regelmäßigen Zufluss an Mediendateien und dann ist CC-4.0 völlig ausreichend (die letzten 150 Uploads verteilen sich auf ~4 Jahre, vgl. Spezial:Dateien).

Vorschlag für die Änderung der Seite:
  • BLU|Ich weiß die Lizenz nicht (Bilder ohne Lizenz werden nach 14 Tagen gelöscht)
  • [empfohlene Lizenzen (ggf. mit Genehmigung durch die Autorenschaft)]
    • Bild-CC-by-sa/4.0|Creative Commons Attribution-ShareAlike License Version 4.0
    • Bild-PD-self|Public Domain / gemeinfrei / freie Verwendung
  • [weitere Freie Lizenzen (ggf. mit Genehmigung durch die Autorenschaft]
    • [GNU-Lizenzen:]
      • Bild-GFDL|GNU Free Documentation License Version 1.2 oder einer späteren Version
      • Bild-GPL|GNU General Public License Version 2 oder jede spätere Version - (nur für Screenshoots von GPL Programmen)
    • [Creative-Commons-Lizenzen:]
      • Bild-CC-by-sa/2.0|Creative Commons Attribution-ShareAlike License Version 2.0
      • Bild-CC-by-sa/2.0/de|Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 2.0 Deutschland
      • Bild-CC-by-sa/2.5|Creative Commons Attribution-ShareAlike License Version 2.5
      • Bild-CC-by-sa/3.0|Creative Commons Attribution-ShareAlike License Version 3.0
  • [Public Domain / gemeinfrei / freie Verwendung: (ggf. mit Genehmigung durch die Autorenschaft)]
    • Bild-PD|Urheberrechtlich geschützt, aber die Datei ist für jede (inklusive kommerzieller) Verwendung freigegeben
    • Bild-PD-US|Ein Werk einer US-amerikanischen Regierungsbehörde - public domain
    • Bild-PD-USGov-HHS-CDC|Ein Werk der Centers for Disease Control and Prevention - public domain
Viele Grüße, HirnSpukDisk17:48, 30. Jul. 2024 (CEST)Beantworten
Ja, besser so. --MGA73 16:44, 5. Aug. 2024 (CEST)Beantworten
Ping@Yomomo, @Mjchael, wie siehts aus? Einwände? Könnt Ihr das sonst ggf. mal irgendwann umsetzen? Viele Grüße, HirnSpukDisk17:15, 31. Aug. 2024 (CEST)Beantworten
Wenn in den nächsten 7 Tagen kein weiteres Kommentar vorkommt, werde ich die hier vorgeschlagene Änderung in der MediaWiki Seite übernehmen. LG! Yomomo 21:34, 2. Sep. 2024 (CEST)Beantworten

Neulizenzierung von GFDL auf CC-BY-SA

Bearbeiten

Im Jahr 2009 gab es eine Abstimmung über ein Update von GFDL auf CC-BY-SA. Sie können darüber unter m:Licensing update/Result/de lesen.

Das Update wurde auf den meisten Wikis abgeschlossen und kann auf zwei Arten dokumentiert werden:

  1. Eine Methode, bei der die einzelnen Dateiseiten bearbeitet und ein wenig Code hinzugefügt wird, wie unter c:Commons:GFDL 1.3 Kriterien zur Neulizenzierung erwähnt. Dazu müssen etwa 4000 Seiten bearbeitet werden.
  2. Die Lizenzvorlage wird wie bei der deutschen Wikipedia bearbeitet, wo CC-by-sa 3.0 direkt zu w:Template:Bild-GFDL hinzugefügt und dann ein w:Template:Bild-GFDL-Neu ohne die CC-by-sa 3.0-Vorlage erstellt wurde, um es für alle neuen Dateien zu verwenden. Dazu müssen weniger als 200 Seiten bearbeitet werden.

Ich möchte hier das Update mit Methode 2 durchführen. Der Vorteil dabei ist, dass viel weniger Änderungen erforderlich sind und es manuell durchgeführt werden kann. Wenn MediaWiki:Licenses auf „-Neu“ geändert wird, sind künftige Änderungen nicht mehr erforderlich. Auf diese Weise kann ich es alleine fertigstellen und keine anderen Benutzer müssen Zeit für das Projekt aufwenden (außer für die Bearbeitung geschützter Seiten).

Die eigentliche Neulizenzierung erfolgte im Jahr 2009. Die Änderungen, die ich vorschlage, verändern die eigentliche Lizenz nicht, sondern dokumentieren lediglich, was im Jahr 2009 stattfand.

Es gibt mehrere Vorlagen mit der Lizenz GFDL. Daher muss CC-by-sa 3.0 zu allen diesen Vorlagen hinzugefügt werden (falls relevant) und wir benötigen möglicherweise mehr als eine Vorlage mit dem Namen „-Neu“, es sei denn, es ist in Ordnung, für alle neuen Dateien dieselbe Vorlage zu verwenden.

Es gab bereits Diskussionen unter Wikibooks:Schwarzes_Brett#GFDL_and_other_stuff und Wikibooks:Ich_brauche_Hilfe#Lizenz-Migration. Im Moment habe ich das Zusammenführen von Vorlagen usw. aufgegeben, mit Ausnahme von Dateien mit der Vorlage „-Neu“, von denen wir hoffentlich nicht vier erstellen müssen. MGA73 17:40, 14. Okt. 2024 (CEST)Beantworten

Moin zusammen, ich bin absolut dagegen, weil ich entstehende Überprüfungsarbeit, Verwirrung mit Kategorien (vielleicht denke ich falsch, aber die automatische Kategorisierung durch die Vorlagen müsste überdacht werden?) und keinen wirklichen Vorteil sehe. Nur Arbeit. Außerdem müssten scheinbar neue Seiten erstellt werden (also noch mehr Lizenzvorlagen). Die Situation, wie sie aktuell ist, ist nach meiner Einschätzung völlig in Ordnung. Gestützt wird diese Ansicht meiner Meinung nach von m:Requests_for_comment/GFDL_to_CC_License_Migration_of_files. Grundsätzlich wäre ich schon dafür sich mal um die Lizenzvorlagen zu kümmern und bei der Gelegenheit könnte man ggf. auch über die "Dokumentation der Migration" nachdenken. Allerdings sehe ich aktuell nicht die Tatkraft dafür. Nur damit es nicht in Vergessenheit gerät, man müsste sich in dem Zuge auch noch um
kümmern. Viele Grüße, HirnSpukDisk19:53, 14. Okt. 2024 (CEST)Beantworten
Wir benötigen keine neuen Kategorien und die von Ihnen genannten Vorlagen werden nur benötigt, wenn Methode 1 verwendet wird. Hoffentlich brauchen wir nur Bild-GFDL-Neu. --MGA73 20:09, 14. Okt. 2024 (CEST)Beantworten

Hallo zusammen! Ich sehe hier und auf Meta vier Bedenken zu diesem Thema:

  1. Ist es legal?
  2. Lohnt sich der Aufwand?
  3. Werde ich (MGA73) Störungen verursachen, wenn ich ein Bot-Flag bekomme?
  4. Wird es in Zukunft viel Arbeit verursachen?

Die Antworten darauf sind:

  1. Ja. Die Neulizenzierung wurde 2009 durch eine zentrale Resolution der WMF durchgeführt. Um es den Wiederverwendern zu erleichtern, die Neulizenzierung zu erkennen, wurde ein Hinweis zu fast allen Dateien hinzugefügt. Dies wurde von vielen verschiedenen Benutzern über Hunderte von Wikis hinweg durchgeführt, und die meisten Dateien wurden vor August 2009 bearbeitet, aber viele wurden später bearbeitet.
  2. Ich denke schon. Der Zweck aller Wiki-Projekte ist es, Wissen zu teilen. Es ist einfacher, Dateien zu teilen, wenn sie eine CC-Lizenz haben. Wenn jemand keine Zeit dafür aufwenden möchte, muss er es nicht tun.
  3. Nein! Warum sollte ich? Ich bin ein vertrauenswürdiger Benutzer auf vielen Wikis und habe mit meinen Bots auf einer Reihe von Wikis einige Millionen Bearbeitungen vorgenommen.
  4. Nein. Ändern Sie einfach MediaWiki:Licenses und fügen Sie entweder “|migration=not-eligible” oder “-Neu” nach dem bestehenden “Bild-GFDL” hinzu. Das wird sicherstellen, dass alle zukünftigen Uploads als nicht für die Neulizenzierung geeignet markiert werden. In den letzten 5 Jahren wurden jedoch nur 5 Dateien als GFDL hochgeladen. Selbst wenn der Uploader „das alte GFDL“ wählt, wird es kein großes Problem sein.

Wenn jemand andere Bedenken hat, lassen Sie es mich wissen. Ich bin sicher, dass alles behoben werden kann. --MGA73 16:06, 6. Nov. 2024 (CET)Beantworten

Es gibt jetzt weniger als 900 Dateien in Kategorie:GFDL-Bild. Davon schätze ich, dass 50 nicht für die Neulizenzierung geeignet sind und die Lizenzvorlage geändert werden muss. Weitere 50 Dateien sind möglicherweise nicht geeignet und müssen überprüft werden. Daher ist der benötigte Arbeitsaufwand nicht sehr groß.
Ich habe die 2 Vorlagen Vorlage:Bild-GFDL-Neu und Vorlage:Cc-by-sa-3.0-migrated vorbereitet. Ich habe auch eine Kategorie erstellt, die je nach Bedarf entweder vorübergehend oder dauerhaft sein kann. In den Vorlagen gibt es einen kleinen Text, der entfernt werden kann, wenn das Update abgeschlossen ist.
Ich bin kein Muttersprachler, also fühl dich frei, den Text umzuformulieren und zu korrigieren. --MGA73 20:28, 1. Dez. 2024 (CET)Beantworten

Einige Dateien befinden sich jetzt in Kategorie:Doppellizenz und einige in Kategorie:GFDL-Bild-Neu. Der Rest (weniger als 750 in Kategorie:GFDL-Bild) ist meiner Meinung nach für eine Neulizenzierung geeignet. Ich habe jetzt Vorlage:Cc-by-sa-3.0-migrated zu Vorlage:Bild-GFDL und Vorlage:Bild-GFDL-self hinzugefügt. Also sollte jetzt alles korrekt sein. Wie oben erwähnt, können wir den größten Teil des kleinen Textes entfernen und Kategorie:GFDL-Bild-Neu kann ebenfalls gelöscht werden, sobald alle, die die Dateien überprüfen möchten, die Überprüfung abgeschlossen haben.

Wenn MediaWiki:Licenses aktualisiert wird, sodass Bild-GFDL in Bild-GFDL-Neu geändert wird, werden alle neuen Dateien mit der Lizenz GFDL als nicht für eine Neulizenzierung geeignet markiert. --MGA73 19:53, 6. Dez. 2024 (CET)Beantworten

Ich denke, dass die Neulizenzierung jetzt abgeschlossen ist. Wenn jemand möchte, können Dateien immer noch nach Commons verschoben oder gelöscht werden, wenn sie nicht verwendbar sind oder Lizenzprobleme haben. --MGA73 17:39, 14. Dez. 2024 (CET)Beantworten